Electronic timestamps explained

Three kinds of file time

NIST Special Publication 800-86, Guide to Integrating Forensic Techniques into Incident Response, describes three file times. Modification time is the last time a file was changed in any way. Access time is the last time any access was performed on a file. Creation time is the time and date the file was created ¹.

Systems differ. NIST says Windows systems retain the last modified time, last access time and creation time. UNIX systems keep modification, inode change and access times ¹.

Why a file time can mislead

NIST advises that where an analyst needs an accurate timeline of events, the file times should be preserved. It recommends bit stream imaging over some logical backup tools, which may alter creation times when data is copied ¹.

• Copying changes creation time. NIST says that when a file is copied to a system, the creation time becomes the time it was copied. The modification time stays the same ¹.
• The clock may be wrong. NIST says the computer clock may be incorrect or may not have been synchronised regularly with an authoritative time source ¹.
• Detail may be missing, such as omitted seconds or minutes ¹.
• An attacker may have altered the recorded file times ¹.

Time zones and UTC in records

RFC 3339, Date and Time on the Internet: Timestamps, is a profile of ISO 8601 for Internet protocols ². It says interoperability is best achieved by using Coordinated Universal Time ².

A timestamp such as 1996-12-19T16:39:57-08:00 carries its offset from UTC. RFC 3339 says it is equivalent to 1996-12-20T00:39:57Z ². The same moment falls on different calendar days depending on the offset, which matters when a chronology lists dates only.

Where the UTC time is known but the local offset is not, RFC 3339 allows an offset of -00:00. This differs from Z or +00:00, which imply UTC is the preferred reference point ².

The seconds field may be 60 at the end of a month in which a leap second occurs. The RFC gives 1990-12-31T23:59:60Z as an example ².

Trusted time-stamp tokens

RFC 3161 sets out the Internet X.509 Public Key Infrastructure Time-Stamp Protocol ³. A Time Stamping Authority, or TSA, time-stamps a datum to establish evidence that it existed before a particular time ³.

The TSA must use a trustworthy source of time. It time-stamps only a hash of the datum, not the datum itself ³. The token's genTime field is in UTC, to reduce confusion with local time zones ³.

An optional accuracy field gives the margin around genTime. Adding it gives an upper bound and subtracting it gives a lower bound on when the token was created ³. A token is evidence of a latest possible time for the data, not of when the data was first written ³.

Rules that require synchronised clocks

India's CERT-In issued directions on 28 April 2022 under section 70B(6) of the Information Technology Act, 2000 ⁴. Entities must connect to the Network Time Protocol server of the National Informatics Centre or the National Physical Laboratory, or to NTP servers traceable to them ⁴.

The same directions require logs of all ICT systems to be kept securely for a rolling period of 180 days within Indian jurisdiction, and listed cyber incidents to be reported within 6 hours of noticing them ⁴. The directions took effect 60 days after issue ⁴.