Cryptmount allows you to encrypt both your filesystems and swap space. An encrypted filesystem can be stored on a block device like a normal filesystem — for example, using /dev/sda2 — or inside a normal file in another filesystem. This later method is especially handy when you would like to work with an encrypted filesystem without changing your partition tables or working with the Logical Volume Manager (LVM). Cryptmount can also encrypt your swap space so that information from an encrypted filesystem is not inadvertently made less secure by the Linux kernel swapping a process out to disk.
The encryption Cryptmount sets up is performed in the Linux kernel at the device mapper level. This means that you can create any supported filesystem type on top of the encrypted device mapper block device file. Cryptmount handles setting up the device mapper encryption and mounting the filesystem that lives on top of the encrypted device mapper layer. Simple use of Cryptmount doesn’t require you to know about any of these details, however.
Cryptmount is packaged in Ubuntu Gutsy Universe and is available for Slackware and Gentoo in various forms. There is also an RPM file on the Cryptmount SourceForge.net page which you can use to install on Fedora 8.
The simplest way to get started using Cryptmount is with the interactive script cryptmount-setup. It lets you quickly create an encrypted filesystem in a single file. The defaults for cryptmount-setup are geared towards creating a directory under /home for encrypted content.
Take note of the
cryptmount --unmount message. Although the Linux kernel will see /home/crypt as just another filesystem, you shouldn’t
umount /home/crypt, because Cryptmount will still consider it to be active. If you do, the kernel filesystem would be unmounted, but Cryptmount would not let you remount it and will give you the message, “create ioctl failed: Device or resource busy.”
Once the filesystem is unmounted, you cannot issue the correct
cryptmount --unmount my-encrypted-files command either, because Cryptmount will tell you that the filesystem does not appear to be mounted. The solution is to use the
--release option to tell Cryptmount to release resources associated with a cryptmount that has already been unmounted by other means.
In the above session the encrypted filesystem is using ext3. You can specify the filesystem (ext2, ext3, XFS, etc.) to use, along with other options, inside the /etc/cryptmount/cmtab file. The above invocation of cryptmount-setup will have created an entry in cmtab for us already:
The dev option specifies the name of the block device or the filename where the encrypted filesystem is to be stored. The dir option is where to actually mount the encrypted filesystem. The type of filesystem is specified with the fstype, and fsoptions specifies the filesystem options in the same manner as in fstab. Keyformat and location are fairly straightforward. For a full description see the cmtab manual page. Another option specified here is to store the keyfile itself on a USB flash drive so that you can keep the key separate from the machine it unlocks.
The cipher option lets you choose which encryption algorithm to use for your Cryptmount filesystem. The default is AES, which should be fine for almost all users. The commands shown below display the ciphers that are available for the kernel you are running. If you have some encryption either built into your kernel or in a currently loaded kernel module, it will show up in /proc/crypto. To see which options are available for a kernel module, use modprobe to load it and check its information in /proc/crypto.
The cryptmount-setup script must be run as root, as must most other commands that perform the same work as the script. The process of manually setting up an encrypted filesystem is shown in the cryptmount man page, so in this article I’ll put a slight variation on it by changing some options and targeting an encrypted filesystem stored entirely in the user’s home directory.
I’ll set up a 64MB encrypted filesystem which will be mounted inside my home directory using the XFS filesystem. As regular users cannot specify another cmtab file path, we’ll have to edit the global /etc/cryptmount/cmtab and place our Cryptmount information in there. The
--generate-key option specifies the desired key size in bytes. In this case I want a 256-bit (32-byte) key. This is where the min and max keysize from /proc/crypto are relevant; you must use a value within that reported range. The
--prepare option will have cryptmount set up all device mapper files for the filesystem but not actually mount it. This is exactly what we are after, so that we can create a filesystem on the device mapper supplied device file. As we have seen above, calling
--release will get cryptmount to release any resources and device mapper files for a filesystem, letting us start clean on the next line getting cryptmount to mount the (recently created) filesystem. Still as root, we modify the protection of the root directory of the filesystem to allow the ben user to read and write to it and unmount it again. At this point the ben user can freely mount, interact with, and unmount the encrypted filesystem.
The contents of the swap file on disk do not need to be preserved between one mounting and the next, so we can use random data as the key that protects the swapfile. Each time the swapfile is mounted again, the script chooses a new random key and recreates the swapfile with mkswap. This avoids having to remember a passphrase for the swapfile. The down side of a random key is that we can never recover the contents of an unmounted swapfile, but we are not interested in doing that, so we can just use the /dev/random file for our key.
The code segment below will create an encrypted swapfile in the file /var/swapfile. In this case it is only 32MB of swap, but if the initial
dd command were changed to create a 16GB file, then the remaining commands would create a huge encrypted swapfile.
Because the cmtab lists swap mounts as fstype=swap, you might attempt to mount an encrypted swap partition without using the
--swapon option. This mistake will lead to a page of complaints from the mount command and no encrypted swap partition. Although the fstype is swap, you have to use the
--swapon option to mount encrypted swapfiles. If you want to use a separate partition for encrypted swap, replace the path in the dev= line to point to the block device for your swap partition. Make sure not to list the swap partitions and files in /etc/fstab so that they don’t get set up twice!
There is no option in cmtab to mark mount points to be automatically mounted after a reboot. You must list the names of the cryptmounts that you would like to bring up at boot time in the /etc/default/cryptmount file. The two variables of interest are CM_BOOTFS for filesystems to bring up and CM_BOOTSW for encrypted swap to set up at boot time. The below commands set up both an encrypted filesystem and swap space. With the change to the configuration file in place, the cryptmount and cryptmount-early services are set to start at boot time. During boot up the system will prompt you for the passphrase for home-ben-myencfs (in this example; you’ll have your username on your system instead of “ben”) and then continue to boot. Both home-ben-myencfs and the swap will be mounted when the system has booted.
You can change the passphrase for an encrypted filesystem using the
cryptmount --change-password option. This changes the password that is used to encrypt the key for the encrypted filesystem. As such the filesystem itself does not need to change.
Cryptmount is useful for protecting information on mobile devices running Linux. Knowing that both your home directory and swapfile are encrypted makes having your laptop stolen an inconvenience and perhaps a financial loss, but not necessarily a data leak. Of course you must select passphrases that are resilient to dictionary attacks to protect information against somebody who wants the data more than the laptop (insert paranoia here).
Ben Martin has been working on filesystems for more than 10 years. He completed his Ph.D. and now offers consulting services focused on libferris, filesystems, and search solutions.