Please Note:

Disk Encryption After Initial Deployment

For added security, the disk of CipherTrust Manager can be fully encrypted with the public SSH key. For public cloud deployments this SSH key was provided during first launch. For physical appliance and private cloud deployments, the SSH key is provided after initial deployment.

Encryption can be initiated when an instance is first launched for Virtual CipherTrust Manager, or after deployment for both physical appliance and virtual instances. Cloud-init configuration with a user-data file is used for encryption on first launch.

Because installation specific secrets are generated the first time a Virtual CipherTrust Manager instance is launched, it is recommended that the instance be encrypted at launch time when possible to ensure these secrets are never exposed.

After encrypting the disk, you will need to unlock the encrypted instance on every boot using the 'ksctl diskenc secureboot' command and the private SSH key associated with the instance. See to unlock an encrypted instance. Disk encryption is always applied, and this behavior cannot be disabled. If you wish to store your keys on an unencrypted instance, you can launch a new Virtual CipherTrust Manager and then use backup and restore to transfer keys and other data.

Security Best Practices

We always recommend enabling disk encryption.
Because installation specific secrets are generated the first time a Virtual CipherTrust Manager instance is launched, it is recommended that the instance be encrypted at launch time when possible to ensure these secrets are never exposed.
Provide an externally signed certificate to the preboot interface if possible. As you cannot provide this certificate with cloud-init configuration, this is the preferred deployment sequence for Virtual CipherTrust Manager deployments:
1. Enable disk encryption with cloud-init.
2. Launch the Virtual CipherTrust Manager instance.
3. Upload an externally signed certificate.
4. Reboot the Virtual instance.
5. Verify the preboot certificate when unlocking the disk.

Encrypting an already launched instance

The following are examples for encrypting an already launched instance and for checking on its encryption status. Also provided is a CLI example for unlocking the instance at boot time. These operations are only available through CLI or REST API.

To encrypt the instance

Run the following command:
```
ksctl diskenc cryptsetup
```
CipherTrust Manager creates the preboot interface and dynamically generates a self-signed certificate with the default server name preboot.ciphertrustmanager.local.
(Optional, but recommended) Upload an externally signed certificate file to the preboot interface. This certificate is used to protect ksctl and REST TLS communications with CipherTrust Manager while the disk is locked, in the preboot stage.
```
ksctl interfaces certificate modify --name preboot --file <certificate_file> --format <pem_or_pkcs12>
```
CipherTrust Manager supports PEM or base64-encoded PKCS#12 format certificates. The private key algorithm must be RSA-2048 or RSA-4096. The certificate file must include the private key. You can include a chain of certificates, in ascending order from server certificate to root certificate authority (CA).
Save the preboot interface certificate file to later compare the fingerprint with the presented preboot interface certificate before unlocking the instance.
- For an externally signed certificate, convert a copy of the certificate you uploaded in the previous step to DER format. Provide this DER certificate to anyone unlocking the instance.
- For the default self-signed certificate, download the self-signed certificate to a PEM file and then convert it to DER format. Provide this file to anyone unlocking the instance.
```
ksctl interfaces certificate get --name preboot --icertfile verifypreboot.pem
openssl x509 -in verifypreboot.pem -outform der -out verifypreboot.der
```
Reboot the instance.

To check encryption status

To check the encryption progress, you can run following CLI command:

$ ksctl diskenc status -p

This command might time out during system restart or due to a slow connection. As an alternative, you can view the Console for the instance to see disk encryption progress.

Example:

$ ksctl diskenc status -p

This returns the following response:

Encrypting...

14.81 GiB / 15.52 GiB [====================================>-----] 95.44% 11s

The instance starts up after the encryption has finished. You do not need to unlock the disk on this startup after the initial encryption.

To unlock an encrypted instance

Every time an encrypted instance boots, you must unlock the instance to allow admins and users access to most Virtual CipherTrust Manager interfaces. To unlock the instance, you can provide the private key in OpenSSH, PKCS1, and PKCS8 format. We recommend the following practices when you unlock the instance for increased security:

Independently obtain the preboot interface certificate out-of-band before rebooting. In general, the person who first encrypted the disk can provide the certificate file. Compare the fingerprint of the independently provided certificate with the returned preboot interface certificate fingerprint before unlocking.
Enable TLS verification of the presented preboot interface certificate.

The following examples show unlocking examples, presented from most secure unlocking to least secure.

Run the following commands to unlock the disk while verifying an externally signed preboot interface certificate.
1. Obtain the preboot interface certificate available on port 443 in PEM format.
```
echo | openssl s_client -connect <ciphertrust_manager_ip>:443 | sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' > <certificate-file>.pem
```
2. Convert the downloaded interface certificate to DER format.
```
openssl x509 -in <certificate_file>.pem -outform der -out preboot.der
```
3. View the fingerprint for the downloaded preboot interface certificate.
```
openssl dgst -sha256 -c preboot.der
```
4. Inspect the fingerprint for the independently obtained certificate file. Make sure the two certificate fingerprints match. The example command works for a DER encoded certificate file.
```
openssl dgst -sha256 -c <certificate-name>.der
```
  Tip
  If you have SSH or console access to the CipherTrust Manager instance, you can also view the expected preboot certificate fingerprint there. The fingerprint is displayed during boot up.
5. Unlock the disk.
```
ksctl diskenc secureboot -i <private ssh key for the instance> --trusted-ca-file <filename_for_the_trusted_CA_that_issued_the_preboot_certificate> --server-name <hostname_on_preboot_certificate>
```
  Tip
  Alternatives to including the --server-name flag are modifying the /etc/hosts file on the client workstation to include the hostname or mapping this hostname on your network's DNS server.
Run the following commands to unlock the disk while verifying a self-signed preboot interface certificate.
1. Obtain the preboot interface certificate available on port in PEM format.
```
echo | openssl s_client -connect <ciphertrust_manager_ip>:443 | sed -n '/BEGIN CERTIFICATE/,/END CERTIFICATE/p' > preboot.pem
```
2. Convert the downloaded interface certificate to DER format.
```
openssl x509 -in preboot.pem -outform der -out preboot.der
```
3. View the fingerprint for the downloaded preboot interface certificate.
```
openssl dgst -sha256 -c preboot.der
```
4. Inspect the fingerprint for the independently obtained certificate file. Make sure the two certificate fingerprints match.
```
openssl dgst -sha256 -c verifypreboot.der
```
  Tip
  If you have SSH or console access to the CipherTrust Manager instance, you can also view the expected preboot certificate fingerprint there. The fingerprint is displayed during boot up.
5. Unlock the disk.
```
ksctl diskenc secureboot -i <private ssh key for the instance> --server-name preboot.ciphertrustmanager.local
```
  Tip
  Alternatives to including the --server-name flag are modifying the /etc/hosts file on the client workstation to include preboot.ciphertrustmanager.local or mapping this hostname on your network's DNS server.
Run the following command to unlock the disk without verifying the preboot interface certificate.
```
ksctl diskenc secureboot -i <private ssh key for the instance> --nosslverify
```

Suggest A Change

Disk Encryption After Initial Deployment

Security Best Practices

Encrypting an already launched instance

To encrypt the instance

To check encryption status

Example:

To unlock an encrypted instance

On this page