Managing Encrypted Filesystems with dirlock

Every article on LWN.net is written by humans, for humans. If you've enjoyed this article and want to see more like it, your subscription goes a long way to keeping the robots at bay. We are offering a free one-month trial subscription (no credit card required) to get you started.

As with a mobile phone, a portable gaming device like the Steam Deck can contain lots of personal information that the owner would like to keep secret—especially given that such devices can do far more than gaming. Alberto Garcia worked with his colleagues at Igalia and people at Valve, the company behind the Steam gaming platform, to come up with a new tool to manage encrypted filesystems for SteamOS, which is a Linux distribution optimized for gaming. Garcia gave a talk about that tool, dirlock, at Open Source Summit Europe, which was held in Amsterdam in late August. In the talk, he looked at the design process for the encrypted-files feature, the alternatives considered, and why they made the choices they did.

Over a long career at Igalia, he has worked on many different projects, including GNOME, the Maemo and MeeGo mobile-Linux platforms, and more recently on QEMU. He is also a Debian developer; "I've been using Debian basically all of my life, but I'm also contributing to the project and I've been an active developer for many years". At the moment, he is working on SteamOS.

He was quick to point out that dirlock is not a new encryption system as it is only meant to manage filesystems that are encrypted using existing tools. Steam Decks and similar devices are easy to misplace—or steal. Since the hard drive is not encrypted, whoever ends up with the device can read its contents. That may not sound all that problematic for a gaming handheld, but the devices are much more than that; they may have credentials for things other than just Steam accounts, for one thing. In addition, the devices have a desktop mode where various programs can be installed, including web browsers that may store even more personal information. Users have been requesting disk encryption for a long time, Garcia said.

From his slides, he showed the disk layout of the device. It is based around an A/B arrangement for the operating system partitions, which consists of two sets of read-only root partitions, boot partitions, and /var partitions. None of those are particularly sensitive; most of the data on those is downloaded to the device from the internet. The bulk of the disk is taken up with the /home partition, which is where all of the user's data is stored. That includes the games, but also configuration and other data that the user may want to keep private.

Currently, users do have an encryption option, but it is somewhat limited. SteamOS ships with the KDE Plasma desktop, so the Plasma Vault tool can be used to create encrypted directories. It is not a general-purpose solution, however, for encrypting everything in the user's home directory.

Goals

The goals of the project were focused on the needs of SteamOS, but "the idea is to make them general enough so they can be used in any Linux system or in other systems". The most important goal is that if the device is lost or stolen, the personal files on it should be unreadable; there are other scenarios, such as the so-called evil maid attack, that are important to guard against, but the main goal is to protect the personal data, he said. For that, the user's home directory should be encrypted, but it would be nice to be able to encrypt other directories too. The devices have removable media that can be used to store games and other data, so encrypting those would be useful, for example.

While SteamOS is currently single-user, support for multiple users with independent encryption keys is another goal for the tool. Access to the encrypted files must be authenticated somehow, with a PIN, password, or something else. But, since handheld gaming devices do not have a physical keyboard, the expectation is that users will have short, weak passwords or PINs. Having support for a hardware-backed mechanism of some sort may help mitigate that weakness.

These devices are already out there in the hands of users, so "it would be nice to have a way to enable encryption without having to reinstall the whole operating system from scratch". From a security point of view, doing it that way is not ideal, but the goal is to avoid requiring users to wipe their devices; the hope is to have a simple "encrypt data" button or command. Beyond that, the tool needs a D-Bus API. The underlying encryption should also have reasonable performance, "so the user can use the machine normally without noticing any regression in the performance".

There are three available encryption technologies that were considered. The first, stacked filesystem encryption, stores the data as regular files in the filesystem with encrypted contents and names. It is implemented in user space, which hurts performance; the Filesystem in Userspace (FUSE) mechanism is used to mount an encrypted filesystem that gives access to the data. Two examples of this type of encryption are gocryptfs and EncFS; the Plasma Vault tool uses the technique as well.

Another technology, block-device encryption, encrypts each individual block of block devices, such as disk partitions or loopback-mounted files; it does not care what the contents of the block device are, normally it is a filesystem, but it does not have to be. The technique "offers the best confidentiality because what's inside is completely hidden"; attackers have no way to know how much data is stored there, just that it is less than the size of the device. In Linux, the most popular implementation is LUKS, which stores the encryption keys in a header on the block device.

The third option is native filesystem encryption, where files are encrypted by the kernel at the filesystem level. That allows filesystems to contain a mix of encrypted and unencrypted directories. The file names and contents are encrypted, but the metadata (e.g. sizes, permissions) of files is not protected. The kernel provides the fscrypt API to access the feature, but it must be implemented by individual filesystems; at the moment, ext4 and f2fs have support, and he believes it is in progress for Btrfs. All of the encryption keys for fscrypt must be managed by user space.

LUKS versus fscrypt

For SteamOS, the decision came down to either LUKS or fscrypt. LUKS has better confidentiality and works with hardware-backed mechanisms like the TPM and FIDO tokens, but it has some downsides as well. Normally, the LUKS partition needs to be unlocked early in the boot process, which may limit the input methods that can be used for authentication. There is no fine-grained control over what is encrypted and there is no way to encrypt an existing installation; it is meant to be used for a new filesystem on a block device.

"On the other hand, fscrypt makes it very easy to encrypt an existing installation, because you can start from an existing filesystem and start encrypting directories there." It also makes it easy to encrypt other directories, for separate user accounts, for example, with different keys. It integrates easily with PAM, which opens up lots of possibilities for authentication mechanisms, and fscrypt directories can be unlocked after booting, and even remotely via ssh. On the con side, the lack of protection for the file metadata allows attackers to know or guess some things about the files and directory structure; in addition, fscrypt does not stop attackers from deleting files.

The team chose fscrypt as the better option for SteamOS. It is "more practical", with good confidentiality guarantees. It is flexible and "very easy to enable in existing system". Fscrypt offers good performance as well; in his tests, it performed a little better than LUKS, Garcia said.

But fscrypt is just a kernel API, SteamOS will need to handle the encryption keys. Two existing tools, the fscrypt command-line tool and systemd-homed, which are incompatible with each other, were considered. fscrypt, which is related to but different than the kernel API, is "the reference tool to manage encrypted directories"; it was developed in Go by the people working on the kernel API. It is simple to use and supports PAM, but it only allows passwords or raw binary keys and has no support for hardware-backed mechanisms. It also lacks a D-Bus API.

Systemd-homed is not really an encryption tool, or one for managing encrypted filesystems directly, it is for managing user accounts—and only for those tied to humans, not for system accounts. The goal is to separate the configuration of the accounts from the rest of system in order to make it easier to move the accounts to other systems, he said. It has multiple storage backends, two of which are encrypted; one uses a LUKS loopback-mounted file and the other uses the deprecated v1 fscrypt API. Systemd-homed supports D-Bus, PAM, and FIDO tokens, but there is no TPM support. It also only handles encrypting the home directory, while the SteamOS developers want to be able to encrypt more than just that, it has its own user database, separate from /etc/passwd, and it uses ID-mapped mounts, which can conflict with other tools, such as Podman. Overall, systemd-homed was a strong contender, Garcia said, but the team decided to go in a different direction.

dirlock

Dirlock just "does encryption, authentication, and nothing else; it doesn't touch anything else, it tries to be as least invasive as possible". It is "heavily inspired" by fscrypt and Garcia tried not to diverge from the choices made by the tool. Dirlock is still under development, but it is usable at this point. PAM and FIDO support are working, as is basic TPM support. Since users are expected to have low-entropy PINs, the anti-hammering feature of the TPM is used to protect against brute-force attacks. There is also a D-Bus API, but it is in the prototype stage and not yet ready for widespread use.

Dirlock is open-source software, available under the three-clause BSD license. It was written from scratch in Rust, with the needs of SteamOS in mind, but it should work on any Linux system. It will be available in the upcoming SteamOS 3.8 release as an experimental feature; some users are testing it on pre-release versions of SteamOS, so the developers are already getting feedback on it.

A directory encrypted with fscrypt has an "encryption policy" associated with it; the policy is the master encryption key and several configuration parameters, including the encryption algorithm used. The master key is loaded into the kernel to unlock the directory, so that the files can be seen and accessed normally, and is removed to lock the directory. It is up to user space, dirlock in this case, to manage the master key and to keep it safe.

The master key is not used directly by dirlock, he said, it is wrapped with intermediate keys called "protectors"; there are protectors using passwords, FIDO2 keys, and others. That scheme has the advantage that "if the protector is compromised, because the password is lost or something, it can be deleted without exposing the master key and without having to re-encrypt other data". The design for key-handling in dirlock was taken from fscrypt, but the idea of using intermediate keys to protect the master key is much older and is also used in LUKS and BitLocker.

For dirlock, there may not just be a single master key because there may be more than one encrypted directory, so those keys can be protected in various ways. For example, two users can each have their encrypted home directory with protectors using their own password. In addition, a single FIDO2 protector can be used for both users' master keys, so it can decrypt either of the home directories. The users can change their passwords without affecting the ability of the FIDO2 protector to provide access to the directories.

Another scenario might be two users who share a third directory. Each user's password protector can unlock their personal home directory and the shared directory. Each user only needs to know their password for access. Either can change their password at will, without affecting the other user's access.

So far, several protectors have been implemented. The password protector uses the password and cryptographic salt as inputs to a key-derivation function, which generates an encryption key that can decrypt the protected (i.e. master) key. The FIDO2 protector gets the encryption key from the token, which uses a credential and salt internal to the token, possibly mixed with a PIN provided by the user, to generate it. For the TPM protector, the key is obtained from the TPM based on a PIN provided by the user. There are other authentication possibilities using the TPM and its platform-configuration registers (PCRs), but those have not been implemented for dirlock, at least yet.

There is a pam_dirlock.so module for PAM integration. Users do not need to be converted as the PAM module checks to see if the home directory is encrypted. If it is, then the authentication is handled by dirlock, otherwise, it returns PAM_USER_UNKNOWN so that the next PAM module can handle the authentication. He showed a sample PAM configuration that would implement that sort of behavior.

He did a demo of dirlock on a virtual machine (VM) running Debian. He set up two protectors, one for the software TPM in the VM and another for a real YubiKey FIDO2 token that was passed through to the VM. When the user logged in, they were prompted to press the YubiKey button, which would unlock the directory. Removing the YubiKey device from the VM caused it to fall back to the TPM-based key, which required a PIN to be entered. He showed logging in—and failing to log in—using those mechanisms and also noted that the TPM only allowed a certain number of attempts before disallowing further entry of PINs, which is part of its anti-hammering protection.

Something that struck me about the presentation was the total lack of fanfare surrounding the programming-language choice. It was not all that long ago when choosing Rust might have been given a rather higher profile in a talk of this nature, but it seems we are past that point now. Rust is just another attribute of a project—as it should be.

Those interested can view a YouTube video of the talk.

[I would like to thank the Linux Foundation, LWN's travel sponsor, for supporting my trip to Amsterdam for Open Source Summit Europe.]