Home / Blog / Trusted timestamping

Trusted timestamping

Posted on 11/18/2014, by Jesús Díaz (INCIBE)
Trusted timestamping

Trusted timestamping is a cryptographic function with fewer use cases than more common methods such as encoding or hashing. However, it can be very useful on multiple occasions. In brief, a timestamp is a time mark that guarantees that certain information existed at a given time.

It has various applications. For example, it can be used for visas and electronic betting so that the data can’t be modified afterwards (to extend the validity of the visa or create winning bets once the result of the event is known); to protect authorship, as it enables proving the possession of information before its publication; or for the protection of system logs so that they can’t be manipulated afterwards to alter the temporary sequence associated with an incident, etc.

There are many kinds of trusted timestamps. There are systems that include the timestamp instant (date and UTC time for example); and there are others that establish a timestamp chain, where an explicit timestamp instant is not necessarily introduced. In the latter, rather than proving existence at a specific time, what is proven that certain information existed before another: this is known as linked timestamping. There are also systems that base their entire security on the trust placed on an authority, the Time Stamping Authority (TSA), and decentralised systems (e.g. Bitcoin based) that do not have that dependence. In this post we will see various practical cases of these last two types in operation.

Conventional stamping: trustworthy authorities and RFC 3161

The most classic solution is the one based on Time Stamping Authorities. The trust placed on these authorities is similar to that placed on certification authorities for X.509 PKI’s. In other words, for a corrupt authority it would be trivial to change the issued timestamps. In fact, what a TSA does is sign the petitions of the timestamps their clients receive, including the moment in time that the signature is issued. Obviously, a TSA does not "simply" return signatures of the received data.

In the RFC 3161 a total of 11 requisites for TSA’s are established. Amongst those requisites, regarding timestamp information introduced in messages sent by TSA’s, the first three stand out:

  1. The TSA must use a reliable time source (in this aspect, the RFC 3628 gives indications regarding requisites for TSA’s).
  2. The TSA must include a reliable timestamp value for each timestamp token.
  3. The TSA must include a unique integer for each newly generated timestamp token.

RFC 3161 also establishes the syntax of requests and responses, the type of timestamping information (including information regarding the provided precision), and different transport options: e-mail, files, sockets or HTTP, with the possibility of incorporating new mechanisms.

In particular, responses must have the following structure:

TimeStampResp ::= SEQUENCE {
   status PKIStatusInfo,
   timeStampToken TimeStampToken OPTIONAL }

The “important” field is the timestamp Token, which will contain a timestamp marker signed by the TSA.

Testing free services

Openssl provides the ts command (openssl ts) which implements utilities for clients and servers compatible with RFC 3161. With these commands you can generate, process and verify requests and responses. Besides, openssl provides the sget tool, which implements a timestamping client that uses HTTP(S) as a transport mechanism. Finally, there are also available authorities that, also using HTTP(S) as a means of transport, attend timestamping petitions free of charge.

To try timestamping out, time.certum.pl may be used (whose root certificate, Certum CA, belonging to Unizeto Technologies S.A., is installed by default in Firefox), or safecreative.org’s authority, that allows up to five daily requests free of charge.

For example, in order to obtain a timestamp from the file file.txt, the process is as follows (where it is possible to exchange the URL of time.certum.pl by that provided by safecreative.org, or any other authority that complies with RFC 3161):

$ openssl ts -query -data file.txt -cert | tee file.tsq | tsget -h http://time.certum.pl -o file.tsr

To verify the response, the -cert modifier is important, as it makes the authority include the employed signing certificate. After this step, it is possible to print the request and response, or verify the latter with the following commands:

# Print the request in text format
$ openssl ts -query -in file.tsq -text
# Print the response in text format
$ openssl ts -reply -in file.tsr -text
# Verify the response using the root certificate CA at CA.crt
$ openssl ts -verify -queryfile file.tsq -in file.tsr -CAfile CA.crt

One observation: when printing the request, note that the data sent to timestamp is not directly the contents of the file, but its hash.

By default, openssl uses SHA1, although this can be controlled by specifying the hashing algorithm in use (for example –sha256 or –sha512). This is especially important, since a timestamp should be robust over time and, in this case, the election of an adequate hash function is essential. The following image shows an example of a response:

Status info:
Status: Granted.
Status description: unspecified
Failure info: unspecified
TST info:
Version: 1
Policy OID: 1.2.616.1.113527.2.2.5
Hash Algorithm: sha1
Message data:
0000 - 63 bb fe a8 2b 88 80 ed-33 cd b7 62 aa 11 fa b7 c...+...3..b....
0010 - 22 a9 0a 24  "..
$ Serial number: 0x038D7EA78B6DAC
Time stamp: Oct 22 09:23:43 2014
GMT Accuracy: 0x01 seconds, unspecified millis, unspecified micros
Ordering: no
Nonce: 0x975E8BC93BAA2694
TSA: DirName:/C=PL/O=Unizeto Technologies S.A./OU=Certum Certification Authority/CN=Certum
Time-Stamping Authority Extensions:

Distributed timestamping with Bitcoin

With the arrival of Bitcoin, services that use its original infrastructure to create timestamps have also appeared. With these services, following Bitcoin’s decentralisation model, it is not necessary to trust in any central authority, but in the cryptographic properties of Bitcoin instead.

Although, in this case, the objective is normally to include a function that indicates the data that needs timestamping in the Bitcoin blockchain, the method varies from one proposal to another.

For example, BTProof creates Bitcoin addresses from the data to timestamp. These addresses are not "normal" addresses, as they do not have public or private passwords associated to them (since they have not been generated following the "usual" procedure). Therefore, once a payment is made to this address, it will appear in the blockchain and, since there is not private password associated to it, the money it contains cannot be spent and the transaction cannot be "pruned", so it will always appear on the blockchain.

To verify timestamps, it suffices to repeat the process for obtaining the address and look up the blockchain (via blockexplorer, for example). The block where the associated transaction has been introduced will include the date in which it was added to the chain.

Another similar option is Crypto Stamp. In this case, a similar procedure is followed, but to minimise the number of transactions, all the data that is going to be timestamped on a same day is brought together using a Merkle tree (which implies a timeframe of timestamping of at least a day). In this case, the Bitcoin address is derived from the root of the Merkle tree.

- Merkle tree from the timestamp for the message "Crypto Stamp is born" -

The act of grouping together every transaction (for their timestamping) from a same day in one Merkle tree has various implications. On one hand, the maximum precision of the timestamp is of one day. On the other, the number of transactions are reduced, cutting down the cost of the service and minimising "dust" transactions (term used in Bitcoin for small transactions).

Lastly, and most importantly, to verify a timestamp it is mandatory to have information from the Merkle tree where the hash of the timestamped content has been included. From there, it is possible to reconstruct the Bitcoin address where the payment has been made. Crypto Stamp stores this information in a .csp (Crypto Stamp Proof) file that can be downloaded and processed with utilities available from the website itself.

Given the nature of Bitcoin, it’s inevitable that every service based on this system has an associated cost. However, some are practically free. BTProof, for example, has a minimal cost of 1 satoshi (approximately 0.00000001 bitcoins, around 0.000003€ with the current exchange rate), although it is recommendable to use larger quantities as, in order to avoid congestions online, miners and main clients tend to ignore such small transactions. In Crypto Stamp, the payment made for a transaction is of 0.00000001 BTC that, along with the necessary fee for miners, is covered by the service itself.

Both BTProof and Crypto Stamp offer API’s to interact with their services.

Integral solutions

As indicated at the beginning, this cryptographic function has important applications. In fact, there are multiple products that incorporate this function as part of a more complete solution (to issue electronic receipts sent by email, contracts, etc.). There are also a number of Spanish products of these types such as eGarante that, amongst other services, enables you to obtain a free email timestamp by putting the address mailsigned@egarante.com in carbon copy; evicertia, that allows you to register and have three free certifications, as part of a trial mode besides paid subscriptions; and the aforementioned safecreative.