Encrypting Linux Filesystems with dm-crypt

Information security is one of the most important tasks most system administrators will have to manage as a business requirement and custodial responsibilities to organizations. While there are many methods available to reliably encrypt filesystems for security, backup and storage requirements, linux users can employ the dm-crypt tool to protect hardware and disk arrays. An encrypted filesystem will protect against bare-metal attacks against a hard drive. Anyone getting their hands on the drive would have to use brute force to guess the encryption key, a substantial hindrance to getting at your data.

Windows and Mac OS X each provide its own standard cryptofs tools while Linux, of course, provides many tools to accomplish the task. The tool of choice these days, it seems, is dm-crypt. Invoked with the userspace cryptsetup utility, dm-crypt provides a fairly clean and easy-to-use cryptofs tool for Linux.

Additionally, CentOS 5 includes an improved version of dm-crypt that supports LUKS. LUKS is an upcoming standard for an on-disk representation of information about encrypted volumes. Meta-data about encrypted data is stored in the partition header, and allows for compatiblity between different systems and support for multiple user passwords. Besides that, GNOME and HAL have support for handling LUKS volumes, and can automatically prompt for a password if a removable medium with a LUKS volume is attached. If you do not require compatiblity with older CentOS versions or systems that do not support LUKS, it is advised to use the LUKS scheme. The commands for setting up encrypted LUKS volumes are also described in the examples in this article.

Here are Scripts to automate creation, un-mounting, and remounting of LUKS encrypted filesystems following the method described below.

Required Packages

Before getting started, make sure all the requisite packages are installed:

• cryptsetup (cryptsetup-luks for CentOS-5)
• device-mapper
• util-linux

It’s likely, however, that they’re already present on your system, unless you performed a very minimal installation.

Initial FS Creation

I typically encrypt files, not whole partitions, so I combine dm-crypt with the losetup loopback device maintenance tool. In the bare language of the Unix shell, here are the steps to create and mount an encrypted filesystem.

# Create an empty file sized to suit your needs. The one created
# in this example will be a sparse file of 8GB, meaning that no
# real blocks are written. Since we will force block allocation
# lateron, it would not make much sense to do this now, since
# the blocks will be rewritten anyway.
dd of=/path/to/secretfs bs=1G count=0 seek=8
# Lock down normal access to the file
chmod 600 /path/to/secretfs
# Associate a loopback device with the file
losetup /dev/loop0 /path/to/secretfs
# Encrypt storage in the device. cryptsetup will use the Linux
# device mapper to create, in this case, /dev/mapper/secretfs.
# The -y option specifies that you'll be prompted to type the
# passphrase twice (once for verification).
cryptsetup -y create secretfs /dev/loop0
# Or, if you want to use LUKS, you should use the following two
# commands (optionally with additional) parameters. The first
# command initializes the volume, and sets an initial key. The
# second command opens the partition, and creates a mapping
# (in this case /dev/mapper/secretfs).
cryptsetup -y luksFormat /dev/loop0
cryptsetup luksOpen /dev/loop0 secretfs
# Check its status (optional)
cryptsetup status secretfs
# Now, we will write zeros to the new encrypted device. This
# will force the allocation of data blocks. And since the zeros
# are encrypted, this will look like random data to the outside
# world, making it nearly impossible to track down encrypted
# data blocks if someone gains access to the file that holds
# the encrypted filesystem.
dd if=/dev/zero of=/dev/mapper/secretfs
# Create a filesystem and verify its status
mke2fs -j -O dir_index /dev/mapper/secretfs
tune2fs -l /dev/mapper/secretfs
# Mount the new filesystem in a convenient location
mkdir /mnt/cryptofs/secretfs
mount /dev/mapper/secretfs /mnt/cryptofs/secretfs

Unmount and Secure Filesystem

To unmount and secure the encrypted filesystem manually, you essentially do the last part of the set instructions in reverse.

# Unmount the filesystem
umount /mnt/cryptofs/secretfs
# Remove device mapping
cryptsetup remove secretfs
# Or, for a LUKS volume
cryptsetup luksClose secretfs
# Disassociate file from loopback device
losetup -d /dev/loop0

Remount Encrypted Filesystem

Once you’ve created an encrypted filesystem, remounting it is a relatively short process:

# Associate a loopback device with the file
losetup /dev/loop0 /path/to/secretfs
# Encrypt mapped device; you'll be prompted for the password
cryptsetup create secretfs /dev/loop0
# Or, for a LUKS volume
cryptsetup luksOpen /dev/loop0 secretfs
# Mount the filesystem
mount /dev/mapper/secretfs /mnt/cryptofs/secretfs

Note that cryptsetup will not provide a useful error message if you mistype the passphrase. All you’ll get is a somewhat unhelpful message from mount:

• mount: you must specify the filesystem type

If that happens, then recycle cryptsetup and try mounting the filesystem again:

cryptsetup remove secretfs
cryptsetup create secretfs /dev/loop0
mount /dev/mapper/secretfs /mnt/cryptofs/secretfs

This does not apply to LUKS volumes, where cryptsetup will provide a useful error message during the luksOpen step.

Adding additional keys to a LUKS volume

As mentioned earlier, the LUKS format allows for the use of multiple keys. This means that you can add more than one key that can be used to open the encrypted device. Adding a key can simply be done with:

cryptsetup luksAddKey <device>

For instance, if you use the /dev/loop0 loopback device, you could execute:

cryptsetup luksAddKey /dev/loop0

cryptsetup will ask you to enter one of the existing passphrases twice. After that you will be asked to enter the additional key twice. When this step is also succesfully completed, you can use the existing key(s), and the new key to open the volume.

Setting up encrypted volumes during system boot

Sometimes you may want to set up encrypted volumes during the system boot, for instance, to set up an encrypted home partition for a laptop. This can be done easily on CentOS 5 through /etc/crypttab. /etc/crypttab describes encrypted volumes and partitions for which a mapping should be set up during the system boot. Entries are separated by a newline, and contain the following fields:

mappingname        devicename        password_file_path        options

Though, normally you don’t need all four fields:

• Most of the possible options for the options field are ignored for LUKS volumes, because LUKS volumes have all the necessary information about the cipher, key size, and hash in the volume header. Second,

• Normally, you don’t want to store a password file in plain text on the root partition. It’s certainly possible to store it somewhere else, but at this boot stage in rc.sysinit only the root partition is normally mounted read-only. If the password field is not present, or has the value none, the system will prompt for the password during the system boot.

So, if you are using a LUKS volume and would like to prompt the system for a password, only the first two fields are required. Let’s look at a short example:

cryptedHome        /dev/sdc5

This creates a mapping named cryptedHome for an encrypted volume that was previously created on /dev/sdc5 with crypsetup luksFormat /dev/sdc5. If you have also created a filesystem on the encrypted volume, you can also add an /etc/fstab entry to mount the filesystem during the system boot:

/dev/mapper/cryptedHome       /home        ext3    defaults        1 2

There are two options that are not ignored for LUKS partitions:

• swap: the volume will be formatted as a swap partition after a mapping is set up.

• tmp: the volume will be formatted as an ext2 filesystem, with permissions set up correctly to be used as a filesystem for temporary files.

Both options require that there are entries for using the mapping in /etc/fstab, and both options are destructive. An entry for an encrypted swap partition could look like this:

cryptedSwap        /dev/sda2        none        swap

Or if you do not want to type a password for the swap partition during every boot:

cryptedSwap        /dev/sda2        /dev/urandom        swap

Note that this will not work if /dev/sda2 already is a LUKS partition, because LUKS partitions require a non-random key.

If you need to get support with your websites and web applications contact our team or send us a message.