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

Pros

  • 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.

Cons

  • 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

Pros

  • 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.

Cons

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.

February 19, 2016

Using the ykpersonalize command to reconfigure the Yubikey

Here’s how to program slot 2 of the Yubikey, and then swap slots 1 and 2, using the ykpersonalize command:

Danger, Will Robinson!

As delivered, the configuration in slot 1 of the Yubikey allows the Yubikey to authenticate against the Yubico cloud authentication service. Once deleted from the Yubikey, it cannot be recreated as was. Specifically, one cannot recreate a public id (and corresponding AES key) beginning with Modhex cc, and upload that pair to the Yubico cloud.

Our aim – for now, anyway – is to completely preserve the as-delivered configuration of slot 1 – not to delete it! – and to save it in slot 2.

Please proceed with the appropriate amount of caution!

We first need to choose a public id, in Modhex; as well as a private id, in hex. (One way to have suitable values these generated automatically is via the ‘Cross-platform Yubikey Personalization Tool’ – equally, randomly-chosen strings should be good.)

Notes:

  1. As in the previous post Using the Cross-platform Yubikey Personalization Tool, we note that, for compatibility with the Yubico cloud authentication service, the public id we choose should start with the two characters Modhex vv.
  2. The ‘private id’ (a.k.a. ‘uid’) is not significant, and – when using Yubikeys in standard Yubico OTP mode, as we are – plays no role in the authentication process. It might just as well be set to all zeroes.

Then, either specify an explicit AES key:

[host]user: ykpersonalize -2 -a12c676fa8f906cf9505122ac4d5ef058 -o fixed=vvbhchbhchcb -o uid=d17bb68be71e \
-o -static-ticket -o -strong-pw1 -o -strong-pw2 -o -man-update
Firmware version 2.4.3 Touch level 2307 Program sequence 9

Configuration data to be written to key configuration 2:

fixed: m:vvbhchbhchc
uid: d17bb68be71e
key: h:12c676fa8f906cf9505122ac4d5ef058
acc_code: h:000000000000
ticket_flags: APPEND_CR
config_flags: 
extended_flags: 

Commit? (y/n) [n]: y

or let the interface generate a random AES key:

[host]user: ykpersonalize -2 -o fixed=vvbhchbhchc -o uid=d17bb68be71e \
-o -static-ticket -o -strong-pw1 -o -strong-pw2 -o -man-update
Firmware version 2.4.3 Touch level 2307 Program sequence 9

Configuration data to be written to key configuration 2:

fixed: m:vvbhchbhchc
uid: d17bb68be71e
key: h:ac22d24832fd612a82b3ef4505a02838
acc_code: h:000000000000
ticket_flags: APPEND_CR
config_flags: 
extended_flags: 

Commit? (y/n) [n]: y

(Comment: the command line switches -o -static-ticket -o -strong-pw1 -o -strong-pw2 -o -man-update are ugly, but unfortunately very necessary here. It turns that ykpersonalize asserts those options by default for the programming of slot 2 (but not slot 1) – but we definitely don’t want them when programming slot 1 in Yubico OTP mode, so we need explicitly to deassert them with a ‘-‘ sign. If you’re now wondering why we didn’t swap the slots first, and then program slot 1: depending on firmware versions, you don’t necessarily seem to be able to swap slots 1 and 2, if slot 2 is currently unconfigured …)

To now swap the contents of slots 1 and 2:

[host]user: ykpersonalize -x
Firmware version 2.4.3 Touch level 2307 Program sequence 8

Configuration in slot 1 and 2 will be swapped

Commit? (y/n) [n]: y

Using the ‘Cross-platform Yubikey Personalization Tool’ to reconfigure the Yubikey

Here’s how to program slot 2 of the Yubikey, and then swap slots 1 and 2, using the Cross-platform Yubikey Personalization Tool:

Danger, Will Robinson!

As delivered, the configuration in slot 1 of the Yubikey allows the Yubikey to authenticate against the Yubico cloud authentication service. Once deleted from the Yubikey, it cannot be recreated as was. Specifically, one cannot recreate a public id (and corresponding AES key) beginning with Modhex cc, and upload that pair to the Yubico cloud.

Our aim – for now, anyway – is to completely preserve the as-delivered configuration of slot 1 – not to delete it! – and to save it in slot 2.

Please proceed with the appropriate amount of caution!

Start the tool: yubikey-personalization-gui&

yubikey-personalization-gui

Select Yubico OTP Mode, then Quick

yubikey-personalization-gui - OTP Quick configuration

We’ll just accept whatever randomized values are suggested here – though feel free to Regenerate.

(By the way: there is an advantage to using a public id which starts with Modhex vv (i.e. Hex FF) as this page produces, rather than a completely random public id (as is available via the Advanced configuration page): for user-generated keys, only those starting with Modhex vv can be uploaded to the Yubico cloud authentication service.)

Select Configuration Slot 2

Unhide values, and take a note of the Public Identity, the Private Identity, and the Secret Key.

(Comment: The ‘Private Identity’ is not significant, and – when using Yubikeys in standard Yubico OTP mode, as we are – plays no role in the authentication process. It might just as well be set to all zeroes.)

Select Write Configuration:

The configuration will be written to the key, and also to a log file which you will be asked to nominate.

To now swap the contents of Slots 1 and 2:

Select Settings

yubikey-personalization-gui - Settings

Select Update Settings...

yubikey-personalization-gui - Settings

Select Swap

Now, try using your Yubikey.

You should find that Slot 1 emits a OTP corresponding to the new public id just defined, and Slot 2 emits an OTP corresponding to the pre-existing factory-defined public id.

Reconfiguring/personalizing the Yubikey

As mentioned in the earlier post What is a Yubikey, and how does it work? :

A Yubikey is a small device [which], when plugged into the USB port of any PC, presents itself as a standard USB HID keyboard and, when the capacitive ‘button’ on the Yubikey is pressed, emits a character string which implements a one-time password (OTP).

As delivered, the Yubikey emits its single factory-configured OTP when its button is pressed for about 0.5s or so. But in fact, the Yubikey has two configuration ‘slots’, each of which can be programmed to emit a one-time password. If the second slot is configured, the Yubikey acts as follows:

  • Short press (0.3 – 1.5 seconds) and release: OTP from configuration slot 1 is emitted
  • Short press (2.5 – 5 seconds) and release: OTP from configuration slot 2 is emitted

Each slot can be reprogrammed, and the contents of the two slots can be swapped. It’s very useful to keep the contents of the ‘as-delivered’ slot exactly as they are: the public id and AES key contained therein are already factory-registered on Yubico’s cloud authentication service, so the key as delivered is good for authentication against that service. However, for our testing we also want to set up our own authentication service. To do so, our plan is to reprogram the second slot with an appropriate internal public id and AES key, and then swap slots 1 and 2 so that our internal OTP is the default choice. This means we can revert to the as-delivered configuration of the Yubikey later on, should we choose to.

For Yubikey programming and reconfiguration, Yubico makes two programming utilities available:

January 29, 2016

Modified Hexadecimal encoding – a.k.a. ‘Modhex’ – and Yubikey public id’s

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 4:42 pm
Tags: ,

Recall from an earlier post What is a Yubikey, and how does it work? that, in its standard mode and using its default settings, a Yubikey produces a 44 character text string in which the first 12 characters are a public id string, and the final 32 characters are an AES-encrypted OTP. As an example:

fifjgjgkhchbirdrfdnlnghhfgrtnnlgedjlftrbdeut
<-12 chars-><---------- 32 chars ---------->

where the public id of the Yubikey in question is fifjgjgkhchb.

What are the characters here? And what do they represent?

Well: the Yubikey is ‘pretending to be’ a USB keyboard. Keyboards send their keystrokes via a sequence of ‘scan codes’, rather than actual characters; the translation from scan codes to character representation is done by the operating system. For the Yubikey to work, it is critical that the same character representation is generated whether the Yubikey is inserted into a UK or US computer with a QWERTY keyboard layout, a French computer with an AZERTY layout, or a German keyboard with a QWERTZ layout.

To achieve this, the Modified Hexadecimal encoding – a.k.a. ‘Modhex’ – was devised by Yubico. The idea is to use a set of alpha characters which are known to be represented by the same scan codes on all of the above keyboards, and to map those onto the normal hexadecimal characters which we want to encode. The mapping is as follows:

Hex 0 1 2 3 4 5 6 7 8 9 A B C D E F
Modhex c b d e f g h i j k l n r t u v

We can see, for example, that the Yubikey public id fifjgjgkhchb above (which is in Modhex) in fact translates to the hex sequence 474858596061.

Normally all this is transparent, and all just works. However, for administration purposes, it has an important use in the identification of the public id string of any particular Yubikey from the serial number (physically stamped on the key both as a decimal string, and also as a QR code) of the Yubikey.

Example: suppose our Yubikey is stamped with the physical serial number ‘0219 8612’. Now, 02198612 (dec) = 218C584 (hex). Padding that out to 12 characters, we get 000000218C54 (hex) = ccccccdbjrgf (modhex). And ccccccdbjrgf turns out to be the factory-defined public id of the Yubikey in question.

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.

November 10, 2015

A test Cosign service using Yubikey two-factor authentication

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 7:08 pm
Tags: ,

The previous posts regarding Cosign and Yubikey two-factor authentication are intended to record the investigations and thought processes which have taken place to date during the course of this project. As such, they might seem rather theoretical – but they’re a record for us and, with luck, they might also be of use to other people thinking of implementing the same thing.

However: in practice, where are we with this project right now?

At present:

  1. We have a working test Cosign server, customized with the standard Informatics look-and-feel, which is configured to implement two-factor authentication; the two factors being Kerberos username/password, and Yubikey OTP.
  2. We have a working test Cosign client website configured to authenticate against the two-factor server.
  3. Almost all of the configuration for both server and client has been tidily included in the corresponding LCFG profiles, and almost all of the necessary s/w has been packaged to our usual standards. (In that respect, some work remains to be done: for example the building and installation of the ‘universal Cosign PAM factor adaptor’ needs to be integrated into our ‘normal’ Cosign packages.)
  4. Two test users (currently, we have only two test Yubikeys available) have been verifying the service, with good results. We find that the two-factor authentication (including Kerberos SPNEGO) works intuitively, and we are able successfully to configure different sections of the client website to require differing levels of authentication: some single-factor; others two-factor; etc. (all this being arranged via appropriate CosignRequireFactor entries in Apache <Directory …> stanzas.)

In summary: the test service seems to provide what we want.

Notes:

  1. The configuration for the Yubico PAM module is exactly the same as described in the previous post Towards two-factor Yubikey authentication with OpenSSH, namely:
    auth	required	/lib64/security/pam_yubico.so	id=<secret> key=<secret> authfile=/etc/yubikey_mappings debug 
    
  2. There is no specific ‘per-user’ treatment in the PAM configuration (as there is, for example, in the corresponding test ssh configuration described in the previous post mentioned above): anybody attempting to authenticate via a Yubikey is doing so because they want access to web content explicitly mediated via Yubikey authentication: such authentication either succeeds, or it doesn’t.

What we plan to do next:

  1. The current test client website is purely a proof of concept. We now plan to set up a test website to provide access to the School database (via ‘Theon’), in order to demonstrate two-factor access to ‘real’ data.
  2. We are purchasing more Yubikeys so that all members of the Computing staff – as well as any other interested parties – can participate in the trial.
  3. Currently, we associate Yubikey ID’s with School usernames via a map file – namely /etc/yubikey_mappings. That works, but isn’t particularly scaleable. We would like to investigate the use of LDAP to hold those mappings: the Yubico PAM modules supports that.
  4. Currently, we use the Yubico ‘Cloud’ service as the back-end authenticator. For any real service we will need to perform Yubikey authentication in-house – so that needs investigation. Failover and/or replication of any such service needs thought.
  5. Some further work is necessary to tweak the HTML and Javascript supporting the two-factor Cosign service.
  6. Amendments to building and packaging are necessary to incorporate the Universal PAM factor adaptor into LCFG.
  7. And other issues will undoubtedly arise in the course of the further testing to come …

A Yubikey Cosign authentication ‘factor’

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 3:34 pm
Tags: , , ,

Bearing the above specification in mind, we could now write a Cosign ‘factor’/authenticator which targets Yubikeys: we’d just need to feed it with the username, as well as the one-time-password produced by the Yubikey; have it perform the authentication – by slaving that off to a back-end authentication server; and then have it produce outputs as specified by the protocol.

However: we already have a Yubico PAM module which handles the details of the back-end authentication of the Yubikey one-time-password, and it turns out that a ‘universal Cosign PAM factor adaptor’ is available – see the relevant postings on the cosign-discuss mailing list. So we can use that instead.

The relevant C code file is now part of the Cosign download tarball, but it’s not autobuilt as part of the ./configure; make process. However:

  1. find it (as file pam_factor.c in the cgi/factors directory of the distribution);
  2. build it as follows:
    gcc -lpam -o pam_factor pam_factor.c
    
  3. copy the resulting binary factor to some suitable location, e.g., /usr/lib/cosign/factors; and
  4. edit /etc/cosign.conf to add the factor.

In the /etc/cosign.conf configuration file, all this finally takes the form:

factor /usr/lib/cosign/factors/otp login passcode

where otp is a symlink to the universal Cosign PAM factor adaptor pam_factor, and a new ‘otp‘ PAM service using the Yubico PAM module has also been declared.

Note: the name of the factor is significant, and is more than just, for example, self-documentation! Recall that the factor must, on successful authentication:

  • write the factor name to stdout; and
  • exit with 0.

The universal Cosign PAM ‘factor adaptor’ is coded to emit a factor name which corresponds to its basename – i.e. in our case, it will emit the factor name of ‘otp‘ on successful authentication. So the literal factor name ‘otp‘ is what the rest of the corresponding Cosign configuration client-side must be set up to expect.

In addition: the name of the corresponding local PAM service must match that of the factor: the factor is coded to call out to the local PAM service which corresponds to its basename.

Finally, however: why call this factor ‘otp‘ rather than, say, the more mnemonic name ‘yubikey‘? After all, both of the above-mentioned pieces of configuration could be fixed up accordingly. Well, as well as ‘leaking’ less internal configuration information, it turns out that the factor ‘otp‘ is already explicitly supported by the supporting HTML and Javascript distributed in the Cosign tarball. So ‘otp‘ is just better and easier all round.

November 9, 2015

Back to work …

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 10:32 pm
Tags: ,

Quite some time ago now (!), I wrote ‘In the New Year, I’ll post more information about the new project and, in particular, progress with integrating Yubikey use into Cosign.’

Practical work on this project stalled since I wrote that sentence – in part, owing to the lack of a ‘real’ test case which we could use for serious testing. However we’ve now restarted the effort, and I’ll document the successful integration into Cosign of Yubikey two-factor authentication in some forthcoming posts.

December 13, 2014

A new project

Filed under: Pilot service for Yubikey two-factor authentication — idurkacz @ 11:33 am
Tags: ,

The test OpenSSH service described in previous posts which uses Yubikey two-factor authentication seems to work fine, has been running in a very small-scale way since about August 2014, and was in fact developed as part of the more general investigative precursor project Project 279 – Options for two-factor authentication.

However, as mentioned in an earlier post, in order to make our overall site configuration both sensible and consistent, we’d definitely want to integrate the use of Yubikeys into our Cosign-protected websites too. So, having satisfied ourselves that the use of Yubikeys seemed to be viable, we created the project which is the subject of this blog – namely Project 313: Pilot service for Yubikey two-factor authentication – in order to develop a more fully-fledged ‘test’ service.

The previous posts bring this blog more or less up-to-date with the state of the test two-factor OpenSSH service, but by now there has also now been progress with Cosign integration.

In the New Year, I’ll post more information about the new project and, in particular, progress with integrating Yubikey use into Cosign.

Next Page »

Theme: Rubric.