3 ms·
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 t
by dvanduzer 12y ago
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 12y ago> 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 12y agoThe 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 12y agoIf 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).