The ANSI X9.95 standard for trusted timestamps expands on the widely used - Internet X.509 Public Key Infrastructure Time-Stamp Protocol by adding data-level security requirements that can ensure data integrity against a reliable time source that is provable to any third party. Applicable to both unsigned and digitally signed data, this newer standard has been used by financial institutions and regulatory bodies to create trustworthy timestamps that cannot be altered without detection and to sustain an evidentiary trail of authenticity. Timestamps based on the X9.95 standard can be used to provide:
A superset of the IETF's RFC 3161 protocol, the X9.95 standard includes definitions for specific data objects, message protocols, and trusted timestamp methods, such as digital signature, MAC, linked token, linked-and-signature and transient-key methods. X9.95 compliance can be achieved via several technological approaches, such as transient-key cryptography. Several vendors market X9.95-compliant systems.
In an X9.95 trusted timestamp scheme, there are five entities: the time source entity, the Time Stamp Authority, the requestor, the verifier, and a relying party.
Before a timestamp-service commences operations, the Time Stamp Authority calibrates its clock(s) with an upstream time source entity, such as a legally defined master clock for the jurisdiction the TSA is time-stamping evidence for. When trusted time has been acquired, the TSA can issue timestamps for unsigned and digitally signed data based on all of the jurisdictions it maintains timing solutions for.
Applications using timestamps on unsigned data can provide evidence to a verifier that the underlying digital data has existed since the timestamp was generated.
When a requestor requires a trusted timestamp for a piece of data, it creates a hash of the data using a cryptographic hash function and sends it to the TSA (through a network connection). The TSA then signs the hash and the time of signature to create a trusted timestamp. This trusted timestamp is finally returned to the requestor, who can store it along with the data.
For applications using digitally signed data, the requestor signs the digital hash with its private key and submits the digital signature to the TSA, which performs the same operations as in the previous example: bind the submitted data with a timestamp using its cryptographic binding and return the results to the requestor.
When the requestor receives the timestamp token from the TSA, it also optionally signs the token with its private key. The requestor now has evidence that the data existed at the time issued by the TSA. When verified by a verifier or relying party, the timestamp token also provides evidence that digital signature has existed since the timestamp was issued, provided that no challenges to the digital signature's authenticity repudiate that claim.
Timestamp tokens in open timestamping models can be obtained from different TSAs on the same data and can be verified at any time by a third party.
When verification is needed, the verifier uses the RSA public key for the purported interval to decrypt the timestamp token. If the original digital hash inside the token matches a hash generated on the spot, then the verifier has verified:
These three verifications provide non-repudiable evidence of who signed the data (authentication), when it was signed (timeliness) and what data was signed (integrity). Since public keys are used to decrypt the tokens, this evidence can be provided to any third party.The American National Standard X9.95-2005 Trusted Time Stamps was developed based on the RFC