CryptoFS on GNU/Linux laptop

Last updated: $Date: 2006/05/19 14:40:20 $

It's occurred to me before that I should have an encrypted file system on my laptop. I often leave it lying around at client sites, or I might leave it on the train, or something. Hell, even Her Majesty's spies occasionally lose laptops. Yes, mine is configured so that the screensaver will be running when it's resuscitated. But if blackhats rebooted it, or even worse, removed the HDD and plugged it into another device, my home directory would be exposed to the world.

What I need is to have a part of the file system that's encrypted so that the machine itself can't read it, unless I provide a key which is not stored on the machine (except in memory while the encrypted FS is held open). There's a lot on the 'net about doing this with loopback file systems, but not much that seems recent and/or applicable to 2.6 kernels.

Fortunately, I found James' account of encrypted loopback file systems in FC2 test2, which points to the dm-crypt page. In combination with some comments on this kerneltrap.org thread, these make clear that the old way (losetup -e ciphername /dev/loopn /path/to/file) has been superseded by the device-manager approach, using the crypto extensions for the device manager module. These are in the kernel tree as of 2.6.3, I'm told; they were certainly in 2.6.8.1, although I hadn't turned them on, and they were present and active in my Fedora Core 4 desktop's kernel (2.6.12-1.1447_FC4).

Briefly, the steps are:

Create the file which will contain the encrypted file system
dd if=/dev/zero of=/path/to/file bs=1M count=nnn
where nnn is the size, in megabytes, you want the encrypted "partition" to be.
Attach this to a loopback device
losetup /dev/loop0 /path/to/file
Create the encryption mapping
Before you do this step, see the section below on LUKS.
cryptsetup -y create homes /dev/loop0
You may wish to use another name instead of "homes". It's only a name, but if you change it, you'll need to carry the change through the rest of these steps. The -y flag gets you prompted twice for the passphrase, to avoid the risk of typos ruining your day. Don't forget the passphrase you provide. If you do, you lose all the data on the encrypted file system!
If this step fails, it's probably because you don't have the necessary crypto turned on in your kernel. My config file (for 2.6.13, with a few other patches) can be found here, in case that helps. Particularly important settings seem to be "Device mapper support" and "Crypt target support", both under "Device drivers" -> "Multidevice support".
Optional: check the encryption mapping
cryptsetup status homes
Make a file system on the device
mke2fs -j /dev/mapper/homes
Mount the file system
mount /dev/mapper/homes /mnt

You should now be able to copy files on and off the mounted partition.

LUKS - Linux Unified Key Setup

My laptop and desktop now support LUKS. If LUKS is available to you, the cryptsetup create step above can be replaced with
cryptsetup luksFormat /dev/loop0 cryptsetup luksOpen /dev/loop0 homes the first of these commands only being done once. The benefits of LUKS seem to be:

Without LUKS, when you reuse cryptsetup create to unlock your encrypted file system, if you provide the wrong passphrase, the command succeeds but any subsequent mount attempt fails, as there's nothing but gibberish in the decrypted file device. This is correct behaviour for a good encryption algorithm - any key is as good as any other, save that only one key recovers what you encrypted - but it's unhelpful for a file system. LUKS adds a partition header, and the luksOpen command verifies that the header is visible in the newly-decrypted device. Result: if you provide the wrong passphrase, a more helpful error is immediately produced.
Multiple keys can be used, which may be helpful if you're doing several of these. The sysadmin can set the same key on all of them, for his/her own use in emergency, whilst individual users can have keys peculiar to themselves without running the risk of data loss in the case of forgetfulness. I'm not arguing for key escrow here, I'm just noting that it can be really useful in a corporate environment.

Having the partition appear automatically at boot time

This isn't much use if you want to encrypt your whole home directory, as then you have to mount the home directory before you can log in, and you have to log in before you can mount your home directory. I kludged it together as follows:

Put a line in /etc/fstab that says
/dev/mapper/homes /home ext3 noauto 0 0
Copy this file to /etc/rc.d/rcN.d/S93cryptofs, where N is your usual run level. It's a bit of a hack, but at least it checks if the partition mounts (ie, if you got the passphrase right).
If you can use LUKS, this startup script uses LUKS-compliant commands. And it's less of a hack.

I know this goes without saying, but you need to copy your home directories to the new crypto file system before rebooting! I found this best done manually from single-user mode.

Back to Technotes Index
Back to Main Page