Dynamic Resource Sets

The Dynamic Resource Set feature has been modified in CTE v7.7, and subsequent versions, with the inclusion of new key rules, when registered with CipherTrust Manager v2.17, and subsequent versions.

CTE supports the inclusion of a new resource set, in a new key rule, in an LDT policy already applied to a GuardPoint. The new key rule allows LDT to launch and rekey the files associated with the resource set. Before inclusion of the key rule, the 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, and dir5.

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:

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, included in the key rules, are encrypted with the key rule. Files not associated with any key rules are implicitly excluded from rekey. Files associated with exclusion key rules are explicitly excluded from rekey. The exclusion property is only enforced until a new non-exclusion key rule is added that covers the implicitly excluded files.

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 update 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 including 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 key rules corresponding to the new location.

The files which are marked as rekey_excluded are not rekeyed, however, if they are renamed or moved to a directory covered by a key rule, the rekey_excluded flag remains persistent.

Adding a New Key Rule

Addition of a new key rule for encrypting the files associated with a resource set will increment the policy key version. 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 files under dir1 are under an exclusion rule, the files under dir2 are encrypted, and the other files are under implicit exclusion due to not having an association with a 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

Rekeying the New Key Rule

After including resource set dir3 in a new key rule, in the same LDT policy, the files associated with the newly added resource key are rekeyed under the corresponding key rule.

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

The following sections describe 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.

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

When a CTE v7.6 registers with CipherTrust Manager v2.17, or a subsequent version, and then upgrades to CTE v7.7.

• The files that are not associated with any key rule have already been marked with a rekey_excluded flag in a version prior to CTE v7.7. 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 CTE agent is upgraded to v7.7.

• If the user adds a new key rule immediately after upgrading CTE, the files associated with the new key rule will fail to rekey. To avoid this, as a workaround, after CTE is upgraded to v7.7, trigger a key rotation on any key in use to allow LDT to change all of the files that are not associated with a key rule within the GuardPoint to rekey_no_key_rule.

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

After upgrading to CTE v7.7, and subsequent versions, and triggering a key rotation on any of the LDT keys used in the policy, 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

Once the CipherTrust Manager upgrade completes, push a manual policy to trigger CTE 7.7, or a subsequent version, to comply with the behavior with CipherTrust Manager v2.17. To force a manual policy push:

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 as described above for CTE v7.7 with CipherTrust Manager v2.17 and subsequent versions.

Dynamic Resource Set with Exclusion Key rule

The Dynamic Resource Set policy in CTE v7.7 now supports the addition of an Exclusion key rule when registered with CipherTrust manager v2.17. Resource sets under the exclusion key rule remain as rekey_excluded and persists regardless of the addition of new key rules and key rotations, or relocation of files or directories.

Limitations with Dynamic Resource Sets

1. Users cannot change the order of the rule, or the encryption key, applied to a file.

2. Support for Dynamic resource sets does not include GuardPoints over NFS.