Yubico Forum

Q: The security model of the key implies that you have to trust all entities with whom you're gonna identify using a YubiKey. Every entity knows your secret private key which would allow them to impersonate you. That is, all the nformation being transmitted using the key can be forged if you know the AES key. Let's elaborate:

From http://www.yubico.com/technology/description/:
1. A hidden identity field to verify the decrypted result to a non-published identity.
- This is known to every entity you're identifying yourself to, so it is known to attacker.com

2. A volatile counter is incremented by one for each code that has been generated. This code is reset at each power-up.
- As this could have been reset any time (by unplugging the key in the meantime) it can be any value.

3. A non-volatile counter is incremented by one for each power-up event. The value of this counter is preserved even when power is lost.
- This counter has to be >= the value you last used to identify to some-neat-site.com. Easy to do, just pick a large enough number or use your knowledge (see below)

4. A non-predictable counter value is fed by a time-base that is highly device and session dependent. Together with a server-based authentication module, this counter can provide a strong protection against "Phishing" attempts.
- This could be a tough one, it's device depended. Let's have a look into the security review: "The 3 byte timestamp is stored in volatile memory, and is set to 0 every time the device is connected. It is incremented by a 8Hz clock, which may drift up to 20% depending on the USB power feed and temperature. The timestamp field tracks the length of time the device has been connected during a particular session. This corresponds to about 24 days." So it seems it's just
the time the key has been plugged into the USB port. But how should a remote authenticator know this value? It can't. And the counter is reset every time the key is plugged in so this can be any reasonable value.

5. A random seed.
- Well that's easy, isn't it

6. A simple checksum.
- The algorithm is known so that's easy too.

Let's have a look at a possible scenario:
1) Victim uses YubiKey to authenticate to some-neat-site.com
2) Victim uses the same YubiKey to authenticate to attacker.com -> attacker.com knows the last value of the non-volatile counter, neat! It knows the last time-based counter value too, even better!
3) Attacker uses info from last authentication to attacker.com to create a valid 128 Bit AES encrypted blob
4) If some-neat-site.com uses one-factor-authentication, the attacker has already won, otherwise she starts to brute-force the other factor
5) Victim wonders when she spent $100.000 for a new automobile at some-neat-site.com

What can we learn from this:
1) Either use one key with multiple entities you explicitly trust (and will trust tomorrow...and the day after that .. companies tend to get bought by ... Microsoft, the NSA, Russia, pick your evil).
2) Use one YubiKey with exactly one authenticating party so it can't impersonate you at another site.
3) This problem could be avoided if instead of asymmetric crypto was used
instead of symmetric.

Am I missing something here?

A: You are absolutely correct in pointing out the vulnerability of having multiple instances holding your symmetric key. We really discourage such a setting for the reasons you've mentioned. Furthermore - integral of the security model of the Yubikey is that one single point holds the last session counter and use counter values. Otherwise, each validating service would need to just ignore these fields as the key could have been used at another site since the last login. That would certainly lower the security of the scheme substantially.

Our proposed setup involves just a single server holding the authentication key, the private id and the key-related counter values. In a scenario where the key is to be used to logon to more than one server, we propose an exchange protocol where the request is forwarded to the authentication server and a signed response is sent back. That of course requires a trust model between all parties.

Have you looked how our authentication server works ? We have an API for it and by posting a HTTP request, a "signed" pass/fail response is sent back. This service is provided for free to allow simple test and evaluaton of the concept.

Your scenario below would then be that some-neat-site.com would forward the received OTP blob together with a nonce to the-validator.com. The-validator.com woud then decrypt the blob and verify all fields and update the database appropriately. The pass/fail response would then be sent back to some-neat-site.com together with the nonce and a signed response, using a key shared between these parties only.

Using an asymmetric scheme could have been an option and we've been considering that for certain use cases. However, the additional hardware complexity to perform asymmetric encryption would make the key substantially more expensive and also the OTP string sent would have to be very long. Given the "limited bandwidth" of the USB keyboard input, that would slow down the process considerably. But, it would have been neat to allow anyone to publish their own public keys. And - as mentioned earlier, the counters and timer values would have to be checked and updated somewhere in the end, so it would be a bit unpractical after all, I beleive.