Encrypt your hard drive (1)
There’s been a lot of talk in the past year or so about the security of your internet data, first with the Edward Snowden revelations and later with the Heartbleed bug in OpenSSL and Shellshock, the Bash vulnerability. There was also a lower-profile bug in GnuTLS discovered shortly before Heartbleed. As a result of all this, we’re paying more attention to the security of our data in transmission – but what about when we store it?
We’ve previously mentioned TrueCrypt , which is great for encrypting removable storage (as long as you use the right version, see p51 for details ), especially because it’s available for Windows and Mac too, but if you’re really concerned you may want to encrypt your entire home directory, or even the whole hard drive. This is not just about protection from black hat hackers: what if you have personal, business or otherwise confidential information stored on your laptop and it’s lost on the train or taxi or simply stolen? There are two popular types of encryption that are supported by the Linux kernel: dm-crypt and ecryptfs.
The latter is an encrypted filesystem that sits on top of a standard filesystem. If you mount the ‘lower’ filesystem, you’ll see all the files but their contents, and usually their names, are encrypted. It works at the directory level, and other directories on the same filesystem can be left unencrypted or encrypted separately. This is the method used by Ubuntu, among others, to encrypt users’ home directories.
The other method, which is the one we’ll look at here, is dm-crypt , and it works at a lower level, encrypting the block device that the filesystem is created on. A benchmark run by Phoronix showed better performance from a whole disk that was encrypted with dm-crypt than with using ecryptfs on home directories.
A stack of blocks
Before we look at the encryption, it’s important to understand how block devices work. Block devices are the system’s interface to storage hardware, for example /dev/sda1. Underneath the block device is the hardware driver, such as a SATA driver, and then the hardware itself. The operating system then works with the block device to create a filesystem on it.
That is the usual view of block devices, but they can be much more. In particular, a block device can be an interface to another set of block devices – they can be stacked. You already do this: you have a filesystem on /dev/sda1 (a disk partition) that is a block device referencing /dev/sda (the whole disk). Technologies such as RAID and LVM (Logical Volume Management) also stack block devices.
You could have LVM on top of a RAID array which itself is stacked on the block devices of the individual disks or their partitions. Whole device encryption using dm-crypt works like this: it creates a block device on top of your storage medium which encrypts data as it is saved and decrypts it as it is read.
You then create a standard filesystem on top of the encrypted block device and it functions just the same as if it had been created on a normal disk partition. Many distros have an option to install to an encrypted disk, but here we’ll look at creating and working with dm-crypt devices directly to see how they work, as opposed to some black magic that’s been set up by the installer.
Dm-crypt uses the kernel’s device mapper subsystem (hence the name) to manage its block devices and the kernel’s cryptographic routines to deal with the encryption. This is all handled by the kernel, but we need userspace software to create and manage dm-crypt devices, with the standard tool being cryptsetup . It’s probably already installed on your distro – if not, it will definitely be in its main package repositories.
Cryptsetup can create two types of encrypted devices: plain dm-crypt and LUKS. If you know you need to use plain dm-crypt , you already know far more about disk encryption than we’ll cover here, so we’ll only look at LUKS, which is the best choice for most uses.
Experimenting with filesystems, encrypted or otherwise, risks the data on the disk while you’re learning. All examples here use /dev/sdb, which we take to be an external or otherwise spare device – do not try things out on your system disk until you’re comfortable doing so.
All these commands need to be run as root, so log into a terminal as root with su , or prefix each command with sudo . Let’s start by creating an encrypted device: cryptsetup luksFormat /dev/sdb1 This sets up an encrypted partition on /dev/sdb1 after prompting you for a passphrase.
You can open the encrypted device with: cryptsetup luksOpen /dev/sdb1 name This will ask for the passphrase and then create the device in /dev/mapper, using the name given on the command line. You can then use /dev/mapper/name as you would any disk block device: mkfs.ext4 /dev/mapper/name mount /dev/mapper/name/ /mnt/encrypted The usual rules about passphrases apply: keep them long and varied, hard to guess but easy to remember. If you lose the passphrase, you lose the contents of the device.
Keeping the keys safe
A LUKS encrypted device contains eight key slots. Keys are another term for passphrases, so you can assign multiple passphrases to a device, which is useful if you maintain multiple systems and want to have a master passphrase that only you know.
When you use LuksFormat , the passphrase you give is stored in slot 0. You can then add another with: cryptsetup luksAddKey /dev/sdb1 You’ll be asked for an existing passphrase and then prompted for the new one.
A key can also be the contents of a file instead of a passphrase; the file can contain anything but it’s usual to use random data: dd if=/dev/urandom of=/path/to/keyfile bs=1k count=4 chmod 0400 /path/to/keyfile cryptsetup luksAddKey /dev/sdb1 /path/to/keyfile cryptsetup luksOpen –key-file /path/to/keyfile /dev/sdb1 name It goes without saying that keyfiles should be stored securely, readable only by root and not stored on the encrypted device.
Personally, even if a volume is always unlocked by key file, I prefer to also set a very strong passphrase, recorded in a secure place, to guard against the key file ever becoming corrupted or otherwise inaccessible. Keys can also be changed or removed with the luksChangeKey and luksRemoveKey commands.
So far, we’ve stuck with the default encryption choices, but cryptsetup accepts –hash and –cipher options. The former sets how the passphrases should be hashed, while the latter selects the encryption method.
The defaults are usually more than sufficient but you can see the available options by using: cryptsetup –help These options are needed only with LuksFormat .
Once the encrypted device has been created, cryptsetup will automatically use the correct settings when opening it. It’s wise to stick with popular ciphers and hashes unless you have a very good reason for using something different. A less frequently used method is more likely to harbour unknown deficiencies due to the fewer number of people using it, as happened recently with the Whirlpool hash implementation in the libcgrypt library used by cryptsetup .
Fixing the implementation caused problems for those with systems that were already using the broken hashes. Another reason for sticking to commonplace methods is portability. This doesn’t matter for an internal disk, but if you want to use an encrypted disk on another system, that must have the used hashes and ciphers installed too. ?