Cryptographic Timestamping

graphic of Cryptographic Timestamping

What Time is it?

In a previous post we mentioned the importance of using cryptographic timestamping to avoid issues related to expiring and, in some cases, revoked certificates. But what is cryptographic timestamping, how does it work, and how can enterprises take advantage of it to safeguard their data?

What is Cryptographic Timestamping

Imagine you are trying to prove when something occurred. Perhaps you are in a legal dispute with your insurance provider and you need to show that the insurance agreement was signed by both parties before some unfortunate incident occurred. Your insurance company is claiming that you signed the agreement after-the-fact and the court is putting the burden of proof on you. How can you prove that the document was signed before the incident? One way to do this is via cryptographic timestamping.

In general, cryptographic timestamping is a method of securely tracking date-related information for data using cryptographic techniques such as digital signatures, hash functions, etc. When properly implemented, cryptographic timestamps provide strong assurances about when the data was last modified (or, more correctly, the latest possible date & time the data was last modified). The most commonly used implementation is the Time-Stamp Protocol (TSP) defined in RFC 3161, although other implementations exist such as Microsoft’s Authenticode Time Stamping and some distributed systems based on Merkle Trees.

How it Works

The high-level idea for the process is shown below:

Cryptographic Timestamping flow

1. A client creates some data

2. A client sends the hash of the data to the Time-Stamp Authority (TSA)

3. The TSA combines the hash with the current timestamp

4. The TSA signs the combined data with its own private key

5. The TSA sends the client the signature, timestamp, and its certificate (the timestamp response)

6. The client stores the timestamp response along with the data (either in attached or detached form)

In the future any system that reads the data can verify the signature against the hash of the data, the TSA-provided timestamp, and the TSA’s certificate (note: the system must also verify the TSA’s certificate chain but that is outside the scope of this post). If either the data or the timestamp has been altered, the signature will not validate. Therefore, if the signature validates successfully then the system can reliably trust the timestamp on the data. 

There are three important things to note:

1. Privacy – The client only sends the hash of the data and since hashes can’t be reversed the TSA doesn’t know what is being signed.

2. Time Interpretation – Nothing stops a client from timestamping data that was created further back in time. Therefore, a cryptographic timestamp doesn’t prove when data was created but rather it proves that the data existed no later than the timestamp date.

3. When vs Who – In most cases, the TSA doesn’t authenticate the client (although some TSAs support authentication) and even if it does the timestamp response doesn’t contain any identity information about the client. Therefore, timestamping doesn’t prove who authored, owns, or last modified the data, it only provides evidence as to when the data could have last been modified.

Use Cases

One of the most common use cases of cryptographic timestamping is to extend the lifetime of digital signatures on code, documents, and backup files. Since the signing certificates (code signing, document signing, etc.) typically have relatively short lifetimes (e.g., 1 to 3 years) as compared to how long the signed code, documents, and backups will be needed, cryptographic timestamping allows tools to verify that the code and documents were signed before the signing certificate expired and thus the signatures should still be considered valid post certificate expiration. This is possible because the TSA’s certificate usually has a very long lifetime, much longer than the signing certificate’s lifetime. Without timestamping, all code, documents, and backups would need to be resigned each time the corresponding signing certificate expires which would be extremely tedious and impractical. Similar reasoning can be applied to revoked certificates. By timestamping your signed data you can avoid issues with your legitimately signed data being invalidated by a certificate that is revoked after your legitimate data was signed.

Another use is in e-Discovery and other legal proceedings. By cryptographically timestamping backups enterprises can prove to the court that the data hasn’t been altered since the backup was taken thereby increasing the chances that the data can be used as evidence. In fact, some municipalities have standards for assigning legal value to qualified digital signatures.

A third use is very relevant today. Ransomware attacks are on the rise and the industry is still figuring out the best ways to combat them. One thing that everyone agrees on is that being able to quickly recover from these attacks is critical to continuing operations. One of the first things enterprises do when they are the victim of a ransomware attack is to try to restore systems from backup. But how do you know if your backup is still in a good state or if it has been altered by the attackers? Cryptographic timestamping provides a quick, easy, and cost-effective way to verify the state of your backups relative to when they were taken.

Enterprise Recommendations

The classic “5 W’s and H” apply when implementing cryptographic timestamping in an enterprise setting. A systematic approach to take is as follows:

1. Who should be my TSA – Back in the day it was possible to get a timestamping certificate from a publicly trusted Certificate Authority (CA) and be your own TSA. Sadly, these days publicly trusted time stamping certificates are very hard to come by. Luckily, many CAs run a timestamping service for free to the public that enterprises and individuals can make use of. However, like any free service it must be used with care. Some TSAs have been known to throttle power users which can cause downstream tools to have unexpected failures. A way to mitigate this is to use an internal TSA (i.e., one issued from an internal PKI) for data that is only needed to be trusted inside an enterprise’s network, and use a publicly trusted TSA for everything else. Another method is to distribute your requests to a mix of publicly trusted TSAs so that you don’t overload any single one of them.

2. What should be time stamped – Cryptographic timestamping doesn’t break anything (sometimes detached signatures are needed) and the storage requirements are small so it is usually good practice to timestamp all important data. Some good candidates are backups, code, and important documents.

3. When should data be time stamped – Ideally, data should be time stamped as soon as it is created or authored. In some cases, the data will be time stamped at multiple different times. For example, a document might be signed by different parties and each signature will be time stamped when it is produced. Then, the document may be stored as part of a backup file and the containing backup file will also be timestamped.

4. Why should timestamping be used – Because it is a cost effective and efficient way to prove when some data was last authored (or when the latest possible time was that the data was last modified to a given state).

5. Where should the timestamp be stored – Some data formats natively support timestamping and so the cryptographic timestamp is stored in the data structure and is referred to as an “attached” or “embedded” signature or timestamp. In other cases the timestamp is stored separately and is referred to as a “detached” signature or timestamp.

6. How should timestamping be done –  Some tools natively support cryptographic timestamping. Of these tools, some will give you an option to timestamp (e.g., the -tsa switch in jarsigner, the /tr switch in signtool, etc.), and others will automatically and transparently perform timestamping for you (e.g., some PDF tools). Enterprises should ensure that signing tools that don’t automatically timestamp are configured and used in a manner where timestamping is employed.

Are you interested in using cryptographic timestamps to protect your enterprise? The Garantir team has a wealth of experience deploying digital signature solutions including ones with advanced cryptographic timestamping use cases. Contact us to discuss your needs. 

Share this post with your network.