On: Multiple vulnerabilities released in NTP

[Ricapar]

There is still a lot of crypto out there that works off of using the current timestamp as a seed.

Being able to control he time could theoretically let you control any PRNGs that rely on it.

[tedunangst → Ricapar]

I don't think I need to control your clock when I can just look at my watch and know what your clock says. Why do things the hard way?

[cbsmith → tedunangst]

Because any cryptographic implementation worth its salt wouldn't be using even second resolution time, so what your watch says is irrelevant. Also, if I cracked an NTP feed, I'd not use it to know what the server's clock is set to so much as to manipulate the server's clock to all kinds of wonderful effect.

[dvanduzer → cbsmith]

You're misunderstanding the attack vector. The exploit is about precisely controlling the delta between a client and server.

There is no problem with using low-resolution time signatures as a cryptographic seed. Using time as an entropy source is only a problem if you sample at a lower resolution than your clock's error rate.

[cbsmith → dvanduzer]

Maybe I wasn't clear, but I was thinking one would manipulate the delta specifically to cause the machine to adjust its clock.

[cbsmith → Ricapar]

It's more than that. There is tons of logic in crypto protocols around timeouts, and of course services themselves often have bugs around the handling of time (there's a great list of assumptions developers make about time that are fatal and create all kinds of security problems).

[dvanduzer → Ricapar]

The much bigger issue is with hardware that doesn't have a local clock/battery. Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.

[cbsmith → dvanduzer]

> The much bigger issue is with hardware that doesn't have a local clock/battery.

Ummm, no. NTP normally runs on machines that have a local clock/battery, but which need an established network clock anyway.

> Critical initialization code should probably compare uptime with current epoch time if it needs a random seed for a long-use token.

Using time as a random seed is probably a mistake in the first place. You could perhaps try to add entropy from a clock, but you'd want another source of entropy. Generally crypto code needs network clocks for other things (think of Kerberos ticket expiration).

[dvanduzer → cbsmith]

The average longevity of a Kerberos ticket makes it the perfect example for this attack vector, actually.

Are you familiar with something other than NTP as a time source for devices without CMOS? I have a project that desperately needs crypto without a clock.

[cbsmith → dvanduzer]

If you are really worried, use layer 3 or layer 2 security (say with IPSec) to secure NTP communications.

Yes, there is a bit of a bootstrapping problem, but you can address that with a bootstrapped handshake that sets a clock baseline.

Alternatively, you could just hardwire a radio receiver (like say... a GPS receiver).