Encrypt Your Root Filesystem

I successfully extrapolated your instructions to an Intel architecture PC with only minor changes required.

**Preparing the USB Flash Disk

I prepared the USB Flash disk by formatting it as FAT16 and using syslinux (http://syslinux.zytor.com/) to install the bootstrap program. This works cleanly to boot most PC's built in recent years. It may be necessary to go into the BIOS and add USB to the list of boot options, depending on how your PC is setup.

**Modifying mkinitrd

I downloaded the latest source for mkinitrd (4.2.03) and applied the patch that you specified in your article. The patch had been updated since your article, so the flag -authtype=paranoid is no longer required: mkinitrd now automatically looks for /etc/crypttab to determine the authtype setting.

I had to edit a line in /sbin/mkinitrd to make it work. The original line that runs cryptsetup is as follows in mkinitrd (line 787 for 4.2.03):

echo "cryptsetup $cryptsetup_params -d /root-key create root /dev/root" >> $RCFILE

I had to change /dev/root to /dev/hdxx, consistent with the entry in /etc/crypttab:

echo "cryptsetup $cryptsetup_params -d /root-key create root /dev/hda6" >>$RCFILE

(In my case /dev/hda6 is the encrypted partition.)

This is pure hacking, I don't know why mkinitrd uses /dev/rootdev here.

**Verifying presence of aes module

Mkinitrd looks for aes.ko by scanning modules.dep. In the latest version of Fedora, FC3 with the 2.6.10-1.760_FC3 kernel, the aes module is actually aes-i586.ko, not aes.ko. Rather than modify mkinitrd to handle this difference I copied aes-i586.ko to aes.ko, in the same subdirectory, and then ran depmod to register the change in the modules.dep file:

# cd /lib/modules/2.6.10-1.760_FC3/kernel/arch/i386/crypto
# cp aes-i586.ko aes.ko
# depmod -a

**Running mkinitrd

Mkinitrd can now be run, as described in your article, to produce the initrd file. I will use initrd.gz as the file name in the rest of this desciption, although it can be named anything (initrd-.img is commonly used).

**Copy files to USB Flash key

I copied /boot/vmlinuz-2.6.10-1.760_FC3 (shortening the name to vmlinuz for convenience) and the new initrd file, initrd.gz, to the root of the USB Flash disk. Alternativley you can have mkinitrd write the new initrd.gz file directlly to the USB Flash disk, as done in the artilcle.

**Booting with syslinux

Rebooting the PC with the USB Flash key inserted displays some information and presents the syslinux prompt: boot: Enter the name of your kernel file and the keyword "initrd=" followed by the name of your initrd file:

boot: vmlinuz initrd=initrd.gz

Alternatively, the required boot directions can be put in the syslinux.cfg file and referenced with a label at the prompt.

While I found the article interesting and informative, I did have one issue with this configuration: the key is kept in plan text on the USB device. Wouldn’t it be better to create a program that could reliable create a 256bit key from an 8 to16 byte pass phrase? In this way, even if someone borrowed your USB device they still wouldn’t be able to access the machine without the pass phrase.

I missed the article on encrypting the home directory, but from the references made to it in this article I think it suffers from the same issue. It doesn’t really protect against physical attack as the password is in plan text on an unencrypted partition on the same machine. As an attacker all I would have to do is plug your hard drive into my machine, mount the root directory, get the key, then mount the encrypted drive. If I was willing to steal your computer to get to your data, then this presents no barrier. On the other hand, if they key is generated via an md5 (or some other) hash, then I’m still stuck trying to brute force it.

I’ve often thought of modifying the kernel code for ext3 so that unless my kernel was used to access the partition, it would be so many meaningless bits.

- John T. Williams