Yubico Forum

Hi,

Do you have any plans to produce a yubikey that uses assymetric keys to encrypt the token?

The question has been up a few times and conceptually it would have been nice.

There are two main problems as I see it

a) The hardware required to do an asymmetric encryption is a magnitude more complex than the one we have now. We would need a serious bignum engine on board and we beleive that would make the product significantly more expensive

b) Anything less than 2048 bits signatures would not impress. That OTP would be *very* long to send in via the keyboard port. Given that some 20 keystrokes per second can be safely sent, this will take a bit too long time to execute.

Bottom line: Not now, but we might find out some nice compromise as time gets by.

Regards,

Jakob E
Firmware and Hardware guy @ Yubico

I was thinking of making the otp an encrypted digest of the time (see my other forum thread) so the otp need not be all that long. only the "public" key could decrypt it ensuring that it was really "The Key" that encrypted the otp. This would mean that your customers could "publish" the public key to all the services that use the key for authentication and

i. there is no need for a central authorising party (so offline validation works)
ii. there is not the issue of the risk of the key repository getting compromised

You are going to become a very high value target for hackers / foreign government agencies with all those secrets you hold.

It sounds like you are refering to something more like an asymmetric version of the SecureID, Vasco et.al. , is that right ?

- The variant part would then be a timer, with say one minute resolution
- The "blob" would be encrypted with RSA-2048 or so
- Then hash the stuff with SHA-1 or so, reducing it to 160 bits. A shorter hash would do as well of course...
- Convert it to 40 characters

That would be nice of course and it's definately worth keeping in mind.

Matching the OTPs would be considerably more complex, given that you would have to try over a fairly wide time window. A low-cost crystal varies at least some +/-100 ppm and given that we have about 526,000 minutes on a year that would be some +/- 53 minutes drift.

Maybe there is some other way to do it.

Regarding the Yubico server being a specific target for bad guys, that's a point. But there are so many services relying on symmetric keys, I beleive most people would agree there are ways to maintain and store these keys in a secure way. It is furthermore important to say that we won't be the single point of attack. Things will grow and lots of sites will maintain their own keys. It's going to be distributed, just like password databases.

Regards,

J

regarding drift: you would store the "Local key time" with the user profile and the drift window would only be relative to the time of the last logon. So if the user hasn't logged on for a whole year the drift window would be "only" 106 minutes. If they log on each week the window would only be +-1 min.

The above scenario won't work by the way. The public key can't decrypt a hash of the encrypted data. It can only decrypt unaltered data.

How big would the output of a 10 character string be that has been encrypted with a long private key?

If you look at just PKCS#1 RSA encrypt/sign, I believe the output will be as long as the modulus size. Thus, a 2048 bit key (which is the minimum you want to use to be safe) would be 256 bytes, or 512 modhex characters. Right now the output is 44 modhex characters and it is getting on the long side.

There is ECC though, which has significant shorter signatures.

/Simon

I got a Yubikey because I loved the principle of a hardware token with open source infrastructure. But after contemplating it for a while I came to the conclusion that symmetric keys are a significant weakness (for reasons already pointed out in this thread). I just wanted to add my "2 cents" by saying that I think assymetric keys would help address what I see as the single biggest weakness of the Yubikey. I'd love to see a second generation device that uses public/private key pairs.

I'd like to see this discussion continue in the hope that somebody comes up with a clever idea for addressing some of the issues brought up so far (e.g. reducing the size of the encrypted blob, etc).

P.S. - Regarding clock drift, I was wonder if they clock couldn't be resyncronized? While it is true that the Yubikey should be able to operate without requiring any software to be installed but of course a user could optionally install software that resync'd the Yubikey (as a performance improvement, for example).

I completely agree with mtiller.
What about the idea that Simon posted? The output is only 64 bytes, which can be encoded to 90 characters. This is only 2x of the current output.

What I don't quite understand is what would be the input to encrypt.

Yubikey needs a central authority to prevent replay attacks with or without asymmetric encryption. The Yubikey encrypts a monotonically increasing counter and checks to make sure it's higher than any previously seen counters. Without the central authority the OTP you send to server A will be accepted by servers B, C, and D, no matter what kind of encryption is used.

Instead of having to worry about the integrity of a single authentication server you now have to worry about the N servers you log into, your computer, and the channel between them, your OTP is 20 times longer, and your key is more expensive.

If you want to take away the central party then you should go buy a smart card and then try to set up its reader and drivers on each system you use. Smart cards generate a public and private key internally, they can only reveal the public key, and they use their private key to sign a challenge received from the server.