Create an Encryption Key

1. From the Products page in the CipherTrust Manager Console, click Keys in the left hand pane.

   

   Tip

   To navigate to the Products page from anywhere in the CipherTrust Manager Console, click the App Switcher icon in the top left corner.

2. Above the Key table, click Add Key.

3. In the Key Name field, add a name for the key. This name must be unique. For example, Simple-Key.

4. In the Key Usage section, make sure Encryptand Decrypt are selected.

5. Click Add Key. CipherTrust Manager displays the properties for the new key.

6. In the general options area, enable the Exportable option.

   You can also enable the Deletable option in this section if you want a CipherTrust Manager Administrator to be able to delete the key.

   

7. In the Key Access section, do the following:

   a. In the Search Groups box, type CTE.

   If no groups display, make sure that the Added Only option is disabled.

   b. Click the Read and Export option for both the CTE Admins and CTE Clients groups.

   

   c. When you are done, click Update.

8. Click the CTE tab and set the following properties:

   • CTE Versioned: Specify whether the key is versioned.

     For a standard policy, and for CTE UserSpace, you should clear this check box. If you do not, the key will not appear in the keys list when you add the key rule to the standard policy.

   

   Note

   CTE UserSpace only supports standard and offline policies. It does not support LDT.

   • Persistent on Client: Specify whether the key is stored in persistent memory on the client.

     • Unselected

       The keys are only stored on the disk inside the CipherTrust Manager. When required, they are downloaded to CipherTrust Transparent Encryption, but only cached in kernel memory and while encrypted. This is the default mode. The Agent continues to work even if communication to CipherTrust Manager is not active. Note that this mode requires a stable connection between CipherTrust Manager and the CipherTrust Transparent Encryption agent in case the agent is restarted, or the server is rebooted to retrieve the keys and polices from CM.

     • Selected

       In this mode, the keys are further encrypted with a derived key generated using a FIPS-approved derivation function and stored in the local protected directory which can be accessed only by CTE services and utilities. If the connection between CipherTrust Manager and CTE agent is not available, keys are recovered for service through the challenge/response mechanism.

   • Encryption Mode: Encryption mode of the key:

     • CBC-CS1
   

   Note

   1.  CTE-U 10.x supports **only** CBC-CS1 for new GuardPoints/deployments. Using a CBC key for a new GuardPoints can lead to data corruption.
   
   2.  CTE-U 10.x is compatible with CTE-U 8.x, 9.x and ProtectFile Linux. For GuardPoints migrated from previous versions of CTE-U, and ProtectFile Linux, you can use CBC keys.

   Copy

9. When you are done, click Update.

   For creating keys through the API, see Creating Keys for more information.

Migrating an Encryption Key

When a key is backed up and restored to a different domain or CipherTrust Manager, the KeyID may be changed. This triggers a protection code that is designed to prevent accidental use of the wrong key or double encryption. If the KeyID changes, but the key (material) is not changed, then you may see the following error when accessing a file, after the new key is pushed to the agent:

root@u20dev:/data-xfs/gp1# cat profile
cat: profile: Input/output error

Additionally, the following messages is logged in syslog:

Nov  8 11:06:02 u20dev secfs_fuse[242513]: [3378] <2> [lo_open] [fuse_check_keyid]: keyid MISMATCH (profile) inode keyid da62b804 header keyid 942ca39
Nov  8 11:06:02 u20dev secfs_fuse[242513]: [3378] <2> [lo_open] [fuseCTEHdr_LoadFromFD]: bad keyid check for profile (-22)

Since the KeyID changed, you must update the metadata stored with each file.

Note

Only perform the following steps if there was some sort of key migration or restoration that occurred on the CipherTrust Manager that would have resulted in the KeyID change. Accidental use of a policy with the wrong key can also result in the same behavior and messages.

To update the metadata:

1. Update the GuardPoint path. Type:

   voradmin secfs config update_keyid 1 <gp_path>

   Copy

2. Restart CTE services. Type:

   /etc/cte/secfs restart

   Copy

   After restart, the GuardPoint is fully accessible and the errors should no longer appear.

3. Ensure that all files in the GuardPoint are updated to the new keyid. This command does not re-encrypt any data.

   dataxform --gp <gp_path> --update_keyid

   Copy
   

   Note

   You can update the key simultaneously, while applications are accessing the GuardPoint.

4. Reset the GuardPoint back to enforcing mode to prevent accidental use of wrong key.

   voradmin secfs config update_keyid 0 <gp_path>

   Copy
   

   Note

   This does not take effect until the next restart of CTE-U, but the restart does not need to be done immediately.

5. Restart CTE services. Type:

   /etc/cte/secfs restart

   Copy