The Yubikey

Picture of Yubikey

Some time ago Yubico were kind enough to send me an evaluation copy of their Yubikey device. I’ve finally got around to reviewing it and making deployment plans for buying some more. Above is a picture of my Yubikey on the keyboard of my Thinkpad T61 for scale. The newer keys apparently have a different color in the center of the circular press area and also can be purchased in white plastic.

The Yubikey is a USB security token from Yubico [1]. It is a use-based token that connects via the USB keyboard interface (see my previous post for a description of the various types of token [2]). The Yubikey is the only device I know of which uses the USB keyboard interface, it seems that this is an innovation that they invented. You can see in the above picture that the Yubikey skips the metal that is used to surround most USB devices, this probably fails to meet some part of the USB specification but does allow them to make the key less than half as thick as it might otherwise be. Mechanically it seems quite solid.

The Yubikey is affordable, unlike some token vendors who don’t even advertise prices (if you need to ask then you can’t afford it) and they have an online sales site. $US25 for a single key and discounts start when you buy 10. As it seems quite likely that someone who wants such a token will want at least two of them for different authentication domains, different users in one home, or as a backup in case one is lost or broken (although my experiments have shown that Yubikeys are very hardy and will not break easily). The discount rate of $20 will apply if you can find four friends who want to use them (assuming two each), or if you support several relatives (as I do). The next discount rate of $15 applies when you order 100 units, and they advise that customers contact their sales department directly if purchasing more than 500 units – so it seems likely that a further discount could be arranged when buying more than 500 units. They accept payment via Paypal as well as credit cards. It seems to me that any Linux Users Group could easily arrange an order for 100 units (that would be 10 people with similar needs to me) and a larger LUG could possibly arrange an order of more than 500 units for a better discount. If an order of 500 can’t be arranged then an order of 200 would be a good thing to get half black keys and half white ones – you can only buy a pack of 100 in a single color.

There is a WordPress plugin to use Yubikey authentication [3]. It works, but I would be happier if it had an option to accept a Yubikey OR a password (currently it demands both a Yubikey AND a password). I know that this is less secure, but I believe that it’s adequate for an account that doesn’t have administrative rights.

To operate the Yubikey you just insert it into a USB slot and press the button to have it enter the pass code via the USB keyboard interface. The pass code has a prefix that can be used to identify the user so it can replace both the user-name and password fields – of course it is technically possible to use one Yubikey for authentication with multiple accounts in which case a user-name would be required. Pressing the Yubikey button causes the pass code to be inserted along with the ENTER key, this can take a little getting used to as a slow web site combined with a habit of pressing ENTER can result in a failed login (at least this has happened to me with Konqueror).

As the Yubikey is use-based, it needs a server to track the usage count of each key. Yubico provides source to the server software as well as having their own server available on the net – obviously it might be a bad idea to use the Yubico server for remote root access to a server, but for blog posting that is a viable option and saves some effort.

If you have multiple sites that may be disconnected then you will either need multiple Yubikeys (at a cost of $20 or $15 each) or you will need to have one Yubikey work with multiple servers. Supporting a single key with multiple authentication servers means that MITM attacks become possible.

The full source to the Yubikey utilities is available under the new BSD license. In Debian the base functionality of talking to the Yubikey is packaged as libyubikey0 and libyubikey-dev, the server (for validating Yubi requests via HTTP) is packaged as yubikey-server-c, and the utility for changing the AES key to use your own authentication server is packaged as yubikey-personalization – thanks Tollef Fog Heen for packaging all this!

The YubiPAM project (a PAM module for Yubikey) is licensed under the GPL [4]. It would be good if this could be packaged for Debian (unfortunately I don’t have time to adopt more packages at the moment).

There is a new model of Yubikey that has RFID support. They suggest using it for public transport systems where RFID could be used for boarding and the core Yubikey OTP functionality could be used for purchasing tickets. I don’t think it’s very interesting for typical hobbyist and sysadmin work, but RFID experts such as Jonathan Oxer might disagree with me on this issue.

10 comments to The Yubikey

  • Erik Johansson

    It has worked perfectly since 2009 for me, it’s really nice to have them instead of password in non computer related businesses. The one who holds the Yubi “has the password”, makes it really easy to get outside help and be a bit flexible with root access.


  • Barak A. Pearlmutter

    i don’t understand. isn’t this thing vulnerable to eavesdropping and replaying? even if *it* has a counter which changes etc, the things it is talking to (web sites) can’t know that some generated string is being reused. and it doesn’t even have a clock, so these things can be old.

  • Just want to point out that the YubiPAM module authenticates *locally*, meaning you have to save the AES key of the device somewhere in /etc. The pam_yubico module uses Yubico’s auth servers for authentication. Don’t know for sure, but maybe the last is packaged for debian?

  • etbe

    Barak: If you use it to talk to one server only (which is not an uncommon case) then the server can store the last counter value. If you use it to talk to multiple servers then they can all use the one back-end authentication server which stores the last counter value. If you want to use it to talk to multiple servers that are independent then you have a potential problem, a Yubi code from one server can be used on another. But that only happens IF the attacker knows the other server and knows all other data. If logging in requires a regular password and a Yubi code then an attacker who sniffs my login to server A will not be able to re-use the Yubi code to login to server B which is disconnected from server A.

    maxim: Thanks for the information on the relative merits of those PAM modules. I can imagine use cases where each option is ideal. Also a quick aptitude search shows that neither PAM module is in Testing.

  • My work recently rolled these out, however I am yet to actually test it. I will get around to it, just happy using the one time password setup we have via a bastion type linux host. It works and does what I want. The newer solution was implemented to help those less technical get VPN type access into the corporate environment.

  • Barak A. Pearlmutter

    So basically this gizmo is a (pseudorandom) one-time pad, and other mechanisms need to be used to ensure that reuse is detected and rejected. This requires coordination between servers if a single device is to be used with multiple servers. One compromised server could do a man-in-the-middle attack on login to another server. Or, a man-in-the-middle attack during login to one server, which kills the connection before that server actually sees the string or bumps the centralized count, could be used by the attacker to either log in to that server later or even to another server.

    This sounds a bit vulnerable to me.

    (Obviously two-factor authentication, e.g., an additional per-server password, would make such attacks trickier, although perhaps not impossible. Additional passwords, however, also make the device itself of much less utility, since the password alone provides reasonable security.)

    Also, from a practical perspective, couldn’t similar functionality be provided by a USB storage dongle holding some secret information (long one-time pad) together with some program to trickle it out on demand in the right way?

  • etbe: You’re welcome :) I was asking because I am the maintainer for some of these packages for Fedora, and I know for sure we have pam_yubico, as well as ykpers and libyubikey in Fedora. I’m considering packaging YubiPAM, but I lack time and development seems a bit slow on it. Oh, I’m having a hard time with your spam stuff. OpenID refuses to work and keeps calling me a spambot :)

    Barak: pam_usb does that, sort of. That project has pretty slow development though. I even think pam_usb got dropped from Fedora for it. The limitation of such a setup would be though, that it would not work – or at least: not easily – over a network. Yubikeys are designed to work over the network. Mitm attacks are an issue for a lot of other network authentication mechanisms too. I a bit short on time, but I invite you to read a bit in the docs on the Yubico website. It’s not as simple as you make it sound.

  • etbe

    Michael: You can do equivalent OTP calculations on a laptop or PDA but it takes more typing and requires more things to carry around.

    Barak: It’s not a OTP. If you have server A and server B accepting the same login credentials then if you login to server A which has been compromised then that server could instead of authenticating you use the credentials you supplied to login to server B. This applies for all methods of authentication. If server A authenticates you and if the authentication server has not been compromised then server B will not accept a login with the same code from the Yubikey.

    Sure everything the Yubikey does could be done with some software and a USB storage device. The point of the Yubikey is that it’s small enough and compatible enough that you can carry it everywhere.

    Maxim: If you are accused of being a “spambot” then you missed the arithmetic question. I don’t like the way it handles errors in that regard and plan to change it.

  • Barak A. Pearlmutter

    etbe: “If you have server A and server B accepting the same login credentials then if you login to server A which has been compromised then that server could instead of authenticating you use the credentials you supplied to login to server B. This applies for all methods of authentication.” That is not true. For instance, challenge/response authentication, where the challenge starts with the name of the server, would not be vulnerable to this.

  • etbe

    Barak: Good point.

    I should have said that the principle in question applies for all methods of communication other than some of those which rely on a challenge from the server.

    Some challenge-response systems won’t be safe against such an attack either, if you don’t have public key encryption and you have the same algorithm and data set used by all servers then any compromised server should be able to gain credentials for others. The problem is that doing this properly requires more compute power on the client side – which can be a problem for a smart-card or other limited device.

    Maxim: I’ve replaced the “spambot” message with one that makes things easier for humans.