I don't understand what attacks are possible... making an enemy late for work when his alarm goes off several hours late?
Or can you circumvent certificate revocations this way?
Or can you circumvent certificate revocations this way?
You could also cause expired certificates to be accepted, which limits the utility of short-lived certs as a means of protecting against key compromise.
And as hannob said, you can circumvent HSTS by setting the time in the future, causing all HSTS entries to be expired.
NTP does not sync time. NTP measures time drift across groups of servers, and sprinkles in known time. I'm not saying authentication is useless, you should turn it on for your known time sources, but it's not so simple as you make it out to be.
Unless you use SNTP on your servers. Don't do that. Ever.
Being able to control he time could theoretically let you control any PRNGs that rely on it.
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).
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.
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).
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.