Archive for October, 2011

Yet Another Full Disk Encryption with Ubuntu 11.10

Posted in Uncategorized with tags on October 21, 2011 by voline

Why does the world need another full disk encryption (FDE) for ubuntu howto?  There are plenty of resources and posts about this issue.  Technically, I’ll be going over full volume encryption (FVE), but it can easily be modified to encrypt the whole disk (excepting the LUKS header at the beginning of the disk, unless you utilize the –header option of newer cryptsetup packages, but this requires some hacking of the initrd scripts).  I have decided that the benefits to having a partition table outweigh the costs (I have the option to boot windows or other operating systems).   This post is not meant to be a definitive guide to FDE, but more to present ideas and implementations for when you’re actually setting up FDE (presumably with some other tutorial).

The ultimate solution would be to have the disk do the encryption itself, and you only feed it a key or password to unlock it at boot.  This could be much better performance-wise since the encryption would be all done by the processor on the drive.  There are now some SSDs which come with FDE (Intel’s 320 series and a samsung one), however there are a few reasons to be cautious.  It appears as though the drive can be locked and unlocked with a password, but I have no reason to believe that the encryption key, which in Intel’s case is randomly generated, is encrypted with the password.  I suspect that the data encryption key is stored in the clear somewhere on the device.  Also, I’d like a way send an arbitrary (valid) data encryption key to the drive to be used for encryption and there should be a way to independently verify that the encryption key is being used.  Perhaps a way to request data before encryption/decryption.  The other issue is that there is in general only support for one encryption algorithm, whereas with software FDE there can be potentially limitless.  Since, I don’t have one of these drives and I’m not sure I trust them, I’m stuck with software FDE.  Now on with the show.

The big picture

What we want to end up with is Ubuntu residing on an FDE partition, booting from a USB stick.  There should be no way to boot the Ubuntu partition from the disk itself.  This will prevent determined attackers from installing a modified bootloader to grab your passwords or keys.  Also, we’d like to allow Ubuntu to hibernate to some encrypted space, so attackers can read the hibernation dump to get the master key which decrypts the partition.

Installing Ubuntu FDE

I won’t go into detail on how to do this, since there are good resources for doing this (this seems better as it goes over installing boot onto usb).  However, I want to reiterate that you should not create an unencrypted boot partition.  I recommend creating a single lvm partition for the whole system, that includes /boot.  But how can we boot if /boot is itself encrypted?  Continue reading…

The Bootloader

There are two main ways to boot your encrypted volume from a USB stick: boot from an unencrypted initrd located on the usb and unlocking the luks partition from grub and then booting from the initrd in /boot (will need to compile latest grub2).  The former is the easiest to setup, but the latter more secure (in a probabilistic sense).

Booting from initrd on usb stick

Your usb should have a filesystem readable by grub (fat32 should work) with enough space to store the initrds and kernels (100Mb should work).  To install grub, mount the usb partition and do grub-install –no-floppy –boot-directory <path/to/usb/mount> <usb device>.  Now grub is installed, but we need to add a configuration file and the initrds and kernels.  The easiest way to do this is to copy /boot/grub/grub.cfg and /boot/{initrd,vmlinuz}* to the mounted usb partition (make sure the directory structure is the same, eg. <usb mountdir>/boot/grub/grub.cfg exists).  You should now have a bootable usb, which will appear to boot as if you have booted from the disk after a normal Ubuntu install.

However this still leaves much to be desired.  When you upgrade your kernel, you’ll have to manually copy over the files again.  Also, the initrd is stored unencrypted on the usb, so an attacker with access to the usb could easily modify it to capture your key or password.  Can we do better?  I’d argue we can, see next section.

Booting from encrypted initrd

This section requires that you have compiled a luks-enabled grub2 (you’ll need device mapper development files).  Support has been merged in to trunk, and I believe is included in the 1.99 release.  We will use this new grub to open the luks container to load the initrd from our encrypted boot.  Once you’ve got the newer grub compiled and usable, you can install the newer grub on the usb the same way you installed it in the previous section.  After, boot/grub/luks.mod and boot/grub/cryptodisk.mod should exist.  Since the grub config in /boot is automatically updated it should always be in sync with installed kernels, so we’ll have grub load this config.  Here’s a grub menu entry to do all this:

menuentry 'Grub Cryptomount: Ubuntu 11.10 load grub.cfg' {
    insmod luks
    insmod lvm

    cryptomount -u 0123456789abcdef0123456789abcdef
    set root=(lvm/ubuntu-root)
    configfile /boot/grub/grub.cfg

The cryptomount UUID and root device will need to be changed.  You can boot the new grub on the usb and enter the commandline to figure out these parameters.  Try manually unlocking the luks partition with cryptomount.  Also, as far as know, cryptomount can only unlock luks via a password, and not a key.

Once you’ve got this working, you’ll notice that you need to enter the password for your encrypted volume twice: once when grub need to get the initrd and again when the initrd needs to decrypt the volume.  You could modify the initrd to contain a keyfile and the key to the luks volume (luks allow for 8 slots of keys or passwords to decrypt the volume), but this requires some non-trivial initrd hacking.  The key would be securely stored on the encrypted boot.

A note on security, assuming the most capable attacker this method isn’t any more secure than the first method.  The grub boot sector or grub.cfg could be hacked to load key logging code.  However, the number of people capable of this attack is orders of magnitude smaller than those that can install one in an initrd.

Thanks to xercestech for this luks grub idea.

Hash verification

You may wish to perform a hash check on critical data to detect if someone has been tampering with your device.  Of course, a successful hash check does not mean that this data has not been modified, since the hash checker could have been modified to always return true.  However, it can present an extra hurdle for a would be attack.  Also, there could be a real benefit to checking the hash of the luks header, to prevent an old comprimised header from being reinstalled.  Grub has a “sha256sum” command which has a “-c” option for doing a hash check of data against a list of signatures from a given file.  So you could store a hash signature file on the usb and have grub do the hash verification from that file.  One thing to note is that file names may contain grub block syntax.  So you could verify the hash of the first 4k of (hd0,1) with a hash file containing the line “<<HASH>> (hd0,1)+8”.

Tux-on-ice encrypted hibernate

I have found the tux-on-ice hibernation kernel patches to be superior to the mainline swsusp, so naturally I wanted to get hibernation with this kernel working on my encrypted system.  Now, I should say that I’m not sure its strictly necessary to add the resume parameter to the kernel when resuming from hibernation (this parameter tells the kernel where to look for the hibernation image).  Tux-on-ice might be able to automatically find it based on fstab, unless you’ve configured the hibernation image as a file.  Either way, I didn’t want to take any chances.  The easy way to have the resume parameter added to each kernel menu entry in the grub.cfg is to add the parameter to the GRUB_CMDLINE_LINUX variable in /etc/default/grub and then run update-grub.  If you’re using the unencrypted initrd’s, then you’ll need to change the grub.cfg on the usb manually.

Can we do better?

Mandos is an interesting idea for getting servers with encrypted root file systems to reboot unattended and/or remotely.  Though, it would give us less security if configured with an unencrypted boot.  It could be installed in an initrd booted from a usb stick inserted by a person “trusted enough to put the usb in and boot, but not trusted enough to have a password for the encrypted volume.”

Lukstool might be an good tool to integrate with the initrd, to try to thwart memory dumping attacks (it can open multiple “fake” crypt devices, so that there are multiple keys in memory.

Scubed is steganography for your hard drive.  This tool would allow you to plausibly deny the existence of your encrypted system.  Unfortunately, it appears to be unmaintained (no changes in at least 4 years).  So it might take some effort to get it to work with the current device mapper.

For headless servers, an ssh daemon can be run from within the initrd so that a password or keyfile can be provided remotely.  There is documentation at /usr/share/doc/cryptsetup/README.remote.gz and many posts about this.  This would again necessitate an unencrypted initrd.