Managing encrypted filesystems with dirlock [LWN.net]

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.

$ sudo subscribe today

Subscribe today and elevate your LWN privileges. You’ll have
access to all of LWN’s high-quality articles as soon as they’re
published, and help support LWN in the process. Act now and you can start with a free trial subscription.

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.]