Guard the Linux Device with an IDT-Capable GuardPoint

After the device has been initialized, you can guard the device as an IDT-Capable GuardPoint from the Key Manager. For existing devices, as soon as the GuardPoint configuration has been pushed to the host and the status changes to guarded, CTE begins transforming the data on the disk using the encryption key associated with the GuardPoint Policy.

Warning

If access to the device is shared access across multiple CTE Protected hosts in a cluster, be sure to guard the device on one and only one of the CTE hosts.

Note

For details about how to create a GuardPoint in CM, see, “Managing GuardPoints", CTE Administration Guide.

To see the data transformation progress, use the voradmin idt xform status <device-name> command, as described in Viewing Device Status and the IDT Device Header.

After the device is initialized and guarded, the protected device must be accessed through the CTE device pathname. This pathname corresponds to the secvm device. For example, the Linux device pathname /dev/sdc2 becomes /dev/secvm/dev/sdc2 as soon as the process is complete.

Note

• Be sure to use the secvm device name when using file system management tools such as mkfs and fsck.
• Do not use the device mapper names corresponding to IDT-Capable GuardPoints for GuardPoint administration on protected hosts.

Data Relocation and Transformation on Existing Linux Devices

When you add an IDT-Capable GuardPoint to a device that has been initialized with the voradmin idt xform command and you opted to embedded the CTE Private Region on the device, CTE first relocates existing data in the region of the device designated as CTE Private Region. The data is relocated to the end of the device, into the new space allocated when you resized the device. The relocation occurs once when the device is guarded for the first time. No relocation is necessary for subsequent rekeys on the device.

Relocation of data is transparent to applications accessing data through the IDT-Capable GuardPoint. CTE will map application I/O requests over the private region to the relocated region. After guarding the device, you can grow the device size further if necessary. However, you cannot shrink the device size.

IDT does not require a separate policy for data transformation. If you initialized the device with the xform option, CTE starts the IDT process when transformation is required. During the IDT process, access to the device is blocked until the IDT process completes and all the data on the device has been encrypted.

voradmin idt status xform /dev/sdc3
Status:         In-Process
        Relocation Zone 9764864 (relocated = 1)
        SegSpc 27, Xformation Range: 3217 ... 4799, SegIDs: 4795 4796 4791 4792 4797 4798 4799
        KeyID:          2793    Key Name:     IDT_DEMO_KEY_1
        Old KeyID:      0       Old Key Name: clear_key

# dd if=/dev/secvm/dev/sdc3 of=/dev/null bs=512 count=1
dd: failed to open 'dev/secvm/dev/sdc3': Resource temporarily unavailable

# voradmin idt status xform /dev/sdc3
Status:         Complete
        Relocation Zone 9764864 (relocated = 1)
        SegSpc 27, Xformation Range: 3217 ... 20189, SegIDs: none
        KeyID:          2793    Key Name:     IDT_DEMO_KEY_1
        Old KeyID:      0       Old Key Name: clear_key

# dd if=/dev/secvm/dev/sdc3 of=/dev/null bs=512 count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000989039 s, 518 kB/s

Thin-Provisioned Devices

IDT skips transforming thin-provisioned regions of a device. Data returned to IDT as sequence of clear-text zeros, in sector size granularity, is indication of possible sparse or un-allocated regions of the device that do not have to be transformed.

IDT Recovery From Crash

IDT is fault tolerant in the event of system crashes. IDT keeps track of the transformation process over the entire device. In the event of a crash, IDT will automatically resume transformation from the point of failure as soon the GuardPoint is enabled after system startup.

If you find the transformation status set to In-Progress when the GuardPoint is not enabled, the In-Progress state reflects an earlier system crash after which the GuardPoint has not been enabled to recover from the interruption in the IDT process.