A streamlined view into data integrity and confidentiality in modern Linux environments

Current state of encryption on Generic Linux Distributions

Linux has had support for Full Disk Encryption and technologies such as UEFI Secure Boot and TPMs for a long time. They are usually set up suboptimally in distributions.


Tools & Mechanisms

We can separate the mechanisms and tools that we have to perform confidentiality and integrity operations in our systems in two large categories; disk encryption and data authentication.

Before we dive into the direction of listing the technologies and tools that are available for each aformentioned category, it would be useful to explain the two concepts.

Disk encryption translates into the process of transforming the data contained within a disk in such a way that reading them in clear-text form is only possible if you possess a secret of some form, usually a password/passphrase.

Data authentication means that there are mechanisms in place verifying that no one can make changes to the data on disk unless they have a secret of some sort.

Technologies empowering disk encryption:

Technologies empowering data authentication:

Since we have stated that both disk encryption and data authentication require a secret of some form, we can talk about TPMs. We will focus on one facet of TPMs capabilities, that of protecting secrets. TPMs, in general, release the secret keys only if the code that booted the host can be authenticated. The whole process is roughly explained below:

Distribution exploitation of these practices

In order to understand how these technologies are used in practive in modern Linux distributions we can take a look at the typical boot process of a distribution today (we are assuming - wrongfully so - that every system at hand is UEFI powered):

Encryption strategies

Provided that we are seeking to enforce an disk encryption and/or data authentication policy we have three operating system areas to include into our encryption strategy. We can, of course, choose to only focus on a specific area rather every one of them.

Authentication of OS binaries

Most Linux distributions store system-related binaries under /usr/. Given that it generally contains no secret data - anyone can download the binaries off the Internet anyway, and the sources too - by encrypting this you'll waste CPU cycles, but beyond that it doesn't hurt much. What you can do, although, is use some form of data authentication to verify the integrity of the binary files that your operating system is using to perform tasks. This can be achieved by:

Encryption/Authentication of OS configuration and state

The OS state and configuration stores, a.k.a stuff in /etc/ and /var/ can be considered as the root file system. The root file system should be both encrypted and authenticated since it might contain secret keys, user passwords, sensitive logs and similar. The encryption of choice here is dm-crypt (LUKS) + dm-integrity. This provides both authenticity and encryption. The secret key must be provided somehow, ideally by the TPM.

Encryption/Authentication of the User's Home Directory

The data in the user's home directory should be encrypted as they usually contain personal and confidential information about the user.

We've seen the boot process of a system in a previous chapter and we now know that during boot, the data in the disk are decrypted after the invocation of the initrd image. In order for user specific encryption to make sense we need to get away from the concept of a system wide key and move to a per-user key. That will ensure that the user's password is what unlocks the user's data.

systemd provides a service called systemd-homed that implements this behavior in a safe way: each user gets its own LUKS volume stored in a loopback file in /home/, and this is enough to synthesize a user account. The encryption password for this volume is the user's account password, thus it's really the password provided at login time that unlocks the user's data.

Wrapping up

So, what is the state of encryption in modern day Linux distributions anyway; it's definitely complicated and fragmented.

And to be honest, I wouldn't expect it to be any other way. Vendors rarely agree on which package manager to ship, little could be done in the direction of a unified encryption strategy. It's up to the user, as is everything in the Linux way of doing things.

Speaking of idealized systems, I believe that simplicity is the key so that vendors can find a unified pattern of empowering their users to encrypt their data.

The ideal OS would be simpler without so many moving parts - especially during the boot process. Since UEFI is there and so is ESP, writing everything there would be the simplest solution. That would allow the firmware authenticate the boot loader/kernel/initrd without any further component for this in place.

In the end, the Linux ecosystem has always been that of a diasporic community and it is this dispersion that feeds creativity and diversity.

DISCLAIMER ⚠️ This work is inspired by Lennart's Poettering publication on "Authenticated Boot and Disk Encryption on Linux". My goal was to streamline the information so that it is digestible and usable in fast-paced research.