Encryption

Edit online

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 have not purchased a license, contact a customer representative to purchase an encryption license.

The system supports optional encryption of data at rest. This support protects against the potential exposure of sensitive user data and user metadata that is stored on discarded, lost, or stolen storage devices. Depending on your model, the system also supports self-encrypting drives, where data encryption is completed in the drive itself. Data encryption keys remain on the drive without being stored in system memory. In addition, the system supports automatic locks of encrypted drives when the system or drive is powered down. When the drive or system restarts, a master key, which is created when you enable encryption on the system, is required to unlock the drive and continue I/O operations. If you add a new control enclosure to a system that has encryption that is already enabled, the control enclosure must also be licensed.

Accessing an encrypted system

Before you can enable encryption ensure that you have purchased a license and activated before configuring the function on the system. Enabling the encryption feature is a nondisruptive procedure. During the procedure, the system continues to process the I/O operations normally and the existing storage objects are not impacted. The system supports two methods of configuring encryption. You can use a centralized key server that simplifies creating and managing encryption keys on the system. This method of encryption key management is preferred for security and simplification of key management. In addition, the system also supports storing encryption keys on USB flash drives. USB flash drive-based encryption requires physical access to the systems and is effective in environments with a minimal number of systems. For organizations that require strict security policies regarding USB flash drives, the system supports disabling these ports to prevent unauthorized transfer of system data to portable media devices. If you have such security requirements, use key servers to manage encryption keys.

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 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.

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.

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

For the supported list of key servers, refer to the Supported Key Servers - IBM Spectrum Virtualized .

Encryption using key servers

A key server is a centralized system that generates, stores, and sends encryption keys to the system. Some key server providers 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 IBM Security Guardium Key Lifecycle Manager, Thales CipherTrust Manager, or Gemalto SafeNet Key Secure key servers to handle key management on the system. These supported key server management applications create and manage cryptographic keys for the system and provide access to these keys through a certificate. Only one type of key server management application can be enabled on the system at a time. Authentication takes place when certificates are exchanged between the system and the key server. Certificates must be managed closely because expired certificates can cause system outages. Key servers must be installed and configured before they are defined on the system.

IBM Security Guardium Key Lifecycle Manager key servers support Key Management Interoperability Protocol (KMIP), which is a standard for encryption of stored data and management of cryptographic keys.

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 rekeying 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. The amount of time it takes to replicate the key to a secondary key server depends on the amount of key and certificate information that is being replicated. Each replication to a secondary key server can take some time. Replication must 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.

Thales CipherTrust Manager and Gemalto SafeNet KeySecure key servers also supports KMIP and 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 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.

Encryption using USB flash drives

You can use USB flash drives to enable encryption and copy a key to the system. You must create system encryption keys and write those keys to all USB flash drives.

Two options are available for accessing key information on USB flash drives:

USB flash drives are left inserted in the system at all times: If you want the system to restart automatically, a USB flash drive must be left inserted in all the canisters on the system. When you power on, all canisters then have access to the encryption key. This method requires that the physical environment where the system is located is secure. If the location is secure, it prevents an unauthorized person from making copies of the encryption keys, stealing the system, or accessing data that is stored on the system. If a USB flash drive that contains valid encryption keys is left inserted in both of the two canisters, the system always has access to the encryption keys and the user data on the drives is always accessible.
USB flash drives are not left inserted into the system except as required: For the most secure operation, do not keep the USB flash drives inserted into the canisters on the system. However, this method requires that you manually insert the USB flash drives that contain copies of the encryption key in the canisters during operations that the system requires an encryption key to be present. USB flash drives that contain the keys must be stored securely to prevent theft or loss. During operations that the system requires an encryption key to be present, the USB flash drives must be inserted manually into each canister so data can be accessed. After the system completes unlocking the drives, the USB flash drives must be removed and stored securely to prevent theft or loss.

Encryption technology

Data encryption is protected by the Advanced Encryption Standard (AES) algorithm that uses a 256-bit symmetric encryption key in XTS mode, as defined in the IEEE 1619-2007 standard and NIST Special Publication 800-38E as XTS-AES-256. That data encryption key is itself protected by a 256-bit AES key wrap of a key derived from the access key stored on the USB flash drive. The wrapped key is stored in the system in non-volatile form.