Cryptomathic Time Stamping Authority

Technical White Paper

Cryptomathic TSA Technical White Paper

 2003, Cryptomathic A/S. All rights reserved

Jægergårdsgade 118, DK-8000 Aarhus C, Denmark

This document is protected by copyright. No part of the document may be reproduced in any
form by any means without prior written authorization of Cryptomathic.
This document is provided “as is” without warranty of any kind.
Cryptomathic may make improvements and/or changes in the product described in this
document at any time. The document is not part of the documentation for a specific version or
release of the product, but will be updated periodically.

www.cryptomathic.com

Cryptomathic A/S Cryptomathic Ltd Cryptomathic NV Cryptomathic GmbH

Jægergårdsgade 118 329 Cambridge Science Interleuvenlaan 62/box19 Rosenheimer Str. 116
DK-8000 Aarhus C Park B-3001 Leuven GB91-9/11
Denmark Milton Road Belgium D- 81669 Munich
Tel.: +45 8676 2288 Cambridge CB4 0WG Tel.: +32 (0) 16 39 48 22 Germany
Fax: +45 8620 2975 United Kingdom Fax: +32 (0) 16 39 48 21 Tel.: +49 (89) 234-20931
Tel.: +44 (0) 1223 225350 Fax: +49 (89) 234-20932
Fax: +44 (0) 1223 225351
Postal Address:
Cryptomathic GmbH
P.O. Box 800 949
Balanstr. 73
D- 81609 Munich
Germany

Date: 2004-05-12
Doc. title: Cryptomathic TSA Technical White Paper
Doc. version: 1.1

2
Cryptomathic TSA Technical White Paper

Table of Contents
1 Introduction.............................................................................................4
1.1 Contact Information .................................................................................................. 4
1.2 Terminology.............................................................................................................. 4
1.3 References ............................................................................................................... 4
2 Introduction to Time Stamping..............................................................5
2.1 Digital Notary Services ............................................................................................. 5
2.2 Digital Signatures and Non-Repudiation .................................................................. 5
2.2.1 Digital Signatures with Time Stamps ................................................................................................... 6
2.2.2 Code Signing ....................................................................................................................................... 7

2.3 Standards ................................................................................................................. 8

3 Domain Description................................................................................9
3.1 Time Stamps and Time Stamp Requests ................................................................ 9
3.2 Certificates ............................................................................................................... 9
3.3 Policies ................................................................................................................... 10
4 System Architecture.............................................................................11
4.1 CTSA Server .......................................................................................................... 11
4.1.1 Cluster Support .................................................................................................................................. 12

4.2 CTSA Administration Clients.................................................................................. 12

4.3 Time stamp Clients................................................................................................. 12
5 Security Design.....................................................................................13
5.1 Access Control ....................................................................................................... 13
5.1.1 Administrator Roles............................................................................................................................ 13
5.1.2 Administrator Authentication .............................................................................................................. 13

5.2 Client Server Communication ................................................................................ 14

5.3 Audit Log ................................................................................................................ 14
5.4 Key Management ................................................................................................... 14
5.4.1 Hardware Security Modules............................................................................................................... 15

3
Cryptomathic TSA Technical White Paper

1 Introduction
This document provides an introduction to Cryptomathic Time Stamping Authority
(below, CTSA). It includes an introduction to time stamping in general and describes
the overall domain and architecture of CTSA with particular focus on security design.
The intended audience is IT-security managers, solution architects and security
experts who are interested in time stamping and consider using CTSA. The reader is
assumed to be familiar with the basic concepts of a Public Key Infrastructure.

1.1 Contact Information

If you need further information about Cryptomathic Time Stamping Authority or any
other Cryptomathic product, you are always welcome to contact us. Contact
information can be found on page 2.

1.2 Terminology
Term Meaning
CA Certification Authority
CTSA Cryptomathic Time Stamping Authority
HSM Hardware Security Module
NTP Network Time Protocol
SCR Smart Card Reader
SNTP Simple Network Time Protocol
TSA Time Stamping Authority

1.3 References
[1] C. Adams, P. Cain, D. Pinkas, R. Zuccherato: Internet X.509 Public Key
Infrastructure – Time Stamp Protocol (TSP), RFC 3161, August 2001.
[2] D.L. Mills: Network Time Protocol (Version 3) — Specification,
Implementation and Analysis, RFC 1305, March 1992.
[3] D.L. Mills: Simple Network Time Protocol (SNTP) Version 4 — for IPv4,
IPv6 and OSI, RFC 2030, October 1996.

4
Cryptomathic TSA Technical White Paper

2 Introduction to Time Stamping

By using an independent time stamping service provided by a trusted third party, a
unique and unforgeable time stamp can be assigned to any piece of digital data. The
time stamp makes it possible to prove that this particular data existed at a certain point
in time.

2.1 Digital Notary Services

Time stamps are an important means to protect intellectual property rights; e.g. to
secure electronic documents and communication pertaining to patents.
Time stamps may also be required on electronic documents related to legal
proceedings, on annual reports etc. Such applications of time stamping have already
made their way into legislation in several European countries.

Notary Archive

time stamp
on data

time stamped data

Originator Recipient

Figure 1: A notary provides time stamping – and possibly also archiving – services.
In short, electronic time stamping is applicable for all purposes where traditional
notary services apply in the non-digital world. The need for such services is, however,
much more pertinent in the digital world, as electronic documents are easier to forge
and backdate than traditional paper-based ones.

2.2 Digital Signatures and Non-Repudiation

An equally important application is time stamping of digital signatures. One of the
reasons for applying digital signatures to documents and transactions is to achieve
non-repudiation. The digital signature captures the contents of the transaction or
document and links it uniquely to the signer. The validity of a digital signature hangs
on two things: (1) the signature must match the signed data, and (2) the signer’s
certificate must be valid. Now, certificates can be revoked and will eventually expire.
This does, of course, not change the validity of signatures made prior to the
revocation or expiration, but without a reliable time stamp, it may not be possible to
prove that the signature was actually made before the certificate lost its validity.

5
Cryptomathic TSA Technical White Paper

2.2.1 Digital Signatures with Time Stamps

Figure 2 below shows a scenario where a person is able to first sign a message and
then successfully disavow the signature.

Figure 2: As B cannot prove that the signature was made before the
certificate was revoked, the court may decide to accept A’s claim.

Thus, for the recipient of a digital signature the challenge is to prove that the signature
was generated at a time, when the signers certificate was valid. As illustrated in
Figure 3 below, the required proof is obtained by having the document and signature
time stamped by a Time Stamping Authority.

6
Cryptomathic TSA Technical White Paper

Figure 3: A time stamp on the signed message proves that A’s key was still valid,
when the signature was made. As a result, A does not have a case.

Thus, in a Public Key Infrastructure, the TSA takes on the role of a trusted third party
to provide true non-repudiation.

CA TSA

validate time stamp

certificate on signature

exchange of signed data

Recipient Signatory

Figure 3: A Time Stamping Authority in a Public Key Infrastructure.

2.2.2 Code Signing

To assure the authenticity and protect the integrity of executable code, it is normally
signed, particularly if the code is made available for download via the Internet. The
certificate used for validating the signature is delivered together with the signed code.
Without any reliable indication of the time of signing, however, the validity of the

7
Cryptomathic TSA Technical White Paper

signature is bound to the certificate. This means that when the certificate expires, the
code is no longer considered trustworthy, and the publisher is forced to re-sign the
code with a new certified key.
By applying a time stamp at the time of signing, the publisher can assure that the code
will be trusted also after the certificate expires.

2.3 Standards
The relevant standards for implementation of a TSA are:
• Internet X.509 Public Key Infrastructure Time-Stamp Protocol, RFC 3161
• Network Time Protocol (Version 3), RFC 1305
• Simple Network Time Protocol (Version 4), RFC 2030

Time-Stamp Protocol
The RFC 3161 Time Stamp Protocol (TSP), see [1], defines the TSA’s role in a
Public Key Infrastructure and sets the requirements for the TSA service. It specifies
the formats of time stamp requests and responses and describes transport protocols.

Network Time Protocol

The RFC 1305, see [2], defines Network Time Protocol (NTP) Version 3 and
supersedes RFC-1119 (NTP Version 2, September 1989).

Simple Network Time Protocol

The RFC 2030, see [3], defines Simple Network Time Protocol (SNTP) Version 4. It
is a sub-set of NTP Version 3 and only suitable for NTP clients – not for NTP servers.

8
Cryptomathic TSA Technical White Paper

3 Domain Description
Cryptomathic Time Stamping Authority implements a TSA, which can be used for
providing non-repudiation and notary services. The TSA is responsible for issuing
time stamp tokens that can prove the existence of data at a particular point in time.
Cryptomathic Time Stamping Authority complies with the RFC 3161 time stamp
protocol.

3.1 Time Stamps and Time Stamp Requests

Getting a time stamp on a piece of data, e.g. a message, a document or a transaction,
involves sending the hash value of the data to CTSA together with a request for a time
stamp. The time stamp requests are sent to the CTSA server from time stamp clients
via TCP/IP. As only the hash value is sent, the data is never revealed to the TSA.
Provided that the request conforms to the required format (as specified in [1]), CTSA
will then return a time stamp token that includes the hash value and is signed by the
TSA.
Included in the time stamp token is also a reference to the policy under which the time
stamp is issued (see paragraph 3.3).
A time stamp request may specify that certificates should be included in the time
stamp response. Therefore, CTSA provides functionality for importing and storing
TSA and CA certificates and for selecting certificates to be included in time stamps.

3.2 Certificates
Two types of certificates are relevant in connection with the CTSA system: TSA
certificates and CA certificates.

TSA Certificates
A TSA certificate is a certificate on a key used in CTSA for signing time stamps.
CTSA can have several TSA certificates but only one active certificate at a time.
Generating a new TSA certificate involves generation of a key pair and creation of a
self-signed certificate. Self-signed certificates can be used for signing time stamps,
but it is also possible to use a certificate issued by an external CA. In the latter case, a
certificate request on the TSA public key is exported from CTSA and the resulting
certificate is subsequently imported.

CA Certificates
CA certificates can be imported into the CTSA system. Normally, one would want to
import the certificate (or certificate chain) of a CA that has certified a TSA key, but in
principle, any certificate can be imported into the system. The certificates may be
included in time stamps issued by the TSA in cases where a requesting entity has
specified a desire for this. In such cases, the active TSA certificate, i.e. the certificate

9
Cryptomathic TSA Technical White Paper

on the active key, is always included in the time stamp token. It can be configured
which CA certificates, if any, to include.

3.3 Policies
All time stamps issued by the TSA are issued under a specific policy, which describes
the possible use and limitations of the time stamp. CTSA may issue time stamps
under different policies depending on the requirements of the requester. In each case,
the policy under which a time stamp was issued will be specified in the time stamp
token.
When an entity requests a time stamp, it may be specified under which policy the time
stamp should be issued. If no policy is specified, the time stamp will be issued under
the default policy. Therefore, one of the policies created in the system must be set as
the default policy. If the specified policy is not supported by CTSA, no time stamp
will be issued.

10
Cryptomathic TSA Technical White Paper

4 System Architecture
The Cryptomathic Time Stamping Authority server resides in a secure room and is
administered via the two types of administration clients (secure and remote client, see
paragraph 4.2).

Secure Room

CTSA TCP/IP Network

Time
Source CTSA Service HSM
Remote SCR
administration
client
Secure SCR SCR
Database administration
Server client SCR

Time stamp
client

Cryptomathic TSA System Overview

4.1 CTSA Server

The CTSA server handles all commands sent from the CTSA administration clients as
well as requests sent by the time stamp clients. The server is multi-threaded allowing
simultaneously processing of several requests. The CTSA server uses:

Database Server
The CTSA system stores all data in the database. The only exceptions are the keys of
the HSM, the system administrator log and the trace log.

Hardware Security Module

The private key used to sign time stamp tokens as well as the symmetric key
protecting the audit log are generated and managed by a HSM.

Time Source
CTSA supports accessing external time sources using the NTP protocol to ensure
correct time stamps. The frequency with which the external time source is queried is
configured from the CTSA administration client: It may be done every time a time
stamp is issued, or it may be done at a frequency specified in seconds.

11
Cryptomathic TSA Technical White Paper

4.1.1 Cluster Support

To enhance availability as well as throughput, several CTSA servers can be set up in a
cluster. Each server will then have its own HSM but they will all use the same
database server. Furthermore, it is possible to install multiple HSMs on a single
CTSA server, which is also a means of furthering availability and throughput in case
the HSM is the bottleneck.

4.2 CTSA Administration Clients

The CTSA system has two types of administration clients: a secure and a remote one.
The two administration clients are basically equal. However, the secure client offers
the full functionality for setting up and administering the system including the
functionality for performing security related operations, whereas the remote client
only provides the possibility for performing a limited number of day-to-day tasks.
Due to this constellation, the secure client must run inside the secure room and always
be installed on the same machine as the CTSA server. The remote client can be
installed on any computer on the network.
Administrators log on to the administration clients using smart cards. Therefore, two
smart card readers must be connected to each client.

4.3 Time stamp Clients

The time stamp clients request the time stamping service of CTSA by sending time
stamp requests in accordance with the required format as defined in [1] to the CTSA
server. The issued time stamp tokens are sent directly back to the time stamp clients
from the server.
For convenient integration of time stamping into an application, an SDK is available
as part of the Cryptomathic PrimeInk Premium pack. It is an API provided in ANSI C,
which enables integration into almost any application. The API provides the functions
for creating a request, verifying the token sent in response and getting the value of the
various fields of the token. For further information on Cryptomahtic PrimeInk
Premium, please contact us; contact information can be found on page 2.

12
Cryptomathic TSA Technical White Paper

5 Security Design
Cryptomathic Time Stamping Authority has been designed to meet a number of
requirements with regard to security. The measures taken to meet these requirements
are presented in the following.

5.1 Access Control

For each command sent from one of the CTSA administration clients to the CTSA
server, there is a set of requirements that must be met before it can be executed. These
requirements include the number of administrators that consent to the command, the
role of the administrator, and the type of the administration client (secure or remote).
This is to prevent a single administrator from taking control of the entire system.

5.1.1 Administrator Roles

In CTSA, the following administrator roles exist:

The Security Officer, SO

The Security Officers are responsible for the secure operation of CTSA.

The Operator
The Operators are responsible for the daily monitoring and maintenance of the
system.

The Auditor
The Auditors are responsible for managing the CTSA audit log.

5.1.2 Administrator Authentication

Whenever an administrator wishes to use a CTSA administration client, he must insert
his user smart card into one of the connected smart card readers and enter the correct
password for the smart card. As long as the smart card remains in the card reader, the
administrator is consenting any commands sent from the client. This means that the
client will use the smart card to authenticate any issued command. For commands
requiring dual control, an additional administrator must insert his smart card into the
second card reader and enter the correct password. As long as the second smart card
remains in the reader, the commands sent from the client will be consented by the
second administrator as well. This means that the client will use both smart cards to
authenticate issued commands.
The actual authentication is performed using a MAC key stored on the administrator’s
smart card.

13
Cryptomathic TSA Technical White Paper

After verifying the authenticity of the administrator consenting the command, the
CTSA server determines his role. This enables the server to determine whether the
privileges required for this command are met.

5.2 Client Server Communication

Communication between the CTSA clients and server is based on the TCP/IP
protocol, which means that the clients can communicate with the server on any
TCP/IP connected network. As, however, the TCP/IP protocol does not provide strong
authentication, the administrator authentication protocol layer is employed in order to
provide the server with administrator authenticity.

5.3 Audit Log

CTSA keeps an audit log that contains information on all security-related events in the
system, including all incoming time stamp requests and all issued time stamp tokens.
Each log entry is assigned a unique serial number, and a MAC value is calculated for
each entry, which makes it possible to detect any tampering of the log. Only the
HSMs have knowledge of the audit log MAC key. The MAC is verified whenever the
audit log is viewed online, which makes it possible for auditors to detect any
modification or deletion of an entry.

5.4 Key Management

Three types of cryptographic keys are involved in connection with the CTSA system:

TSA Keys
The TSA keys are the keys used by CTSA for signing time stamps.
A TSA key is an asymmetric key pair consisting of a public key used for verifying
signatures on time stamps issued by CTSA, and a private key used for the actual time
stamp signing. Several TSA key pairs can exist in the system at the same time,
however only one key pair can be active at a time (see also paragraph 3.2).

Audit Log MAC Keys

The audit log MAC keys are symmetric keys used by CTSA to authenticate the audit
log.
There is always one active audit log MAC key, which can be re-generated at any time.
Old audit log MAC keys are, however, kept in the system in order to facilitate
verification of old log entries.

Administrator MAC Keys

The administrator keys are symmetric keys used by administrators in order to
authenticate themselves to the system.

14
Cryptomathic TSA Technical White Paper

Each administrator has one key stored on a smart card. The smart cart must be
inserted and a password must be entered each time an administrator wishes to log on
to a client (see also the description of user authentication in paragraph 5.1.2).

5.4.1 Hardware Security Modules

The TSA keys and the audit log MAC keys are generated and managed by a Hardware
Security Module (HSM). In this way, the keys are never exposed in clear and cannot
be tampered with. The keys never leave the HSM, except during initialisation when
the keys are exported in encrypted and distributed form using secret sharing
techniques so that they can be recovered in case of errors.

15