News for hackers. Stuff that matters.
Re:Multiple vulnerabilities released in NTP by dvanduzer on Friday December 19, 2014 @03:32PM (#8774337)
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.
Re:Multiple vulnerabilities released in NTP by cbsmith on Friday December 19, 2014 @08:05PM (#8775455)
> 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).

Re:Multiple vulnerabilities released in NTP by dvanduzer on Friday December 19, 2014 @08:34PM (#8775526)
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.

Re:Multiple vulnerabilities released in NTP by cbsmith on Saturday December 20, 2014 @11:46PM (#8778965)
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).