Red Hat Security: Linux in Physical, Virtual, and Cloud

Objectives

After completing this section, students should be able to use NBDE to manage decryption policy and automatically decrypt storage when specified conditions are met, using NBDE.

Introducing Network-bound Disk Encryption

One of the pitfalls of LUKS encryption is that you have to enter a passphrase manually to decrypt a disk at boot time. With a large number of servers, this requirement becomes a problem. Network-bound Disk Encryption (NBDE) automates the decryption of those encrypted disks without manually entering any passphrase at boot time in a secure way, by ensuring certain criteria are met. You can use NBDE to automatically decrypt LUKS storage devices containing root and non-root file systems.

Persistently Mounting LUKS File Systems

You must edit the /etc/crypttab file to specify the encrypted block devices to open (decrypted and mapped) at boot time. This file contains an entry for each encrypted block device. Two entries in /etc/crypttab might appear as follows:

[root@demo ~]# cat /etc/crypttab
decrypted1  /dev/vdb1  none  _netdev
decrypted2  UUID=43d8995e-b876-4385-b124-7e402446d6c7  none  _netdev

The first field contains the name to use for the decrypted block device. This name is mapped to a device file, /dev/mapper/name. In the example, the name for the first mapped and decrypted block device is /dev/mapper/decrypted1.

The second field includes either the device name or LUKS UUID (from cryptsetup luksUUID device) for the encrypted LUKS device. In this example, the encrypted block device /dev/vdb1 maps to the decrypted device /dev/mapper/decrypted1, and the encrypted block device labeled with the LUKS UUID 43d8995e-b876-4385-b124-7e402446d6c7 maps to the decrypted block device /dev/mapper/decrypted2.

The third field specifies the absolute path to a file containing the encryption password. It is set to none in the example, which has special meaning. In this case, either the boot process will pause to prompt for manual entry of the encryption password on the machine's console, or it will trigger block device decryption with NBDE.

Finally, the last field includes a comma-separated list of options, in this case only specifying the _netdev option. At boot time, NBDE attempts to unlock all block devices with the _netdev option.

When the LUKS-encrypted block device maps to /dev/mapper/name, you can use the latter to mount this device to a specific mount point with the /etc/fstab file.

The following example mounts the file system of the decrypted block device /dev/mapper/decrypted1 on the /encrypted directory. This example assumes that the underlying file system on the device is XFS.

[root@demo ~]# vi /etc/fstab
...output omitted...
/dev/mapper/decrypted1   /encrypted       xfs    _netdev        1 2

Unattended Device Decryption at Boot Time

You can use /etc/crypttab on its own to configure LUKS to decrypt devices at boot time, but this requires either that passwords be entered manually on the console, or that they are stored in plain text on a decrypted device on the system. This is inadequate for use cases where servers need to boot unattended and still keep the decryption password secure.

NBDE provides a mechanism to automatically decrypt LUKS devices at boot time in a secure manner. This mechanism is based on two key components. Clevis runs on the system and decrypts devices and defines the policy whose conditions must be met for the data to be decrypted. Tang is a very simple server which Clevis clients contact to determine if they are booting with access to a secure network and therefore decrypt their LUKS devices. You can use this to stop automatic decryption of a device that has been removed from the data center.

Configuring Clevis and Tang

The architecture of NBDE uses two key components: the Clevis framework, and the Tang server. The Clevis framework is a pluggable framework that supports NBDE on the client side and automates the unlocking of LUKS-encrypted block devices. The Tang server supports NBDE on the server side, and makes data available on a system when that system can reach the Tang server over a specific secure network. The Clevis framework supports plug-ins to interact with Tang servers (PINs). Both the Clevis framework and the Tang server use the JOSE framework as their back end for encryption and decryption.

Figure 3.1: NBDE architecture with Clevis and Tang

Clevis gets a list of the keys for each Tang server, and uses one of those keys to generate an encryption key. The Clevis PIN then uses that encryption key to encrypt the data. The encryption generates some state information, which is stored in the LUKS header. That state information is accessible with the luksmeta show command.

Configuring a Tang Server

To configure a Tang server, you need to install the tang package. This package installs the tangd service, which uses systemd socket activation, so it starts with the first connection.

Use the following command to enable socket activation for the tangd service:

[root@demo ~]# systemctl enable tangd.socket --now
Created symlink from /etc/systemd/system/multi-user.target.wants/tangd.socket to /usr/lib/systemd/system/tangd.socket.

To stop the tangd service, disable the socket activation for that service as follows:

[root@demo ~]# systemctl disable tangd.socket ‐‐now
Removed symlink /etc/systemd/system/multi-user.target.wants/tangd.socket.

Managing Keys for Tang Servers

You need to periodically rotate the signature and exchange keys used by a Tang server. The rotation interval for those keys depends on your application, key sizes, and organizational policies. The Tang server stores those keys in the /var/db/tang directory. To rotate those keys you need to generate new keys with the jose command for the JOSE framework, as follows:

[root@demo ~]# cd /var/db/tang
[root@demo tang]# jose jwk gen -i '{"alg":"ES512"}' \
> -o signature.jwk
[root@demo tang]# jose jwk gen -i '{"alg":"ECMR"}' \
> -o exchange.jwk

You need to rename the old keys, adding a dot as a prefix to the old key name. Existing client connections use the old keys, while the Tang server uses the new keys automatically for new client bindings. When all existing client connections finish, you can safely remove the old keys.

Configuring the Clevis Framework

To configure the Clevis framework with LUKS support, you need to install the clevis, clevis-luks, and clevis-dracut packages. The clevis luks bind command binds a block device to a Tang server. This command also associates a binding policy with the device, which decrypts the device based on the Tang server availability. There are several available binding policies such as the REST HTTP escrow server policy, the Shamir's Secret Sharing policy, and the Tang binding server policy. The following example binds the /dev/vda1 device to the demotang.lab.example.com Tang server.

[root@demo ~]# clevis luks bind -d /dev/vda1 tang '{"url":"http://demotang.lab.example.com"}'

The previous command uses the -d option to specify the device which binds to the Tang server.

This command also associates a binding policy, the Tang binding policy, to bind the device to the Tang server. A Tang binding server policy definition, such as the one in the previous example, requires at least the base URL for the Tang server. Other policies are also available, such as the Shamir's Secret Sharing policy .

If the policy requirements are not met (for example, the Tang server is not available), the Clevis framework prompts for the LUKS passphrase during the boot process.

[root@demo ~]# systemctl enable clevis-luks-askpass.path
Created symlink from /etc/systemd/system/remote-fs.target.wants/clevis-luks-askpass.path to /usr/lib/systemd/system/clevis-luks-askpass.path.

Shamir's Secret Sharing

The Clevis framework supports other policies to bind LUKS-encrypted block devices to Tang servers. In the previous example, the Tang binding server policy allows you to define a unique Tang server. The Shamir's Secret Sharing (SSS) policy supports the definition of complex policies with multiple Tang servers. You can define a policy with SSS that requires a minimum number of Tang servers to be available before a LUKS-encrypted block device can be decrypted.

The following example binds the /dev/vdb1 device to an SSS policy which defines three Tang servers, and requires at least two of them to be available for automatic decryption to occur.

[root@demo ~]# cfg=$'{"t":2,"pins":{"tang":[\n
> {"url":"http://demotang1.lab.example.com"},\n
> {"url":"http://demotang2.lab.example.com"},\n
> {"url":"http://demotang3.lab.example.com"}]}}'
[root@demo ~]# clevis luks bind -d /dev/vdb1 sss "$cfg"
The advertisement contains the following signing keys:

4R1tkfaTw-67bW0uxTAmTprUPoo

Do you wish to trust these keys? [ynYN] Y
The advertisement contains the following signing keys:

gks_IaVo1yog0KuQei95rg_yGns

Do you wish to trust these keys? [ynYN] Y
The advertisement contains the following signing keys:

vA5xAeUiKPqvkg4UyR4TemzXoAw

Do you wish to trust these keys? [ynYN] Y
You are about to initialize a LUKS device for metadata storage.
Attempting to initialize it may result in data loss if data was
already written into the LUKS header gap in a different format.
A backup is advised before initialization is performed.

Do you wish to initialize /dev/vdb1? [yn] y
Enter existing LUKS password: demopass

As shown above, you need to trust the key for each Tang server.