Yubico Forum

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

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

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

Is there a easy way to upgrade the yubikey we have now???
Thanks

_________________
Patgadget
Montreal

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

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

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

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

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

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