Hardware Security Modules with KeyControl

A hardware security module (HSM) is a physical device that stores, protects, and manages cryptographic material. An HSM is often used to do cryptographic processing as well, including the generation of secure cryptographic keys. It is used in a client-server environment, which means that the server and the client each need to be prepared in advance. Using an HSM allows you to protect cryptographic keys and data, such as the Admin key and information you have stored in your vaults.

If you use multiple HSM servers and/or KeyControl Vault nodes to provide high availability of your services, you must ensure that all HSM servers are accessible from each KeyControl Vault instance.

When you configure an HSM, it does not automatically immediately start to protect data. You must regenerate the Admin key if you wish to store it in the HSM, and a Vault Admin must enable HSM protection in any vault where you want the HSM to protect keys or other material. See the documentation for the particular vault type: 

If using an nShield HSM you can also configure it as a root of trust for the system. For more information, see Adding HSM Root-of-Trust to nShield Server .

When an HSM is used with BYOK, keys are never stored as plaintext. In-memory keys are also encrypted (wrapped), except for software-protected keys in Azure. When a software-protected key has to be uploaded to Azure, KeyControl unwraps it before upload. For other keys, including hardware-protected keys on Azure, when KeyControl has to upload them to the cloud, it encrypts (wraps) them in the HSM using the master key and the cloud provider's wrapping key before uploading the wrapped keys to the cloud.

KeyControl supports the following HSMs: 

  • nShield HSM

  • nShield as a Service (nSaaS)

  • Luna HSM
  • Luna Cloud HSM

Requirements and Recommendations for nShield HSM Servers

The nShield HSM client version 13.6.3 is included in KeyControl. Only nShield HSMs compatible with the 13.6.3 client are supported. The minimum HSM firmware version for BYOK and KEK generation is 12.70. You can also use either the on-premise nShield HSM or nShield as a Service (nSaaS).

Note: If you plan to use Entrust Elliptic Curve Cryptography (ECC), you must have the appropriate licensing to support this feature.

The following details apply where nShield HSMs are configured in a FIPS 140-2 Level 3 compliant Security World environment:

Security World Files—For each nShield HSM, the following files must be present and up to date in KeyControl. These files are supplied in the world.zip file uploaded when configuring the HSM:

  • world

  • A module_<ESN> file for each module that KeyControl uses

  • A cards_<IDENT> file for each card set that is to be used

  • A card_<IDENT>_<NUMBER> file for each card in each card set that is to be used to provide FIPS authorization

These files are not updated automatically. You must ensure that they are synchronized whenever the Security World is updated on the module. For more information, see ‘Creating a Security World’ in your HSM User Guide. The updated files should be in included in a world.zip archive and updated using the 'Upload Security World' action on the nShield HSM Server Settings page.

Important: The Security World must be created for nShield client software version 13.6.3 or later.

Smart cards—When using an nShield HSM with a FIPS 140-2 Level 3 Security World, a FIPS authorization token is required to authorize most operations, including the creation of keys. This is provided by an ACS or OCS card must be loaded in the HSM or presented using a remote admin client. Cards are usually configured when setting up an HSM, so Entrust recommends leaving one of the configured OCS cards in the HSM slot to satisfy this requirement.

Smart card serial numbers—nShield HSMs include a security feature that checks the serial numbers of the cards as well as checking they are part of an OCS for this HSM. This allows the admin to disable a card that is mislaid for example. In KeyControl, you can specify whether all cards are accepted, no cards are accepted, or cards in a specific list are accepted. Card serial numbers are 16 decimal digits and, if you enable the option, KeyControl checks that the card in use matches one of the serial numbers listed.

For additional details, see your nShield documentation https://nshielddocs.entrust.com or the nShield support site https://nshieldsupport.entrust.com.

Requirements and Recommendations for Luna HSM Servers

You can configure the nodes in your KeyControl cluster to either connect to the HSM using one certificate that they all share or with individual certificates for each node. The KeyControl nodes can also be connected to multiple HSM servers that have been configured as an HA Group to allow for High Availability. For more information, see Configuring KeyControl as a Luna HSM Client with a Single Cluster Certificate and Configuring KeyControl as a Luna HSM Client with Individual Node Certificates.

Note: If you have a Luna HSM server with the ipcheck feature enabled, you must use unique node certificates.

  • The Luna client version 10.5.1 is included in KeyControl. Luna client 10.5.1 is compatible with HSMs running Luna 6.2.1 or higher.

  • Bandwidth recommendation:

    • Minimum: 10 Mbps half duplex
    • Recommended: 100 Mbps full duplex

  • Latency recommendation:

    • Maximum: 500 ms
    • Recommended: 0.5 ms

  • TCP port 1792 is required to establish a trusted connection between KeyControl and Luna. The other ports used are:

    • TCP port 22 for SSH (Secure Shell).
    • TCP port 1503 for Remote PED. This is the only configurable port.
    • UDP port 514 for the Syslog service.
    • UDP port 123 for NTP service.
    • UDP ports 161/162 for SNMP service.

For additional details, see your Luna HSM documentation.

Related Topics