After my
first post about smartcards under Linux, I thought I would share some information I ve been gathering.
This post is already huge, so I am not going to dive into much specific commands, but I am linking to many sources with detailed instructions.
I ve reviewed several types of cards. For this review, I will focus on the OpenPGP card and the Yubikey NEO, since the Cardomatic Smartcard-HSM is not supported by the gpg version in Jessie.
Both cards are produced by people with strong support for the Free Software ecosystem and have strong cross-platform support with source code.
OpenPGP card: Basics with GnuPG
The
OpenPGP card is well-known as one of the first smart cards to work well on Linux. It is a single-application card focused on use with GPG. Generally speaking, by the way, you want GPG2 for use with smartcards.
Basically, this card contains three slots: decryption, signing, and authentication slots. The concept is that the private key portions of the keys used for these items are stored only on the card, can never be extracted from the card, and the cryptographic operations are performed on the card. There is more information in my original post. In a fairly rare move for smartcards, this card supports 4096-byte RSA keys; most are restricted to 2048-byte keys.
The FSF Europe hands these out to people and has a
lot of good information about them online, including some
HOWTOs. The official
GnuPG smart card howto is 10 years old, and although it has some good background, I d suggest using the FSFE instructions instead.
As you ll see in a bit, most of this information also pertains to the OpenPGP mode of the Yubikey Neo.
OpenPGP card: Other uses
Of course, this is already pretty great to enhance your GPG security, but there s a lot more that you can do with this card to add two-factor authentication (2FA) to a lot of other areas. Here are some pointers:
OpenPGP card: remote authentication with ssh
You can store the private part of your ssh key on the card. Traditionally, this was only done by
using the ssh agent emulation mode of gnupg-agent. This is still possible, of course.
Now, however, the OpenSC project now
supports the OpenPGP card as a PKCS#11 and PKCS#15 card, which means it works natively with ssh-agent as well. Try just
ssh-add -s /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so if you ve put a key in the auth slot with GPG. ssh-add -L will list its fingerprint for insertion into authorized_keys. Very simple!
As an aside: Comments that you need scute for PKCS#11 support are now outdated. I do not recommend scute. It is quite buggy.
OpenPGP card: local authentication with PAM
You can authenticate logins to a local machine by
using the card with libpam-poldi here are
some instructions.
Between the use with ssh and the use with PAM, we have now covered 2FA for both local and remote use in Unix environments.
OpenPGP card: use on Windows
Let s move on to Windows environments. The standard suggestion here seems to be the
mysmartlogon OpenPGP mini-driver. It works with some sort of Windows CA system, or the local accounts using
EIDAuthenticate. I have not yet tried this.
OpenPGP card: Use with X.509 or Windows Active Directory
You can use the card in X.509 mode via these
gpgsm instructions, which apparently also work with Windows Active Directory in some fashion.
You can also use it with web browsers to present a certificate from a client for client authentication. For example, here are
OpenSC instructions for Firefox.
OpenPGP card: Use with OpenVPN
Via the PKCS#11 mode, this card should be usable to authenticate a client to OpenVPN. See the
official OpenVPN HOWTO or
these other instructions for more.
OpenPGP card: a note on PKCS#11 and PKCS#15 support
You ll want to install the opensc-pkcs11 package, and then give the path /usr/lib/x86_64-linux-gnu/pkcs11/opensc-pkcs11.so whenever something needs the PKCS#11 library. There seem to be some locking/contention issues between GPG2 and OpenSC, however. Usually killing pcscd and scdaemon will resolve this.
I would recommend doing manipulation operations (setting PINs, generating or uploading keys, etc.) via GPG2 only. Use the PKCS#11 tools only to access.
OpenPGP card: further reading
Kernel Concepts also has some nice readers; you can get this card in a small USB form-factor by getting the mini-card and the Gemalto reader.
Yubikey Neo Introduction
The Yubikey Neo is a fascinating device. It is a small USB and NFC device, a little smaller than your average USB drive. It is a multi-application device that actually has six distinct modes:
- OpenPGP JavaCard Applet (pc/sc-compatible)
- Personal Identity Verification [PIV] (pc/sc-compatible, PKCS#11-compatible in Windows and OpenSC)
- Yubico HOTP, via your own auth server or Yubico s
- OATH, with its two sub-modes:
- OATH TOTP, with a mobile or desktop helper app (drop-in for Google Authenticator
- OATH HOTP
- Challenge-response mode
- U2F (Universal 2nd Factor) with Chrome
There is a ton to digest with this device.
Yubikey Neo Basics
By default, the Yubikey Neo is locked to only a subset of its features. Using the yubikey-personalization tool (you ll need the version in stretch; jessie is too old), you can use
ykpersonalize -m86 to unlock the full possibilities of the card. Run that command, then unplug and replug the device.
It will present itself as a USB keyboard as well as a PC/SC-compatible card reader. It has a capacitive button, which is used to have it generate keystrokes to input validation information for HOTP or HMAC validation. It has two slots that can be configured with HMAC and HOTP; a short button press selects the default slot #1 and a long press selects slot #2.
But before we get into that, let s step back at some basics.
opensc-tool list-algorithms claims this card supports RSA with 1024, 2048, and 3072 sizes, and EC with 256 and 384-bit sizes. I haven t personally verified anything other than RSA-2048 though.
Yubikey Neo: OpenPGP support
In this mode, the card is mostly compatible with the physical OpenPGP card. I say mostly because there are a few protocol differences I ll get into later. It is also limited to 2048-byte keys.
Support for this is built into GnuPG and the GnuPG features described above all work fine.
In this mode, it uses firmware from the
Yubico fork of the
JavaCard OpenPGP Card applet. There are
Yubico-specific tutorials available, but again, most of the general GPG stuff applies.
You can use gnupg-agent to use the card with SSH as before. However, due to some incompatibilities, the OpenPGP applet on this card cannot be used as a PKCS#11 card with either scute or OpenSC. That is not exactly a huge problem, however, as the card has another applet (PIV) that is compatible with OpenSC and so this still provides an avenue for SSH, OpenVPN, Mozilla, etc.
It should be noted that the OpenPGP applet on this card can also be used with NFC on Android with the
OpenKeychain app. Together with
pass (or its Windows, Mac, or phone ports), this makes a nicely secure system for storing passwords.
Yubikey Neo: PKCS#11 with the PIV applet
There is also support for the PIV standard on the Yubikey Neo. This is supported by default on Linux (via OpenSC) and Windows and provides a PKCS#11-compabible store. It should, therefore, be compatible with ssh-agent, OpenVPN, Active Directory, and all the other OpenPGP card features described above. The only difference is that it uses storage separate from the OpenPGP applet.
You will need one of the
Yubico PIV tools to configure the key for it; in Debian, the yubico-piv-tool from stretch does this.
Here are some instructions on using the Yubikey Neo in PIV mode:
A final note: for security, it s important to
change the management key and PINs before deploying the PIV mode.
I couldn t get this to work with Firefox, but it worked pretty much everywhere else.
Yubikey Neo: HOTP authentication
This is the default mode for your Yubikey; all other modes require enabling with ykpersonalize. In this mode, a 128-bit AES key stored on the Yubikey is used to generate one-time passwords (OTP). (This key was shared in advance with the authentication server.) A typical pattern would be for three prompts: username, password, and
Yubikey HOTP. The user clicks in the Yubikey HOTP field, touches the Yubikey, and their one-time token is pasted in.
In the background, the service being authenticated to contacts an authentication server. This authentication server can be either your own (there are several open source implementations in Debian) or the free
Yubicloud.
Either way, the server decrypts the encrypted part of the OTP, performs validity checks (making sure that the counter is larger than any counter it s seen before, etc) and returns success or failure back to the service demanding authentication.
The first few characters of the posted auth contain the unencrypted key ID, and thus it can also be used to provide username if desired.
Yubico has provided quite a few
integrations and
libraries for this mode. A few highlights:
You can also find some
details on the OTP mode. Here s
another writeup.
This mode is simple to implement, but it has a few downsides. One is that it is specific to the Yubico line of products, and thus has a vendor lock-in factor. Another is the dependence on the authentication server; this creates a potential single point of failure and can be undesireable in some circumtances.
Yubikey Neo: OATH and HOTP and TOTP
First, a quick note: OATH and OAuth are not the same. OATH is an authentication protocol, and OAuth is an authorization protocol. Now then
Like Yubikey HOTP, OATH (both HOTP and TOTP) modes rely on a pre-shared key. (See details in the
Yubico article.) Let s talk about TOTP first. With TOTP, there is a pre-shared secret with each service. Each time you authenticate to that service, your TOTP generator combines the timestamp with the shared secret using a HMAC algorithm and produces a OTP that changes every 30 seconds. Google Authenticator is a common example of this protocol, and this is a drop-in replacement for it. Gandi has a
nice description of it that includes links to software-only solutions on various platforms as well.
With the Yubikey, the shared secrets are stored on the card and processed within it. You cannot extract the shared secret from the Yubikey. Of course, if someone obtains physical access to your Yubikey they could use the shared secret stored on it, but there is no way they can steal the shared secret via software, even by compromising your PC or phone.
Since the Yubikey does not have a built-in clock, TOTP operations cannot be completed solely on the card. You can use a
PC-based app or the
Android application (
Play store link) with NFC to store secrets on the device and generate your TOTP codes. Command-line users can also use the yubikey-totp tool in the
python-yubico package.
OATH can also use HOTP. With HOTP, an authentication counter is used instead of a clock. This means that HOTP passwords can be generated entirely within the Yubikey. You can use ykpersonalize to configure either slot 1 or 2 for this mode, but one downside is that it can really only be used with one service per slot.
OATH support is all over the place; for instance, there s libpam-oath from the
OATH toolkit for Linux platforms. (Some
more instructions on this exist.)
Note: There is another
tool from Yubico (not in Debian) that can apparently store multiple TOTP and HOTP codes in the Yubikey, although ykpersonalize and other documentation cannot. It is therefore unclear to me if multiple HOTP codes are supported, and how..
Yubikey Neo: Challenge-Response Mode
This can be useful for doing offline authentication, and is similar to OATH-HOTP in a sense. There is a shared secret to start with, and the service trying to authenticate sends a challenge to the token, which must supply an appropriate response. This makes it only suitable for local authentication, but means it can be done fairly automatically and optionally does not even require a button press.
To muddy the waters a bit, it supports both Yubikey OTP and HMAC-SHA1 challenge-response modes. I do not really know the difference. However, it is worth noting that libpam-yubico
works with HMAC-SHA1 mode. This makes it suitable, for instance, for logon passwords.
Yubikey Neo: U2F
U2F is a new protocol for web-based apps. Yubico has
some information, but since it is only supported in Chrome, it is not of interest to me right now.
Yubikey Neo: Further resources
Yubico has a lot of
documentation, and in particular a
technical manual that is actually fairly detailed.
Closing comments
Do not think a hardware security token is a panacea. It is best used as part of a multi-factor authentication system; you don t want a lost token itself to lead to a breach, just as you don t want a compromised password due to a keylogger to lead to a breach.
These things won t prevent someone that has compromised your PC from abusing your existing ssh session (or even from establishing new ssh sessions from your PC, once you ve unlocked the token with the passphrase). What it will do is prevent them from stealing your ssh private key and using it on a different PC. It won t prevent someone from obtaining a copy of things you decrypt on a PC using the Yubikey, but it will prevent them from decrypting other things that used that private key. Hopefully that makes sense.
One also has to consider the security of the hardware. On that point, I am pretty well satisfied with the Yubikey; large parts of it are open source, and they have put a lot of effort into hardening the hardware. It seems pretty much impervious to non-government actors, which is about the best guarantee a person can get about anything these days.
I hope this guide has been helpful.
What happened in the reproducible
builds effort this week:
Toolchain fixes
QEMU 
Maybe setting up a BOF would also be a good idea.
So, everybody knows that WPS (Wi-Fi Protected Setup) is broken. But sometimes, you don't own the access point, and you'd just want the wireless to work. That happens for example when you're a guest in some place using an Orange Livebox and you don't have the WPA passphrase (usually because it's written somewhere you don't have access too, or because someone forgot to tell you).
Liveboxes WPS is the press button thing: you press a button on the front for one second, then any device can connect in the next two minutes. That works fine with Android devices, for example, but it didn't work with my laptop and NetworkManager, which doesn't support WPS at all.
Fortunately, the underlying piece of software (wpa_supplicant) does support WPS, and even the push button style. And you can nicely ask it to reveal the passphrase to you with the following trick.
The problem
One problem to solve when doing web authentication has always been one
identity provider, so you don't have to remember which username (or
email address) you used for that bugtracker you used three years ago
or that website. And tie it to one login ideally. Five years ago this
problem seemed to be basically solved. There was OpenID and while it
may not have been great it worked. You could have your own provider,
your institution (university, company, foss project, ..) could have
one and you could use your university-provided ID for all university
stuff.
Today's state
Looking at the problem again today and the situation seems to have
changed. To the worse. A lot. People are actively removing OpenID
support. There seemed to be a replacement with, at least, proper
design goals: Mozilla's persona. However this seems to be a dead end,
no-one (almost) actually supports it.
Then there is what people call OAuth2. However there does not seem to
be such a thing as OAuth2 at all, at least not for logging into
websites. So for example
Since ever the Kobo firmwares also allowed downloading of a bunch of dictionaries, most of which I don t need. As I am fluent in most languages I read and write, the only real dictionary I would like to see is a Japanese-English (I don t dare asking for a Japanese-German). Unfortunately, Kobo never shipped one. OTOH, starting with firmware 3.16.10 they ships two different English-Japanese dictionaries, one excellent Japanese-Japanese dictionary, but not one Japanese-English. So I took the liberty to write a script that allows everyone to enrich the shipped Japanese-Japanese dictionary with English definitions.
Till now I have used 
There is only one caveat: Syncing with Kobo will re-download the original dictionary and overwrite the enhanced one. There is at least one solution here, which I am employing, see 
It's been a while since I talked about Ceilometer and its companions, so I
thought I'd go ahead and write a bit about what's going on this side of
OpenStack. I'm not going to cover new features and fancy stuff today, but
rather a shallow overview of the new project processes we initiated.
Ceilometer growing
Ceilometer development activity
