Trusted timestamping as defined in RFC 3161 makes its way into my digital forensics workflow quite often. For instance, depending on case requirements, I usually obtain a trusted timestamp for data acquired during a forensic website or email collection and have my expert reports timestamped.
We have recently added this functionality to Forensic Email Collector to improve automation, and I wanted to write this post to discuss what trusted timestamping is and how it can be useful in your digital forensics work.
What Is Trusted Timestamping?
Trusted timestamping, in essence, is a mechanism to certify that specific electronic information existed before a certain point in time.
In the digital forensics context, this can be extremely useful when dealing with time-sensitive information. For instance, in my experience, forensic preservation of websites is often time-sensitive and legal teams aim to show that certain content was or was not present on a web page on a given date. Similarly, forensic email preservation may involve data points such as mailbox filters, server metadata, and other logs that may not have easily verifiable timestamps themselves. Forensic preservation along with trusted timestamping can be used to show that certain IMAP Unique Identifier (UID) gaps were observed on a server, or that specific mailbox filters were active on the target mailbox at a certain point in time.
Another common use case is expert reports—when you prepare an expert report, in addition to digitally signing it, you may want to obtain a trusted timestamp so that the timing of your report is certified by a trusted third party.
In the absence of a trusted timestamp, the timing information associated with most of your work product would be correlated with the local time kept by your workstations. While most forensic examiners diligently ensure that their devices keep accurate time, it is possible that a workstation’s time may be off, or the accuracy of the time may be called into question by opposing counsel in a highly time-sensitive case. In such scenarios, trusted timestamps can help nip potential issues in the bud and avoid lengthy cross-examination.
According to RFC 3161, the certification is typically performed by a trusted third-party (TTP) service that acts as a Time Stamping Authority (TSA).
What is A Time Stamping Authority (TSA)?
Also known as an online notary or digital notary, a Time Stamping Authority (TSA) is typically a server that runs timestamping server software (e.g., ADSS TSA Server by Ascertia, or an open-source alternative). Such a server often contains a high-performance hardware security module (HSM) such as the IBM 4767 Coprocessor. The HSM brings added performance, reliability, security, and tamper resistance beyond what would ordinarily be available on standard server hardware. For instance, the IBM 4767 documentation states that “IBM 4767’s cryptographic processes are performed within an enclosure on the HSM that is validated to FIPS PUB 140-2, Security Requirements for Cryptographic Modules, Overall Security Level 4″.
TSAs are typically audited regularly by independent security firms and comply with regulations such as eIDAS and Code of Federal Regulations Title 21 Part 11 (21 FDA CFR-11). For context, you can find the Policy & Practice Statement of Sectigo’s eIDAS qualified TSA here.
A list of publicly available RFC 3161-compliant TSAs can be found here.
How Does Trusted Timestamping Work?
Trusted timestamping, as defined in RFC 3161, leverages public-key cryptography. First, the cryptographic hash of the file that needs to be timestamped is calculated. At the moment, SHA-256 and SHA-512 are commonly used cryptographic hash algorithms for this purpose.
The timestamping client then forms a request including the hash and the object identifier of the hash algorithm that was used, the version of the timestamp request (currently 1), a nonce—a large random number with a high probability that the client generates it only once, the policy under which the timestamp token should be provided, and whether or not the TSA’s referenced public key certificate should be included in the response.
The request is then relayed to the TSA using a supported transport mechanism such as email (Content-Type: application/timestamp-query; Content-Type: application/timestamp-reply), a simple TCP-based protocol, or via HTTP. In my experience, HTTP is used more often than other transport mechanisms.
The TSA responds back to the timestamp request with a timestamp response. The response contains detailed status information (e.g., status code, description, failure reason, etc.) as well as a timestamp token if the request was granted. The content of the timestamp token is in SignedData format as defined in Cryptographic Message Syntax (CMS) (RFC 5652). The SignedData construct looks as follows:
The certificates field optionally contains a set of certificates—the timestamp request discussed above controls whether the certificates should be included in the TSA’s response. If they are, the set of certificates should form a certification chain from a recognized root or top-level certification authority to all of the signers in the signerInfos field.
Side Note: When researching RFC 3161, you will often run into RFC 5816. RFC 5816 is an update to RFC 3161 and allows the use of ESSCertIDv2, as defined in RFC 5035. In a nutshell, this allows the hash of a signer certificate to be calculated using a cryptographic hash function other than SHA-1.
The eContent field of the EncapsulatedContentInfo of the SignedData construct contains an octet string that reflects the DER-encoded value of the TSTInfo. For clarity, eContent is digitally signed using the private key of the TSA. The structure of the TSTInfo construct is as follows:
The messageImprint field contains the cryptographic hash of the file that was timestamped while genTime reflects the time when the timestamp token was created by the TSA. If the timestamp request contained a nonce, the same nonce value must be repeated here.
How To Review Timestamp Response Structure
You may be wondering how one can parse the timestamp response and review its contents manually. The timestamp response is a Distinguished Encoding Rules (DER)-encoded file expressed in Abstract Syntax Notation One (ASN.1)—isn’t that a mouthful? You can review its contents with a tool such as ASN.1 Editor. You will find that the contents of the timestamp response look something along these lines (cropped for brevity):
RFC 3161 Trusted Timestamp Verification
Verifying the trusted timestamp requires a few steps:
First, the hash of the timestamped file should be compared to the messageImprint field of the timestamp token to make sure that the timestamp response belongs to the file whose timestamp we are verifying.
If the above hashes match, then the timestamp request and response are validated against each other. For instance, if the timestamp request contained a nonce, the same nonce should be present in the corresponding timestamp response. The cryptographic hash algorithm specified in the timestamp request should match the messageImprint algorithm in the timestamp response, etc.
Finally, the timestamp response itself is validated. This involves verifying the digital signature of the signed timestamp data, as well as checking the certificate chain to make sure that the chain can be verified to a trusted root or top-level certificate authority.
Some trusted timestamping service providers such as DigiStamp offer a web-based interface where end-users can drag files to have them timestamped or have previously-created timestamps verified. It is also possible to verify trusted timestamps using tools such as OpenSSL (see below) or using the tool that requested the timestamp. When using a web-based service, it is important to ensure that hashing is performed on the client-side rather than on the server. That is, the actual file you are timestamping is not transmitted to the server.
How Can One Perform RFC 3161 Timestamping?
One of the benefits of RFC 3161 timestamping is that the Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) defined in the RFC is an Internet standards track protocol. Therefore, it has broad support and RFC 3161 timestamps can be obtained and verified using numerous tools. This was important in our decision to implement RFC 3161 in Forensic Email Collector as well—we wanted to make sure that the trusted timestamps could be verified by an independent third party without requiring specific commercial tools.
For example, here is how one can create a timestamp request using OpenSSL:
The timestamp response can be obtained from the TSA using curl as follows:
Contents of the timestamp response can be queried as follows:
At this point, the hash reported from the timestamp response should be checked against the hash of the target file that was timestamped. If the hashes do not match, the timestamp does not belong to the file and verification failed.
Finally, the timestamp response can be verified using OpenSSL as follows:
The CAfile switch above is optional but comes in handy to input multiple certificates in PEM format for certificate chain verification. One would typically add the certificate of the TSA’s certificate authority (CA) using this switch.
Alternatives to RFC 3161?
When it comes to trusted timestamping, RFC 3161/5816 is not your only option. One can certify that a data point existed before a certain point in time in a few different ways. For example:
1. Poor Man’s Trusted Timestamping — Email
A quick and easy way to certify that a data point existed before a certain point in time is to send the data, or its cryptographic hash, via email and retain the incoming email from the recipient’s inbox. If a trusted email provider that DKIM and ARC signs messages (including the entire message payload) is used, this can serve as proof that the data existed before it was emailed.
Needless to say, this method has a few downsides. Let’s say an end-user calculated a reasonably strong cryptographic hash of an important business document and emailed the hash to themselves via Gmail. The incoming email would need to be preserved in a forensically sound manner and would need to be authenticated by a forensic examiner. This is not nearly as simple a process as verifying an RFC 3161 timestamp. Additionally, email servers are not designed to keep as accurate time as Time Stamping Authorities, nor are they audited regularly for time accuracy—there can be time differences between the mail transfer agents that are involved in the transmission of the email.
2. Blockchain-based Timestamping
Another mechanism that can be used to certify that a data point existed before a certain point in time is a blockchain. In a nutshell, a blockchain consists of a list of blocks that are cryptographically connected to each other. As new blocks are created, the list grows. Blocks typically contain a cryptographic hash that points to the previous block as well as a timestamp*. Because of the distributed and decentralized nature of a blockchain, a data point can be added to the blockchain as part of a transaction in an immutable manner, and its presence can serve as proof that the data point existed before a certain point in time.
While most of us are familiar with blockchains because of the increasing popularity of cryptocurrencies, a paper from 1991 introduces the concept as a means to securely timestamp documents. In their paper titled “How to Time-Stamp a Digital Document“, Haber and Stornetta discuss improving the security of a trusted timestamping authority by chaining requests together to form a chronological record and using a decentralized system.
While there are quite a few blockchain-based timestamping services available, I feel that blockchain-based timestamping has not gained enough popularity to dethrone RFC 3161 yet—at least in the legal use case. In my view, one of the missing pieces is standardization. Blockchains operate in different ways, have varying transaction costs (some very high for the timestamping use case), and have varying levels of timing accuracy. For example, Bitcoin blocks are created approximately once every 10 minutes while Ethereum blocks are produced once every 15 seconds on average. Moreover, due to the lack of standardization and adoption, it is harder to instruct a third party to verify a blockchain-based timestamp independently—without having to go through a service provider.
Having said that, blockchain is positioned to be the perfect candidate for this task and I expect to see blockchain-based timestamping gain more and more traction in the near future. For example, take a look at this article about Solana.
Conclusions
Trusted timestamping as defined in RFC 3161 allows digital forensic examiners to certify that they were in possession of specific electronic information at a certain point in time. This can be the hash of a forensic image, data acquired from social media or a website, the results of an email collection, or anything else where timing is of the essence. By leveraging trusted timestamping, it is possible to create an immutable record that can easily be verified by others without having to use specialized software. While most digital forensics tools do not automatically timestamp their output, it is possible to add trusted timestamping to your workflow using free and open-source tools.
* This is stated in very simple terms. See this thread for more information on Ethereum as an example.
References:
RFC 3161: Internet X.509 Public Key Infrastructure Time-Stamp Protocol (TSP) — https://datatracker.ietf.org/doc/html/rfc3161
RFC 5816: ESSCertIDv2 Update for RFC 3161 — https://datatracker.ietf.org/doc/html/rfc5816
RFC 5652: Cryptographic Message Syntax (CMS) — https://datatracker.ietf.org/doc/html/rfc5652
Arman Gungor is a certified computer forensic examiner (CCE) and software developer. He has been appointed by courts as a neutral computer forensics expert as well as a neutral eDiscovery consultant. Arman is passionate about doing digital forensics research, developing new investigative techniques, and creating software to support them.