Migration From Encryption Key Server To Usb Flash Drive Provider; Recovering From A Provider Loss; Using Encryption - IBM Storwize V5010 Manual

13.6.2 Migration from encryption key server to USB flash drive provider

Migration in the other direction, that is to say from using encryption key servers provider to
USB flash drives provider, is not possible using only the GUI.
To perform the migration, add USB flash drives as a second provider. You can do this by
following steps described in 13.5.2, "Adding USB flash drives as a second provider" on
page 782. Subsequently in the CLI issue the following command:
chencryption -usb validate
to make sure that USB drives contain the correct master access key. Subsequently, disable
the encryption key server provider by running the following command:
chencryption -keyserver disable
This will disable the encryption key server provider, effectively migrating your system from
encryption key server to USB flash drive provider.

13.7 Recovering from a provider loss

If you have both encryption key providers enabled, and you lose one of them (by losing all
copies of the encryption key kept on the USB flash drives or by losing all SKLM servers), you
can recover from this situation by disabling the provider to which you lost the access. In order
to disable the unavailable provider you must have access to a valid master access key on the
remaining provider.
If you have lost access to the encryption key server provider, then run the command:
chencryption -keyserver disable
If you have lost access to the USB flash drives provider, then run the command
chencryption -usb disable
If you want to restore the configuration with both encryption key providers, then follow the
instructions in 13.5, "Configuring additional providers" on page 780.
Note: If you lose access to all encryption key providers defined in the system, then there is
no method to recover access to the data protected by the master access key.

13.8 Using encryption

The design for encryption is based on the concept that a system should either be fully
encrypted or not encrypted. Encryption implementation is intended to encourage solutions
that contain only encrypted volumes or only unencrypted volumes. For example, once
encryption is enabled on the system, all new objects (for example, pools) are by default
created as encrypted. Some unsupported configurations are actively policed in code. For
example, no support exists for creating unencrypted child pools from encrypted parent pools.
Chapter 13. Encryption
785