EncryptedFilesystemsInstaller

Differences between revisions 1 and 8 (spanning 7 versions)
Revision 1 as of 2007-05-18 12:13:50
Size: 4404
Editor: 87
Comment: summary and bof notes
Revision 8 as of 2008-08-06 16:21:59
Size: 7927
Editor: localhost
Comment: converted to 1.6 markup
Deletions are marked like this. Additions are marked like this.
Line 18: Line 18:
This should cover the _why_: why is this change being proposed, what justifies it, where we see this justified. 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.
Line 22: Line 22:
 * 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`.
Line 23: Line 27:

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.
Line 26: Line 36:
=== 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 [[http://luks.endorphin.org/spec|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.
Line 28: Line 59:
=== UI Changes  === === Installer changes ===
Line 30: Line 61:
=== Code 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.
Line 34: Line 73:
Include:
 * data migration, if any
 * redirects from old URLs to new ones, if any
 * how users will be pointed to the new way of doing things, if necessary.
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").
Line 45: Line 81:
 * 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.
Line 47: Line 89:
We are talking about crypted blockdevices, not 'real' crypted filesystems.  * 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, ...?
Line 49: Line 91:
Use cases:
 * encrypted swap
 * suspend/resume from crypted swap
 * encrypted home directory
 * encrypted sub-area (lack of plausible deniability)
 * boot from crypted /
 * encrypted removable media
 * keys on removable media

Keep in mind possible compatibility with other cross-platform / Linux-volumes compatible tools like TrueCrypt, OTFE and BestCrypt. Migration from existing volumes created using those may be another use case.

Possible implementations:
 * 'plain' dm-crypt
 * luks (<= we want this); see the spec at http://luks.endorphin.org/spec

User interface:
 * Look at existing code:
  * luks-tools in Fedora Extras: http://www.flyn.org/easycrypto/easycrypto.html

* Look at existing GUIs:
 * TrueCrypt and Free OTFE (keep licensing in mind, those are not entirely free [1])
 * luks-tools screenshots: http://www.flyn.org/projects/luks-tools/index.html
 * http://www.gnome.org/projects/seahorse/screenshots.html

[1] http://www.truecrypt.org/license.php, http://www.freeotfe.org/docs/licence.htm

Partitioning:
 * crypted / with seperate unencrypted home
 * crypted PV, and put a VG and several LV like swap, /, /home, etc. there
 * default to LUKS, manual installer should also support plain dmcrypt
 * the manual partitioner needs to offer a choice for luks, the automatic partitioner can just use luks

Passphrase entering:
 * teach usplash about entering passphrases (it already has this: INPUTQUIET command)
 * VT switching should either allow
 * cryptsetup / cryptdisks
 * pam_mount / luks

 * Removable media usage examples
  * http://ubuntu.wordpress.com/2006/01/24/use-an-encrypted-usb-drivepartition/

There's an Ubuntu 2007 GSoC project related to this
http://code.google.com/soc/ubuntu/appinfo.html?csaid=EF4FCF874D88234

Automatic conversion:
 * Not possible to do without a separate /boot (not at least at this point), since the default 'wipe my disk' option does not provide /boot
 * Possibility: Write a separate conversion tool which offers to resize partitions, make room for /boot, and convert / (and other partitions) on the fly. This is not sufficiently reliable and should not be attempted, unless it integrates the backup workflow.
  * crackful idea: if they haven't filled their drives, resize / to half size, build encrypted PV/LV and copy data over, delete original and add original / device as an additional encrypted PV. But in all cases, I suspect backup/install/restore is easier. :)

Outstanding issues:
 * Cryptsetup and other important packages are all in universe, preventing effective support based on assumptions of regular and effective feature / security updates enterprise systems would rely on.

TODO:
 * teach usplash about cryptsetup
 * Re-work the cryptsetup MIR, the current issues are not fundamentally blocking it, only needs better information.

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

EncryptedFilesystemsInstaller (last edited 2008-08-06 16:21:59 by localhost)