loop-aes and Debian
This post was lying around, but I never actually popped it up on the blog. I was just playing around with loop-aes on Debian, since I had used it in days long since gone by and had a desire to try it out again. Loop-aes served its purpose for a short period, but over a month has now passed since I touched any of the Debian boxes around here.
(On FreeBSD 6, I just quickly hacked /etc/rc.d/gbde script to support encryption of the device mounted as /tmp with random keys, much like is already available for swap via /etc/rc.d/encswap, and I played around with using encrypted memory disks, so maybe I will do a quick post on that.)
The way one of my Debian workstations was configured, all of my personal data was stored in the partition mounted as “/home”, and I wanted all data written to this partition transparently encrypted before write (and, of course, transparently decrypted on read). I also wanted this functionality applied to the parition mounted as “/tmp” and the swap partition. While I used GPG to provide services for encryption my email and files, I needed something more robust and settled on loop-aes. I say this as if I researched it, but the reality was that I had used loop-aes a while back, and, in slightly more recent times, brought that knowledge back for a project at my previous employer.
As has been read numerous times in previous Debian posts on this blog, I fired up “aptitude” and searched for “loop-aes”. Lo and behold, there it was. I installed the “loop-aes-source” and “loop-aes-utils” Debian packages. Now, as described in the previous post, the “loop-aes-source” was the code for kernel module, and so it had to be custom built for the custom kernel I was running. Well, as we saw before, that can be quite easy.
From the “/usr/src” directory, I extracted (”tar -xvjf loop.aes.tar.bz2″). This created the directory “modules/loop-aes” under the “/usr/src” directory, which contained the loop-aes kernel module source code.
Unhappily, as I looked at the readme for loop-aes (”cat /usr/src/modules/loop-aes/README | less”), I found that I would have to rebuild the kernel after editing the kernels configuration (/usr/src/linux/.config). While “CONFIG_MODULES=y” and “CONFIG_KMOD=y” were proper, “CONFIG_BLK_DEV_LOOP=m” was not and needed to be changed to “CONFIG_BLK_DEV_LOOP=n”. I made the change, cleaned up a few other areas I wanted to tweak in the kernel, and proceeded to build the new kernel image.
I ran the following from “/usr/src/linux”.
- fakeroot make-kpkg clean
- fakeroot make-kpkg –append-to-version=.03102005 –revision=10.01.Custom –added-modules=loop-aes kernel_image
- modules_image
This built a kernel-image and loop-aes into Debian packages, which could be installed as root by running “dpkg -i kernel-image-2.6.8.03102005_10.01.Custom_i386.deb” and then “dpkg -i loop-aes-2.6.8.03102005_10.01.Custom_i386.deb”.
The kernel was installed as “/boot/vmlinuz-2.6.8.03102005″, a System.map was created as “/boot/System.map.2.6.8.03102005″, and the configuration for the kernel was installed as “/boot/config-2.6.8.03102005″. I ran “depmod -v 2.6.8.03102005″ and, then, to create the initrd-img, I run “mkinitrd -o /boot/initrd-img-2.6.8.03102005 2.6.8.03102005″. In “/boot”, I remove the symbolic links for “config”, “initrd.img”, “System.map”, and “vmlinuz”, and replaced them with symbolic links to the 2.6.03102005 counterparts. Finally, I ran “update-grub”, which updated “/boot/grub/menu.lst” to include this kernel and set it as the default, and then I rebooted the system.
That was the easy part. Now I needed to configure it.
First, I needed to activate the loops for loop-aes. I ran “modprobe -r loop” and then “modprobe loop”. This loaded the loop-aes module and created devices “/dev/loop0″ through “/dev/loop7″ by default. In order to have loop-aes automatically loaded during boot up, which I needed for mounting “/home” automatically during boot, I added the “loop” on a separate line in “/etc/modules”.
The readme for loop-aes contained all sorts of useful examples for setting up the system exactly as I wanted it. After reading the readme (”zcat /usr/share/doc/loop-aes-2.6.8.03102005/README.gz | less”), I decided to create keyfile encrypted with gpg for use by loop-aes for encrypting “/home”. I did this with the following commands as “root”, based on an example in the readme for loop-aes.
- mkdir /etc/loop-aes
- openssl rand -base64 2880 | head -n 65 | tail -n 64 | gpg –symmetric –cipher-algo aes256 -a > /etc/loop-aes/homekey.gpg
- chown root:root /etc/loop-aes/homekey.gpg
- chmod 600 /etc/loop-aes/homekey.gpg
Note: The GPG command above prompted for a password to be entered. This password will be derived into a symmetric key that GPG will use to AES encrypt the keys that will be used to encrypt the “/home” partition. This is one of the weakest links in the chain of this setup, so choosing the longer and more random the password, the better.
After this was completed, I rebooted the system into single user mode. On Debian with the grub bootloader, this was simply a matter of selecting the “Recovery” boot up variant for the kernel desired (2.6.8.03102005 in this case).
My goal was to encrypt swap, “/tmp”, and “/home”. Once in single user mode, I backed up the contents of home (”cd /home; tar -cvjf /root/home.tar.bz2 *”), and then unmounted “/home” (”umount /home”), unmounted “/tmp” (”umount /tmp”), and turned off swap (”swapoff -a”). Next, I edited “/etc/fstab”, placing the configurations for our encrypted partitions at the bottom of the file and commenting our their previous “unencrypted” variants.
-
/dev/hda5 none swap sw,loop=/dev/loop1,encryption=AES128 0 0
/dev/hda6 /tmp ext2 defaults,loop=/dev/loop2,encryption=AES128,phash=random/1777 0 0
/dev/hda9 /home ext2 defaults,loop=/dev/loop3,encryption=AES128,gpgkey=/etc/loop-aes/homekey.gpg 0 0
Now that the partition for “/home” was going to be encrypted, I needed to reformat it with the following commands.
- losetup -F /dev/loop3
- mkfs -t ext2 /dev/loop3
- losetup -d /dev/loop3
Note: When running this first command, I was prompted to enter the password for the “/etc/loop-aes/homekey.gpg” file. Anytime an attempt to mount “/home” is made, a password prompt appears to enter the password for the “/etc/loop-aes/homekey.gpg” file.
After this was completed, I was turned swap back on (”swapon -a”), mounted “/tmp” (”mount /tmp”), and mounted “/home” (”mount /home”). Next, I extracted my backup of the contents of “/home” into “/home” (”cd /home; tar -xvjf /root/home.tar.bz2 ./”).
Then, I rebooted the system and was good to go.
The negative side effect here was that during boot up, I was prompted to enter the password for the “/etc/loop-aes/homekey.gpg” file as this was required to mount “/home” and mounting of “/home” was configured to happen automatically at boot. I preferred this extra layer during boot, but there are ways to avoid it; however, this avoidance might not be good for the overall security of the configuration.
Note: If this is done on a laptop, beware of suspsend, as it could suspend to disk the plaintext keys for any mounted encrypted partitions. There are steps that can be taken here, such as making sure to manually unmount encrypted partitions and turn off swap before letting a laptop suspend, shutting down a laptop rather than letting it suspend, or having the laptop unmount encrypted partitions and turn off swap automatically as part of the suspend process. The latter can be accomplished using using suspend scripts, but it has the disadvantage of needing a forced unmount that could be problematic to open files contained within the encrypted partition; however, if suspend is configured such that it can occur automatically, then I typically do this as having the plaintext keys written to disk essentially nullifies all of the previous efforts.
—
What reminded me of this lingering blog post was a quick discussion that occured on the Practical Security mailing list. My minor post was bounced, so I will just pop it in down here. (x’s used below so the email addresses are not harvested.)
Date: Tue, 13 Dec 2005 00:07:44 -0500
From: lists <xxxxxxxx@xxxxxxxx.xxx>
To: Alexander Klimov <xxxxxxxx@xxxxxxxx.xxx>
CC: Hagai Bar-El <xxxxxxxx@xxxxxxxx.xxx>, xxxxxxxx@xxxxxxxx.xxx
Subject: Re: [PracticalSecurity] Not-different-enough IVs?On 12 Dec 2005 12:42:48 +0200, Alexander Klimov wrote:
> On Sun, 11 Dec 2005, Hagai Bar-El wrote:
>> The authors claim that (without encryption) adjacent sectors will
>> have IVs that are just a few bits apart from each other. However,
>> does this matter? Does anyone see the motivation for “hashing”
>> addressed before using them as IVs?
>
> First of all CBC with a non-random IV gives away information about
> plain text: if, say, one (even) sector starts with ‘x…x0′ and the
> next one (odd) starts with ‘x…x1′ (IV is the sector number), then
> the first block of both sectors will be the same.This made me remember an implementation issue in loop AES (and others),
and a quick Google (loop aes watermark) popped up a post [1] and a paper
[2].[1] http://www.uwsg.iu.edu/hypermail/linux/kernel/0402.2/1137.html
[2] http://mareichelt.de/pub/notmine/wisa2004.pdf-Andrew
December 30th, 2005 at 12:54 am
[...] So, as mentioned earlier, I played around with using gbde on memory disks in FreeBSD 6. The following are a few notes. At the very end, I also talk about encrypting the disk partitions used for swap and mounted as “/tmp”. [...]
July 7th, 2006 at 4:12 pm
Don’t forget /var/tmp when looking at tmp!
March 13th, 2008 at 7:49 am
I would add some non-obvious for beginners (like I am) things so that they not to waste their precious time of sleep in case of some mess
While editing fstab it is important to put the line about swap above all, since it must be activated before mounting the rest of encrypted partitions. Remember that the order fstab gives to the boot procedure is important. The root partition must be mounted before encrypted ones. (It’s possible to encrypt root partition, too, but it’s a different thing, not this case.) If you have several encrypted partitions that use different gpg-keys, you should remember which goes first in fstab, as the boot procedure when mounting them and asking for your password will not show the partition’s name, so you assume that it is the first one it finds in fstab.
Also, it is important to put “0″, not “2″ in the last field of each line describing encrypted partitions. “2″ enables fsck when booting, but fsck does its work _before_ mounting, so you’ll get an error. Putting “0″ ensures you that fsck test will never be performed.
Fsck, when trying to check an encrypted partition says that it cannot find any file system on it and suggests to do some manual correction (that you shouldn’t do if you’d like to have your data unscrambled). If you see something like this, most probably you’ll be prompted to give the root password to edit things or to press Ctrl-D to continue. You could press Ctrl-D to follow but it has no sense, as you’ll get a mess. Enter the password and reboot, and choose single user mode when getting grub prompt. When booting again you’ll get that error once more so press Ctrl-D, and now you’ll be able to edit fstab while being in single user mode.
Good luck!
March 13th, 2008 at 12:30 pm
Very informative comment. Thank you for taking the time to post it!
Also of possible note to newbies, they may want to look at Ubuntu Gutsy, which can be configured to walk through full disk encryption setup during installation. Ubuntu is derived from Debian, and has become my GNU/Linux flavor of default these days, although I tend not to leave the (Free)BSD world too much.