Musings about on-disk encryption in Fedora Core

[Nils Philippsen]

Hi,

I realize that it's a tad too late in the FC3 cycle, but I couldn't help
thinking about on-disk encryption and how to integrate it into Fedora
Core over the last week or so.

The state of affairs as far as I can see is that we finally have
everything low-level, both kernel- and userspace, i.e. we have
device-mapper and dm-crypt along with assorted cipher algorithms on the
kernel side and dmsetup and cryptsetup tools on the user side. I'll talk
about block-device level encryption and will leave out features a'la
Windows-like encrypted directories which need support from the file
system.

While this all can be used rather easily for your needs if you are
willing to fiddle a bit, there is virtually no real integration into the
operating system, none I have found anyway ;-).

Talking about on-disk encryption, one should differentiate some "use
cases". I would split it up like this, sorted by estimated effort to
implement:

- encrypted swap
- encrypted file system partitions or logical volumes
- user owned encrypted storage (encrypted loop devices, can substitute
  encrypted directories to a certain degree)

Encrypted swap space is pretty much a prerequisite for everything else
because you don't want data that's encrypted on another device lying
around decrypted in swap space. Fortunately this as well as encrypted
file system volumes (except the root device and /boot) are fairly easy
to implement, e.g.:

both swap and fs:

- have an fstab like list containing:
  - real device
  - device mapper device to be accessed from VM or FS layer
  - crypto parameters (like algorithm, key length, ...)
- reference the device mapper device from /etc/fstab

swap:

- generate a random passphrase from /dev/random or /dev/urandom
- attach to en/decrypting device mapper device
- mkswap
- swapon

fs:

- ask for the passphrase very early in the boot process
- attach to en/decrypting device mapper device
- sanity check whether the passphrase is correct (look for FS magic
  numbers or the like), if wrong, re-ask for a couple of times
- continue boot process (fsck, mount, ...)

Leaving aside the question how desirable it is to have the root fs
encrypted on disk, this is more complicated than the above -- you'd need
to put this all in the initial ramdisk, i.e. enhance mkinitrd, add some
tools to the initial ramdisk (causing bloat ;-), there is no way to
specify crypto parameters in a configuration file (which is still
encrypted at that time. Having /boot encrypted would be even more
complicated (and less desirable), because you would have to teach boot
loaders about how to deal with encrypted partitions. In my opinion let's
rather teach them about LVM instead ;-).

User owned encrypted storage on Linux -- which can be mounted when
needed and unmounted later -- is very different to handle. At the moment
it boils down to loopback images owned by the users with some means for
the user to:

- losetup the image
- attach it to en/decrypting device mapper device after asking for the
  pass phrase (sanity checking like above)
- probably r/o sanity fsck on the device
- mount device mapper device somewhere accessible by the user

All of this would need to be wrapped up in a package, probably with a
nice UI around it, at least as long mount doesn't support asking for
pass phrases etc. and it could be done with more traditional Unix means
;-). We would then need to find a balance between flexibility (rather
not ;-) and security (as most of this needs root privileges), probably
starting with no "user-configurable data" and work up from there if
necessary, i.e. hardcoded paths for a single image file and mount
directory and small easily auditable tools to setup the environment and
to mount/umount which in turn can be used by a GUI or else.

This all needs changes/development in:

swap + normal fs: initscripts and installer
root fs: ditto plus mkinitrd
user owned crypto storage: toolset as described

To keep all this sane and portable some items (like configuration files
etc.) should maybe be discussed more widely than only on this list so
this stuff could work on other distros as well.

What do you all think?

Nils
-- 
     Nils Philippsen    /    Red Hat    /    nphilipp at redhat.com
"They that can give up essential liberty to obtain a little temporary
 safety deserve neither liberty nor safety."     -- B. Franklin, 1759
 PGP fingerprint:  C4A8 9474 5C4C ADE3 2B8F  656D 47D8 9B65 6951 3011
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040705/4a7a935d/attachment.sig>