Full disk encryption, FDE, has long been an integral part of Ubuntu’s security strategy. Its mission is straightforward: to mitigate the risks of data breaches due to device loss and unauthorised access, by encrypting data while stored on the computer’s hard drive or storage device.

For 15 years, Ubuntu’s approach to full disk encryption relied on passphrases for authenticating users. On Ubuntu Core, however, FDE has been designed and implemented using trusted platform modules (TPMs) for more than 2 years now, starting with Core 20. 

Based on Ubuntu Core’s FDE design, we have been working on bringing TPM-backed full disk encryption to classic Ubuntu Desktop systems as well, starting with Ubuntu 23.10 (Mantic Minotaur) – where it will be available as an experimental feature. This means that passphrases will no longer be needed on supported platforms, and that the secret used to decrypt the encrypted data will be protected by a TPM and recovered automatically only by early boot software that is authorised to access the data. Besides its usability improvements, TPM-backed FDE also protects its users from “evil maid” attacks that can take advantage of the lack of a way to authenticate the boot software, namely initrd, to end users. 

How full disk encryption is built in Ubuntu today 

Full disk encryption on Ubuntu is achieved using the Linux Unified Key Setup (LUKS) framework, which provides disk encryption at the block level. Here’s a general overview of the main steps involved in realising FDE:

1. Encryption Process Setup: When setting up full disk encryption using LUKS on Ubuntu, you’ll be asked to provide a passphrase or key. 
2. LUKS Header Creation: The passphrase you enter is not used directly as the encryption key. Instead, it goes through a computationally expensive key derivation process that generates a more secure encryption key,  which is then used to encrypt the master encryption key. This encrypted key, along with other necessary information, is stored in a header at the beginning of the encrypted device.
3. Passphrase Prompt at Boot: When you boot your Ubuntu system, the initrd will prompt you to enter the passphrase you initially provided. This passphrase is used to decrypt the LUKS header, obtain the encryption key, and unlock the encrypted device.
4. Device Mapper Integration: The encrypted device, which can be a partition or an entire disk, is mapped to a virtual block device using the device mapper subsystem. This virtual device transparently encrypts and decrypts data on-the-fly as data is read from or written to the device.
5. Decryption and Data Access: Once the encrypted device is unlocked, the device mapper subsystem decrypts the data as it is read, allowing the operating system and applications to access the data as if it were not encrypted. Similarly, data is encrypted on-the-fly as it is written to the device.
6. Flexibility: LUKS allows for various encryption algorithms and modes to be used, providing flexibility to choose the level of security and performance that suits your needs. Ubuntu uses well-established algorithms, namely AES-256 with XTS cipher mode. 

It is important to note that the security of your encrypted data relies heavily on the strength of your passphrase. A strong and unique passphrase significantly enhances the security of your encrypted disk.

The building blocks of full disk encryption

Before discussing the new architecture of TPM-backed FDE, let us first understand its building blocks. These are verified boot, trusted platform modules, and measured boot. 

Verified boot

Computers are vulnerable during the boot process if they are not secured. The kernel, hardware peripherals and user space processes are all initiated at boot and any vulnerability in the boot firmware can have cascading effects on the entire system. One such type of boot vulnerabilities are bootkits, which target the early stages of a computer system’s boot process, and aim to gain unauthorised control over the system by embedding themselves within these critical components, allowing them to execute malicious code before the operating system and other security measures are fully operational. In fact, bootkits are designed to operate stealthily, persistently, and with escalated privileges, so as to evade detection, resist removal, and potentially deliver additional payloads or enable unauthorised access to the compromised system.

To guard against such malware, verified boot is designed to enhance the security of the boot process by ensuring that only trusted and properly signed software components, such as firmware, bootloaders and operating system kernels, are allowed to run during system startup.

It achieves this by requiring that each software component involved in the boot process is digitally signed using a cryptographic key. These signatures ensure the authenticity and integrity of the software. During the boot process, the UEFI firmware checks the digital signatures of each loaded software component against the trusted keys in its key database. If a component’s signature is valid and its signing key is trusted, the component is allowed to execute. If not, the firmware halts the boot process, preventing potentially malicious code from running.

Trusted platform modules

A trusted platform module, TPM, is a hardware-based security component that resides on the motherboard of a computer. It is a dedicated microcontroller that plays a pivotal role in generating, storing, and managing cryptographic keys and performing various security-related tasks. These keys can be used to authenticate the system, ensure secure communication, and protect sensitive data.

Platform Configuration Registers, PCRs, are a central part of TPMs. They are a set of registers which store cryptographic hashes representing measurements of critical system components. These hashes create a chain of trust that allows for remote attestation, ensuring the integrity and authenticity of the system. 

Measured boot

Measured boot involves the use of cryptographic measurements to create a secure record, or log, of the various components and stages involved in the boot sequence. These measurements are taken at critical points in the boot process, starting from the firmware initialisation and extending through the loading of the operating system kernel. The measurements are stored as hashes, which are unique representations of the components’ content. Measured boot uses the TPM’s PCRs to store the measurements securely, and guarantee that they can’t be tampered with.

This boot profile can be compared against a known-good reference measurement to determine if any unauthorised or unexpected changes have occurred in the boot process, indicating potential tampering or malware infection.

Solution architecture

TPM-backed FDE brings a number of improvements. Because it eliminates the need for users to manually enter passphrases during boot, it provides a lower barrier to enabling encryption on devices that are shared in enterprise environments, and streamlines the boot process in large-scale enterprise deployments, leading to increased operational efficiency. 

For users who will choose to use  a passphrase (in addition to TPM), they will still increase their security posture, as they will eliminate the attacker’s ability to perform offline brute-force attacks against the passphrase.

In order to deliver these benefits, the implementation of TPM-backed FDE relies on two main design principles. First, it seals the FDE secret key to the full EFI state, including the kernel command line. Second, access to the decryption key will only be permitted if and when the device boots software that has been defined as authorised to access the confidential data.  This is when the initrd code will unseal the key in the secure-boot protected kernel.efi at boot time.

Protecting the key in the TPM

The TPM has 4 hierarchies in which objects can be protected, with the root of each hierarchy being a primary seed which is used to derive primary objects.  For FDE, we’re only concerned with the storage hierarchy, which is associated with the device owner. The other hierarchies are the endorsement hierarchy (associated with the device identity and the root of trust for attestations), the platform hierarchy (which is only available to the platform firmware) and the null hierarchy (which is ephemeral and gets a new seed on every reset).

Objects can have several uses. They can be asymmetric keys used for signatures or key exchange, symmetric keys used for symmetric encryption or HMACs, sealed objects that contain external data, or storage keys that can be used to protect other objects, forming a hierarchy of TPM objects. Because a TPM has a limited amount of storage space, objects don’t have to be stored within its internal storage. Instead, they are often encrypted by a key derived from a seed associated with the parent storage key , and then stored outside of the TPM. For full disk encryption, Ubuntu stores the disk encryption key outside of the TPM, protected by the TPM’s storage hierarchy inside a sealed data object.

The TPM will only reveal the key to code executing inside of the initramfs if the boot environment has previously been authorised to access the confidential data. If certain components of the boot environment are modified, then the TPM will not permit access to the key. In order to achieve this, the TPM object must have an appropriate authorisation policy.

Authorization policy

TPM resources can have an authorisation policy in order to require that a set of conditions are met in order to access or use them. An authorisation policy describes the set of conditions that have to be met before the TPM will allow the resource to be used. An authorisation policy consists of a single digest value, but despite this they can be arbitrarily complex. Authorisation policies can contain branches that allow a policy to be satisfied by multiple different conditions.

In order to access or use a resource that has an authorisation policy, a policy session is created. The policy is then executed by running a set of policy assertion commands that modify the digest associated with the policy session. When executing a command that uses a resource with an authorisation policy, the TPM will check that the digest associated with the supplied policy session matches the resource’s policy digest.

An authorisation policy can be created that requires that the values of a selection of PCRs match a set of pre-calculated values. The sealed data object that protects the disk encryption key makes use of this to ensure that the key can only be accessed by a specific boot environment. This policy is configured to ensure that access is denied if any components of the boot environment that are fundamental to the protection of the data are modified. This includes the bootloader, kernel and initramfs code, secure boot configuration and kernel command line.

The role of Snapd 

TPM-backed FDE on classic Ubuntu Desktop systems is based on the same architecture as Ubuntu Core, and it shares a number of its design and implementation principles. Namely, the bootloader (shim and GRUB) and kernel assets will be delivered as snap packages (via gadget and kernel snaps), as opposed to being delivered as Debian packages. As such, it is the Snapd agent which will be responsible for managing full disk encryption throughout its lifecycle.

The bootloader logic includes boot mode selection and kernel selection, and is encoded in the GRUB configuration which is provided by Snapd, rather than being automatically generated on the device. Finally, we will make use of Unified kernel images, where the kernel and initramfs will be encapsulated in a single PE binary containing a small stub to execute the kernel. This will be signed as a single artefact.

Beyond the kernel and bootloader, the rest of your operating system, namely its userspace, will be exactly that of a classic Ubuntu environment. 

It all starts with the installer

You will continue to have the option to choose the full disk encryption solution that you prefer, with or without TPM. As such, the installer will give you two installation paths to choose from:

• TPM-backed FDE: this will Install a classic desktop system that gets its kernel and bootloader assets from snaps instead of debs.
• Non TPM-backed FDE  2: this will Install an entirely deb-based classic desktop system, with the same layout as the first option, in order to facilitate potential upgrade paths. This will be the default installation option and isn’t going anywhere.

Try TPM-backed full disk encryption today

As we will be rolling out TPM-backed FDE as an experimental feature starting with Ubuntu 23.10, we invite all early adopters to try it out and share their thoughts. A word of caution resonates here: we strongly advise that you only venture into this feature exclusively with hardware you’re prepared to wipe completely, and to be fully  aware of the dangerous risks that come with testing it.

For those who will take the plunge, your feedback will be crucial  in this testing phase, and highly valuable in further shaping the ongoing implementation of FDE ahead of the next LTS release of Ubuntu.

• Ubuntu daily builds
• Mantic Minotaur release notes
• Ubuntu Desktop discourse
• Desktop installer bug tracker