Timestamp Authority Server - the must have features!

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.

Although the main focus of this topic is technical there are of course also commercial aspects that need consideration, these are summarised at the end. The features explaineTime monitoring & TSA service shut-down settings in ADSS TSA Serverd here are all available and implemented in the Ascertia ADSS TSA Server, which is available for free evaluation.

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:

Support for Multiple Timestamp Authority (TSA) Profiles

Some organisations have a requirement to deploy multiple logical TSA servers each with unique policy parameters, time accuracies and TSA signing keys. It should therefore be possible to establish multiple virtual TSA servers all from the same physical machine with easy central management console, and lower total cost of ownership when compared to having separate TSA servers with dedicated hardware and software costs. The following screenshot shows the ADSS TSA profile configurations (the number of TSA profiles allowed depends on the license):

Timestamp Authority Appliance Vs Build Your Own

In the past appliances have been seen as attractive options to avoid post-sales installation and configuration issues. Today virtualisation techniques are in demand to provide better CPU, memory, disk resource and energy management. The ability to run a virtual appliance is therefore highly desirable.

ADSS TSA Server has been designed to run both as a virtualised service or if preferred in a dedicated platform. Either way the power and performance and hence throughput of the ADSS TSA Server can be determined by the IT department. The system platform, database, backup strategy and all other choices can fit in with the IT strategy.

Traditional appliance approach tends to constrain resilience, performance and throughput and this is certainly true over the course of 3 to 5 years. ADSS TSA Server empowers an organisation to select what it wishes in these areas and grow as it needs. It is important to note that ADSS TSA Server is so well documented that Ascertia does not routinely need to provide professional services, instead a Quick Guide enables the software to be installed and running in around 30 minutes or less.

TSA Algorithm Support & Key Management

Cryptographic algorithms are continually weakening as the computing power available per dollar grows and as a result of continued cryptanalysis effort by the crypto community. It is therefore essential that an effective TSA Responder is capable of meeting future challenges, especially because TSA keys need to be around for 10, 15 or 30+ years. As a minimum it means that the TSA Server must provide flexibility when generating keys. The current norm is 2048-bit RSA keys but 4096-bit RSA keys should also be supported for future needs. Support for the Elliptic Curve signature algorithm ECDSA should also be provided since this provides greater security using much shorter key lengths. Having both algorithms available means that the investment is automatically protected against technology issues or changes.

With regards to algorithm agility the main focus of the crypto community is currently on the hash algorithms that are used to calculate the input document hash fingerprints as well as within the TSA signing process. SHA-1 has been used in the vast majority of implementations until recently, however FIPS is now recommending that SHA-2 algorithms be used instead. The SHA-2 algorithms include SHA-256, SHA-384 and SHA-512 and a TSA server must be able to use these. Note that the security community has already started work on the SHA-3 set of algorithms!

Another important aspect with regards to key management is the principle of “key separation”. Your TSA Server must be capable of using separate crypto keys for separate functions, e.g. timestamp issuance, SSL Server key (when it is acting as the SSL server to clients), log signing, etc. Each key should be managed with its own policy.

The TSA Server Public Keys should be certifiable by either internal or external CAs using PKCS#10 certificate requests and PKCS#7 certificate responses.

TSA Server Performance, Scalability & Resilience

Generally customers are aware of the importance of performance and scalability for an online TSA Server which may be contacted by hundreds of TSA clients simultaneously. Performance figures are usually created by a marketing department, so there are a few things to watch out for:

TSA Server Security

Security is critical issue for a TSA Server. Such security cannot be bolted on and needs to part of the design. Ascertia recognises the value of the ETSI CWA 14167-1 standard for trustworthy systems in this area and has designed ADSS Server to comply with this. This is an overlooked area and an area where other technology solutions and in particular open source products need to be reviewed with care. The major security features to look for are:

Auto Archiving configuration in ADSS TSA Server

Management Reporting

As the use of the TSA Server grows within multiple systems and business applications, it is important for the TSA service providers to be able to get meaningful data on the TSA service performance. This is essential within a commercial TSA service that is metered and run within a SLA. Such management reporting data may include:

This information should be digestible in easy to understand manner using pie-charts and tables. The management reports should be exportable in PDF and CSV formats so that they can be imported into Adobe® Reader, Microsoft Excel and other databases for example. The following screenshots show some reports and associated settings for management reporting in ADSS TSA Server:

TSA service report

TSA Service usage report

Standards Compliance

There are a number of standards in the area of timestamping which vendors must comply with, including:

There are a number of other cryptographic and general security standards which the product vendor must comply with including: PKCS#11, PKCS#10, PKCS#7, NTP, TLS/SSL etc.

Billing Option

Some customers require a facility where timestamp services can be charged for using pre-purchased credits. In this scenario the TSA Server must first authenticate the TSA client (either the actual client itself or an organisation proxy) using e.g. SSL client authentication. Once authenticated the TSA Server must then check if the user holds sufficient credit for the transaction to proceed. This credit check can be done via an external web services call to a credit server. If the credit server responds that transaction should be allowed the TSA Server can then return the timestamp to the client. As part of completing the transaction the TSA Server must also inform the credit server that the timestamp was successfully provided so that the user’s credit can be deducted. If whilst checking if the user has enough credit the result is negative, then the TSA can return a suitable error response to the user. Ascertia can provide this billing option within ADSS TSA Server as part of a project delivery.

TSA Server Commercial considerations

Commercial issues have a high priority when choosing a TSA server product, with sensible TSA server pricing being highest on the list. Occasionally you may find per timestamp transaction or usage limit charges, which can really push up the pricing for a TSA server in the long term. Generally it should only be server-based pricing with unlimited users. Test and pre-production test TSA servers should be low or zero license price. Competent suppliers should also be able to provide the necessary TSA test tools that measure TSA performance as well as service monitoring tools.

Finally before making an investment in TSA Server technology check whether the vendor has the right long-term strategy - are they investing in future protocols such as Long-Term Archive & Notary Service (LTANS)? Does the product support signature creation on the same platform, at low cost, so that you can e.g. do long-term document signing from one application?