This article describes why RFC3161 compliant Time Stamp Authority (TSA) servers are needed and what to look for when choosing a Timestamp Authority (TSA) server. ETSI TS 101 861 and TS 102 023 also places important requirements for TSA services providers and these are also considered in this hot topic.
Why do you need a Timestamp Authority server?
With the move from paper to electronic records many public and private organisations are realising the importance of being able to prove that electronic records are trustworthy and have not changed since archiving. Without adequate and provable security measures it’s just not possible to prove the data has not changed to an independent party, as required for dispute resolution.
An RFC3161 timestamp server provides an essential function in protecting data records for the long-term. It provides proof that the data existed at a particular moment in time and that it has not changed, even by a single binary bit, since it was notarised and time-stamped.
A timestamp authority achieves this by cryptographically binding the data’s unique fingerprint (typically a SHA-2 hash value) with the current date and time that is synchronised with a trusted time source. This binding is achieved using strong digital signature algorithms and with a private signing key under the sole control of the timestamp authority. Using standard public key cryptographic techniques, this means only the timestamp authority can issue the secure timestamps whilst anyone who trusts the TSA certificate can verify these.
Example uses of a timestamp authority can be quite diverse, e.g. Ascertia ADSS TSA Server is being used in national infrastructure schemes such as protecting the national digital archive maintained by the British Library for the long-term preservation of all digitally published material for future generations. The British Library is a legal depository and required by law to retain published material in perpetuity, thus it needs to be able to provide assurance that an archived digital object is authentic.
Within a corporate context timestamp authorities are used to secure important business records such as financial reports & statements, invoices and receipts. Timestamps are also used to ensure digital signatures can be verifiable in the long-term as explained below.
Aren’t digital signatures enough by themselves?
We sometimes get asked – if I digitally sign a data record isn’t that enough to prove authenticity, why do I need a separate timestamp? The answer is that a basic digital signature is sufficient whilst the signer’s certificate is still valid, i.e. not expired or revoked. But typically certificates expire after one or two years, and any signatures already produced cannot be verified after this. The signer’s certificate may expire sooner than this after several months of use or even be revoked if they leave the organisation or lose control of their singing key.
To make digital signatures verifiable in the long-term, RFC3161 timestamps are essential – these are generally added to the signature at the time of signing or soon after (for instance once the details of the transaction are confirmed or after any grace period). The embedded timestamps then prove when the signature was applied and any later expiry or revocation of the signer’s certificate is irrelevant, because at time of signing the certificate can be shown to be valid. To deliver these advanced long-term digital signature techniques have been standardised by ETSI, CEN and IETF (e.g. PAdES, XAdES and CAdES).
Examples of such long-term signatures includes signed and time-stamped PDF documents and time-stamping of software code signatures, i.e. drivers and executables are time-stamped to prove their authenticity and authorship and can be verified by operating systems even after the signer’s certificate expires.
Time Source Accuracy
Naturally a timestamp server needs to reference an accurate and reliable time source, without which the trustworthiness of the entire system can come into question. According to CWA 14167-1 the TSA’s trusted time source(s) must be synchronised to Co-ordinated Universal Time (UTC) within the tolerance dictated by policy e.g. to within 1 second. It is further recommended that two independent sources of UTC are used to maintain a resilient time source. According to ETSI TS 102 023 , if the TSA's clock is detected as being out of the stated accuracy then time-stamp tokens must not be issued.
The Ascertia ADSS TSA Server implements these requirements in the following way:
- The server on which ADSS TSA Server runs should have its system time set by a suitable time source, often the datacentre time or Windows NTP servers.
- ADSS Server has an option to monitor one or more additional internal or external NTP time sources, for instance GPS NTP servers or other trusted NTP servers. ADSS TSA Server can then monitor the time from these trusted sources and compare this with system time. If the time drift falls outside a pre-configured threshold then real-time alerts can be sent to specified ADSS TSA Server administrators (using SMS, SNMP or email). Once a second threshold is exceeded then ADSS TSA Service will stop all services and the administrators are notified.
The ADSS TSA Server admin GUI screenshot shows the relevant configuration detail:
Time monitoring & TSA service shut-down settings in ADSS TSA Serve
Note the general use of Part 3 to 5 of PAdES will be limited until these are also supported in the freely available Adobe® Reader. It’s currently uncertain when Adobe Inc will do this, possibly not until 2011 when ISO32000-2 is released.
Configuring PAdES Part 2 Signatures in PDF Sign&Seal
Configuring PAdES Part 2 Signatures in ADSS Server (Step 1)
Configuring PAdES Part 2 Signatures in ADSS Server (Step 2)
PAdES is fast becoming a recognised acronym within European signature industry. It will be an important future standard and various legislations may mandate this. PAdES consists of 5 different parts, current PDF software supports PAdES Part 2 which is based on ISO 32000.
Later parts of PAdES allow the signature to be extended for long term verification by allowing ability to embed a chain of timestamps. These later parts of PAdES will eventually become a part of ISO 32000-2 (possibly in 2011/12).
Ascertia products currently support PAdES Part 2 and enhancements are due later in 2010.
References to PAdES Specifications
PAdES specifications consist of five parts:
- Part 1 is the overview – explains general features of PDF signatures.
ETSI TS 102 778 PDF Advanced Electronic Signature Profiles; Part 1: PAdES Overview - a framework document for PAdES
- Part 2 is the basic form of PadES - This is equivalent to what is already specified in ISO 32000-1.
ETSI TS 102 778 PDF Advanced Electronic Signature Profiles; Part 2: PAdES Basic - Profile based on ISO 32000-1
- Part 3 is an enhanced form of PAdES which includes an equivalent to the BES and EPES as specified in CAdES (TS 101 733) and XAdES (TS 101 903).
ETSI TS 102 778 PDF Advanced Electronic Signature Profiles; Part 3: PAdES Enhanced - PAdES-BES and PAdES-EPES Profiles
- Part 4 specifies extensions to a PDF document to carry information to support validation of signatures long after they are created. This is referred to as PAdES LTV (Long Term Validation).
ETSI TS 102 778 PDF Advanced Electronic Signature Profiles; Part 4: PAdES Long Term - PAdES-LTV Profile
- Part 5 specifies the application of XAdES signatures applied to XML within PDF documents either a general XML document or using XFA. It includes profiles to support long term validation of signatures.
ETSI TS 102 778 ETSI TS 102 778 PDF Advanced Electronic Signature Profiles; Part 5: PAdES for XML Content - Profiles for XAdES signatures