Encrypted data on a laptop isn't something that those who have something to hide need to do, it's also a matter of keeping data safe. While I'm sure no-one would be likely to steal my laptop in order to get access to the data that is on it, I still have an obligation to keep the personal details of students confidential should my laptop be lost or stolen. (This cartoon from xkcd is quite applicable here too.) In this situation, a fully encrypted hard drive isn't required. It doesn't matter if the machine can be booted; it's just the data that's important to keep confidential.

Installation

Having set up the partitions on LVM using the installer you can also specify that individual partitions should be used as encrypted partitions. Specifying that one of the LVM volumes should be encrypted with AES-256 is sufficient, the installer will even help you mount the decrypted volume on /home. (Recent hardware makes the use of that cipher extremely advantageous.)

One problem I did experience was that the installed system was unbootable after doing all this. Oops... It turned out that the cryptsetup and lvm2 packages hadn't been installed on the target system; the absence of lvm2 was particularly problematic as it meant that the initramfs did not contain the tools necessary for mounting /. The installer disk makes an excellent rescue disk from which to correct such problems (manually mount /boot prior to installing the packages so that the initramfs can be regenerated).

Mounting on login

One final touch that make sense for a laptop, is to have /home mounted on login rather than being mounted by a separate passphrase earlier in the boot process. To do this, you need to add your user password as one of the LUKS passwords for the partition:

# cryptsetup luksAddKey /dev/mapper/group-volume

which will prompt you first for an existing passphrase and then for a new passphrase (your user password).

The last step for mounting on login is to use PAM to mount the volume.

# aptitude install libpam-mount

There are many useful guides available, but beware of date material. In particular for Debian squeeze, you should not configure a

/etc/pam.d/common-pammount

for this. Instead, the tool

pam-auth-update

manages which PAM modules are used and this tool will automatically enable pam-mount at install time for you. See /usr/share/doc/libpam-mount/NEWS.Debian.gz for mode details.

The only configuration of pam-mount that is required these days is to tell it what volume to mount and for which user(s). While the configuration is potentially very powerful (NFS or samba home directories etc), for our purposes here, a very simple configuration is sufficient. To /etc/security/pam_mount.conf.xml, we would add:

<volume user="USERNAME" fstype="crypt"
       path="/dev/mapper/volume-group"
       mountpoint="/home" options="relatime,exec,fsck,nodev,nosuid" />

The exact details you obviously need to tune a little for yourself, but that's the general idea. (relatime is what all the cool kids are using these days to improve disk access; you probaby want to make sure you have exec permissions so that you can have scripts etc in your ~/bin; nodev,nosuid are a good idea on a user mountable volume, but if it's your laptop and you've got root on it anyway...).

Removing old configuration

The last thing you need to do is to remove (or comment out) the entries for your encrypted volume from /etc/crypttab and /etc/fstab.

Testing & Troubleshooting

To test, just log in on console. There should be no errors printed and your home directory should now be mounted.

If logging in generates the following errors either on console or in /var/log/auth.log:

 pam_mount(mount.c:64): Errors from underlying mount program:
 pam_mount(mount.c:68): crypt_activate_by_passphrase: File exists
 pam_mount(pam_mount.c:521): mount of /dev/mapper/volume-group failed 

then you'd be forgiving for thinking that mounting had indeed failed. This extraordinarily cryptic error message is actually just telling you that you enabled pam-mount twice and that it was trying to mount the volume twice as a result and the second time fails because the mount point is not empty. As noted above, you do not need to configure pam-mount with a /etc/pam.d/common-pammount file and you do not need @include common-pammount; pam-auth-update takes care of this for you.

If you see the error:

pam_mount(pam_mount.c:100): unknown pam_mount option "use_first_pass"

the this is cured in the same way; this is deprecated and unneeded configuration. Just remove it and the error goes and the mount still works.