Changing the Encryption Key on Linux ESG Devices

To meet various compliance requirements, you may want to change the key that CTE has used to encrypt ES GuardPoints. Thales refers to this changing of encryption keys as “Key rotation” or “Rekey”. Unlike the CipherTrust Transparent Encryption - Live Data Transformation product offered by Thales for file systems on traditional storage devices, to change the encryption key on an ES GuardPoint, the device must be taken offline. The data on the device will be inaccessible during the key rotation process.

The key rotation process involves the following:

• Creating a new policy for key rotation.

• Preparing the CTE-Efficient Storage device for key rotation.

• Applying the new policy to the CTE-Efficient Storage device on the CipherTrust Manager.

See the following sections for details of key rotation. If your organization has separated security duties, some of the steps below may need to be completed by different people.

Creating a New Policy for Key Rotation

As part of rekeying the data on a CTE-Efficient Storage device, you must create a new policy with a key rule specifying the new key and include a second key rule that specifies the current key. The screenshot below depicts a policy named ESG_DEMO_POLICY_2 for rekey:

Similar to the policy ESG_DEMO_POLICY_1, the above production policy applies the key specified in the first key rule, ESG_DEMO_KEY_2, on the device guarded with the policy. The second key rule is actually ineffective, because the first key rule is always selected for IO operations to devices guarded with ESG_DEMO_POLICY_2, hence never selecting the second key rule for key operations.

The reason for inclusion of the second key rule is the availability of the key specified in the second key rule (ESG_DEMO_KEY_1) to the protected host. Note that the name and the ID of the key applied to the data on ES GuardPoints are persistently recorded in the CTE private region on the device. However, the recording of the key name and ID in the private region may not be sufficient for availability of ESG_DEMO_KEY_1 to the protected host without the second key rule listed in ESG_DEMO_POLICY_2 policy. If another GuardPoint on the protected host guarded with a policy that specifies ESG_DEMO_KEY_1 as a key rule, the key ESG_DEMO_KEY_1 is available to the protected host, and the policy ESG_DEMO_POLICY_2 does not have to include the second key rule listing ESG_DEMO_KEY_1. Absence of any GuardPoint not guarded with a policy specifying ESG_DEMO_KEY_1 causes the CipherTrust Manager not to push the key ESG_DEMO_KEY_1 to the protected host.

Notice the resource set empty-Ø listed as the resource set in the second key rule. This is an empty resource set that does not associate any object in a guarded GuardPoint with the key specified in the key rule. An empty resource set is specified in the second key rule because a resource set is required for adding the second or additional key rules to the policy.

Prepare an ES GuardPoint for Rekey

Before you apply the new policy, you must shutdown any applications accessing the ES GuardPoint. This also includes unmounting file system if the ES GuardPoint is a device mounted as a file system. The next step is to unguard the guarded device on the protected host and then on the CipherTrust Manager. Unguarding the device on the CipherTrust Manager deletes the ES GuardPoint on the host.

The following screenshot enumerates the administrative steps for rekeying ES GuardPoints. The following figure shows the transformation from ESG_DEMO_POLICY_1 using ESG_DEMO_KEY_1 to the new policy ESG_DEMO_POLICY_2 using ESG_DEMO_KEY_2.

Notice the key name and the old key name associated with the device as recorded in the device private region.

Next, unguard the device on the CipherTrust Manager and then run the voradmin command to prepare the device for rekey. Be sure the device is unguarded on the CipherTrust Manager before running the voradmin command, otherwise the voradmin command refuses to prepare the device for rekey. Notice that the ES Header is temporarily deleted from the device in preparation for rekey.

Next, guard the device on the CipherTrust Manager as an Efficient Storage device using the policy ESG_DEMO_POLICY_2. After the CipherTrust Manager pushes the configuration on the ES GuardPoint, proceed with guarding the device on the protected host. The guard operation detects the policy/key change on the device and begins the CTE-IDT process to transform data from ESG_DEMO_KEY_1 to ESG_DEMO_KEY_2. During the CTE-IDT process, user access to the ES GuardPoint is blocked until IDT completes the transformation process.

After CTE-IDT completion you can restart application workloads on the guarded device.