Full Disk Encryption (FDE) has long been a cornerstone of Ubuntu’s security strategy. Its purpose is simple: to minimize data leakage risks associated with device loss or unauthorized access by encrypting the data stored on a computer’s hard drive or storage device.
For 15 years, Ubuntu’s approach to disk encryption has relied on passphrases for user authentication. However, in Ubuntu Core, FDE has been developed and implemented using Trusted Platform Modules (TPMs) for over two years, starting with Core 20.
Drawing from the FDE design in Ubuntu Core, work is underway to implement TPM-supported full disk encryption in classic Ubuntu desktop systems, starting with Ubuntu 23.10 (Mantic Minotaur), where it will be available as an experimental feature. This means that on supported platforms, passphrases will no longer be needed, and the secret used to decrypt encrypted data will be guarded by the TPM and automatically retrieved only by early boot software with the right to access this data. Besides improving usability, TPM-supported FDE also protects users from “evil maid” attacks, which can exploit the lack of boot software authentication, specifically initrd, for end users.
Full disk encryption in Linux is achieved using the Linux Unified Key Setup (LUKS) framework, which provides block-level disk encryption. Here’s a general overview of the main steps involved in implementing FDE:
Encryption process setup: When setting up full disk encryption using LUKS on Ubuntu, you will be asked to enter a passphrase or key.
Creating a LUKS header: The entered passphrase is not used directly as the encryption key. Instead, it undergoes a costly key computation process, resulting in a more secure encryption key that 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.
Passphrase prompt at boot: When booting the Ubuntu system, initrd will prompt you to enter the passphrase that you initially provided. This passphrase is used to decrypt the LUKS header, obtain the encryption key, and unlock the encrypted device.
Device mapping integration: The encrypted device, which could 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” when reading and writing data from the device.
Decryption and data access: After unlocking the encrypted device, 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” when written to the device.
Flexibility: LUKS allows the use of various encryption algorithms and modes, providing flexibility in choosing a level of security and performance that suits your needs. In Ubuntu, proven algorithms are used, specifically AES-256 with XTS encryption mode.
It’s important to note that the security of encrypted data largely depends on the strength of the passphrase. A strong and unique passphrase greatly enhances the security of an encrypted disk.
Before discussing the new TPM-supported FDE architecture, let’s understand its components. These are verified boot, trusted platform modules, and measured boot.
Verified Boot
Computers are vulnerable during boot if they are not protected. The boot process initiates kernel, hardware peripherals, and user-space processes operation, and any vulnerability in the boot firmware can have cascading consequences for the entire system. One such type of vulnerability includes bootkits, aimed at the early stages of the system boot process and designed to gain unauthorized control over the system by injecting into these critically important components. This allows them to execute malicious code before the operating system and other security measures are fully operational. Essentially, bootkits are designed to operate stealthily and persistently with elevated privileges to avoid detection, resist removal, and possibly deliver further payloads or provide unauthorized access to the compromised system.
To protect against such malware, the verified boot system was developed, enhancing the security of the boot process by ensuring only trusted and properly signed software components, such as firmware, bootloaders, and operating system kernels, are initiated at system startup.
This requires each software component involved in the boot process to be signed with a cryptographic key. These signatures provide software authenticity and integrity. During the boot process, the UEFI firmware verifies the digital signatures of each loaded software component against trusted keys in its key database. If the component’s signature is valid and its signing key is trusted, the component is allowed to execute. Otherwise, the firmware halts the boot process, preventing potentially malicious code from running.
Trusted Platform Modules
A Trusted Platform Module (TPM) is a hardware security component that is placed on a computer’s motherboard. It is a specialized microcontroller that plays a key role in generating, storing, and managing cryptographic keys, as well as performing various security-related tasks. These keys can be used for system authentication, secure communication, and protection of confidential data.
Platform configuration registers, PCRs, are at the heart of the TPM. They are a set of registers that store cryptographic hashes that represent measurements of critical system components. These hashes create a chain of trust that allows for remote attestation, ensuring system integrity and authenticity.
Measured Boot
Measured boot involves using cryptographic measurements to create a secure record, or log, of various components and stages involved in the boot sequence. These measurements are taken at critical points in the boot process, starting with firmware initialization and ending with loading the operating system kernel. The measurements are stored as hashes, which are unique representations of the components’ contents. Measured boot uses the TPM’s PCR for secure storage of measurements and ensures that they cannot be forged.
Such a boot profile can be compared to a known reference measurement to determine whether any unauthorized or unexpected changes have occurred during the boot process, indicating possible interference or malware infection. FDE with TPM support provides several advantages. Since it eliminates the need for manual entry of the passphrase at boot, this allows reducing the barrier to enabling encryption on shared devices in corporate environments and simplifying the boot process in large corporate deployments, leading to increased operational efficiency.
For users who choose to use a passphrase (in addition to the TPM), this will enhance security by eliminating the possibility of offline brute-force passphrase attacks by adversaries. To provide these benefits, the implementation of FDE with TPM support relies on two main design principles. First, the FDE secret key is locked away from all EFI state, including the kernel command line. Second, access to the decryption key will be granted only if the device boots software that is deemed authorized to access sensitive data. At this point, the initrd code at boot will unseal the key from the secure-boot protected kernel.efi file.
Key Protection in TPM
The TPM has 4 hierarchies where objects can be protected, with each hierarchy rooted in a primary seed used to derive primary objects. For FDE, we are looking at only the storage hierarchy, which is tied to the device owner. The other hierarchies are the endorsement hierarchy (tied to the device ID and is the root of trust for attestation), platform hierarchy (accessible only to embedded platform software), and null hierarchy (ephemeral and gets a new seed at every reset).
Objects can serve multiple purposes. They could be asymmetric keys used for signatures or key exchange, symmetric keys used for symmetric encryption or HMAC, sealed objects containing external data, or storage keys that can be used to protect other objects, forming a hierarchy of TPM objects. Since the TPM has limited memory, objects do not necessarily have to be stored in its internal storage. Instead, they are often encrypted with a key derived from a seed associated with the parent storage key and then stored outside the TPM. For full disk encryption, Ubuntu stores the disk encryption key outside the TPM, protected by the TPM’s storage hierarchy inside a sealed data object.
The TPM will unseal the key to code running inside initramfs only if the boot environment has been previously authorized to access sensitive data. If certain components of the boot environment were to change, then the TPM would not grant access to the key. For this, the TPM object must have an appropriate authorization policy.
Authorization Policy
TPM resources can have an authorization policy that requires a set of conditions to be met for access or use. An authorization policy describes a set of conditions that must be met before the TPM will allow a resource to be used. An authorization policy consists of one digest value but can be arbitrarily complex. An authorization policy can contain branches, allowing satisfaction of multiple different conditions.
To access or use a resource that is subject to an authorization policy, a policy session is created. The policy is then executed by performing a set of policy assertion commands that change the digest associated with the policy session. When executing a command using a resource with an authorization policy, the TPM checks that the digest associated with the policy session matches the policy digest of the resource.
An authorization policy can be created that requires the values of selected PCRs to match a set of precomputed values. The sealed data object protecting the disk encryption key uses this to ensure access to the key only in a certain boot environment. This policy is configured so that access is denied if any components of the boot environment critical to data protection are changed. These include the bootloader, kernel, and initramfs code, secure boot configuration, and kernel command line (source: https://docs.oracle.com/cd/E52734_01/oam/AIAAG/GUID-CB141736-1B93-4035-83C4-56E7EA969186.htm).
Snapd’s Role FDE with TPM support in classic Ubuntu Desktop systems is based on the same architecture as Ubuntu Core and has several common design and implementation principles. Specifically, the bootloader (shim and GRUB) and kernel will be delivered as snap packages (via gadget and kernel snap), not as Debian packages.
The bootloader’s operating logic includes choosing the boot mode and selecting the kernel, and it’s encoded in GRUB configuration provided by Snapd, not generated automatically on the device. Finally, we will use unified kernel images where the kernel and initramfs are encapsulated in a single PE binary file containing a small trailer to execute the kernel. All this will be signed as a single artifact.
Aside from the kernel and bootloader, the rest of the operating system, namely its userspace, will be exactly the same as in the classic Ubuntu environment.
Everything Starts with the Installer You will still have the option to choose your preferred full disk encryption solution, with or without TPM. The installer will offer you two installation choices:
FDE with TPM support: Installing a classic desktop system that gets the kernel and bootloader from snaps, not from deb. FDE 2 without TPM support: Installing a classic desktop system completely based on deb, with the same layout as in the first option to facilitate possible upgrade paths. This installation option will be used by default and is not going anywhere. Since we will be introducing FDE with TPM support as an experimental feature starting with Ubuntu 23.10, we invite all early adopters to try it out and share their thoughts. However, we strongly recommend using this feature only on hardware that you are prepared to completely wipe and fully understand the risk that may arise from its testing.
Leave a Reply