A few years ago there was a major story about credit card account information being compromised because of a stolen laptop. Irrespective of whether personal information should be kept on a company's laptop or not, the issue is why was it so easy to extract? We have all been in the position of disposing of a computer, only to wonder what to do with the hard drive. Any student in this class will know that it is insufficient to simply reformat the disk, as that does not wipe the data. In fact, we have all heard that even if the disk is rewritten, it may be possible, though difficult, to extract the data!

The solutions here are rarely foolproof. Like most any security issue, the path to take is not total safeguard, it is to make it so difficult to break the security that it is not feasible (or cost-effective!). For our personal data, unless you have something very valuable on your system and others know about it, that bar is probably not terribly high. Placing your data on an encrypted filesystem may be sufficient security to ease your mind. It is distressing enough to lose or have stolen your laptop. It is much worse when you must wonder if they are smart enough to use your stored passwords (or, horrors, peruse your browsing history!)

Before you decide to encrypt your data, you should first ask the question: What needs to be encrypted? Does the system data need encryption? Probably not. Neither do the log files, nor, probably, temporary files. Really, about the only data needing encryption is user data, which would be kept on a separate /home partition. You will have to answer this question for your own system.

Setting up for filesystem-level LUKS encryption proceeds like this:

• create a partition
• fill it with random data (this erases any "clues" about where active data is actually stored)
• choose a passphrase (once again, choosing a good passphrase is very important. Hopefully, no one at this point would choose "secret" or "1234567"). Longer,  more random passphrases are better, but a 60-character sentence with some words interchanged is reasonable. Of course, if you forget the passphrase, you have lost all your data!
• set up the device to use encryption. Later, when the device is mounted and the passphrase entered, this basically creates a loop from the raw [encrypted] device through encryption code in the kernel, then back to a new device. A filesystem is then created on the new [unencrypted] device and the filesystem operates as normal.
• Note that an encrypted filesystem only protects data while the filesystem is unmounted! Once it is mounted and the passphrase is entered, the decrypted data is presented with the same permissions as any other data. The bottom line, then, is that LUKS encryption only protects the physical data on the disk from unauthorized access. (In other words, it does no good to use LUKS encrypted filesystems and leave yourself logged in!)
  

Normally, the passphrase must be entered when the filesystem is mounted, at boot time. You can also store it in a keyfile, but for brevity, we will only cover the interactive passphrase entry method.

Preparing your system for LUKS encryption

Before beginning, check that your kernel has the LUKS encryption modules loaded:

lsmod | grep dm_crypt

If nothing is output, you should next try to load the modules

modprobe dm_crypt

If this fails, you must install the cryptsetup-luks package

yum install cryptsetup-luks

We assume you already have a partition (or logical volume) that  you want to be encrypted. The next step, then, is to fill the device with random data. Assuming /dev/xxx is the device file for the [unmounted] partition that you want to encrypt:

dd if=/dev/urandom of=/dev/xxx

For a virtual machine, this takes about 2-1/2 minutes per GiB, so do it in the background when you go to lunch.

Creating and mounting your encrypted filesystem

Now you are ready to set up /dev/xxx for encryption. You must have the passphrase ready:

cryptsetup luksFormat /dev/xxx

Now your encrypted device is ready. You are ready to decrypt it and present the decrypted device for mounting. It will create a new [decrypted] device file and place it under /dev/mapper. You choose the name, here shown as yyy:

cryptsetup luksOpen /dev/xxx yyy

You will have to enter the passphrase here as well. You will now have a new device file /dev/mapper/yyy. From this point on, you simply treat /dev/mapper/yyy as a normal partition - you must create a filesystem on it, mount it somewhere, and use it! Let's assume you want to mount it at /mystuff, which is an existing directory:

mkfs -t ext4 /dev/mapper/yyy

Then get the UUID

tune2fs -l /dev/mapper/yyy | grep UUID

and do your test mount

mount -U theuuid /mystuff

Preparing your LUKS-encrypted filesystem to be mounted automatically

Automating the mount of your LUKS filesystem is a two-step process:

1. mounting the encrypted device, asking for the password, and presenting the decrypted device
2. mounting the decrypted device
   

The second step proceeds as normal via the /etc/fstab. The first step is accomplished by another table, /etc/crypttab. Its format is simple (and is similar to the arguments for the cryptsetup luksOpen command we saw earlier)

newname rawdevice [passphrase]

where the optional passphrase field is a path to a file containing the passphrase for the device. (If this field is used, the passphrase must be on a filesystem that was previously mounted - not on the encrypted filesystem itself.) [ I haven't checked whether the filesystem that contains the passphrase file can itself be encrypted, but I imagine it can. ] If the field is missing or contains the word none, the passphrase is requested at boot.

In our example,

yyy /dev/xxx

would be sufficient

Just like the fstab, a UUID can be used instead. The UUID is added to the encrypted device in the LUKS header when it is formatted for LUKS. All you have to do is retrieve it. You can do this using

cryptsetup luksUUID device

The UUID is then used in the crypttab like this:

newname UUID=uuid-string [passphrase]

Our next example shows the use of UUIDs for both phases of mounting the LUKS device.

A real example

As an example, I configured a VM to use /dev/vda3 as a LUKS-encrypted volume, and to present the decrypted device using the name junk

When I rebooted the system, the passphrase was requested at boot time, then the decrypted device was presented at /dev/mapper/junk. To mount it, the UUID was discovered

# tune2fs -l /dev/mapper/junk | grep UUID
Filesystem UUID:          4c8baa1f-cd4a-4bd3-9191-9e672efce5e7

This UUID was entered into /etc/fstab using the standard format, mounting it at /junk:

# grep junk /etc/fstab
UUID=4c8baa1f-cd4a-4bd3-9191-9e672efce5e7 /junk     ext4    defaults   1 2

Note: the section on LUKS UUIDs italicized below does not appear to work on Redhat 7. On that system, you must used the device file in the crypttab at this time.

We could have used the LUKS UUID to specify the encrypted device in /etc/crypttab as well. This can be discovered by

# cryptsetup luksUUID /dev/vda3
73f35edd-3e6c-4eab-bee5-3f4dc4c58dc1

and editing /etc/crypttab to use it

# grep junk /etc/crypttab
junk   UUID=73f35edd-3e6c-4eab-bee5-3f4dc4c58dc1 none

The resulting version used UUIDs to mount both the encrypted and decrypted device at boot..

Using LUKS encryption for a logical volume

Using LUKS for a logical volume is the same idea. There is just one extra step - preparation of the logical volume first.

1. Create a standard logical volume. This will be accessible at /dev/mapper/lvol, for example
2. Write random data on the [unmounted] logical volume, just the same way you would for the unmounted raw device.
   
3. Use /dev/mapper/lvol as the input to cryptsetup luksFormat, setting the passphrase. This generates the encrypted logical volume.
4. Generate an access point for the decrypted device using luksOpen /dev/mapper/lvol  name, and using the passphrase. This creates an access point (device) for the decrypted logical volume at /dev/mapper/name
5. Create a filesystem using /dev/mapper/name.
   

To automate this at boot, create the crypttab with the line

name /dev/mapper/lvol

Then enter it into the fstab using its device (/dev/mapper/name) or (if it worked in RH7) retrieve the UUID from the filesystem in the usual way and mount it by UUID.