Yubico Forum

We are beginning to use Yubikeys for two-fact auth (we'll be using Yubikey OTP, nothing else), and I've realised that I don't fully understand the usage and standards regarding the OTP public identities.

Background:

Currently, our test service uses authentication via the Yubicloud service - that all works fine, with Yuibikeys fresh 'out-of-the-box'. However, we will *probably* want to set up our own authentication servers internal to our network, so that authentication can continue to work if/when we have a complete external network outage. So, in order to get the AES keys, I need to reprogram slot 1 of our Yubikeys. The ideal situation might be if our keys were able to be authenticated via both our own authentication servers, as well as the Yubicloud service (though I realise that that opens up some possibility of OTP replay attacks.)

So, various questions:

1. Is it possible to use the personalization GUI to reset the AES key, but to retain the existing public identity - and then have the new AES key uploaded to the Yubicloud servers?

2. Am I right in assuming that all 'cc....' public identities which come with fresh 'out-of-the-box' Yuibikeys are guaranteed to be unique?

3. The personalization GUI autogenerates new 'vv....' public identities which are then able to be uploaded to the Yubicloud servers. What guarantee is there that such identities are not already present on the Yubicloud servers? And what happens on the Yubicloud servers in the event of such a clash?

4. What is the significance of the 'vv' (= 0xFF) prefix?

5. Referring to section 5.4 of the Yubikey manual, is the 'customer prefix' part of the six byte public identity? Are the currently-assigned customer prefixes currently 'accessible as a global repository'?

Thanks for any explanations.

1. Is it possible to use the personalization GUI to reset the AES key, but to retain the existing public identity - and then have the new AES key uploaded to the Yubicloud servers?

Yes, there are 2 configuration slot in the Yubikey OTP side. You can configure slot 2 with your won custom generated credential. You can also move pre-configured credential from slot 1 to slot 2, and generate a new custom credential in slot1

2. Am I right in assuming that all 'cc....' public identities which come with fresh 'out-of-the-box' Yuibikeys are guaranteed to be unique?

Yes, those are unique.


3. The personalization GUI autogenerates new 'vv....' public identities which are then able to be uploaded to the Yubicloud servers. What guarantee is there that such identities are not already present on the Yubicloud servers? And what happens on the Yubicloud servers in the event of such a clash?

Yes, they will be unique, no clashes.


4. What is the significance of the 'vv' (= 0xFF) prefix?

Nothing, it is just a reserved names space to make everything easier. We know that YubiCloud validates CC and VV names space. All other name spaces are for customers to choose and use within internal validations

5. Referring to section 5.4 of the Yubikey manual, is the 'customer prefix' part of the six byte public identity? Are the currently-assigned customer prefixes currently 'accessible as a global repository'?

No, they are not.

Yubico's Tom2's answers are solid and outline the ability of two different AES keys to reside in the two available slots (short-press=slot 1, long-press=slot 2) to allow for two different Yubico OTP validation services to be used: theirs + yours or yours + yours.

Used in that way, you can:
1) swap slots, which moves yubico's key to slot 2 (if you prefer to give priority to your internal service)
2) put your internally generated key in the other slot (slot 1 if you do the above) for use with your own authentication servers.
3) validate against your internal service or yubico's service as needed.

One additional clarification:

Just in case you were planning to try to upload the exact same key to both your internal server as well as yubico's servers: this won't work.

Why? To prevent replay attacks, the Yubico OTPs depend on locally incremented power-on and usage counters which are internal to the key and associated with the key and slots. These are part of the encrypted/hashed data used to generate each OTP. Verification tracks their presumed position and allows only the handful of codes generated "not too many steps" from the last known position of the counters (which are then updated server-side on each successful validation).

Using two separated verification services that do not synchronize the counter positions means that one service will very likely lag behind the other and then the key will no longer be accepted. And re-syncing with one service starts pushing it out of sync with the other.

Brendan

Thanks for the responses. I've now got a couple of resulting questions:



Thanks very much: that sounds exactly what we'd like to do, but I didn't realise it was possible to do it via the personalization tools. I'll give it a try.



I assume your reply corresponds to the second of my two questions, right?

So, for my own understanding, can you clarify whether or not the 'customer prefix' is supposed to part of the six byte public identity?

Beyond that, I am struggling to understand some of the detail on section '5.4.1. Interoperability guidelines in Yubico OTP mode' in the Yubikey Manual.

For example, the manual says that public IDs should be six bytes (i.e. the default config) to remain interoperable, but then goes on to say that such IDs are interoperable if (and only if?) the first byte is 0x28 (=modhex dj). How would that square with the use of a 'customer prefix'?