IDT-Capable GuardPoint Encryption Keys

IDT-Capable GuardPoints must be encrypted using XTS/CBC-CS1 AES 256 keys. An XTS/CBC-CS1 AES 256 type key is a 512-bit key composed of two components:

• The first 256 bits of the key is the AES 256 encryption key component.

• The second 256 bits is the tweak component.

• Create XTS keys on the DSM using the "Add Agent Key" function.

• For CM, refer to “Creating a New Key" for more information.

The Key Manager (CipherTrust Manager) generates a UUID, along with other relevant attributes, for each newly-added key. It then provides the key and its attributes to the CTE protected host when the policy containing the key is pushed to the host device. CTE stores the key and its attributes, including the key's UUID, in the IDT Device Header. The first time a device is guarded as an IDT-Capable GuardPoint, CTE writes the IDT Header on the device before data transformation takes place, if data transformation is required.

Key Attributes - Example

The following describes the parameters you should specify to add a new XTS/CBC-CS1 AES 256 key named IDT_DEMO_KEY_1. Note the algorithm and encryption mode specified for the key.

• Algorithm: AES

• Size: 256

• Encryption Mode: XTS/CBC-CS1

Note the UUID of the key. This UUID is stored in the IDT Device Header on all devices encrypted with this key, allowing you to verify which key is being used on each device.

Policy Requirements for IDT-Capable GuardPoints

IDT-Capable GuardPoints require a policy of type in-Place Data Transformation with a single key rule specifying the key names for Current Key and New Key. The Current Key name is clear_key or an XTS/CBC-CS1 AES 256 key name, depending on whether the data on the device has already been encrypted.

• If there is no existing data on the device or if the existing data on the device has not yet been encrypted, specify clear_key for Current Key. In the New Key field, specify the name of the XTS/CBC-CS1 AES 256 key that you want to use to encrypt the data on the device.

• If the existing data on the device has already been encrypted, specify the name of the key used to encrypt the data in the Current Key field and the name of the new XTS/CBC-CS1 AES 256 key you want to use to rekey the data in the New Key field. When the policy is pushed to the host, CTE will rekey the data on the device using the key specified in New Key. In other words, the New Key field specifies the XTS/CBC-CS1 AES 256 production key name to apply to the device.

In all cases, the New Key field specifies the XTS/CBC-CS1 AES 256 production key name that you want to use to encrypt the data on the device. After you guard an existing device with an in-Place Data Transformation policy, CTE transforms the existing data using the New Key. When the process is finished, the New Key becomes the Current Key for that device, and all data will be encrypted or decrypted with that key. The IDT Device Header contains the UUID of the key currently being used to encrypt/decrypt data on the device. To view the current key UUID, use the voradmin idt status <device-name> command.

You may add security rules to restrict certain user/process access to protected devices. For suggestions, see Use Cases Involving IDT-Capable GuardPoints.

A simple IDT policy requires:

• Policy type: in-Place Data Transformation

• Rule: Simple security rule that permits access to all users and programs

• Current key: clear_key

• New key: an IDT_KEY for encrypting the data on any device associated with the policy