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
and plugged it into another device, my home directory would be exposed to
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
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 184.108.40.206, although I hadn't
turned them on, and they were present and active in my Fedora Core 4 desktop's
Briefly, the steps are:
You should now be able to copy files on and off the mounted partition.
- 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
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
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