Managing Encryption Keys

Oracle ZFS Storage Appliance includes a built-in LOCAL keystore and the ability to connect to OKM and KMIP keystores. Each encrypted pool, project, or share requires a wrapping key from a keystore. The data encryption keys are managed by the storage appliance and are stored persistently encrypted by the wrapping key from the keystore.

Oracle Key Manager (OKM) Keystore

Oracle Key Manager (OKM) is a comprehensive key management system (KMS) that addresses the rapidly growing enterprise need for storage-based data encryption. Developed to comply with open standards, this feature provides the capacity, scalability, and interoperability to manage encryption keys centrally over widely distributed and heterogeneous storage infrastructures.

OKM meets the unique challenges of storage key management, including:

  • Long-term key retention - OKM ensures that archive data is always available, and it securely retains encryption keys for the full data life cycle.
  • Interoperability - OKM provides the interoperability needed to support a diverse range of storage devices attached to mainframe or open systems under a single storage key management service.
  • High availability - With active N-node clustering, dynamic load balancing, and automated failover, OKM provides high availability, whether the appliances are sited together or distributed around the world.
  • High capacity - OKM manages large numbers of storage devices and even more storage keys. A single clustered appliance can provide key management services for thousands of storage devices and millions of storage keys.
  • Flexible key configuration - Per OKM cluster, keys can be generated automatically or created individually for a LOCAL or OKM keystore. Security administrators are responsible for providing the key names which, when combined with the keystore, associate a given wrapping key with a pool, project, or share.

Note:

If the Oracle ZFS Storage Appliance system is clustered, do not use the "one time passphrase" setting when creating the OKM server agent. Otherwise, registration on the other cluster node will fail, and keys will not be available on failover.

Key Management Interoperability Protocol (KMIP) Keystore

The Key Management Interoperability Protocol (KMIP) keystore is used in conjunction with KMIP-compliant servers, including Oracle Key Vault. Oracle Key Vault is a software appliance that is installed on a dedicated server and that supports the OASIS KMIP standard.

When multiple KMIP servers are listed, Oracle ZFS Storage Appliance will failover to alternate servers if the current server is not responding. Each configured KMIP server must present the same set of keys to the appliance, and must accept the same certificate presented by the appliance for client authentication.

The set of KMIP servers and the client certificate can be changed without removing the keys from the keystore.

Match Hostname

When this option is enabled, the system attempts to verify that the specified KMIP server matches the host specified in the peer server certificate.

KMIP allows you to use either the hostname or the IP address to specify a KMIP server. If you specify an IP address for the KMIP server, and the CA-signed certificate subject common name only has a domain name, then host validation for the certificate fails. If the Match Hostname BUI option is disabled or the host_match CLI property is set to false, host validation is not performed.

For stronger security, perform the host validation. Use the hostname to specify the KMIP server, and enable the host validation option.

Destroy or Preserve a Key on the Server

KMIP has the option to destroy or preserve a key on the KMIP server when that key is deleted on the appliance. When the option is enabled, a key that is deleted from the list of keys that are known to the appliance is also destroyed on the key server. When the option is disabled, keys remain on the key server after they are deleted from the list of keys on the appliance.

One example of when you want to keep keys on the key server after they are deleted from the appliance is when multiple, separate appliances are configured in Oracle Key Vault to see the same set of keys. If you delete a key on one appliance and the key is deleted from the key server, the key remains on the list on the other appliances and you cannot delete the key because the key is not found and appears to be already deleted.

Another example of when you want to keep keys on the key server after they are deleted from the appliance is when you are using replication to repurpose the appliance. You move (replicate) all the source off the appliance and you want to encrypt that moved source with the same keys. When the replication process cleans the original source appliance and deletes the key, the shares on the replica will not be able to be encrypted with that key if the key is deleted from the key server.

Maintaining Keys

Shares, projects, and pools that use OKM or KMIP keys that are in a deactivated state remain accessible. To prevent an OKM or KMIP key from being used, you must explicitly delete the key.

To ensure encrypted shares, projects, and pools are accessible, back up your appliance configurations and LOCAL keystore key values. If a key becomes unavailable, any shares, projects, or pools that use that key become inaccessible.

  • If a pool key is unavailable, new projects cannot be created in that pool.
  • If a project key is unavailable, new shares cannot be created in that project.

Keys can become unavailable in the following ways:

  • Keys are deleted
  • Rollback to a release that does not support encryption
  • Rollback to a release where the keys are not configured
  • Factory reset
  • OKM or KMIP server is not available

Understanding Encryption Key Values

The following table shows the BUI and CLI encryption key values and descriptions. It also indicates if the encryption type works with deduplication.

Table 8-1 Encryption Key Values

BUI Value CLI Value Description

Off

off

Share/project/pool is not encrypted

AES-128-CCM

aes-128-ccm

Lowest CPU impact encryption, Dedupable

AES-192-CCM

aes-192-ccm

Dedupable

AES-256-CCM

aes-256-ccm

Dedupable

AES-128-GCM

aes-128-gcm

NIST SP800-38D recommended, Not-Dedupable

AES-192-GCM

aes-192-gcm

NIST SP800-38D recommended, Not-Dedupable

AES-256-GCM

aes-256-gcm

Highest CPU impact encryption, NIST SP800-38D recommended, Not-Dedupable