Disk Encryption

Two main methods of disk encryption exist today:

1. Block Layer: The main benefit of this mode of encryption is simplicity of implementation. On Linux, this is implemented using the dm-crypt kernel module. Often dm-crypt is setup by LUKS. However, other user-space implementations are possible.

2. Filesystem: The main benefits of this mode of encryption are partial disk encryption and speed. On Linux, this is currently only supported by ext4. However, other filesystems are likely to join this bandwagon (especially btrfs).

Existing (User-Space) Implementations

LUKS / cryptsetup

The cryptsetup utilities are used to setup and manage block-layer encryption through dm-crypt using the LUKS on-disk header. It is important to note that the kernel does not know about the LUKS header. This is entirely read in userspace and the crypto parameters are provided to dm-crypt.

The LUKS header provides eight slots for keys. During setup, a random encryption key is generated for the disk. After the user supplies a password for encryption, the password is passed through PBKDF to generate an unlock key. The unlock key is XOR'd with the encryption key and stored in one of the slots. Users can repeat this process to store up to eight unlock keys.

images/luks.png

Notice, in the above image, that the unlock threshold is a constant (n = 1). This means that one unlock key is always sufficient to recover the encryption key.

ext4 / e2fsprogs

The encryption support in ext4 is somewhat recent. It works by setting an xattr on an empty directory containing the crypto parameters. Any process whose user has the correct key in the login keyring will be able to access the files. Unlike LUKS, no slots are provided. There is no user-space on-disk format and applications are free to provide their own and insert the relevant key into the keyring.

Shamir's Secret Sharing Algorithm

The use cases already defined require more flexibility than is provided by existing systems. The best way to provide this is to use Shamir's Secret Sharing algorithm. Let's compare LUKS' method with SSS.

images/sss.png

The only difference in the above diagram from LUKS is that the simply copying of the encryption key has been replace with SSS key sharing. This means that n is now variable. It can be as small as 1 (in which case it functions exactly the same as the LUKS, with some minor overhead). It can be as large as the number of slots (in this case: 4), requiring every slot to be unlocked before the encryption key can be calculated. It can also be any number in between. For instance, if n = 2, then, once the second slot was unlocked, decryption could succeed.

Plugins

Rather than doing the simple approach of simply prompting for passwords, we can also have clients implement a plugin infrastructure. Password can be one of those plugins. But with plugins we can also implement other provisioning, acquisition and rotation methods. For instance:

images/sss-plugins.png

Notice that each slot contains a SSS share XOR'd by a plugin-provided key.

• Slot 0 contains the standard password approach used by LUKS.

• Slot 1 contains a master backup key. This is generated at provision time and stored in the FreeIPA Vault. During a disaster recovery scenario, the password can be manually retrieved and typed into a prompt.

• Slot 2 contains a Deo-based key. It can be automatically acquired using the Deo protocol.

• Slot 3 contains a recursive SSS key. This can be used to create complex key policy.

Example policy

Let's look at a complex example policy. This is a corporate laptop in a high security environment. We want a killswitch. Inside the corporate network, we want a majority of Deo servers. Outside the corporate network, we want the user to type a password. We also want a manual recovery key stored in FreeIPA Vault. This setup could look like the following:

images/example-policy.png

Notice the distinct policy requirements of each layer:

• First layer: all slots required
• Second layer: any slot required
• Third layer: at least two slots required

Proposal

Key policy, as described above, will be written to disk using a new on-disk format. The clients will operate in two modes: block-mode and filesystem-mode.

In block mode, the on-disk policy format will be double-written: once at the beginning and once at the end of the disk. A user-space utility will read this on-disk format and setup dm-crypt.

In filesystem mode, the same exact on-disk policy will be saved once per encrypted directory as an xattr. On the root directory, a second xattr will be written which contains the set of directories to unlock at filesystem mount time. Directories in this set will be decrypted for all users. Directories not in this set will need to be unlocked by a directory administrator in the appropriate user context. For example: as the database user just before starting the database.