KeySafe 5 v1.6.1 User Guide

Introduction

The KeySafe 5 platform (KeySafe 5) is a system to enable the management of an estate of HSMs through a web-based graphical user interface. KeySafe 5 also contains a REST API which can be used directly if required to provide custom management of the estate.

The central management platform of KeySafe 5 is deployed as a Kubernetes application. For each nShield host machine that you want to manage using this platform, you must install a KeySafe 5 agent alongside the existing nShield hardserver, see nShield KeySafe 5 agent.

For additional information on installing, upgrading, and deploying KeySafe 5, refer to the Installation and Upgrade guide.

KeySafe 5 architecture

Host Machines

Each host machine can have one or more HSMs installed, and a single Security World. The HSM estate monitored by KeySafe 5 is located on one or more host machines.

For each nShield host machine that you want to manage with KeySafe 5, you must install a KeySafe 5 agent alongside the existing nShield hardserver on the host machine, see nShield KeySafe 5 agent.

nShield KeySafe 5 agent

On each host machine in your estate that you want to monitor with KeySafe 5, the KeySafe 5 agent service is required. The KeySafe 5 agent runs alongside the existing hardserver. The KeySafe 5 agent ensures that all key management data, with the exception of keys, is synchronised between the nShield host machine and the central database. This information is then shared with each host machine in the Security World that has the KeySafe 5 agent running.

HSM Pool

An HSM Pool is a collection of HSMs that are managed together, and which communicate using a KeySafe 5 agent. When you load a Security World into an HSM Pool, the Security World will be loaded onto all the HSMs in the HSM pool. The KeySafe 5 agent synchronises the configuration of the HSM pool with all other HSM pools in the Security World. For example:

  • When you create a new Card Set or Softcard (either through KeySafe 5 or manually) on a host machine, it will be synchronised to all HSM pools in the same Security World.

  • When you delete a Card Set or Softcard using KeySafe 5, that deletion will be applied by the agent to all HSM pools in the same Security World. However, if you delete a Softcard without using KeySafe 5, that deletion will not be applied to other HSM Pools in the same Security World.

An HSM can only be in one HSM pool at any time unless it is network-connected. However, the HSM can be moved between machines in the usual manner, and KeySafe 5 will reflect this change. An HSM may have the HSM Pool’s Security World loaded.

An nShield Connect may be enrolled into multiple HSM Pools, but it can only have one active Security World at a time.

Security World

Each HSM Pool can make use of a single Security World. Loading a Security World into an HSM Pool will result in that Security World being loaded onto all the HSMs in the pool. A single Security World may be loaded on multiple HSM Pools across many host machines.

For details of Security World use in KeySafe 5, see Security Worlds. For full details of Security World use, refer to the Security World documentation.

Operations and authorizations

When performing an operation on the command-line, it must be performed in a single step. For example, creating a Security World. Here, all parameters must be specified, all cards inserted, and their passphrases entered.

With KeySafe 5 this is separated into two steps: creating an operation, and then authorising it. When creating an operation all the parameters for that operation are requested. The operation is then listed in a list of outstanding operations for the Security World to which it belongs, see Outstanding operations.

Whenever a user is required to present a card or a passphrase to complete an operation, an authorization is created. For example:

  • Security World creation requires writing a new Administrator Card Set so will require 'BlankCard' authorizations.

  • Security World loading requires presenting an existing Administrator Card Set so will require 'AdminCard' authorizations.

  • Operator Card Set creation requires writing a new Operator Card Set so will require 'BlankCard' authorizations.

  • Softcard creation requires setting a passphrase so will require a 'Passphrase' authorization.

If there is a specific order that the authorizations must be provided then a subset of the authorizations may initially be in 'Blocked' state.

Examples:

  • In a FIPS-140-2-level-3 Security World, operations such as OCS or Softcard creation require an initial FIPS authorization (presentation of an Administrator or Operator card from the Security World) to authorize the operation. In this case a 'FIPS' authorization is created that must be completed before any other authorization types.

  • Creating a Security World with a quorum of 2/4 cards in the ACS on a pool with 2 HSMs results in 6 authorization requests. The first 4 will be to create the Administrator Card Set on one HSM, and the subsequent 2 will be to load the Security World onto the other HSM.

In local management of nShield Security World software the use of nShield Remote Administration smart cards is controlled by an Authorized Card List located at %NFAST_KMDATA%\config\cardlist. In this release of KeySafe 5, no restrictions are enforced on which smart cards may be presented to HSMs via KeySafe 5, regardless of the contents of any existing cardlist files.

Customer security responsibilities

There are a number of third-party components that are required for correct KeySafe 5 operation, but which are not provided with KeySafe 5. These are considered the responsibility of the customer/operator.

It is the responsibility of the customer to:

  • Ensure that the Web Browser contains all the latest security updates from the Web Browser provider.

  • Ensure that only authenticated users, that are trusted not to perform malicious actions, are given access to the KeySafe 5 system

  • Ensure the integrity of any components that is downloaded from an external source. For example, by verifying the downloaded component using trusted 'hash fingerprints' or signatures.

  • Ensure that a component is updated when an impacting CVE is published for the component.

  • Ensure that all components are configured in a secure fashion and deployed in a secure environment.

  • Ensure that all third-party components are configured in a secure fashion. For example, all third-party components should use mutually-authenticated secure channels to communicate with the KeySafe 5.

  • Ensure that all certificates and keys, used for securing the communications between the third-party components and KeySafe 5, are uncompromised and of sufficient security strength.

  • Ensure that the permissions required to access any sensitive configuration items are sufficient. For example, the permissions to access and manipulate a third-party component’s server certificates and their associated private key should only be provided to authorised and trusted administrators.

  • Ensure that the external identity provider that is providing the bearer token used to authenticate the KeySafe 5 user implements a bearer token with a short lifetime. That is, the bearer token is reissued regularly, as this will mitigate the impact of a compromised bearer token, which would allowing unapproved access to KeySafe 5 for a prolonged period.

  • Ensure that a threat analysis of the KeySafe 5 deployed environment has been performed, and that the results of this analysis justify any changes of KeySafe 5 default configuration.