Understanding traceable time

Earlier this year at a workshop for researchers, I met someone who told me that India had no official policy on synchronized time traceability, and this was a problem in an increasingly digital world. She was having a hard time explaining to officials why it mattered.

I immediately joined the ranks of the confused. What in the world was ‘synchronized time traceability?’

The researcher (who prefers not to be named) explained. When a forensic analyst is investigating digital records on a computer (say, a server on which some incident happened), one may expect timestamped logs recording the incident. The timestamps record whatever the computer thought the current time was. But what if the time was incorrect, and those timestamped logs need to be compared with logs from another computer?

This sort of inaccuracy is common. As an experiment, pull up clock apps on your phone and laptop. Chances are both show the same time to the minute but differ by seconds. Internet-connected computers typically synchronise their clocks once a day with a ‘time server,’ one of several located around the world.

The Network Time Protocol that is used for this can relay the current time to an accuracy of a few milliseconds, even if the connection’s latency is longer than that. However, your computer’s own clock may not be particularly accurate at keeping the time, and may introduce a small error that builds up to several seconds or even minutes over time.

But a second sort of error can happen. What if the time server itself tells you the wrong time? Wikipedia has a summary:

Several security concerns arose in late 2014. Previously, researchers became aware that NTP servers can be susceptible to man-in-the-middle attacks unless packets are cryptographically signed for authentication. The computational overhead involved can make this impractical on busy servers, particularly during denial of service attacks. NTP message spoofing can be used to move clocks on client computers and allow a number of attacks based on bypassing of cryptographic key expiration. Some of the services affected by fake NTP messages identified are TLS, DNSSEC, various caching schemes (such as DNS cache), BGP, Bitcoin and a number of persistent login schemes.

Every major website requires HTTPS today (that’s HTTP over TLS), and if you change a computer’s clock by too much, it can no longer make TLS connections. A rogue NTP server can knock your computer offline by simply sending it the wrong time. Try this yourself: change your computer’s time manually to six months ago and try to open Google.

Given the context of our discussion, my mind immediately raced to Edward Snowden’s revelations about NSA’s offensive capabilities. Practically every computer (server/desktop/laptop) in India today runs Windows, macOS or some flavour of Linux, and all of them come pre-configured with the name of a time server (time.windows.com, time.apple.com, pool.ntp.org, etc). Chances are it’s a server hosted somewhere outside India, in a place where NSA can intercept traffic for a timeshifting attack. (Mobile phones get their time from the local cell tower.)

You want cyber war? How about an offense that can take a computer offline for all practical purposes by simply giving it the wrong time? Or more covertly, if you want a census of computers in a facility, just monitor the requests being sent to known time servers.

I stood there, dazed. Time was important, but this ‘traceability’ thing was still elusive. “So you mean the Indian government does not host its own time servers?” I asked. “Of course it does,” the researcher said, “but it needs to build a massive national-level infrastructure that can serve the demand of digital traffic among networks and devices.” A second attempt at explaining traceability followed.

Let’s say a computer has a timestamped log record that says a particular incident happened at 11:59:43 AM. This was the recorded time on the computer when the log was written. The question is, what was the actual time when the computer thought it was 11:59:43 AM? This question assumes there is such a thing as ‘actual time’ and there is indeed. It’s called Coordinated Universal Time (UTC). To convert from recorded time to actual time, an analyst will need to do several things:

1. Determine where the computer got its time from. What time server, and how long before the recorded time?
2. Determine the computer’s inclination to drift. Is one second on this computer actually one second long?
3. Examine the time server and ask the same questions again. Where did the time server get its time from?
4. Trace all the way up to UTC until the clock difference and thereby the actual time can be established.

As you can tell, this is not a trivial task. If there is a court case and a timestamped log file is presented as evidence, it needs the backing of a trace for the timestamp to be meaningful evidence.

And this, the researcher pointed out, was the problem. The government did not have a policy on how time may be traced, so neither it nor the court have any means by which to treat a timestamp as a fact rather than an opinion.

What can possibly go wrong if an internet-connected device has the wrong time? Here’s a partial list.

1. TLS (previously SSL) requires the certificate to be currently valid. Google resets its TLS certificates every three months. If your clock goes off by more than three months, your browser will refuse to connect to Google. LetsEncrypt, a popular free certificate issuer, also uses three month validity. Most other certificate issuers use 1–2 years. You have probably experienced this sort of breakdown if your computer somehow lost its clock and reset itself back to its manufacturing date, and the internet stopped working. More detail.
2. The Time-based One Time Password (TOTP) protocol used by Google Authenticator, Authy and even the mAadhaar app typically has a validity window of four minutes (current time ± two minutes, and depending on the server). If your clock is off by longer than that, the OTP won’t work.
3. A Point of Sale (PoS) machine must do time synchronization as the first step, so that transactions can be correlated between it and the rest of the banking chain. In the case of an Aadhaar-enabled PoS, the chain is PoS → Sub-AUA → AUA → ASA → CIDR, and then a separate chain involving the banks. The drifts between all the computers in this chain should be <1 second for fraud analytics to work end-to-end, or the ability to trace a transaction through the chain gets painful.
4. The Paxos algorithm used by distributed databases like Cassandra and Google Spanner requires accurate timekeeping. It’s so critical that Google created a timekeeping technology called TrueTime.

Many data centres use a combination of GPS and atomic clocks to maintain time (including Google TrueTime). A little known fact about GPS is that not only can it tell you where you are, it can also tell you the current time to a very high degree of accuracy, and without requiring an internet connection.

But for the rest of us, network time servers, a robust policy, and supporting infrastructure are an absolute must.