French
DeutschANSI ASC X9.95 Standard
The ANSI X9.95 standard for trusted timestamps expands on the widely used RFC 3161 - 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:
- authenticity: trusted, non-refutable time when data was digitally signed
- integrity: protection of the timestamp from tampering without detection
- timeliness: proof that the time of the digital signature was in fact the actual time
- an evidentiary trail of authenticity for legal sufficiency
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.
Definitions
[edit]
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.
- Time source entity - Most countries have an official source of time and this has been codified over the last hundred years through any number of Mutual Recognition Agreement's and Legal Metrological Agreements (see http://www.oiml.org for more information on Legal Metrology). Why this is important is now that the Internet has made it possible to reach directly into the laboratory that operates the official source of time for that jurisdiction, the many layers of "middlemen” who stood between the end-user and the source of time are now gone. As such, time that can be shown as traceable to the specific national measurement institute or master clock of that jurisdiction is the only source that provides the approved "Time Calibration Source" for X9.95. Examples include NIST in the US and Bureau International des Poids et Mesures (BIPM). Other regulatory frameworks also require that time that is moved through the Network Time Protocol ntp is properly certified and authenticated meaning unauthenticated use of time from any provider will fail X9.95 requirements for obtaining time in a provable manner.
- Time Stamp Authority (TSA) - The issuer of timestamps, which can be internal to an organization or a third party or external (as in an Internet-based service). The TSA receives its provable "trusted time" from one or more reliable time sources and generates the timestamps requested from it according to the X9.95 scheme.
- requestor - The entity requesting a timestamp.
- verifier - The entity that verifies a timestamp. A verifier can be a relying party, regulatory body, or entity that employs a third-party verification service.
- relying party - The entity receiving the timestamp. The relying party uses the time stamp token in operations.
Creating a timestamp
[edit]
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.
Verifying a timestamp
[edit]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:
- The hash in the time stamp token matches the data
- The TSAs cryptographic binding
- The requestor's digital signature
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 3161 protocol [TSP] and the ISO/IEC 18014 standards [ISO] yet extends its analysis and offerings. The X9.95 standard can be applied to authenticating digitally signed data for financial transactions, regulatory compliance, and legal evidence.