Is it safe to assume that my computer's clock will always be synced with actual time within the second or a few seconds at the worst?

Question

Years ago, I was running a service where the moderators were able to do various actions with massive privacy implications if the accounts or contributions were less than a short period of time. I did this by checking the timestamp against the current Unix epoch, allowing for X hours/days. Normally, this worked well.

One day, the server where this was hosted on had been "knocked offline" in the data centre where I was renting it, according to the hosting company. When it came back on again, its clock had been reset to the factory default, which was many years back.

This resulted in all my moderators potentially being able to see every single account's history and contributions in my service until I came back and noticed the wrong time (which I might not even have done!) and re-synced it. After that, I hardcoded a timestamp into the code which the current time had to be more than or else it would trigger "offline mode", to avoid any potential disasters like this in the future. I also set up some kind of automatic timekeeping mechanism (in FreeBSD).

You'd think that by now, not only would every single computer be always auto-synced by default with tons of fallback mechanisms to never, ever be in a situation where the clock isn't perfectly synced with "actual time", at least down to the second, if not more accurately; it would be impossible or extremely difficult to set the clock to anything but the current actual time, even if you go out of your way to do it.

I can't remember my Windows computer ever having been out of time for the last "many years". However, I do important logging of events in my system running on it. Should I just assume that the OS can keep the time at all times? Or should I use some kind of time-syncing service myself? Like some free HTTPS API, where I make a lookup every minute and force the system clock to me whatever it reports? Should I just leave it be and assume that this is "taken care of"/solved?

Answer 1

No, in general. Time keeping is an important part of the kernel's duties, but it's not infallible, especially when you're talking about scenarios where other failures are occurring. In general you should not assume that all machines have the correct time in all circumstances, and your security should not depend on this assumption.

The only onboard clock that most computers have is the Real-Time Clock (RTC). This is the clock on your PC's motherboard that historically was powered with a coin cell battery. This clock is typically the default clock for the system, as it is always available. There are many different constructions for this device with varying degrees of accuracy and robustness. Some are just cheap parts that don't work well. Obviously these devices can have bad batteries, in which case they can keep poor time or no time at all. Some constructions are also vulnerable to temperature fluctuations. I've worked with systems in recent memory where the resolution of the RTC was limited to one second, meaning you query the RTC and it only returns a full seconds value, meaning that the reported value can be up to half a second off of the true time (even assuming perfect time is kept).

However, even accurate clocks are only accurate to a certain degree, limited by the accuracy of their crystal oscillators. Most RTCs are spec'ed to have an accuracy of 20 or 30 parts-per-million. This results in a drift of about 1.7-2.5 seconds per day. Some such devices might be more accurate, while others might be less accurate even if they're spec'ed higher. It's not hard to find examples online of people who report drift that is 5-10 times worse than that. This drift must be compensated periodically either manually or through an internet timeserver in order for your machine to keep accurate time.

Note that some systems do not have a RTC, which means they are incapable of keeping accurate time without an internet connection. A notable example of such a system is the Raspberry Pi.

There are other onboard time-reckoning devices such as the Programmable Interval Timer (PIT), High-Precision Event Timer (HPET), and the processor's timestamp counter (TSC). All of these can be used to augment the notion of time that the computer gets from the RTC and internet time servers, but the RTC is the only onboard device that keeps actual time while the computer is unpowered.

Thus, when your computer first boots it uses the RTC to establish what time it is, and then later it will update that notion based on an internet timeserver. It will periodically check in with the RTC and/or internet timeserver to update itself, but between these events it uses those other time sources to keep track of roughly what time it is.

Now how can this system go wrong? If you don't have an internet connection, then the only time source the system can use for the real wall-clock time is the RTC. The RTC will drift, and it might drift up to the tune of 10-20 seconds per day if you're particularly unlucky. The machine normally compensates for this automatically, but if you don't have the internet then this doesn't happen. Even if you had a one-day outage, for example, your machine could drift well outside of your 1-2 seconds parameter with bad hardware.

Second, when a time discrepancy is detected the default behavior is to adjust the clock time gradually rather than setting it instantaneously to the new value. There are lots of processes on the system that are using time and timers constantly (TCP packet timeouts, GUI event loops, etc.) and these processes typically don't take it well when time jumps around. Thus, for a short period of time the clock will artificially run faster or slower than the true time while your clock catches up to the true time. Your clock can even appear to stop, or I've heard in extreme cases run backwards depending on what your specific system implementer did.

Answer 2

When clock's backup battery voltage gets lower over time, most clock circuits run faster. (My job had an RSA key FOB with a random number generator that matched the remote telco server, except it was 5 yrs old and 30 seconds off the remote server. ) However most operating systems seek out Internet time servers and correct themselves. Computers turned off for along time will be off. Microsoft's kerberos authentication allowed for a 5 minute time delta. FYI the Y2K fix for unix computers (including Apple & linux) wiil expire 2037? Open BSD is secure by default and FreeBSD can also be secured, however that means admin must purposely enable functionality. Using a Network Time Server has been an option on Microsoft's Server software.

Answer 3

Is it safe to assume that my computer's clock will always be synced

Assumptions are always bad. As the others have hinted at, configuring NTP for an internet connected machine is easy (even on MS-Windows) and works. And there are other options - radio clocks and satellite geolocation devices can provide very high accuracy from broadcast sources.

Synchronized time is very important for security - without that your audit information has very little value. But using time-boxing as a mechanism for access control makes me very nervous - indeed using time-boxing for any control mechanism is, in my experience, the last resort for a reliable, robust system. Yes, a limited TTL is a must for things like temporary passwords - but as described here....no.