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:
- more than one authentication server;
- replication between all such servers, in order to keep the ‘integer last seen’ per key data correct; and
- 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:
- Yubikey validation server software.
The specific Yubico implementations are: - 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.