Secure By Default: Disk Encryption

It’s time to better protect user data by default.

elementary and System76 got together last month to discuss and continue hacking on a new installer for future releases of Linux-based operating systems like elementary OS and Pop!_OS. A feature we’re working on together is the ability to fully encrypt the device’s drive. This is a user-selectable feature both elementary OS and Pop!_OS have shipped via the Ubiquity installer since it debuted, but it’s always been off by default and poorly communicated. We aim to change that.

Just Do It

While discussing the installer, one thing System76 wanted to ensure was the ability to easily encrypt the installation once users have their computer in-hand; many System76 customers require it (i.e. government, education, and corporate organizations), other consumer electronics like iOS and Android devices manage it, and frankly it’s just good practice to encrypt by default. The problem in the past has been that, as a desktop Linux OEM, you cannot encrypt the installation before it’s in the user’s hands because then there is no guarantee that the encryption key is unique to that user. So customers would reinstall the entire OS from scratch immediately after receiving their computer—downloading the latest release of the OS, digging up a USB drive, flashing the drive, rebooting their computer, walking through the installer, and finally rebooting to finally use the computer. That’s not ideal.

Instead, we should assume that disk encryption—and better protecting user data—is what we want to do by default, and optimize the installation and first-boot process around that.

UX Implications

Another major reason disk encryption isn’t the standard on Linux-based desktop OSes is that it does have some UX implications: users must remember a separate and distinct encryption password, users must enter this every time the computer powers on or restarts, and there are minor potential performance implications for I/O heavy work. The tradeoffs may be worth it, but we need to be sure users understand.

Some of these are mitigated by suspending instead of shutting down—i.e. just closing a laptop or letting a desktop go to sleep instead of explicitly turning it off—though that does leave the disk unencrypted when not in use.

OEMs and Recovery Partitions

Our mantra for the new installer is that “every install is an OEM install.” This is not just to optimize for OEMs, but it ensures the code paths are well-tested no matter the installation scenario.

For a user installing the OS for themself from a flash drive — what I’ll call a user installation — they just step through the OEM-like portion, then step through user setup. For OEMs, they perform the first part the installation, then can power off the device and ship it to a user. The end user then receives the machine, sets up their user, and is off to work.

The wrench with encryption is that the end user must technically reinstall their OS in order to encrypt the disk with a unique password. Since we had been floating the idea of recovery partitions as part of the install, we realized this could provide us with a solution.

If every installation added a small recovery partition onto the drive, OEMs can configure their shipped devices to boot into that instead of the installed session. This allows encryption plus the ability for custom installation parameters if the user so chooses.

If the installer restarts the device, we know the user is present and we can boot into the OS and continue with user setup. If the user powers down, we can assume it will be set up later — in this case, we can boot into the recovery partition and give the end user the opportunity to encrypt the drive

Installer UI

While these are important points to consider, we feel it’s time to push forward and communicate these implications to users instead of just leaving everything unencrypted. To do so, we’ve designed and prototyped a pair of new Encryption views in the installer: