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

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 unlocking 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, also called pins, to interact with Tang servers. 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.

Use the nbde_server role to deploy and configure Tang servers:

---
- hosts: all

  vars:
    nbde_server_rotate_keys: yes
    nbde_server_manage_firewall: true
    nbde_server_manage_selinux: true

  roles:
    - rhel-system-roles.nbde_server

The nbde_client role configures the Clevis client. This role requires the volumes to be already encrypted with LUKS, and that the role can bind a volume to one or more NBDE servers. You can preserve the existing passphrase or delete it. If you remove the original passphrase, then the volume can be unlocked by using only NBDE. If you provide a passphrase and a key file in the playbook, then the role uses the first entry and ignores all other entries.

You can use a Tang binding to map a device to one or more servers. You can have multiple bindings for the same device. To create or update a binding, set the state variable to the present value. To remove a binding, set the state variable to the absent value.

The following example configures the Clevis client for two devices with two Tang servers:

---
- hosts: all

  vars:
    nbde_client_bindings:
      - device: /dev/rhel/root
        encryption_key_src: /etc/luks/keyfile
        servers:
          - http://server1.example.com
          - http://server2.example.com
      - device: /dev/rhel/swap
        encryption_key_src: /etc/luks/keyfile
        servers:
          - http://server1.example.com
          - http://server2.example.com

  roles:
    - rhel-system-roles.nbde_client

[root@host ~]# grubby --update-kernel=ALL --args="rd.neednet=1"

To begin configuring a Tang server, 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@host ~]# 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@host ~]# systemctl disable tangd.socket --now
Removed symlink /etc/systemd/system/multi-user.target.wants/tangd.socket.

[root@host ~]# curl -f http://demotang.lab.example.com/adv

Red Hat recommends that you periodically rotate the signature and exchange keys that a Tang server uses. The rotation interval for those keys depends on your application, key sizes, and organizational policies. The Tang server stores the signature and exchange keys in the /var/db/tang directory. To rotate the Tang server keys, rename the existing keys to include a dot as a prefix, and then generate new keys with the jose command for the JOSE framework, as follows:

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

Existing client connections use the earlier keys and the Tang server uses the new keys automatically for new client bindings. When all existing client connections finish, you can safely remove the earlier keys.

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

To configure the Clevis framework with LUKS support, install the clevis, clevis-luks, and clevis-dracut packages. The clevis luks bind command binds a block device to a Tang server. The command also associates a binding policy with the device, which decrypts the device based on the Tang server availability. Available binding policies include the REST HTTP escrow server policy, Shamir's Secret Sharing (SSS) policy, and the Tang binding server policy. The following example binds the /dev/vda1 device to the demotang.lab.example.com Tang server:

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

The previous example uses the -d option to specify the device that binds to the Tang server.

The example also associates a binding policy, the Tang binding policy, to bind the device to the Tang server. A Tang binding server policy definition requires the base URL for the Tang server. Other policies are also available, such as the SSS policy.

If the policy requirements are not met, such as if the Tang server is unavailable, then the Clevis framework prompts for the LUKS passphrase during the boot process.

[root@host ~]# 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.

The 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 that defines three Tang servers and requires at least two of them to be available for automatic decryption to occur.

[root@host ~]# 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@host ~]# 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

For each Tang server, you must trust the key for that server.

You can use the /etc/crypttab file alone to configure device decryption at boot time with LUKS. LUKS decrypts the device by prompting you to manually enter passwords into the console at boot time or by storing passwords in plain text on a decrypted device. This way of decryption is inadequate for use cases where servers must boot unattended and still keep the decryption password secure.

NBDE provides a mechanism to automatically decrypt LUKS devices at boot time securely. This mechanism is based on two key components:

By using NBDE, you can prevent automatic decryption of a device that is removed from the data center.