Planning for encryption

To use encryption on the system, you must purchase an encryption license, upload certificates, activate the license on the system, set up your method of key management, and create copies of the keys. If you use secured IP partnerships to secure connections between partnered systems, you also require an encryption license. If you have not purchased a license, contact a customer representative to purchase an encryption license.

To encrypt data that is stored on drives, the control enclosure on which they are connected must contain an active license and be configured to use encryption. For systems that also support self-encrypting drives, the drives also benefit from obtaining a license to protect access to these drives. When encryption is activated and enabled on the system, valid encryption keys must be present on the system when the system unlocks the drives or the user generates a new key. If key server encryption is enabled on the system, the key is retrieved from the key server.If USB encryption is enabled on the system, the encryption key must be stored on USB flash drives that contain a copy of the key that was generated when encryption was enabled. If the internal key management method is enabled on the system, the key is retrieved from the internal boot drive.

If you are using encryption to protect data that is copied to cloud storage, the cloud account is always synchronized with the system encryption settings. If both USB flash drives and key servers are configured, the cloud account that is created supports both of these methods. If just one encryption method is configured and the other is disabled, the cloud account supports encryption with the remaining configured encryption method. To ensure that the cloud account supports encryption, one or both methods must be configured with active keys when the cloud account is created.
Note: The internal key management method does not support encrypted cloud accounts.

If a cloud account is created with one encryption method, you can configure the second method later, but the cloud account must be online while the configuration occurs. After the second method is configured, the cloud account will support both key providers.

If you use secured IP partnerships to secure connections between partnered systems, you also require an encryption license. If you have not purchased a license, contact a customer representative to purchase an encryption license.

Before you activate and enable encryption, you must determine the method of accessing key information during times when the system requires an encryption key to be present. The system requires an encryption key to be present during the following operations:
  • System power-on
  • System restart
  • User initiated rekey operations
  • System recovery
Several factors must be considered when planning for encryption.
  • Physical security of the system
  • Additional security requirements for USB ports and portable media. If your environment requires USB ports to be disabled, use key servers to manage encryption keys.
  • Need and benefit of manually accessing encryption keys when the system requires
  • Availability of key data
  • Encryption license is purchased, activated, and enabled on the system
  • 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. However, replication is a manual process and during rekey operations, keys are not available until replication is completed. If you use version 3.0 or higher, the system supports multiple master key servers, which automatically replicates keys to all configured key servers.
  • If you are using Gemalto SafeNet KeySecure key servers to create and manage keys, determine whether the system needs a user name 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.
  • If you are using Thales CipherTrust Manager key server to create and manage keys, determine whether the system needs a user name and password to authenticate to the CipherTrust Manager 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. For more information on migrating key servers, refer to Migrating from Gemalto SafeNet KeySecure to Thales CipherTrust Manager key servers

Key server encryption

Key servers provide useful features that make them desirable to use such as being responsible for encryption key generation, backups, and following an open standard that aids interoperability. 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 are 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.
Although both Thales CipherTrust Manager and Gemalto KeySecure key servers support the same type of configurations, you need to ensure that you complete the prerequisites on these key servers before you can enable encryption on the system. To configure the Thales CipherTrust Manager key servers, complete the following tasks before you enable encryption:
  1. The server certificate that is selected for use with the KMIP interface in Thales CipherTrust Manager should be downloaded to your local machine, ready to upload to the system.
  2. By default, Thales CipherTrust Manager is configured to require a username in the 'common name' field of the Storage Virtualize certificate. This username must be added when generating a new certificate or a new certificate request. You must also create a user with the same name in Thales CipherTrust Manager. This user owns the encryption keys for the system and must be added to the Key Users group in Thales CipherTrust Manager.
  3. The Storage Virtualize certificate must be trusted by the Thales CipherTrust Manager key servers. Thales CipherTrust Manager does not support self-signed certificates. Thus, the Storage Virtualize certificate must be signed by a certificate authority (CA). If the system's root Certificate Authority (CA) is used to sign the certificate, then the system's root certificate must be installed as an External CA in Thales CipherTrust Manager and added to the list of CAs that can be used for KMIP. Alternatively, the system certificate can be signed by a trusted third-party CA. The third-party root certificate must be installed as an External CA in Thales CipherTrust Manager and added to the list of CAs that can be used for KMIP. For more information, see Certificates that are used for encryption key servers.
  4. If you currently have encryption that is enabled with USB flash drives, at least one of the USB flash drives must be inserted into the system before key servers can be configured for managing keys.
For SafeNet KeySecure key servers, ensure that you complete the following tasks before you enable encryption:
  1. Each key server must be configured to allow TLS 1.2 for secure communications.
  2. Ensure that a valid SSL certificate from each KeySecure key server is installed on the system and in use. Either add the server certificate for each KeySecure key server, or add the root CA certificate that was used to sign each server certificate.
  3. 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. To set up authentication with a username and password between the system and KeySecure key servers, disable global keys on the High Security menu in the SafeNet KeySecure interface. When global keys are disabled, key servers cannot authenticate clients to create or access keys without valid credentials.
  4. The Storage Virtualize certificate must be trusted by the SafeNet KeySecure key servers. If the system's root CA is used to sign the certificate, then the system's root certificate must be installed as an External CA in SafeNet KeySecure and added to the list of CAs that can be used for KMIP. Alternatively, the system certificate can be signed by a trusted third-party CA. The third-party root certificate must be installed as an External CA in SafeNet KeySecure and added to the list of CAs that can be used for KMIP. If Storage Virtualize certificate is self-signed, then the self-signed certificate must be installed as an External CA in SafeNet KeySecure and added to the list of CAs that can be used for KMIP. It is recommended to not use a self-signed certificate, as the connection between Storage Virtualize and the key servers is interrupted when the certificate is renewed, until the new certificate is added to the key servers.
  5. If you currently have encryption that is enabled with USB flash drives, at least one of the USB flash drives must be inserted into the system before key servers can be configured for managing keys.
System requirements
Only one type of key server is supported at this time. The system implements the Key Management Interoperability Protocol (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 be 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 in order 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.

Update requirements for key server encryption
If encryption was enabled on a pre-7.8.0 code level system and the system is updated to code level 7.8.x or above, you must run a USB rekey operation to enable key server encryption. Use the management GUI or run the chencryption command before you enable key server encryption. To perform a rekey operation, use the management GUI or run the following commands. 
chencryption -usb newkey -key prepare
chencryption -usb newkey -key commit

The rekey operation must be run after the update is completed to the 7.8.x code level or higher and before you attempt to enable key server encryption.