Ubuntu Wiki

Please check the status of this specification in Launchpad before editing it. If it is Approved, contact the Assignee or another knowledgeable person before making changes.

• Launchpad Entry: dm-crypt

• Packages affected: partman-crypto, partman, usplash

Summary

We already have the necessary components to set up encrypted partitions (including /). We describe the goals for Ubuntu and the remaining work that needs to be done to get convenient support for those in the installer.

Release Note

Both the graphical and the alternate installer now support encrypting the hard disk. This provides reliable data security (limited by the strength of the chosen password, of course) for machines which are switched off, like stolen or raided equipment.

Rationale

Computers have become ubiquituous also for storing all kinds of personal and business relevant data on them. Especially laptops are a common target for swag. Similarly, people might be concerned about securing their servers in case they get raided. This is subject to the relevant country's legal status, of course.

Use Cases

• Mary, a finance consultant, often travels around and keeps all her customer's contact addresses and contracts on her laptop. She installs Gutsy, selects 'use entire disk and encrypt it' in Ubiquity, uses a long passphrase, and takes care of hibernating or switching off her laptop when she leaves it unattended.

• John uses his desktop to develop a great new processor design and is concerned about keeping it private when sending it in for repairs or leaving it unattended in his large office. He's quite concerned about performance as well, so he partitions manually and only encrypts swap and /home. Since he does not want to remember a long passphrase and always type it in at boot, he reads some manuals and creates a keyfile on his USB stick for using as second unlocking method for /home.

Assumptions

This specification proposes encrypted block devices, in contrast to encrypted file systems or solutions which en/decrypt single files or directories on the fly. There are much better developed and tested existing technologies for block devices and they are transparent to the entire system, thus do not need any particular adaptions to desktop software.

This is also limited to the initial configuration when installing Ubuntu. Other scenarios, like converting existing systems to encrypted partitions, or providing an application for the less common configuration tasks should be handled in future specifications.

Encrypted removable devices have been supported in Ubuntu since 5.04 and thus are not covered here.

Design

Technology

The Linux kernel offers dm-crypt for handling encrypted block devices. However, this does not provide any metadata about the underlying partition, such as a UUID, a magic that this is an encrypted partition in the first place, the encryption algorithm used, or a keyring. This kind of metadata is provided by the LUKS headers, implemented in our cryptsetup. With this format, we retain the correct handling of such partitions with udev, hal, gnome-mount, etc.

Partitioning schema in the installer

The installer only offers one default partitioning schema (swap and a single large partition for everything). It is impossible to anticipate reasonable sizes of several partitions, since that depends on what the computer will be used for. For the same reason we will only offer a similar default scheme Use entire disk with encryption with the following layout:

• 200 MB /boot; this gives space for about 10 kernel ABIs.

• all the rest is devoted to a single large partition that will be LUKS-encrypted. The decrypted block device will be used as a LVM physical volume (PV), initially containing one volume group (VG) with two logical volumes (LV) : swap (with the same size default as in the unencrypted case) and /.

Rationale:

• LVM is necessary to put both swap and / on a block device with the same encryption key. cryptsetup also allows swap to be set up with a random key generated at boot, but that breaks hibernation.

• There are many other reasonable use cases for encryption, like not encrypting /usr and only /home and having /tmp as a tmpfs or encrypted partition, or creating encrypted sub-areas for plausible deniability. These can be set up in the manual partitioner.

The manual partitioner should offer both LUKS and plain dm-crypt (with keeping the metadata in /etc/crypttab). Debian's current partman already offers everything we need for that.

Key management

The installer asks for a passphrase for each of the configured LUKS/dm-crypt partitions. At boot, the user is asked for the passphrase to set up the decrypted dm device, and booting continues without any further system part needing to care about encrypted partitions.

Implementation

Installer changes

• The alternate installer already supports LVM and Debian's current partman supports setting up encrypted devices and even has a default 'use entire disk' mode which sets up the layout proposed above. [TODO: check for remaining problems with Colin]
• Ubiquity needs LVM support and an extended manual partitioner dialog to support selecting dm-crypt/luks and passphrase entering [TODO: check with Colin whether this is realistic for gutsy]

Package changes

• The main inclusion report for cryptsetup needs to be revisited to meet the requirements from the current template, and get approved. Both cryptsetup and partman-crypto need to be promoted to main and shippped by default.

• The existing cryptsetup initramfs/init scripts ask the user for entering the passphrase. cryptsetup currently stops usplash and switches to the text mode; this works, but disrupts the clean boot optics Ubuntu users are used to, thus usplash needs to grow a robust way for entering passwords while still allowing VT switching to get a rescue shell. Either usplash stays active on one VT or cryptsetup transparently falls back to console passphrase input when switching VTs and quitting usplash.

Migration

Since an on-the-fly migration to encrypted partition is not reliable and always needs a backup, we will currently not offer a migration tool. The currently recommended way is to backup your data and reinstall from scratch. (This might get easier in the future, see "Outstanding Issues").

Test/Demo Plan

To be added when the features are implemented.

Outstanding Issues

• Conversion of existing partitions
• GUI tool for keyring management (such as adding key files on USB sticks)

• Automatic setup of (non-LUKS) keyrings for unlocking /home with something like libpam-mount to avoid shared passphrases.

• Data safety when the hard disk portion storing the LUKS header (and keyring) gets corrupted

• Removal of very old kernel ABIs to not let /boot overflow.

BoF agenda and discussion

• Putting the boot kernel on an unencrypted device poses a high risk: nearly every programmer may replace your kernel with one including backdoors. Exposing the most critical part of a system to the "public" renders the whole encryption thing widely useless. Recommendation: Ubuntu should warn the user from encrypting everything but the /boot partition and recommend and support to put the /boot partition onto USB sticks that you can carry around like your keys. Of course, that would mean that kernel upgrades must be enhanced to sync the key's data. Additionally, to prevent USB stick modifications, we should recommend some sort of protected USB stick: data checksum display, last-modified time display, ...?

CategorySpec