Yubico Forum

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

All times are UTC + 1 hour




Post new topic Reply to topic  [ 11 posts ]  Go to page 1, 2  Next
Author Message
PostPosted: Tue May 27, 2008 3:36 pm 
Offline

Joined: Sun May 25, 2008 5:06 pm
Posts: 27
Hi,

I have been watching the decrypted output of my yubikey. There seem to be a mistake in it's 8hz timer.
If I plug in my yubikey the timer doesn't start automatically! That means that the first OPT from a newly inserted key always has a predictive timervalue of 0. After generating the first OPT the timer starts.

That is weakening the effect of the timer, because a lot of people would just plug in the key and immediately authenticate to their services.

Is this intentional?

Best regards,
Alex


Top
 Profile  
Reply with quote  

Share On:

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

PostPosted: Tue May 27, 2008 10:41 pm 
Offline

Joined: Mon May 26, 2008 5:16 am
Posts: 27
Hy Alex,
how did you manage to look at your decrypted data?
Did you use the Yubico server or your own?
Is there a easy way without reprogramming the AES key?
Thanks

_________________
Patgadget
Montreal


Top
 Profile  
Reply with quote  
PostPosted: Wed May 28, 2008 7:12 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
That is "by design" and should not affect the security that much. But you definately have a point - why do it this way as it decreases the entropy.

An obvious enhancement would be to pick a random number to seed the timer at power-up.

Thanks a lot for your comment - We'll keep that in the log for the next firmware upgrade. We need to have it stated in the implementation guidelines though so no one relies on the timer value being zero when the session counter is zero.

Anyone who have an objection on implementing this feature ?

Regards,

Jakob E
Firmware guy @ Yubico


Top
 Profile  
Reply with quote  
PostPosted: Thu May 29, 2008 2:24 am 
Offline

Joined: Mon May 26, 2008 5:16 am
Posts: 27
Is there a easy way to upgrade the yubikey we have now???
Thanks

_________________
Patgadget
Montreal


Top
 Profile  
Reply with quote  
PostPosted: Thu May 29, 2008 7:48 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
Updating the firmware is not that easy, but we'll provide an exchange for users who are interested. I'll put you on the "beta" list and you'll get a key for free when we're done with it.

Regards,

Jakob E
Firmware and Hardware guy @ Yubico


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 03, 2008 10:03 am 
Offline
Site Admin
Site Admin

Joined: Tue May 06, 2008 7:22 pm
Posts: 151
While we are likely going to change the firmware for this, it is important to understand something:

Having predictable plaintext doesn't decrease the security. As far as I know and understand, AES is designed to resist known-plaintext attacks. Thus, even if the attacker know the entire plaintext and ciphertext pair for the AES key in your Yubikey, he cannot find the AES key easier than brute force.

http://en.wikipedia.org/wiki/Known-plaintext_attack

Btw, AES is also assumed to resist chosen-plaintext attacks, so even if the attacker can somehow select the plaintexts that the yubikey is going to use (by waiting for an appropriate amount of time etc), that doesn't let the attacker find the AES key faster either.

Thanks,
Simon


Top
 Profile  
Reply with quote  
PostPosted: Tue Jun 03, 2008 11:13 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
Although I fully share Simon's view regarding the known-plaintext attack strength of AES, I beleive there is no real reason of having the timestamp starting at zero. All rational arguments speak in favor of that an increased level of entropy will make any cryptoanalysis attack more difficult.

Therefore, effective from firmware release 1.3.0 that is just around the corner, the 24-bit timestamp will start from a random value at power-up rather than from zero. Any application using the timestamp field to calculate the delta must therefore not rely on the timestamp starting at zero, but rather keep the first timestamp seen. The delta can then be calculated from this offset.

Thanks for the valuable input in this subject.

Jakob E
Hardware- and firmware guy @ Yubico


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 09, 2008 4:48 pm 
Offline

Joined: Mon Jun 09, 2008 4:40 pm
Posts: 5
Location: Cincinnati, OH
It is obvious from other threads that 1.3.0 has been finalized, but I am curious...

Why not start the timer at powerup?

--
Greg Estep


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 09, 2008 5:08 pm 
Offline

Joined: Sun May 25, 2008 5:06 pm
Posts: 27
Hi,

Actually I think it's a bad idea to start the timer at a random value. I know the entropy could potentially be bigger if you start the timer at a random value - but... You will probably be using the same random generator as the one you use for the 16-bit random number, then the entropy will not get much better.

I think it's a good idea to start the timer at 0 at the moment the key is inserted. This could provide some usefull information for the serverside software. For example this would allow a company to enforce a security policy enforcing people to authenticate within a minute after inserting.

Best regards,
Alex


Top
 Profile  
Reply with quote  
PostPosted: Mon Jun 09, 2008 8:25 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
Starting the 24-bit timer at a random value should add a fair amount of extra fuzziness. One can of course argue how much harder it would be for an attacker, but starting with a random number will not make life easier at least.

The starting value is generated during the device enumeration process and the RNG LFSR is seeded from the touch sensor. Given the time it takes from startup to the first key pressed (which as such also seriously affects the RNG), the rnd16 and the initial tstp will be extremely uncorrelated.

One alternative could of course be to start on zero at power-up, but I decided to reject that for three reasons:

a) There is an auto-navigation feature that can be triggered at power-up. The delay before the code is triggered is timed by the 8Hz timer and therefore, the tstp would be at the same value every time.

b) Given the 24-bit space, the probability that the upper bits are zero is higher and we would not utilize the "full potential" of the 24-bits

c) Privacy reasons. Although I don't care myself but for some reason, that thought struck me and that some people might get upset. "Ah, it does not even take John thirty seconds after he turns his computer on before he logs on. He must be very anxious..."

That's the thoughts behind it at least. Please let me know your thoughts.

Regards,

JakobE

Hardware- and firmware guy @ Yubico


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: YahooSeeker [Bot] and 4 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