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:
- 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 Server
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):
Ability to configure multiple TSA profiles in ADSS TSA Server
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!
Choice of hash algorithms when configuring TSA Profile Settings
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:
- When discussing TSA Server performance in terms of timestamp transactions per second (TPS) you really need to try and understand the underlying assumptions. There are many aspects which can affect TSA performance and you may be shown performance data which is possible under lab conditions but never in real production use. TSA Server performance is based on so many factors:
- Where is the TSA response time measured – on the client or on the server?
- How large is the TSA server signing key?
- Are all transactions securely logged
- What is the CPU and memory specifications of the TSA server and the database
- Is an HSM being used and what signing speed does it offer
- Which database is being used and is it on the same machine as the TSA Server
- Are the timestamps requests authenticated (e.g. using SSL client certificates)?
As an example, in our testing we are able to achieve an average of 200 Timestamp Transactions Per Second (TPS) using a TSA Server Key of 2048-bit in software mode. The ADSS TSA Server was installed on an Intel core i7 2.66 GHz machine with 4GB RAM. SQL Server 2005 EE database was used on a separate machine (Intel Core 2 duo 2.93 GHz and 4GB RAM).
- The TSA server should have a scalable architecture to take advantage of multi core CPUs and multiple physical CPUs. Two or more servers should be able to work together as a single managed system behind a network load-balancer to avoid the operational overheard of managing individual TSAs!
- Ensuring high availability for a TSA Server requires the use of multiple instances working behind a network load-balancer so that if one server fails the overall TSA service is not impacted. It should be possible for multiple instances to be operated at different sites to ensure a disaster at one site does not take the TSA service down. Virtualization can also play its part here. It is important to ensure that all components of the TSA service can be replicated, such as databases and HSMs. It is important to note that if TSA signing keys and certificates cannot be cloned between HSMs then the TSA Responder needs to support the automatic use of alternate keys and certificates per server.
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
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:
- How many TSA service transactions were received within a particular date range
- Which TSA clients were making the most TSA requests within a particular date range, and be able to group each of these transactions
- What was the transaction load managed by each logical TSA server profile
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
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.
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?
This article describes some of the high-level must have features for a TSA Server. Naturally Ascertia ADSS TSA Server scores very highly against all these points. An evaluation version of ADSS TSA Server is available for download from the Ascertia website here
For more information Email: email@example.com