Disk encryption with FreeBSD

FreeBSD comes with a flexible framework that allows you to encrypt whole disks or FreeBSD partitions. The different methods are covered in the disc encryption section of the FreeBSD Handbook. Since I use FreeBSD primarily for my desktop and laptop and not as a server, I am mostly concerned with securing the user data under /home. My method is to put /home on a separate partition and encrypt that with geli. In order to use this, it must be built into the kernel or loaded as a module. This is explained in the manual page. Since encrypted partitions (or rather their device nodes to be technical) are recognizable by the system, the FreeBSD startup scripts know to ask for the password for this partition before trying to use it.

Another use is backup disks. Harddisks with a USB connection are extremely convenient as a backup medium because they are faster and easier to work with than DVDs or tapes. But because they are easily lost or stolen, I encrypt those as well.

When using a new disk, you first have to slice it with fdisk (This is called partitioning it in the PC world), then use bsdlabel to create the labeled BSD partitions. This is covered in more depth in my installa page. I will use a USB connected backup disk as an example.

For backups, I use an external hard disk with a USB connection. This device uses the umass driver, which in turn needs the scbus and da devices. If I plug this disk in, a device node is created. I’ll use da0 as an example, but it could use another number if there are other da devices in use. This disk has a single BSD slice, divided into two partitions. The first 20BG partition (da0s1a) is for the dumps of /, /usr and /var. The rest of the disk is a geli(8) encrypted partition (da0s1d.eli) to store data from /home.

fdisk -I /dev/da0
bsdlabel -w /dev/da0s1
setenv EDITOR /usr/bin/ee
bsdlabel -e /dev/da0s1

The EDITOR variable is set to a somewhat friendlier editor (ee) then the default vi! Next, the slices are made with the second bsdlabel command.

# /dev/da0s1:
8 partitions:
#        size   offset    fstype   [fsize bsize bps/cpg]
  a: 20971520       16    4.2BSD     2048 16384 28528
  c: 488392002        0    unused        0     0         # "raw" part, don't edit
  d: 467420466 20971536    4.2BSD        0     0     0

We now have a partition called /dev/da0s1d that we want to encrypt. The first step is to fill this disk with random data. This will deny any attacker knowledge of which parts of the partition are actually in use.

dd if=/dev/random of=/dev/da0s1d bs=32k

You can experiment with larger block sizes. Last time I timed this, it took about an hour to fill 120 GiB this way.

Next, use geli to prepare and attach the partition;

geli init -l 256 /dev/da0s1d
geli attach /dev/da0s1d

This will initialize /dev/da0s1d for use with geli with a 256-bit key (using the AES algorithm) supplied by a passphrase. The second command will create the device node /dev/da0s1d.eli, which provides access to the unencrypted data. These commands have to given as the root user. Next we will create a filesystem on this device using newfs, and mount it.

newfs -U /dev/da0s1d.eli
mount /dev/da0s1d.eli /mnt/backup

After this, the filesystem is ready to be used. The geli init and newfs steps only have to be carried out once. But attaching the geli provider and mounting the filesystem always have to be done once before using the filesystem. As I mentioned before, the eli suffix on a device when used in /etc/fstab enables the startup scripts to make sure that the encryption device is attach-ed before use. But if you want to do it by hand, use:

geli attach /dev/da0s1d
mount /dev/da0s1d.eli /mnt/backup

After you’re finished with it:

umount /mnt/backup
geli detach /dev/da0s1d

Disk encryption on other systems

Mac OS X also comes with en encryption feature called FileVault. It significant limitations as discussed on the Wikipedia page.

Windows 8.1 ships with “device encryption”. If you sign in with a Microsoft account, the recovery key is uploaded to Microsoft’s servers. If you sign into a domain, that key is uploaded to the Active Directory Domain Services, so it is stored on the domain’s server. As always, there are two sides to this. It gives you the possibility to recover your key if you lose it. On the other hand, others might also get their hands on your key. Basically you’re giving the keys to your digital house to Microsoft or whomever controls your domain.

Professional versions of Windows come with BitLocker.

All of these systems are closed source, and I would hesitate to recommend them on those grounds alone. Since the code is not accessible to security researchers, it is impossible to tell which bugs and weaknesses they have.

crypt

UNIX-like systems like FreeBSD and Linux usually come with a program named crypt that was originally used for this purpose. Do not use this program to encrypt your files! Its encryption algorithm has long since been broken. Use some of the alternatives listed below.

openssl

(I’m mentioning this here because it is part of the FreeBSD base system. So some of the remarks in this section are FreeBSD specific. )

The openssl program that also comes with the FreeBSD base system (see openssl(1)) is considered relatively safe at the time of writing. See also enc(1). Some tips for using openssl;

• Read the above mentioned manual pages!
• Use the bf or aes-256 encryption algorithms.
• Always use the -salt option when encrypting files.
• Do not use the -k or -pass options. Let the program ask you for a password.
• After you have encrypted a file, erase the unencrypted original! Use e.g. the rrm program from my software page, or on FreeBSD one of the wipe ports you can find under /usr/ports/security.

As you can see, there are some things you need to keep in mind when using openssl for encryption. Since it is part of the FreeBSD base system, you can always decrypt things encrypted with openssl even on a machine without any additional programs installed. That can be a plus in case you need to restore encrypted backups to a new machine. To use openssl effectively, it would probably be better to write a wrapper script that calls openssl and takes care of the details, like this;

#!/bin/sh
# Uses openssl to encrypt a single file.
# Check if the argument is a file
if [ ! -f $1 ]; then
    echo "Error: $1 is not a file."
    exit;
fi
# Append .aes to the filename to create the output filename.
outname=${1}.aes
# Use the AES algorithm in cipher-block chaining mode with a 256 bit key.
openssl aes-256-cbc -e -salt -in $1 -out ${outname}
# If the encryption fails, bail out.
if [ $? ]; then
    exit 1;
fi
# Overwrite the old file, and remove it.
SZ=`du $1|awk '{print $1}'`
dd if=/dev/zero of=$1 bs=1k count=$SZ >/dev/null 2>&1 && rm $1

The fact that openssl uses MD5 as a key derivation function has me slightly worried. According to Colin Percival’s slides (pdf), this is relatively cheap to attack by brute force. So I don’t think this is the optimal solution for encrypting files.

ccrypt

The ccrypt program was designed as a replacement for the broken crypt(1) program. It uses the same Rijndael cipher that is used in [aes]. One handy feature is that it by default overwrites the target file with its encrypted contents. This means that you cannot forget to delete the old file. On FreeBSD it is available from the port /usr/ports/security/ccrypt.

scrypt

This program uses the scrypt key derivation function mentioned above. In FreeBSD it is available from ports as /usr/ports/security/scrypt.

GNU Privacy Guard

A good program to use is the GNU Privacy Guard. One thing to remember is that this program uses public key cryptography, using a combination of a public and private key. (All the other programs I’ve mentioned before use only a private key.) This makes the gpg2 program usefull for more than just encrypting your own files, it can also be used for encrypting or signing e-mail messages destined for someone else. If you encrypt a file using another person’s public key, only that persons private key can be used to decrypt it.

This program is a good choice because of its multiple uses. It integrates well with several mail programs. There are also several frontends available to make it even easier to use.

The only downside to using this program is that you need to have your keyfiles available. But carrying your private key around is generally not a good idea; you want to keep that private (even though it is protected by a password).