Encryption with key servers

A key server is a centralized system that generates and manages encryption keys that are used by the system. Key servers are ideal in environments with many systems, since key servers send keys to the system automatically over the network without requiring physical access to the systems.

Some key servers support replication of keys among multiple key servers. If multiple key servers are supported, you can specify up to four key servers that connect to the system over both a public network or a separate private network.

The system supports the Key Management Interoperability Protocol (KMIP), which is a standard for encryption of stored data and management of cryptographic keys.

The system supports the following key servers to handle key management on the system.
  • IBM® Security Guardium® Key Lifecycle Manager key server
  • Generic KMIP key servers
    • Thales CipherTrust Manager key server
    • Gemalto SafeNet KeySecure key server
    • Fortanix DSM key server
    • Utimaco ESKM key server
    • Entrust CSP Vault key server
    • HashiCorp Vault key server
Note: For more information on the supported key servers, see IBM Storage Virtualize Supported Key Servers.

One of the key servers defined on the system must be designated as the primary key server. The primary key server is used by the system to create new encryption keys during a rekey operation. All key servers defined on the system are used to fetch the current encryption key when required. When using key servers to manage the master key for the system, a copy of the master key is stored on each defined key server. The master key is a 256-bit AES key, generated by the key server.

When key management is configured using key servers, the system automatically fetches the key from each key server when required. Also, every 30 minutes the system will automatically validate that each configured key server is accessible and able to provide the current key to the system. The validation happens on every node in the system, to every key server defined on the system. A key server can have one of three statuses:
  • Online: the key server is accessible and able to provide the current encryption key to all nodes in the system
  • Degraded: the key server is accessible and able to provide the current encryption key to only some nodes in the system
  • Offline: the key server is not accessible and cannot provide the current encryption key to any node in the system
When planning for key server encryption, the following items are important to consider.
SSL certificates
  • IBM Storage Virtualize and key servers use SSL certificates to authenticate each other and create a secure connection.
  • The system supports certificates signed by both the internal root certificate authority and a trusted thrid-party CA.
  • The correct certificates and their certificate authority certificates must be installed in IBM Storage Virtualize and on the key servers to establish a secure connection.
  • The connection between IBM Storage Virtualize and key servers becomes interrupted if certificates are renewed or expire. Installing the certificate authority certificates prevents this interruption by allowing the endpoint certificates to be renewed without disrupting the connection.
  • IBM Security Guardium Key Lifecycle Manager key servers do not currently support chain of trust checking with IBM Storage Virtualize. The new system certificates generated must be exported to the key servers to re-establish a secure connection.
  • If you are using multifactor authentication with IBM Security Verify, the management GUI is unavailable when you update the certificate. The new certificate generated must be exported using the CLI and added as a new signer certificate to IBM Security Verify for successful authentication.
System requirements
Only one type of key server is supported at this time. The system implements the KMIP that is sent over an SSL connection between the client and the server. Support is provided for internal-signed and external CA-signed certificates. The system validates the server's SSL certificate and conforms to the KMIP standard. Existing SAS hardware needs access to at least one master key to unlock and needs to be able to respond to key server master keys. Enabling key servers for the first time is a simple procedure. Once key server encryption is enabled, the type can be configured and enabled, server end-points can be created, and then the keys can be prepared and committed.
Security requirements
Security of all key server communications is governed by TLS 1.2 and TLS 1.3 protocols. Encryption keys are distributed between nodes in the system using TLS 1.2 and TLS1.3. The system uses AES-256 encryption that uses OpenSSL library interfaces. To establish a connection between the key server and the system, the key server or services must support the configured TLS version.
IP addresses and ports

All nodes that want to communicate with key servers must have their service IP address configured. A node must have its full service IP stack configured (address, gateway, mask) in order for that node to be a candidate for attempting to contact the key server. Key servers are typically set up on a private LAN, and this requires enforcement of service IP addresses. If only a subset of nodes have service IP addresses set, then those nodes without a service IP address log an error. The IP address that the user supplies must be the one that the system uses to communicate with the key server.

Each key server has a TCP port associated with its access. Since a key server serves multiple clients, the system allows the user to use a different port for each server and enables access for this port when required. KMIP server conformance mandates that TCP port 5696 is supported, so this is the default port for the server end point.

Key generation policy and key database

If key server encryption is enabled, then the key server generates and manages the master keys. The node generates all other keys.

The key database can be clustered or unclustered depending on the type of key server that is used. For unclustered key servers, the user needs to consider backup and replication of the key database. IBM Security Guardium Key Lifecycle Manager is an example of a key server product where replication must be configured for encryption keys to be shared automatically between IBM Security Guardium Key Lifecycle Manager instances. Without replication configured, manual backup and restore operations must be used. Other products might self-replicate, so other key server instances automatically have any new keys created. For IBM Security Guardium Key Lifecycle Manager, complete backups and restores by following the IBM Security Guardium Key Lifecycle Manager user guide. The SafeNet KeySecure server and Thales CipherTrust Manager support both clustered and unclustered key servers configuration.

Using key servers with IBM Security Guardium Key Lifecycle Manager

The system supports different types of key server configurations on IBM Security Guardium Key Lifecycle Manager. The following configurations are supported:
  • IBM Security Guardium Key Lifecycle Manager key servers designate one primary key server, which can have up to three secondary key servers (also known as clones) defined. These additional key servers support more paths when it delivers keys to the system. However, during rekey operations, only the path to the primary key server is used. When the system is rekeyed, secondary key servers are not used until the primary key server replicates the new keys to these secondary key servers. Replication must be complete before keys can be used on the system. You can either schedule automatic replication or complete it manually with IBM Security Guardium Key Lifecycle Manager. During replication, key servers are not available to distribute keys or accept new keys. The total time that it takes for a replication to complete on the IBM Security Guardium Key Lifecycle Manager depends on the number of key servers that are configured as clones. If replication is triggered manually, the IBM Security Guardium Key Lifecycle Manager issues a completion message when the replication completes. Verify that all key servers contain replicated key and certificate information before keys are used on the system.
  • Key servers can also be configured with multiple primary key servers where each key server can create new encryption keys. In this instance, any server can be set as the primary key server. The primary key server is the key server that the system uses when you create any new key server encryption keys. If multiple primary servers are enabled on the IBM Security Guardium Key Lifecycle Manager, the key is immediately replicated to the other key servers in the configuration.

For more information about the supported versions, see the IBM Documentation for IBM Security Guardium Key Lifecycle Manager.

When you create key server objects on the system for IBM Security Guardium Key Lifecycle Manager key servers, you must create a device group, in addition to name, IP address, port, and certificate information. The device group is a collection of security credentials (including keys and groups of keys) that allows for restricted management of subsets of devices within a larger pool. The system must be defined on the key server to the SPECTRUM_VIRT device group if you are using the default settings. If the SPECTRUM_VIRT device group does not exist on the key server, it must be created based on the GPFS device family. If you are configuring multiple key servers, the SPECTRUM_VIRT device group must be defined on the primary and all additional key servers. If you are configuring IBM Security Guardium Key Lifecycle Manager 5.0 or later, you need to create a catalog for the specified device group in FlashSystem (for example, SPECTRUM_VIRT) under Endpoint Management > Catalog. This catalog must be based on the GPFS catalog.

If you are using IBM Security Guardium Key Lifecycle Manager to create and manage keys, ensure that you are using version 2.7.0 or later. If you are using version 2.7, the system supports one master (primary) key server and secondary key servers. Keys are not available until replication is completed between the key servers. If you use version 3.0 or higher, the system supports multiple master key servers, which automatically replicates keys to all configured key servers.

Using Generic KMIP key servers

Encryption key servers create and manage encryption keys that are used by the system. In environments with many systems, key servers distribute keys remotely without requiring physical access to the systems.

Generic KMIP key servers creates keys on demand, sharing with the other clustered servers, providing redundant access. The system supports different types of configurations on key servers. The following configurations are supported:
  • Thales CipherTrust Manager and Gemalto SafeNet KeySecure key servers use an active-active model, where multiple key servers are used to provide redundancy. In these configurations one key server must be specified as the primary key server. The primary key server is the key server that the system uses when you create any new encryption keys. The key is immediately replicated to the other key servers in the cluster. All of the key servers that are defined on the system can be used to retrieve keys. Although it is possible to configure a single key server instance, two key servers are recommended to ensure availability of keys, if one key server experiences an outage.
  • The system supports up to four key servers. If the system is accessing multiple key servers, they need to belong to the same cluster of key servers.
  • If you are using Gemalto SafeNet KeySecure key servers to create and manage keys, determine whether the system needs a username and password to authenticate to the KeySecure key servers. If you plan to use a username and password to authenticate the system to these key servers, you must configure user credentials for authentication in the key server management interface. For KeySecure versions of 8.10 and up, administrators can configure a username and password to authenticate the system when it connects. Before version KeySecure 8.10, the use of a password is optional. For more information on migrating key servers, see Migrating from Gemalto SafeNet KeySecure to Thales CipherTrust Manager key servers.
  • If you are using Generic KMIP key server to create and manage keys, determine whether the system needs a username and password to authenticate to the Generic KMIP key servers. If you plan to use a username and password to authenticate the system to these key servers, you must configure user credentials for authentication in the key server management interface. After configuration, you can select your username from the interface.
  • If you are using HashiCorp Vault as a KMIP server, note that Vault uses an internal KMIP Certificate Authority (CA) to generate certificates for clients that authenticate by using the KMIP protocol. You cannot import external KMIP certificate authorities. All KMIP client authentication must use certificates that are signed by the internal KMIP CA. Ensure that KMIP clients trust the internal CA before you configure them for Vault KMIP integration.