Dynamic Resource Sets

The Dynamic Resource Set feature has been modified in CTE v7.7.0, with the inclusion of new key rules, when registered with CipherTrust Manager v2.17, or subsequent versions. The Dynamic Resource Set feature is also now available with Local File Systems, as well as NFS GuardPoints. Support for NFS is available starting with the patch release of CTE v7.7.100.

With Dynamic Resource Sets, you can now add a new key rule to a resource set that includes files that are not encrypted under the dynamic resource style policy. This results in the inclusion of those files for rekey and encryption. LDT launches rekey operations on the affected GuardPoints to encrypt the files associated with the resource set in the newly added key rule. Before inclusion of the key rule, those files associated with the resource set were in clear-text.

Following is an example of a policy applied to GuardPoint /oxf-fs1/gp1 which includes subdirectories dir1, dir2, dir3, dir4. Applying this policy to /oxf-fs1/gp1 will launch and rekey the files under /oxf-fs1/gp1/dir1 and oxf-fs1/gp1/dir2 using the specified key, while the remaining files in /oxf-fs1/gp1 remain in clear-text. To rekey the files under /oxf-fs1/gp1/dir3 and /oxf-fs1/gp1/dir4, you can update the policy as follows:

New resource sets were created for dir3 and dir4 before adding the new key rules in the policy. Once the updated policy is applied to the GuardPoint, the rekey is launched to encrypt the files associated with /oxf-fs1/gp1/dir3 and /oxf-fs1/gp1/dir4 using the encryption keys LDT-KEY2 and LDT-KEY3, respectively. Remaining files in the GuardPoint remain unchanged.

New Key Rule

Files associated with resource sets are encrypted with the key specified in the corresponding key rule. Unlike files associated with the exclusion key rules, files not associated with any key rules are normally not encrypted, and not excluded from rekey, except under the few cases described below.

Following is an example of a policy applied to GuardPoint /oxf-fs1/gp1 which includes subdirectories dir1, dir2 and dir3. In this policy resource set, dir1 has an exclusion key rule and resource set dir2 has a key rule to encrypt from clear to LDT-KEY-1. Other subdirectories under /oxf-fs1/gp1, such as dir3, are not associated with any key rule.

Applying this policy to /oxf-fs1/gp1 launches and rekeys the files under /oxf-fs1/gp1/dir1 and /oxf-fs1/gp1/dir2 using the specified key, while the files in /oxf-fs1/gp1/dir3 remain in clear-text due to them not being associated with any key rule. This is reflected in the following examples for rekey statuses:

Example 1

voradmin ldt attr get /oxf-fs1/gp1/dir1/foo.txt

Example Response

LDT attributes: rekeyed_size=0, rekey_status=rekey_excluded
    Key:    name=AES256, version=none

Example 2

voradmin ldt attr get /oxf-fs1/gp1/dir2/foo.txt

Example Response

LDT attributes: rekeyed_size=10485760, rekey_status=none
    Key:    name=LDT-KEY-1, version=0

Example 3

voradmin ldt attr get /oxf-fs1/gp1/dir3/foo.txt

Example Response

LDT attributes: rekeyed_size=0, rekey_status=rekey_no_keyrule
        Key:    name=clear_key, version=none

Rekeying

To rekey the files under /oxf-fs1/gp1/dir3 you can update the policy as follows:

Once the updated policy is applied to the GuardPoint, the rekey launches to encrypt the files associated with /oxf-fs1/gp1/dir3 using the encryption key LDT-KEY2. The remaining files in the GuardPoint remain unchanged.

Example

voradmin ldt attr get /oxf-fs1/gp1/dir3/foo.txt

Example Response

LDT attributes: rekeyed_size=10485760, rekey_status=none
    Key:    name=LDT-KEY-2, version=0

As depicted above, the files previously marked as rekey_no_keyrule due to their association with a no rekey rule, were encrypted/rekeyed after adding the new key rule with the resource set that includes those files. Note that moving any of those files to other directories associated with key rule(s) for encryption will associate those files with the key rule corresponding to the target location, and consequently, encrypting those files in the new location under different key rules. Refer to the section below for the effect of operations, such as renaming files or directories or restoring files, to the association of the file with the resulting key rule.

Effect of Adding a New Key Rule Resulting in Rekey

Addition of a new key rule for encrypting the files associated with a resource set will increment the policy key version resulting in rekey launch on the affected GuardPoints.

Following is an example of a policy applied to GuardPoint /oxf-fs1/gp1 which excludes subdirectory dir1 and includes subdirectory dir2 before adding a new key rule. The Policy Key Version is 19, before adding a new key rule.

Example

voradmin ldt attr get /oxf-fs1/gp1

Example Response

LDT stats: version=7, rekey_status=rekeyed
Number of times rekeyed:                1 time
Rekey start time:                       2024/10/01 14:52:25
Last rekey completion time:             2024/10/01 14:52:25
Estimated rekey completion time:        N/A
Policy key version:                     19
Pushed Policy key version:              19
Policy ID:
        5e128f2c-3789-4985-85eb-b392c3108e25
Data stats:
        total=30.0MB, rekeyed=10.0MB
        truncated=0.0MB, sparse=0.0MB
File stats:
        total=3, rekeyed=1, failed=0
        passed=0, skipped=0, created=0, removed=0, excluded=2

After adding a new key rule resulting in launching rekey on the GuardPoint, the Policy Key Version of the GuardPoint changes to 20.

Example

voradmin ldt attr get /oxf-fs1/gp1

Example Response

LDT stats: version=7, rekey_status=rekeyed
Number of times rekeyed:                2 times
Rekey start time:                       2024/10/01 14:54:57
Last rekey completion time:             2024/10/01 14:54:57
Estimated rekey completion time:        N/A
Policy key version:                     20
Pushed Policy key version:              20
Policy ID:
        5e128f2c-3789-4985-85eb-b392c3108e25
Data stats:
        total=30.0MB, rekeyed=10.0MB
        truncated=0.0MB, sparse=0.0MB
File stats:
        total=3, rekeyed=1, failed=0
        passed=1, skipped=0, created=0, removed=0, excluded=1

Feature changes for Dynamic Resource Sets after upgrading CipherTrust Transparent Encryption or CipherTrust Manager

CTE v7.6 does not differentiate between files that are not associated with any key rules, and with those associated with an exclusion key rule. As the result, files not associated with key rules are flagged as rekey_excluded, instead of rekey_no_keyrule. This behavior extends into CTE v7.7 if the CTE client is registered with CipherTrust Manager v2.16. Registering CTE v7.7, or a subsequent version, to CipherTrust Manager v2.17 or a subsequent version, enables CTE to differentiate between files associated with an exclusion key rule and those not associated with any key rule.

The following sections describe the effect of upgrading CipherTrust Transparent Encryption v7.6 and registration of a CTE client with CipherTrust Manager v2.16 and v2.17, and the new behavior when using Dynamic Resource Sets with CipherTrust Transparent Encryption v7.7.0 and CipherTrust Manager v2.17.

Scenario #1: CTE v7.6 client registers with CipherTrust Manager v2.16

When a CTE v7.6 client registers with CipherTrust Manager v2.16, or a previous version, and then CTE is upgraded to CTE v7.7, the behavior remains the same as in CTE v7.6. Note that the behavior in this scenario is that files not associated with key rules are marked as rekey_excluded instead rekey_no_keyrule.

Scenario #2: CTE v7.6 client registers with CipherTrust Manager v2.17 and then upgrades to CTE v7.7

Prior to upgrading CTE to v7.7, the files not associated with any key rule have already been marked with a rekey_excluded flag. As the rekey_excluded flag indicates exclusion from rekey, those files set to rekey_excluded must be reset to rekey_no_key_rule status after the upgrade.

If the user adds a new key rule immediately after upgrading CTE, before resetting the rekey_excluded flag, the files associated with the new key rule skip rekey. To avoid this, after CTE is upgraded to v7.7, run the voradmin admin command with the option update-nokeyrule to replace the rekey_excluded with rekey_no_keyrule.

Resetting rekey_excluded to rekey_no_keyrule

To reset the rekey_excluded to rekey_no_keyrule on the GuardPoint, type:

voradmin ldt attr update-nokeyrule ${gp}

Following is an example of a policy applied to GuardPoint /oxf-fs1/gp1, on a host with CTE v7.6, which excludes subdirectory dir1 and includes subdirectory dir2.

In the following example, the file in /oxf-fs1/gp1/dir3 remains in clear-text and rekey_excluded:

voradmin ldt attr get /oxf-fs1/gp1/dir3/foo.txt

Example Response

LDT attributes: rekeyed_size=0, rekey_status=rekey_excluded
    Key:    name=clear_key, version=none

The file continues to remain in clear-text but is now marked as rekey_no_keyrule:

voradmin ldt attr get /oxf-fs1/gp1/dir3/foo.txt

Example Response

LDT attributes: rekeyed_size=0, rekey_status=rekey_no_keyrule
    Key:    name=clear_key, version=none

Scenario #3: CTE v7.7 client registers with CipherTrust Manager v2.16, and then CipherTrust Manager is upgraded to v2.17, or a subsequent version

After upgrading CipherTrust Manager to v2.17 , you must perform a capability synchronization between the CipherTrust Manager and all registered CTE agents.

To initiate a capability synchronization:

1. Go to CipherTrust Manager.

2. Click Transparent Encryption > Settings > Client Information and Capabilities > Get Capability

   

After the CipherTrust Manager upgrade is complete, the behavior remains the same as described above for CTE v7.7 with CipherTrust Manager v2.17 and subsequent versions.

File Operations Causing Key Rule Changes

Some file operations may result in changing the association of target files to a different key rule. For example, renaming a file associated with a key rule can result in changing the association. Renaming a directory can have the same result in a wider scope where all, or a subset of files, under the renamed subdirectory may share the resource set and be associated with the key role of the resulting resource set. Another example is backing up and restoring files. Restoring a file into a different location in a GuardPoint will also change the association of the restored file to the key rule of the target location. Such operations will not only change the key rule association, but they may also change the rekey status and result in encrypting or decrypting data in the target file.

Files under an LDT policy are accessed based on their LDT attribute. As LDT attributes specify the rekey status and the encryption key applied to the data in target file, this information may not agree with the key rule associated with the file in the LDT policy.

Note

Be sure to understand the consequence of changing the association of target files to different key rules.

Restoring files Causing Key Rule Changes

As noted, restoring a file into a different location in a GuardPoint will change the association of the restored file to the key rule of the target location, as well as change the rekey status and data in the target file. The following table indicates how restoring files affects the key status and the key applied to the restored files.

• Source Key Rule: Key rule of the file at the time of backup

• Target Key Rule: Key rule of the file restored into the GuardPoint

Note

1. rekey_excluded: Status not preserved and changes to rekey_no_keyrule.

2. rekey_excluded: Status preserved, data remains encrypted.

3. rekey_excluded: Status preserved; however, data remains clear despite the key rule associated with the target location.

4. rekey_excluded: Status is not preserved.

5. rekey_no_keyrule: Status preserved on the restored file; however, the file will be encrypted during the next rekey process.

6. rekey_no_keyrule: Status preserved on the restored file; however, data in the file remains encrypted.

7. rekey_excluded: Status preserved; however, data remains encrypted to the same key despite the key rule associated with the target location.

8. Different results between GuardPoints on local and NFS.

Renaming files and shared key rules

The following table displays the results of renaming files affecting the key status and the key applied to the file under the new name. Note that renaming files may change the association of the file to another resource set.

Note

1. rekey_no_keyrule: Preserved after file rename; however, the file will be encrypted during the next rekey process.

2. rekey_no_keyrule: Preserved after file rename; however, data remains clear despite the key rule associated with the target location.

Renaming directories and shared key rules

The following table indicates the result of renaming directories affecting the key status and the key applied to each file under the new directory pathname. Note that renaming files may change the association of the file to another resource set.

Note

1. rekey_status and encryption key: Do not immediately change after rename. During the next rekey process, LDT will decrypt the data in the renamed directory and set the rekey_status=rekey_excluded or rekey_status=rekey_no_keyrule to match the rekey status of the target key rule.

2. rekey_status and encryption key: Do not immediately change after rename. During the next rekey process, LDT will encrypt the data in the rename directory.

3. rekey_no_keyrule :Preserved after directory rename; however, data remains clear despite the key rule associated with the target location.