Pilot service for Yubikey two-factor authentication

February 23, 2016

Is a local authentication service necessary/desirable?

So far in this project, we’ve used Yubikeys (in standard Yubico OTP mode, and in their factory-default condition) to provide second factor authentication for both ssh and Cosign logins. There are, of course, service-specific configurations necessary in order to arrange such authentication but – purely regarding the implementation of the back-end authentication of the one-time passwords produced by the Yubikeys – we initially used the Yubico ‘cloud’ authentication service to perform this.

By now, we have also set up a local authentication service (still only in prototype form: the service uses hand-configured machines), and – after suitably reconfiguring our test Yubikeys – have used that service to perform back-end authentication. (See the previous post Yubikey authentication servers for some more general background on local authentication servers. Specifically, also, see Yubico’s Installation notes for a YK-VAL server and Installation notes for a YK-KSM server.)

As further background, recall that, whether ‘remote’ or ‘local’, the authentication server essentially implements a web service: a one-time password is passed over HTTPS, and the authentication server responds with a ‘valid’ or’ ‘not valid’ response. As well as being present and available at all times, it’s obvious that – to provide a usable service – the authentication server needs to respond quickly to every request it receives.

It is also important to note that the authentication servers do not contain, nor do they need to be informed of, any user-specific data – e.g. usernames, UIDs, etc. They have a shared secret with each Yubikey – namely, the Yubikey’s AES encryption key – and they use that encryption key, in conjunction with the public id of the Yubikey, to determine whether the one-time password being presented on behalf of any Yubikey is or is not valid. All of the user-specific data – and, specifically, the association of Yubikey public id to username/UID – remains at the ‘client’ server end.

We now have to decide which of these two types of authentication service – the Yubico ‘cloud’ service, or an in-house local one – we want to use when we start to use Yubikeys in earnest for second factor authentication. It’s not an obvious choice, so let’s try to summarize the pros and cons:

Yubico ‘cloud’ authentication service


  • Requires registration, but is free of charge, and essentially simple to use.
  • Is pre-configured with the as-delivered public ids and AES keys of all Yubikeys – so all Yubikeys can authenticate against the service ‘out of the box.’
  • Overall, much less work to set up and use than would be a local service.


  • Not guaranteed to be permanent: Yubico could disappear as a company tomorrow and, whilst all Yubikeys would continue to work, the Yubico ‘cloud’ authentication service could disappear.

    (But we have no reason to believe the service will disappear.)

  • Not guaranteed to remain free of charge.

    (But we have no reason to believe the service will become chargeable.)

  • Requires the Yubico cloud servers to be on-line.
  • Requires a working network in order to reach the Yubico cloud servers.
  • Potentially at more risk of sluggish response than is a local service acting under more deterministic conditions and load.

    (But our limited experience so far has shown no such problems when using the ‘cloud’ service.)

  • Necessarily transmits both data and metadata to a third-party, namely Yubico.

    (However, note that we are already implicitly trusting that third-party by choosing to use their hardware devices.)

  • Although Yubico don’t get sent any actual user data per se, the key’s public ID is enough to allow both Yubico – as well as anyone who can see their traffic or database – to track the user, and to correlate their activity over time.

    (However, note that the traffic will be encrypted over HTTPS and, if any other than Yubico has access to Yubico’s database, then a more serious security breach has probably occurred – see the following point.)

  • Yubico’s authentication servers present an attractive target for criminals. If those servers were compromised, and (public id, AES key) pairs stolen – and nobody noticed (or was suitably informed) that this had happened – then Yubikeys using the same (public id, AES key) pairs could be cloned. How useful such keys would be to a criminal would depend on where those keys were being used: information about authentication services for which any key is ‘good’ is not part of the key material, but it is possible that additional metadata – which in principle could be also stolen from Yubico – could give a clue.

Local authentication service


  • Maintains all server dependencies ‘in-house.’
  • Maintains all data and metadata ‘in-house.’
  • Does not require a working external network in order to provide authentication.


In our (i.e. the School of Informatics) environment, setting up a robust local Yubikey authentication service would require us to have the initial configuration and subsequent maintenance of both YK-VAL and YK-KSM servers managed via LCFG control, as far as possible. And, likewise, to similarly automate the maintenance of the keying data (public ids, AES keys) held by those servers. (As a detail: such data is held in PostgreSQL databases on out prototype YK-VAL and YK-KSM servers.)

The question is: what approach should we take here? The amount of work in setting up a local authentication service is definitely not trivial – so we need to decide if we want to (or, perhaps, need to) do it. This is really a policy question, but it also depends on what kinds of resources we might be planning to hide behind second factor authentication: we must avoid the possibility of having access to any critical resource at risk of being hampered by problems with the external network! (An example might be a resource, or information, to which we need access in order to fix a particular problem with the network. That is: we need to consider the possibility of ‘chicken and egg’ problems.)

Comments on this post are invited from anybody with an interest or an opinion; any such comments would be welcome. Thanks.

November 17, 2015

Yubikey authentication servers

As mentioned way back in the two posts What is a Yubikey, and how does it work? and Yubikey authentication, the encrypted payload generated by a Yubikey needs to be authenticated (or not!) by an authentication server.

The authentication server decrypts the payload generated by the Yubikey (both the Yubikey and the server have knowledge of the (symmetric) encryption key in use by the Yubikey), and replies with an ‘OK’ or ‘Err’ depending on whether or not the payload represents a valid OTP: the crucial thing is that the integer contained in the payload is larger than any yet seen from the Yubikey in question.

Up till now, we’ve been using Yubico’s free Yubicloud ‘cloud authentication’ service. The advantage of that is that it more-or-less just works ‘out of the box’: the symmetric encryption key used by any factory-fresh Yubikey is already known to Yubico’s authentication servers, so nothing more needs to be done.

Generally, we could continue to use the cloud authentication service. However, what happens if we have arrange to have access to some critical resources (or documentation) mediated via Yubikeys, and we lose all Internet connectivity to the outside world? In that case, we couldn’t authenticate, and so we wouldn’t have access to the resources – which might present a nasty problem …

So: it seems like we should set up our own authentication servers. We will, of course, want these to be robust, and to not present a single point of failure. So, we’ll need:

  1. more than one authentication server;
  2. replication between all such servers, in order to keep the ‘integer last seen’ per key data correct; and
  3. all such servers to be suitably hardened: the symmetric encryption keys which they store are critical and secret pieces of information.

Note that once we start using our own authentication server, we will need to reset the symmetric encryption keys in use on all Yubikeys so that we our authentication server has knowledge of them. Yubico provide tools to do that, namely their ‘Personalization Tools.’

Yubico make available a reference implementation for an authentication server. In fact, their implementation is composed of two servers: the ‘validation server’ (YK-VAL) front end, and the ‘key storage module’ (YK-KSM) back end. It’s the latter which holds the shared secrets, and which must therefore be handled in as secure a manner as possible.

Here’s a collection of relevant links containing more information:

  1. Yubikey validation server software.
    The specific Yubico implementations are:

  2. YubiKey Personalization Tool

A final note regarding replication/synchronization: the Yubico YK-VAL servers incorporate a synchronization protocol so that, if multiple such servers are in use at a site, the ‘integer last seen’ data for any particular Yubikey is correctly updated on all YK-VAL servers. But there is no such synchronization for YK-KSM servers: for those, the (essentially static) AES key belonging to each Yubikey is expected to be added to each YK-KSM at the time of the initialization of the YK-KSM server, or at the time of the addition of the Yubikey in question.

To guard against YK-KSM servers getting out of sync, Yubico provides a YK-KSM Synchronization Monitor tool which compares SHA-1 hashes: running that tool via a cron job should at least flag up a synchronization problem, which can then be dealt with.

Theme: Rubric.