Changing the Encryption Key on Linux IDT-Capable Devices

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

For CipherTrust Manager, see Key Version Modify Request for more information.

Warning

For devices with shared access across multiple CTE Protected hosts in a cluster, you must designate one and only one of the nodes in the cluster as the node on which you plan to initialize and guard the device for rekey. The designated node must be the only one that accesses the device until the entire rekey process has completed. This requires guarding each shared device at the designated host level rather than at the host group level if you are using a host group to manage the CTE Protected nodes in your cluster. DO NOT initialize or guard any device on multiple nodes in the cluster simultaneously, because multiple nodes attempting to transform the same data can corrupt the data on the entire device.

Log on to the Key Manager.
Make sure that you know what Policy you want to associate with the GuardPoint or create a new in-Place Data Transformation policy if needed. The key rule must specify the current XTS/CBC-CS1 AES 256 key that the GuardPoint is currently using as well as the new XTS/CBC-CS1 AES 256 key that you want to use to transform the protected data.

You can either create a new in-Place Data Transformation policy or you can change the keys assigned to an existing in-Place Data Transformation policy. If you use an existing policy however, the new key you specify cannot have been previously used to encrypt the IDT-Capable GuardPoint. If you want to rekey the GuardPoint using a previously-used key, you must create a new policy in order to do so.

Include both the current key and the new key in the policy to ensure that both keys will be available during the rekey process, even if the key information stored in the CTE Private Region becomes unavailable.

Do not push this policy to the host yet.
Shut down any applications accessing the GuardPoint you are planning to rekey. If the GuardPoint is mounted as a file system, you must also unmount the file system.

Once the data can no longer being accessed, you can unguard the GuardPoint on the Key Manager.

If the GuardPoint is a manual device GuardPoint, you must first unguard it using the secfsd –unguard command on the CTE host before you unguard it on the Key Manager. If it is an automatic GuardPoint, you can skip this step and simply unguard the GuardPoint in the Key Manager.

The following example checks the guard status of /dev/sdc1 and gets the current key name, then unguards the device.

secfsd -status guard
GuardPoint  Policy             Type             ConfigState  Status   Reason
----------  ------             ----             -----------  ------   ------
/dev/sdc2   IDT_DEMO_POLICY_1  rawdevice        guarded      guarded  N/A
/dev/sdc3   IDT_DEMO_POLICY_1  rawdevice        guarded      guarded  N/A
/dev/sdc1   IDT_DEMO_POLICY_1  manualrawdevice  guarded      guarded  N/A
# voradmin idt status xform /dev/sdc1
        Status:         Complete
        Relocation Zone 0 (relocated = 0)
        SegSpc 27, Xformation Range: 4294967295 ... 4294967295, SegIDs: none
        KeyID:          2793    Key Name:     IDT_DEMO_KEY_1
        Old KeyID:      0       Old Key Name: clear_key
# secfsd -unguard /dev/sdc1
secfsd: Path is not guarded
# secfsd -status guard
GuardPoint  Policy             Type             ConfigState  Status       Reason
----------  ------             ----             -----------  ------       ------
/dev/sdc2   IDT_DEMO_POLICY_1  rawdevice        guarded      guarded      N/A
/dev/sdc3   IDT_DEMO_POLICY_1  rawdevice        guarded      guarded      N/A
/dev/sdc1   IDT_DEMO_POLICY_1  manualrawdevice  unguarded    not guarded  Inactive

Return to the Key Manager, select the GuardPoint in the GuardPoints table, and click Unguard to unguard the device in the Key Manager.

Wait until the GuardPoint has been removed from the Key Manager.

Return to the device and run the voradmin idt rekey command. After you run the voradmin command, the IDT Device Header is temporarily removed from the device.
```
voradmin idt rekey /dev/sdc1
Enter YES to prepare device /dev/sdc3 for rekey -> YES
# voradmin idt status /dev/sdc1
Device /dev/sdc1 is configured to guard as IDT-Capable GuardPoint
```
Note

For manual GuardPoints, you must unguard the device both using secfsd –unguard and the Key Manager before you can use the voradmin idt rekey command.

In the Key Manager, guard the device with the new in-Place Data Transformation policy you created earlier. If you selected a Manual GuardPoint, use secfsd –guard to activate the new policy and start the data transformation to the new key.

During the IDT process, user access to the GuardPoint is blocked until IDT completes the transformation process.

The following example shows how to use secfsd –guard on manual GuardPoint /dev/sdc1, and the status messages that occur during the rekey process. If you are using an automatic GuardPoint, you do not need to use the secfsd –guard command. Instead, the rekey process starts as soon as you push the new policy from the Key Manager.

secfsd -guard /dev/sdc1
secfsd: Path is guarded
# secfsd -status guard
GuardPoint  Policy             Type             ConfigState  Status   Reason
----------  ------             ----             -----------  ------   ------
/dev/sdc2   IDT_DEMO_POLICY_1  rawdevice        guarded      guarded  N/A
/dev/sdc3   IDT_DEMO_POLICY_1  rawdevice        guarded      guarded  N/A
/dev/sdc1   IDT_DEMO_POLICY_2  manualrawdevice  guarded      guarded  Data transformation in progress
# voradmin idt status xform /dev/sdc1
        Status:                In-Progress
        Relocation Zone 0 (relocated = 0)
        SegSpc 27, Xformation Range: 3987 ... 3993, SegIDs: 3991 3987 3988 3992 3989 3990 3993
        KeyID:          2921    Key Name:     IDT_DEMO_KEY_2
        Old KeyID:      2793    Old Key Name: IDT_DEMO_KEY_1

After the xform status shows as completed, you can restart all application workloads on the guarded device.

voradmin idt status xform /dev/sdc1
        Status:         Complete
        Relocation Zone 0 (relocated = 0)
        SegSpc 27, Xformation Range: 4768 ... 4768, SegIDs: none
        KeyID:          2921    Key Name:     IDT_DEMO_KEY_2
        Old KeyID:      2793    Old Key Name: IDT_DEMO_KEY_1
# secfsd -status guard
GuardPoint  Policy             Type             ConfigState  Status   Reason
----------  ------             ----             -----------  ------   ------
/dev/sdc2   IDT_DEMO_POLICY_1  rawdevice        guarded      guarded  N/A
/dev/sdc3   IDT_DEMO_POLICY_1  rawdevice        guarded      guarded  N/A
/dev/sdc1   IDT_DEMO_POLICY_2  manualrawdevice  guarded      guarded  N/A

Suggest A Change

Changing the Encryption Key on Linux IDT-Capable Devices

On this page