Full Disk Encryption On Ubuntu Based Distos

[oxley]

OK this maybe hypocritical of me, based on my one of posts on this topic, but I have been implementing some full disk encryption on few Linux laptops for some people, so I thought I would share my notes for general discusion and I'm open to any comments etc.

Now one things is they didn't want to use LVM (don't ask)which is the default method when installing Ubuntu, and they wanted to have the option of having the /boot on a USB key (as you can't encrypt the /boot partition) and then use a key file, not a passphrase.

So the general gist of what I did was to use an Ubuntu based live install and create the partitions before installing.

Here are my rough notes, big props to Darren, Eighty of Dual Core and Chris Mooney based on what they did in episode 1106.

Also some things were taking from other sites and I will reference them when I find them again.

Boot from Ubuntu based live CD (tested with pepermint, mint 13 and all flavours of Ubuntu):

Create a 512MB /boot on a USB key or at the start of the drive, it has been recommended to use ext2 on the USB key.

Create a / partition but don't format at this point, also I use a swap file not a partiton (not covered in these notes)

I used gparted for all this.

Format a second USB key with the label “KEYS”

<x> being the correct partition for the second USB key:

sudo mkfs -t ext2 /dev/sd<x>1

sudo e2label /dev/sd<x>1 KEYS

You may need to remove and replace the key so its mounted again, and I assume it mounts to /media/KEYS

Creating a key File (a requirement was also to be able to recreate the same key if needed):

dd if=/dev/random bs=1 count=32 of=/tmp/crypt.key

or

dd if=<picture.jpg> bs=1 count=32 skip=1024 of=/tmp/crypt.key

Copy to the root of the USB key with the label “KEYS” (you'll see why in the crypttab file)

From a terminal with sudo:

(<x> is the / partition, crypt is the /dev/mapper device, mount is a temp mount point, I used /mnt/crypt)

cryptsetup luksFormat /dev/sd<x> /media/KEYS/crypt.key

cryptsetup -d /media/KEYS/crypt.key luksOpen /dev/sd<x> crypt

mkfs.ext4 /dev/mapper/crypt

INSTALL LINUX from the live cd, don't format the drives, use the “something else” option on the partitioning screen, and select the prepared partitions from the previous steps, you will get a warning about no swap and not formatting, but I’ve had no issues so far.

And select, continue testing on completion.

get the blkid UUID of /dev/sd<x> not /dev/mapper/crypt (learn't the hardway), blkid in a terminal will list all devices

mkdir <mount>

mount /dev/mapper/crypt <mount>

mount <boot> /<mount>/boot/

eg (assuming /dev/sdb1 is the /boot partition)

mount /dev/mapper/crypt /mnt/crypt

mount /dev/sdb1 /mnt/crypt/boot/

chroot <mount>

mount -t proc proc /proc

mount -t sysfs sys /sys

mount -t devpts devpts /dev/pts

sudo apt-get update && sudo apt-get install cryptsetup

edit /etc/Crypttab:

# <target name> <source device> <key file> <options>

crypt UUID=<blkid> /dev/disk/by-label/KEYS:/<keyfile> luks,keyscript=/lib/cryptsetup/scripts/passdev

and then:

update-initramfs -u

and now you should be able to reboot, and find the system will not boot without either the USB key with the /boot partition or the USB key formatted with label KEYS and the key file.

So far we have had no issue removing the USB key with the keyfile once the system has booted.

And we have had only 1 problem laptop, which was a low end netbook that takes forever to boot.

There were many reason why they wanted a key rather than a passphrase, but that’s a whole other discussion, and I haven’t passed this setup by any experts, so use at your own risk.

[barry99705]

I usually do a key file as well as a password. I've had thumb drives get mangled with no way to get back into the computer.

[Life like Opossum]

If you don't restrict the auto-mount of the USB key to a specific serial number you can make copies of the key file and store a backup on a spare usb key. I would still suggest using both passwords and keys to be the most secure.

[oxley]

Also using 32 bytes from a picture file makes the key re-creatable.

One of the reasons they wanted keys (and soon they may go Yubi keys) was the site has several spoon fed precious employees that can't remember “complicated” passwords from one day to the next, heck, one office couldn't remember to hit the num lock before putting in the password of 123, and as everyone used the same account....

I think most of us have been down that track.

The catalyst for this was a laptop was misplaced for a few months (not reported, also was shared amongst a department) with a 3G dongle and it wasn't until we got a very large invoice someone confessed to losing the laptop.