Pilot service for Yubikey two-factor authentication

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

1 Comment »

  1. With yubikey 4 I had to add -o allow-update to the initial programming. Otherwise ykpersonalize -x would yield:

    Yubikey core error: write error

    Comment by Orion Poplawski — November 15, 2018 @ 5:17 pm | Reply


RSS feed for comments on this post. TrackBack URI

Leave a Reply

Your email address will not be published. Required fields are marked *

Theme: Rubric.