Protecting Files at Home Using Encrypted Containers

Chances are you have some type of information on your desktop or
laptop computer that someone else wants--for the wrong reasons. For the
most part, your information is relatively safe in your home. However,
if someone was to break into your house and steal a computer,
what would he or she walk away with? Medical information? Bank account
information? Tax records? With the loss of any of these to the wrong
person, you could be facing years of trying to get your life straightened
out due to identity theft.

Concerned about this type of situation, I decided to engineer a way of protecting my family's
critical information. But before I started, I had to set a few goals
for whatever it was that I built:

• It had to be as simple as possible to
  use.
• Data loss was not acceptable.
• The data had to be protected even if a computer
  physically was stolen.

The first goal, simple to use, was absolutely necessary. I wouldn't be
the only one using the system, so it had to be geared toward someone
non-technical. Setting it up could be difficult, but in the long run
it wouldn't be used or useful if the solution itself was difficult. Data loss
also was an important criterion. Protected data is worthless if you have no
way of getting it back in the event of a hard drive failure. The last
criterion was the main point of doing this whole project: if a computer was stolen,
how long would it take before I could get a full night's sleep knowing
that someone had access to all the information necessary to steal the
identity of one of my family members?

Once my goals were set, I went about researching my options and evaluating
ideas. I finally settled on using an encrypted "container" that could
function like any other storage device, but only when needed. To prevent data
loss, it would be backed up to my home server. On the home server, the same technology
would be used to protect my backups and where I centrally could burn
a CD or DVD for off-site storage.

The first step to protecting my data was to figure out how to create an
encrypted container. After doing some research, I discovered there were
two ways to do this. I could use either cryptoloop or its successor,
dm_crypt. A considerable amount of information is available for
using cryptoloop, but I quickly discovered that it has been deprecated
and replaced by the more secure dm_crypt kernel module.
Prerequisites
To complete the encrypted container configuration presented in this
article, you must satisfy the following short list of prerequisites:

• Kernel version 2.6.4-rc2 or higher must be
  installed.
• KDE version 3.3 or higher must be
  installed.
• You must have root access to complete the initial
  setup.

I currently am running this configuration under kernel version 2.6.12
on several Gentoo systems, both x86 and AMD64. I also have used it on kernels
starting around version 2.6.6. The scripts I present here for making
the system easy to use have been used under KDE versions 3.3.x and
3.4.x. Older versions of KDE also may work, but they have not been tested
by me.
Configuring Your System
To use dm-crypt, a few modules must be compiled or built into the
kernel. You first must enable the device-mapper module that lets you
create new logical block devices from portions of existing devices. The
block devices then are "mapped" to devices that for our use are treated like normal
drive partitions. Once device-mapper is enabled, you then can enable
dm-crypt itself; it goes by the name Crypt Target Support
in the kernel configuration menu. dm-crypt is the kernel module that we
actually use to handle the encryption/decryption using the crypto API
available in the 2.6 version kernels.

To use an encrypted container for our files instead of an entire drive
or partition, loopback device support also needs to be enabled in the
kernel. The loopback device kernel module allows us to use ordinary files
as if they were real block devices. Finally, you must have the encryption
type you want to use compiled into the kernel or set as a module. In the
examples given here, I use the AES encryption algorithm, but many other
options are available.

Once you have enabled the required kernel modules, compile the kernel
and install it. Because I did not build the modules directly into the
kernel, I added the necessary modules--dm-mod, dm-crypt and aes-i586--to
/etc/modules.autoload/kernel-2.6 on my Gentoo boxes so they would be
loaded automatically at boot. Below is a list of kernel modules you need
to enable in the kernel:

Device Drivers -> Multi-Device Support (RAID and LVM) -> Device Mapper Support
Device Drivers -> Multi-Device Support (RAID and LVM) -> Crypt Target Support
Device Drivers -> Block Devices -> Loopback Device Support
Cryptographic Options -> <encryption type>

For other systems where there may not be a central location to
load kernel modules automatically at boot, you could add the appropriate
modprobe commands to a startup script. For Debian-based systems such
as Ubuntu, the script to use is the /etc/init.d/bootmisc.sh startup
script. For other distributions you can use /etc/init.d/rc.local. Here
are suggested commands to add to startup scripts for non-Gentoo
distributions:

modprobe dm-mod
modprobe dm-crypt
modprobe aes

Now that the kernel has been configured, two packages must be installed
that will be used to ease the creation and use of
the encrypted container as a device. The first package you need to
install is the device-mapper utilities. Under Gentoo, simply executing
emerge device-mapper automatically downloads,
compiles and installs the package. It already may be installed in other
Linux distributions. An easy way to tell if you already have the
device-mapper package installed is to look to see if /dev/mapper
and /dev/mapper/control already exist. If they do, the device mapper is
installed. Otherwise, for Debian-based systems such as Ubuntu, you
can execute apt-get install libdevmapper.
If you're using a different distribution, check your package management
system and see if it can be installed easily. If not, refer to the
Resources section for a link to where you can download it directly.

The second package you need to install is the cryptsetup utility. Under
Gentoo, it can be installed by executing emerge
cryptsetup. Again, if you are using a different Linux
distribution, cryptsetup already may be installed for you
or available through the package management system. You can determine if
the package already is installed by checking to see if the cryptsetup command
is available, most likely in the /bin directory. Otherwise, refer to the
dm-crypt listing in Resources for the link to the download.
Creating the Encrypted Container
After rebooting with your new kernel, you are ready to create the
container for your files and mount it. Select a partition with enough
space to create the container and make the container large enough to
support all the files you want to put into it. Don't forget to make
it large enough to hold new files. Keep in mind that at the time
this article was written, it was not possible to increase the container
size once it's created. Instead, you have to create a new, larger drive
container, copy everything from the old one to the new one and then delete
the old container.

To create the container file, use the dd command; it typically is
used to copy drive partitions. In the example below, I specified a
block size of 1MB and that the container should be 2,048 blocks
in size. This equates to a container that is 2GB in size--1MB block size X 2,048 blocks.

As a source for the dd command, I used a special device that outputs
nothing but zeros when read. Others have suggested that using /dev/random
may be better, because it makes it impossible to determine how much of
the container actually is being used. The choice is up to you. I also
used a partition (/encrypted) that I set aside specifically for storing
my containers.

dd if=/dev/zero of=/encrypted/data.crypt bs=1m count=2048

Now, create a loopback device using your container file. If you use
multiple containers, you have to use a different /dev/loopX
device--where X is a unique number--if you want them all to be mounted
at the same time. I chose to put specific containers on specific numbers in my
scripts (details below) so I know which one is using which loopback
device.

losetup /dev/loop0 /encrypted/data.crypt

Next, create the encrypted device. In the example given below, I chose
to use the AES encryption algorithm, which was compiled as a kernel module during
kernel configuration. When the device is created, you must specify
a password, otherwise known as a key, that is used to encrypt and
decrypt everything in the container. This can be a secure password that
you specify on the command line. In my case, I used /dev/random to
generate a 32-character random string (256 bits) that I stored in a file
named /home/pritchey/crypto.key temporarily; more on this later.

cat /dev/random > /home/pritchey/foo (hit control-c after a second goes by to stop it!)
cat /home/pritchey/foo | cut -b 0-31 > /home/pritchey/crypto.key
rm /home/pritchey/foo
cryptsetup -c aes -d /home/pritchey/crypto.key create data.crypt /dev/loop0

You now have something that acts like a normal drive partition. In order
to mount and use it, you must create a filesystem on it. I chose to
use the ext2 filesystem, but others can be be used. Once
the filesystem is created, it can be mounted like a regular drive
partition.

mke2fs -j /dev/mapper/data.crypt
mkdir /mnt/encrypted
mount /dev/mapper/data.crypt /mnt/encrypted

Once mounted, your encrypted device acts the exact same way that a normal
drive partition does. You can copy files to it, delete them, edit them
and so on. The only difference is you must remember to unmount the
device properly and destroy the loopback setup when you are done with it:

umount /mnt/encrypted
cryptsetup remove data.crypt
losetup -d /dev/loop0

Getting access to your files in the future requires three simple steps:

losetup /dev/loop0 /encrypted/data.crypt
cryptsetup -d /home/pritchey/crypto.key create data.crypt /dev/loop0
mount /dev/mapper/data.crypt /mnt/encrypted

This solves the problem of protecting our data. But, for non-technical
users, these commands are difficult to remember and scary looking--not
to mention they require root access. The next step is to automate the
mounting/unmounting of the encrypted containers in a way that is easy
to do yet not obvious to someone who might not think to look for them.
Automation Creation, Part I
To automate the mounting/unmounting of the encrypted container, I turned
to my favorite search engine and a coworker. The problem I encountered
when trying to create a script for the above commands was root access
is required to set up everything. I wanted others in the house to be
able to use the encrypted containers, but they're not experienced enough
yet to be trusted with root-level access. Carlos, a co-worker, once had
to solve a similar problem that required root access to run a script,
yet didn't warrant the use of sudo. He found a Perl script that did the
trick when the sticky bit was set, essentially acting as a wrapper
around the real script. I searched the Web and couldn't find the Perl
script, but I did stumble upon exactly what I needed: a tiny program written in
C that acts as a wrapper (see Resources) around a script that needs
root privileges. All that was required was changing the commands the
program was supposed to run, compiling the program and copying it into place
with the sticky bit set.

To use the wrapper, you need to change three values before compiling
it. First, set the variable myprog to the script that you want to
execute. The second variable, named myarg1, contains the name of the
loopback device (/dev/loopX) to be used. The last variable,
myarg2, is set to the name of the container that you want to mount. For
my naming scheme, I add a .crypt to the end of my container file
names. I also named my key files in a similar manner, ending them with
.key. Here is the C source code for wrapper.c:

    #include <stdio.h>
    #include <unistd.h>

    const char myprog[] = "/bin/encrypt_mount_gen";
    const char myarg1[] = "loop0";
    const char myarg2[] = "data";

    main()
    {
        putenv("PATH=/bin:/usr/bin");
        putenv("IFS= \t\n");
        setgid(getegid());
        setuid(geteuid());
        execl(myprog, myprog, myarg1, myarg2, (char*)0);
        fprintf(stderr,"Could not execute %s\n",myprog);
        perror("exec");
        exit(1);
    }

Once the appropriate changes are made, compile the program, copy it into place
and be sure to set the permissions correctly. I chose to create a
special group in /etc/group only for users that should be able to mount
the encrypted container (named crypto). The permissions and
ownership of the directory the encrypted device is mounted to, created in
a previous step as /mnt/encrypted, is also set this way. This prevents
other users who have accounts on the computer from mounting or accessing
the encrypted devices.

    gcc -o mysecretcommand wrapper.c
    cp mysecretcommand /bin
    chown root:crypto /bin/mysecretcommand
    chmod 750 /bin/mysecretcommand
    chmod u+s /bin/mysecretcommand

    #To protect mounted encrypted data:
    chown pritchey:crypto /mnt/encrypted
    chmod 770 /mnt/encrypted

To handle unmounting the encrypted containers, you need to use the
wrapper program again--named encryptoff in the sample scripts. This
time, though, it calls a script containing the appropriate commands to
undo the encrypted container. Here is a sample script for unmounting a
mounted encrypted container:

    #!/bin/bash

    /bin/umount /mnt/encrypted
    /bin/cryptsetup remove data.crypt
    /sbin/losetup -d /dev/loop0
    #Repeat the above three commands for each encrypted container....

Automation Creation, Part II
The script called from the above wrapper is written so that when
called with two parameters, it would be able to mount any encrypted
container. That way I could have as many wrappers as needed that are
unique to each specific encrypted container but only have one script that
actually performs the mounting and unmounting. The script assumes that
the encrypted container ends in .crypt and the key file ends in .key,
but both have the same beginning name that's passed as the second parameter.

To help increase security, I also decided to store the key (password)
used for the encryption device on a USB thumb drive. It's never a good
idea to store passwords in files, but in this case the key is impossible
to remember. As long as the thumb drive is kept separate from the
computer it belongs to--locked in a safe, for example--it would be an
adequate solution. If the computer is stolen, the likelihood of the thief
taking the USB key along with the computer and knowing what to do with it
is small. And with a 256-bit (32-character) key, the system would be difficult
to crack by brute force methods.

So the automation script also is responsible for
mounting the USB thumb drive and unmounting it when done. This minimizes
the amount of time the thumb drive needs to be connected to the
computer. Hopefully, this helps minimize the chances of someone leaving
it connected, as the drive can be removed immediately after logging in (detailed later).

Here is the encrypt_mount_gen shell script called from the wrapper:

    #!/bin/bash

    /bin/mount /mnt/usb_stick
    /sbin/losetup /dev/$1 /encrypted/$2.crypt
    /bin/cryptsetup -d /mnt/usb_stick/$2.key create $2.crypt /dev/$1
    /bin/mount /dev/mapper/$2.crypt /mnt/encrypted_$2
    /bin/umount /mnt/usb_stick

This design partially solves the ease of use requirement, but it still
requires someone to remember a command, which could be named anything I
want in order to hide it. I had an idea, and searching the Web revealed
that KDE has two special directories that can contain scripts or links
to executables the user wants run when he or she first logs in or out.
Every user's home directory contains a hidden directory named .kde. This is
where the two directories used for login/logout are located. The directory
used on login is called Autostart, note the capital letter A. Simply
place a script here that executes as many of your wrappers as needed.
Here is the sample script I placed in my /home/pritchey/.kde/Autostart
directory:

    #!/bin/bash
    /bin/mysecretcommand
    /bin/mysecretcommand2
    ...

Similarly, we can use the directory .kde/shutdown with another script
to unmount and clean up automatically any encrypted containers. This is
the final piece that solves the ease of use issue. To use the system,
all you need to do is power on the computer, plug in the USB thumb
drive with the keys to the encrypted containers and log into KDE. Once
logged in, unplug the thumb drive and return it immediately to its hiding
spot. If you log in before remembering to plug in the thumb drive, you
either can log out and back in again with the thumb drive attached
or execute the wrapper command from a shell prompt.
Almost Done
One remaining requirement needs to be addressed: protecting ourselves
from data loss. I had solved this problem before, so it simply
was a matter of integrating the encrypted containers into my
backup system. All of my systems are set to back up users' home
directories when they log out of KDE, which is triggered by a script in
.kde/shutdown. All I needed to do was modify the script to handle the
encrypted containers when they are mounted. This script executes rsync
and saves any changed files to a server. I modified the backup script
to take parameters specifying the directory to be synced. The default
is to sync the user's home directory with the backup location on the
server. The script in the user's shutdown directory then was modified
to detect if the encrypted containers were mounted and if so, rsync it
before unmounting. Syncing the mounted data is much faster than trying
to sync the large container file itself, even on a quiet home network.
Here is the script I placed in /home/pritchey/.kde/shutdown:

    #!/bin/bash

    # Look to see if our encrypted partitions have been mounted
    # and if so back them up before unmounting them.
    is_projects_mounted=`df | grep encrypted_projects`
    is_encrypted_mounted=`df | grep encrypted | grep -v projects`

    if [ "$is_projects_mounted" != "" ]; then
        /home/pritchey/scripts/backup_rsync.sh /mnt/encrypted_projects
    fi
    if [ "$is_encrypted_mounted" != "" ]; then
        /home/pritchey/scripts/backup_rsync.sh /mnt/encrypted
    fi

    # Now that they have been properly backed up, umount the
    # encrypted partitions.  Call the wrapper that calls the 
    # script with the commands to 'undo' the mounted containers.
    /bin/encryptoff

    # Now backup non-encrypted data so we have an off computer backup.
    /home/pritchey/scripts/backup_rsync.sh

And here is the general purpose directory backup script referenced in my KDE
shutdown script:

#! /bin/bash -x
# This script performs a very simple backup of the user's home directory
# by default (if no parameters are passed).
#
# This script is meant to be referenced in the user's ~/.kde/shutdown directory
#
# If parameters are passed, then they are used as follows:
#       Parameter 1:  Used as the base directory to be synced.
#       Parameter 2:  Used as the 'ignore' list of directories/files
echo "------------" >> /tmp/rsync.log
echo "starting" `/bin/date` >> /tmp/rsync.log
# make sure we're online and have access to our backup server...
if [ `ping -c 1 192.168.1.50 | grep '64 bytes from' | wc -l` -eq 1 ]
then
   if [ "$1z" == "z" ]; then
         BACKUP_DIR="/home/$USER"
         EXCLUDE_DIR="/home/$USER/OpenOffice*"
   else
         BACKUP_DIR="$1"
         EXCLUDE_DIR="$2"
   fi

   /usr/bin/rsync -vauR --delete --stats --exclude="$EXCLUDE_DIR" 
	"$BACKUP_DIR" rsync://192.168.1.50/intrepid-linux
   echo "Rsync for: $BACKUP_DIR succeeded" >> /tmp/rsync.log
    else
   echo "Rsync for: $BACKUP_DIR FAILED" >> /tmp/rsync.log
   fi

     echo "completed" `/bin/date` >> /tmp/rsync.log

Final Notes
I have read many articles on encrypting entire partitions and drives,
but I chose to use containers instead. By using containers, I have the
flexibility to move them around, back them up to CD or DVD and not
mount them when I don't need them. If the situation was different,
I may have chosen the route of using encrypted partitions or drives. In
the beginning I also was concerned about the performance impact of using
an encrypted system. In a year's worth of use, though, I have not noticed
any performance problems.

The backup script I use obviously can be expanded to be much more robust.
For my home use, it's proven to be reliable enough. But in a work
environment, I would take the time to add additional safety checks. I
also chose not to go into too much detail here about the use of rsync.
Many good articles detailing the use of rsync are available, and you
might decide to use another method for performing backups.

In order to complete the protection of my systems, I also have included the
commands used to unmount the encrypted containers in the system shutdown
scripts. This way, if a system is shutdown remotely or the UPS software
shuts the system down, the encrypted containers are unmounted properly and
cleanly.

I would like to thank Carlos for the pointer to the idea of using an suid
wrapper and Darryl for testing the scripts and installation procedure
presented here. I have enjoyed working with both of them over the years,
and they have proven to be great resources of information for things
nobody else can figure out.
Resources
Linux: Replacing Cryptoloop
With dm-crypt: article stating that dm-crypt is the preferred
method to use over cryptoloop.

Cryptoloop
HowTo

dm-crypt Information

Device-mapper Utilities

Root Wrapper
C Code

Implementing
Encrypted Home Directories

Encrypt Your Root
Filesystem