Product overview

Roles and responsibilities

The TSS supports the following types of users:

  • Security Officer: to handle the key and certificate management

  • Network Manager: to manage the day-to-day operations.

Security Officer

The Security Officer is responsible for completing all tasks related to the installation of the TSS, including:

  • Contracting with an auditing service provider

  • Preparing the TSS environment

  • Configuring the TSS

  • Creating and certifying TSA keys

  • Certifying upper clocks.

Network Manager

The Network Manager is responsible for:

  • Enabling or disabling time-stamping and auditing

  • Configuring audit settings.

Features

nShield PCIe module

The TSS uses an integrated nShield PCIe module with Secure Execution Engine (SEE). All cryptographic functions such as processing, time-stamping, and clock operations are performed within the module. The module also meets the internationally recognized FIPS 140-2 at Level 3 standard.

Public Key Infrastructure (PKI) technology

The TSS uses the PKI technology to ensure authenticity, integrity, and traceability of information. The PKI technology validates not only the time used for issuing a time-stamp, but also the actual time-stamp issued by the TSS. In PKI-based time signings, the actual document or file to be time signed does not leave your computer. When you request a time-stamp, a message digest of the file is created using a one-way hash function. The original file cannot be modified without invalidating this hash. The PKI technology provides the following benefits:

  • Privacy: only you can see the message

  • Integrity: you receive what was actually sent

  • Non-repudiation: the sender cannot deny they sent the message

  • Authenticity: you can be sure of the identity of the person who sent the message.

Certificates for signing and authentication

The TSS uses X.509 public key certificates to sign the time-stamps and audit records. A public key certificate is issued by a Certification Authority (CA), and is used for authenticating the identity of a person, or business entity, or system device.

Support for leap second events

The TSS offers complete support for leap second events.

Compliance with IETF standards

Internet Engineering Task Force (IETF) is an international organization that sets standards for internet protocols in their Request for Comment (RFC) papers. The TSS implements time-signing as specified by the IETF PKIX Time-Stamp RFC (RFC3161).

Time-stamp protocol support

The TSS supports the following time-stamp protocols:

  • RFC3161 Socket Base Protocol on TCP/318

  • RFC3161 Time-stamp Protocol by HTTP at the following URL: http://<tss-hostname>/TSS/HttpTspServer

  • Authenticode Time-stamp Protocol by HTTP at the following URL: http://<tss-hostname>/TSS/AuthenticodeTS

In these URLs, <tss-hostname> represents the IP address or domain name of your TSS.

By appending the tsa= query string to the RFC3161 or Authenticode URLs above, it is possible to access a specific TSA. This query string can accept either a TSA’s number (e.g.tsa=tsaid_<tsa number>) or the TSA’s name. For example:

  • TSA number: http://<tss-hostname>/TSS/HttpTspServer?tsa=tsaid_1

  • TSA name: http://<tss-hostname>/TSS/AuthenticodeTS?tsa=exampleTSA

If specifying the TSA number, tsaid must be in lower case. Otherwise, the TSA name is case sensitive.

Getting an auditing service provider

Before you begin, ensure that you are contracted for auditing services with an auditing service provider. For information about service providers, contact Entrust nShield Support, https://nshieldsupport.entrust.com.

After you have signed your agreement with your auditing service provider, your provider will supply you with, at a minimum, the entire certificate chain for all upper clocks and the IP address for all upper clocks you will be using.

TCP/IP and UDP requirements

Your service provider will require the TCP/IP and UDP information regarding the TSS. The TSS listens, by default, on the following TCP/IP or UDP ports for time-stamp, Datum Secure Network Time Protocol (DS/NTP), and administrative functions:

Listens on: For:

UDP/user-configured port

DS/NTP audits when configured to use an upper clock. If using an upper clock, you must configure a unique UDP port number for each TSA. See Configuring a TSA for the instructions.

TCP/318

RFC3161 Socket-Based Time-Stamp protocol (TSP).

TCP/80 and TCP/443

HTTP and HTTPS connections. HTTP and HTTPS are used for the administrative user interface. HTTP also supports:

  • RFC3161 TSP over HTTP (http://<tss-hostname>/TSS/HttpTspServer).

  • Authenticode TSP over HTTP (http://<tss-hostname>/TSS/AuthenticodeTS).

Understanding Security Worlds

The Security World is a paradigm or construct that provides secure life-cycle management for cryptographic keys. Key management involves procedures and protocols used throughout the life cycle of cryptographic keys. These procedures and protocols include the generation, distribution, use, storage, destruction, and optional archiving and disaster recovery of cryptographic keys. The Security World infrastructure enables you to perform and control all these activities under your chosen security policy. A Security World consists of the following components:

  • At least one nShield module.

  • An Administrator Card Set (ACS) requires access to Security World configuration and recovery operations.

  • Optionally, one or more Operator Card Sets (OCS) for controlling access to application keys.

  • Some cryptographic key and certificate data. The data is encrypted using the Security World key and stored on the hard disk.

The Security World key can be restored as it is stored on the hard drive.

Security

The Security World has been designed to ensure that keys remain secure throughout their life cycle. The Security World uses multiple interlocking keys, and because of this, each key is always protected by another key, even during recovery operations. The keys in the TSS are never available in the plain text format. When a Security World is created, a cryptographic key is generated. This key protects the Time Stamping Authority (TSA) keys and card sets that are later created and used in that Security World.

Administrator and Operator Card Sets

A Security World uses smart cards for both administering and operating the TSS. The Administrator Card Set (ACS) is used to control access to recovery functions. One or more OCS are used to protect access to signing operations for the TSAs in the TSS. You can create any number of OCS within a Security World.

In FIPS 140-2 Level 3 Security Worlds, smart cards are required to authorize some operations, including the creation of keys and card sets.

All card sets are distinct. An individual smart card can only belong to either the ACS or to a specific OCS. Each user can access the keys protected by the Security World and the keys protected by their OCS. They cannot access keys that are protected by any other OCS.

The smart cards that are used in an OCS use the Security World key for a challenge-response operation with the TSS. This means that Operator Cards can only be used in a TSS belonging to the same Security World.

Each card set must consist of (K of N) smart cards, where:

  • N is the total number of smart cards in the card set.

  • K is the required number of cards (or quorum) required to authorize an action.

The value for K must be less than N. We recommend that you do not set K equal to N, because an error on one card will render the card set unusable. If this happens with your ACS, you must replace your Security World and generate new keys.

A Common Criteria CMTS Security World requires a 2-of-2 ACS.

FIPS 140-2 compliance

FIPS 140-2 Level 2 is the default setting for the Security World. However, when you create a Security World, you can choose whether you want compliance with the roles and services section of the FIPS 140-2 standard at Level 2 or Level 3. This choice influences the algorithms, key sizes, and curves available.

A Security World that complies with the roles and services section of FIPS 140-2 Level 2 does not require any authorization to create an OCS or an application key.

FIPS 140-2 Level 3 compliance

This option is included for those customers who have a regulatory requirement for compliance with FIPS 140-2 Level 3.

A Security World that complies with FIPS 140-2 Level 3 requires authorization from any smart card that is part of the Security World’s ACS or an OCS, before you can create or erase an OCS. If you create a Security World that complies with FIPS 140-2 Level 3, the TSS initializes in FIPS mode. This option ensures that the hardware security module (HSM) in TSS complies with the roles and services, key management, and self-test sections of the FIPS 140-2 Level 3 standard, as described in its validation certificate. For more information about FIPS validation, see https://csrc.nist.gov/projects/cryptographic-module-validation-program.

Using Operator Card Sets to protect keys

If you want to restrict key access to a particular user, you can create a set of smart cards known as an OCS. An OCS belongs to a specific Security World. An OCS can be read, erased, or formatted only by a TSS that is within the Security World of the OCS. An OCS stores a number of symmetric keys that are used to protect the working TSA keys. Each card in an OCS stores only a fragment of the OCS keys. These keys can only be re-created if you have access to a sufficient number of fragments (K). Because cards sometimes fail or are lost, the number of fragments required to re-create the key (K) must be less than the total number of fragments (N).

The Security World key can be restored as it is stored on the hard drive.

Using card sets for extra security

If you want to create a card set for extra security, you need to make K large and N less than twice K (for example: 3 of 5, or 5 of 9). This practice ensures that if you have a set of K cards that can be used to re-create the key, you can be certain that there is no other such set in existence.

Using pass phrases

You can optionally assign a pass phrase for each Operator Card. The pass phrases are independent. You can assign pass phrases only to a few cards in a card set. To change a pass phrase of a card, you require the card, the existing pass phrase, and a TSS that belongs to the Security World.

A pass phrase can contain a maximum of 255 characters and only those that are accepted by a HTML form.

Using persistent Operator Card Sets

When you create an OCS, you can decide whether or not to make the OCS persistent. However, the property that you choose cannot be modified later.

If you create a standard (non persistent) OCS, the TSA keys protected by the card can only be used while the card—or the last card loaded from a card set—is in the TSS smart card reader. The keys protected by this card are removed from the memory of the TSS as soon as the card is removed from the smart card reader. Although this feature provides added security, it means that only one user can load keys at any time.

If you create a persistent OCS, the keys protected by a card persist after the card has been removed. The TSS maintains strict separation between the TSA keys loaded by each user, and each user can access only those keys that are protected by their OCS.

TSA keys protected by a persistent card set are automatically removed from the TSS:

  • After the time limit specified during the card set creation

  • When the Clear button on the nShield PCIe module is pressed

  • When the TSS is restarted.

A Security World can contain a mix of persistent and non-persistent card sets.

Resilience

The Security World ensures that in the event of a disaster, you can recover the TSS without compromising the security of the system, providing that you back up the system regularly.

Backup and recovery

Ensure that you back up the following on a regular basis:

  • The %NFAST_KMDATA% directory

  • The %NFAST_HOME%\dse200\UserFiles directory. This directory contains the log files and the configuration files for your TSS.

If an attacker obtains the backup data, they cannot use it without the encryption keys stored in your nShield PCIe module and the Administrator cards for that Security World.

When you create a Security World, it automatically creates recovery data for the Security World key. This data is encrypted and the cryptographic keys that protect this data are stored on the ACS. The keys are split among the cards in the ACS using the K-of-N mechanism.

The ACS protects several keys that are used for different operations. The cards in the ACS are only used for recovery operations and adding additional modules to a Security World. At all other times, these cards should each be stored separately, in secure locations.

In FIPS 140-2 Level 3 Security Worlds, the ACS or an OCS is also used for controlling the creation of keys and OCSs.

Replacing the ACS

If you lose one of the smart cards from the ACS, or if the card fails, you must immediately create a replacement set using the racs command-line utility.

When using the racs utility, you cannot redefine the quantities in a K of N relationship for an ACS. The K of N relationship defined in the original ACS persists in the new ACS.

The TSS does not store recovery data for the ACS. It relies on there being at least enough smart cards to reach the number of cards in the quorum K from the original N cards created. Therefore, it can re-create all the keys on the TSS even if the information from one of the cards is missing.

Although replacing the ACS deletes the copy of the recovery data on the host, the old ACS can still be used with the old host data, which may be on backup tapes and other hosts. To protect against this risk, you must immediately erase the old Administrator Cards after you create a new ACS.

Risk management

Although a Security World can manage keys and control which user has access to which keys, it cannot prevent a trusted user from using a key fraudulently. For example, a Security World can only determine whether a user is authorized to use a TSA key. It cannot determine whether the message being time-stamped with that key is accurate. To protect the security of your system, ensure that you:

  • Keep your smart cards safe.

  • Always obtain smart cards from Entrust.

  • Never use your TSS and smart cards with an untrusted smart card reader.

  • Keep your pass phrase secure.

If you suspect that the security of a key or the Security World has been compromised, you must replace that key or Security World with a newly generated one.