Hardware Security Modules with Cryptographic Security Platform Vault

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 Cryptographic Security Platform Vault nodes to provide high availability of your services, you must ensure that all HSM servers are accessible from each Cryptographic Security Platform 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:

Cryptographic Security Platform Vault for Cloud Keys—Managing Key Sets.
Cryptographic Security Platform Vault for KMIP—KEK with a KMIP Vault.
Cryptographic Security Platform Vault for Secrets—Hardware Security Modules with Cryptographic Security Platform Vault for Secrets.
Cryptographic Security Platform Vault for Databases—Configuring a Cryptographic Security Platform Vault Database Connector, Configuring Cryptographic Security Platform Vault for Oracle TDE, Configuring Cryptographic Security Platform Vault for MariaDB TDE, Creating a Cloud VM Set for the Cryptographic Security Platform Vault for Databases
Cryptographic Security Platform Vault for Cryptographic APIs—Signing in to the Vault for the First Time.
Cryptographic Security Platform Vault for VM Encryption—KEKs with Cloud VM Sets, Creating a Cloud VM Set for the Cryptographic Security Platform Vault for VM Encryption.

If using an Entrust 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, Cryptographic Security Platform Vault unwraps it before upload. For other keys, including hardware-protected keys on Azure, when Cryptographic Security Platform Vault 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.

Cryptographic Security Platform Vault 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.8 is included in Cryptographic Security Platform Vault. 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: Elliptic Curve Cryptography (ECC) was an optional feature on nShield HSMs with firmware versions before 13.5. In order to use such HSMs with the Cryptographic Security Platform Vault for Cloud Keys or the Cryptographic Security Platform Vault for Cryptographic APIs containing Elliptic Curve Keys, you must have the feature enabled. You can check the feature status using the HSM's fet command.

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 Cryptographic Security Platform Vault. These files are supplied in the world.zip file uploaded when configuring the HSM:

world
A module_<ESN> file for each module that Cryptographic Security Platform Vault 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 Cryptographic Security Platform Vault, 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, Cryptographic Security Platform Vault 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 Cryptographic Security Platform Vault cluster to either connect to the HSM using one certificate that they all share or with individual certificates for each node. The Cryptographic Security Platform Vault 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 Cryptographic Security Platform Vault as a Luna HSM Client with a Single Cluster Certificate and Configuring Cryptographic Security Platform Vault 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 Cryptographic Security Platform Vault. 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 Cryptographic Security Platform Vault 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.