The device mapper with the dm-crypt target [1] and the Linux Unified Key Setup (LUKS) [2] extension are normally used to encrypt entire hard disks under Linux. Both components can easily handle any kind of block devices. Therefore, it does not matter whether the device to be encrypted is a hard disk, an LVM volume, or a USB stick. LUKS usually uses a 256-bit AES key that is protected with a passphrase to encrypt the data. If required, several of these passphrases can be stored in the LUKS metadata, which enables access to the key that decodes the data again.

To discover how many of these keys exist for a device and to add new keys, you call:

cryptsetup luksDump <LUKS device>
cryptsetup luksAddKey <LUKS device>

Each key is stored in its own key-slot, or a total of eight areas.

Users need to enter the passphrases manually, which is inconvenient. For example, if the root volume of a computer is encrypted, the system does not start until one of the previously defined passphrases has been entered. In this article, I show you how to automate this process.

Managing Secrets

Vaults are typically used to store and manage all kinds of secrets; they primarily serve as key escrows. If a secret is lost, it can be recovered through an escrow service. The terms "vault" and "key escrow" are merely modern terms for a data storage device that stores particularly sensitive data, such as passwords, certificates, or tokens. In most cases, an API is available for accessing such a service. One well-known representative of these data storage devices is HashiCorp Vault [3].

However, vaults have many problems. No one would want a secret stored in a vault to be transferred between the client and the vault service in the clear. Therefore, an additional infrastructure is necessary to secure this communication path – usually using a TLS connection, which in turn requires X.509 certificates, which means a PKI is also required to manage the certificates. Certificates can also be used to authenticate the remote station. After all, you need to be sure that you are actually talking to the correct service and not just any old system that claims to be this service. The same applies the other way around, of course. The client needs to authenticate itself to the service, so that no one can read the secrets from the vault.

Because the vault service now has all the secrets stored in its database, it is also a single point of failure that has to be secured accordingly. After all, you don't want to be in a position in which you can no longer decrypt hard disks because the vault service's database is corrupted or the server has failed. Therefore, high availability and appropriately secured backups are also essential.

Running such an escrow service requires great effort. Two Red Hat staff members, Nathaniel McCallum and Bob Relyea, appreciated this and took a closer look at the underlying problems. The result is a completely new approach to how data can be encrypted and decrypted. The algorithm that implements this new approach is named the McCallum-Relyea exchange after its inventors. Tang [4] and Clevis [5] provide server and client reference implementations for the algorithm.

McCallum-Relyea Exchange

The idea behind the McCallum-Relyea exchange is as follows: A public and private key are generated on both the server and the client. The public key of the server is displayed during access, and the client can either accept or reject the key. First access to an SSH server works in a similar way, where the host key also has to be confirmed. Optionally, this key can be made available offline on the client. The server does not have to be available during data encryption. The client then generates the symmetric key using the server's public key. In addition to the key, some metadata is generated. Because Tang is based on the JSON object signing and encryption standard (JOSE), the data is available in JSON format.

The whole process is also known as the provisioning process. However, unlike Diffie-Hellman, only the client currently knows the secret key, which is thrown away with the client's private key, so access to the data is no longer possible.

Only the server is able to recover the secret key at this point in time. For this purpose, the client generates another short-lived keychain. Both keys of the client are then sent to the server as a sum total. The server then performs a Diffie-Hellman operation and sends the results back to the client. Using the private key from the newly generated client key, the client can now calculate the secret key and decode the desired data. Thanks to this additional client key, which is regenerated each time the recovery process takes place, the server only receives a random cipher blob and cannot uniquely identify the client. However, that doesn't matter, because only the client itself can decode the results from the server with its private key. This process distinguishes the McCallum-Relyea exchange from the classical Diffie-Hellman algorithm.

Clevis and PINs

The client uses the Clevis tool, which supports various encryption and decryption methods, for automatic data decoding. In the Clevis world, these methods are known as PINs (hence the name Clevis and Tang) [6]. The Tang service can be used as a PIN, but several PINs may also be required to recover the secret key to decrypt the data. Clevis uses the Shamir's Secret Sharing (SSS) algorithm [7] developed by Adi Shamir, one of the founders of the RSA algorithm.

Using Clevis and SSS, a policy can be defined during the encryption phase that determines which PINs are to be used. For example, you can specify that both a Tang service and an escrow service must be available. Other PINs could be a Bluetooth beacon that supports the Tang protocol or even a fingerprint. SSS can also be used to specify how many PINs are required for successful recovery of the key.

The following practical example is based on Fedora 25. Clevis and Tang are available from the distribution's standard repository. Otherwise, the GitHub repository provides the Tang and Clevis sources [4] [5]. Once you have installed the software and started the

tangd-update.path
tangd.socket

systemd services, create a signing key and an exchange key with jose:

# jose gen -t '{"alg":"ES256"}' -o /var/db/tang/sig.jwk
# jose gen -t '{"kty":"EC","crv":"P-256", "key_ops":["deriveKey"]}' -o /var/db/tang/exc.jwk

Listing 1 shows how to encrypt and decrypt a simple string. When encrypting the data, Clevis receives the Tang URL in JSON notation. When the server's advertisement is confirmed, the encoded string is saved as a JWE object in the secret.jwe file. The Tang URL is stored in the metadata there, for example. When decrypting the data, it is no longer necessary to enter a passphrase, because it is automatically recalculated using the Tang server before the JWE object can be decrypted.

# echo "Hello World..." | clevis encrypt tang '{ "url": "http://tang"}' > secret.jwe
The advertisement is signed with the Following keys: xCYVzEcowCWY4J8Dy8H8_1zZ6CU
Do you wish to trust the advertisement? [yN] y
# clevis decrypt < secret.jwe
Hello World...

Listing 2 shows the procedure for automatically decrypting a LUKS-encrypted partition during system startup. To do so, you need to tell Tang the LUKS passphrase that you used when setting up the volume. The additionally generated passphrase is simply placed in another LUKS slot so that the volume can also be decrypted. To ensure that the Tang service can be accessed when booting, you need to regenerate the system's initramfs. After rebooting the system, a connection to the Tang server should be established automatically when you are prompted to enter the LUKS passphrase. The passphrase, which was recalculated on the client using Tang, is then used to unlock the volume. Manual input is therefore no longer necessary.

# clevis bind-luks /dev/sdb1 tang '{"url": "http://tang"}'
The advertisement is signed with the following keys: xCYVzEcowCWY4J8Dy8H8_1zZ6CU
Do you wish to trust the advertisement? [yN] y
Enter existing LUKS password:
# dracut -f

Encrypted data can be decrypted automatically within a desktop session using the Clevis udisks2 tool. Once connected, Clevis automatically answers the passphrase query. This presupposes that Clevis was used to bind the removable medium to the Tang server, as shown in Listing 2.