Security Guidance

The key material used by the TSS (e.g. the TSA signing key) is protected by its internal nShield HSM that is initialized into your Security World. However, as with all secure systems, administrators must remain diligent when it comes to who uses the system, see the security-related recommendations below. The network traffic between the TSS and its different communicating entities is protected by different mechanisms:

  • The confidentiality and integrity of network traffic between the TSS and TSMC is protected using the DS/NTP protocol, where PKI certificates are used for mutual authentication, before the secure channel is created.

  • The confidentiality and integrity of network traffic between the TSS and computer hosting the browser of the Security Office or Network Manager, is protected by the HTTPS protocol, where PKI certificates are used for server authentication.

  • There is no protection explicitly provided for the confidentiality or integrity of the network traffic passed between the TSS and the user (who is using an RFC3161 based interface to request a Time Stamp Token (TST) for the TSS). The TST, produced by the TSS, contains implicit integrity protection, provided by the TSA signature (which should be verified by the user, as indicated in RFC3161). The RFC3161 protocol explicitly excludes authentication of the user and does not include provision for authentication of the server (i.e. TSS).

  • When Local Audit is selected, the NTP server is assumed to be running on a trusted local network.

Entrust make the following security related recommendations when operating the TSS:

  • The network environment of TSS should be suitably protected to maintain its availability (e.g. through use of firewalls, intrusion detection/prevention systems).

  • Standard virus prevention and detection measures should be taken on the platform hosting the TSS.

  • All available security patches should be applied in a timely manner to the platform hosting the TSS.

  • Only authorized system administrators should have access to the TSS and only essential trusted software should be run on the platform hosting the TSS.

  • Only authorized and trusted individual should be assigned the roles of Security Officer and Network Manager, and it is assumed that they will not perform any malicious operations that would degrade the security of the TSS.

  • Make sure log levels are set appropriately for your environment. More verbose log levels may expose information that is useful for auditing who uses TSS, but the log information will also contain which administrative and user operations have been performed. While this may be useful for diagnostics, be aware that this log information could be considered sensitive and should be suitably protected when stored.

  • The inactivity timeouts set for HTTPS sessions to both the Security Officer or Network Manager should be set to appropriate values that manage both the potential risk of use by an unauthorized individual and usability.

  • Make sure that all certificates created have a chain of trust to a trusted root certificate.

  • The user must verify that TSA’s Certificates have not been revoked before using the TST (as indicated in RFC3161) and the Security Officer should remove from service any TSA Certificates that have been compromised/revoked.

  • TSA certificates and keys should have appropriate key lengths and cryptoperiods, that reflect the sensitivity of the artefacts for which the TST are being created.

  • On first usage of the TSS, operators should make sure that they replace both the Security Officer/Network Manager default usernames and passwords with unpredictable values, and for the passwords, values that contain sufficient randomness (as dictated by the security policy of the operator).