Yubico Forum

...visit our web-store at store.yubico.com
It is currently Tue Jan 30, 2018 5:34 pm

All times are UTC + 1 hour




Post new topic Reply to topic  [ 11 posts ]  Go to page 1, 2  Next
Author Message
 Post subject: assymetric keys
PostPosted: Thu May 29, 2008 9:52 am 
Offline

Joined: Thu May 29, 2008 9:44 am
Posts: 21
Hi,

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


Top
 Profile  
Reply with quote  

Share On:

Share on Facebook FacebookShare on Twitter TwitterShare on Tumblr TumblrShare on Google+ Google+

 Post subject: Re: assymetric keys
PostPosted: Thu May 29, 2008 7:44 pm 
Offline
Site Admin
Site Admin

Joined: Wed May 28, 2008 7:04 pm
Posts: 263
Location: Yubico base camp in Sweden - Now in Palo Alto
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


Top
 Profile  
Reply with quote  
 Post subject: Re: assymetric keys
PostPosted: Thu May 29, 2008 9:40 pm 
Offline

Joined: Thu May 29, 2008 9:44 am
Posts: 21
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: assymetric keys
PostPosted: Thu May 29, 2008 11:00 pm 
Offline
Site Admin
Site Admin

Joined: Wed May 28, 2008 7:04 pm
Posts: 263
Location: Yubico base camp in Sweden - Now in Palo Alto
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


Top
 Profile  
Reply with quote  
 Post subject: Re: assymetric keys
PostPosted: Thu May 29, 2008 11:24 pm 
Offline

Joined: Thu May 29, 2008 9:44 am
Posts: 21
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.


Top
 Profile  
Reply with quote  
 Post subject: Re: assymetric keys
PostPosted: Fri May 30, 2008 8:02 am 
Offline

Joined: Thu May 29, 2008 9:44 am
Posts: 21
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?


Top
 Profile  
Reply with quote  
 Post subject: Re: assymetric keys
PostPosted: Mon Jun 02, 2008 8:45 am 
Offline
Site Admin
Site Admin

Joined: Tue May 06, 2008 7:22 pm
Posts: 151
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

Code:
jas@mocca:~$ openssl genrsa -out rsa.pem
Generating RSA private key, 512 bit long modulus
.++++++++++++
.++++++++++++
e is 65537 (0x10001)
jas@mocca:~$ cat rsa.pem
-----BEGIN RSA PRIVATE KEY-----
MIIBPAIBAAJBAMJ8JDWnjv/qfvVwv5A6Sm3MyVp59L5RhW8JCOTBYy2yZKa1CeVE
jaJQotpoI4AZ7j+y9Z23bw/a7OFHo3G08MsCAwEAAQJBAI/aOQJCxOAAOBYdZmQs
6X6budelW2UmcVb2zNA/Rre17wwKHpB7RQkchf4Tyc0z2cCXffINi72fWpOw58jj
TVkCIQD4OGywdOzgQLRclVHRq9a685UwW5AYe9JS2N4LwXdytwIhAMiUkyW1InZj
MRrqFGHTWG43RqCa2hqFYMzB4DwOwU6NAiEA9Mvo3SmjRxJpDfmxJGAdOGjrlDJo
7MyIw23fpqZZYAcCIAhfq4T3eujWW0Z0X0V2PUrco+YwkMpqpw/lSCc5tnhBAiEA
3QMqy4qSjSgn4LQdxDWMpFj/kjSMwinD+i9BeEgv7iY=
-----END RSA PRIVATE KEY-----
jas@mocca:~$ echo 'hi'|openssl rsautl -encrypt -inkey rsa.pem  -out foo.out
jas@mocca:~$ ls -la foo.out
-rw-r--r-- 1 jas jas 64 2008-06-02 09:43 foo.out
jas@mocca:~$


Top
 Profile  
Reply with quote  
 Post subject: Re: assymetric keys
PostPosted: Tue Jul 08, 2008 3:20 pm 
Offline

Joined: Tue Jul 08, 2008 3:09 pm
Posts: 1
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).


Top
 Profile  
Reply with quote  
 Post subject: Re: assymetric keys
PostPosted: Wed Apr 22, 2009 3:50 am 
Offline

Joined: Thu Apr 16, 2009 3:03 am
Posts: 5
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.

Code:
$ openssl genrsa -out rsa.pem
Generating RSA private key, 512 bit long modulus
..........++++++++++++
.++++++++++++
unable to write 'random state'
e is 65537 (0x10001)
$ echo 'this is a new hash' | openssl rsautl -encrypt -inkey rsa.pem | openssl enc -base64 -out hash-b64.out
$ wc -c hash-b64.out
90 hash-b64.out
$ cat hash-b64.out
IsXIx0rnI/qvsAAw5ZpyrgibEtlg3Mii0jq5Rf1nsRleCYBCBpDxIKU7OoPxBZ+n
Xxq0xnZNpU34Z5j01TEk4Q==


Top
 Profile  
Reply with quote  
 Post subject: Re: asymmetric keys
PostPosted: Tue Aug 11, 2009 10:27 pm 
Offline

Joined: Tue Aug 11, 2009 6:03 pm
Posts: 7
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.


Top
 Profile  
Reply with quote  
Display posts from previous:  Sort by  
Post new topic Reply to topic  [ 11 posts ]  Go to page 1, 2  Next

All times are UTC + 1 hour


Who is online

Users browsing this forum: No registered users and 7 guests


You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot post attachments in this forum

Search for:
Jump to:  
Powered by phpBB® Forum Software © phpBB Group