by W. Michael Petullo
These days, data is mobile. Every day, sensitive corporate data leaves a company’s headquarters on a flash drive or an employee’s laptop. Regardless of where it is going, mobile data can be an I.T. department’s worst nightmare.
In fact, the 2006 “CSI/FBI Computer Crime and Security Survey,” a joint effort by the San Francisco office of the FBI and the Computer Security Institute, named laptop theft as the third-largest source of financial loss in the computer security domain. This survey reports the results of 426 companies. While most security threats documented by the study decreased, losses from laptop theft have increased since 2005. “Data protection (e.g., data classification, identification and encryption) and application software (e.g., Web application VoIP vulnerability security)” were cited as the “most critical computer security issues in next two years” by 73 respondents.
The data on a stolen laptop may be far more valuable than the device itself.
One of the most important computer security issues today is laptop theft. The data on a stolen laptop may be far more valuable than the device itself. For example, a stolen UC Berkeley laptop contained sensitive data about nearly 100,000 alumni. A stolen Department of Veteran’s Affairs latop yielded information from up to 26.5 million veterans. There are many examples of high-profile laptop theft, and these incidents are often very costly for companies. The cost, however, isn’t related to the hardware replacement, but to the loss of confidential information and customer security.
What if the owner could state that the data has not been compromised? What if the only loss resulting from a stolen laptop was purely material? This would certainly alleviate some of the risks behind mobile data. Disk encryption is one way to help solve this problem. Since the Fedora™ Project was announced in 2003, many disk encryption technologies have been added to the Fedora platform.
There are several disk encryption interfaces available for Linux. Competing projects have encryption as a filesystem implementation. In these cases, an alternative to ext3 (or other common filesystems) is used and encryption is performed by the filesystem itself. The cryptoloop and Jari Ruusu’s Loop-AES encrypt using a different technique. Here, the kernel’s disk loopback device is extended to provide the encryption. Cryptoloop was distributed with the Linux kernel until early in the 2.6 series. It was replaced by dm-crypt in 2.6.4. The dm-crypt code uses the kernel’s device mapper interface to implement the encryption. The dm-crypt interface now seems to be preferred by the kernel developers. The Fedora Project has included it since Fedora Core 2. The rest of this article will focus on technologies that build on top of dm-crypt.
Although dm-crypt provides a solid disk encryption interface within the kernel, the device mapper’s userspace tools are not very user friendly. The dmsetup tool can be used to set up an encrypted disk. However, dmsetup is a general tool that is used for device mapper volumes. Christophe Saout developed a way that focuses on setting up dm-crypt devices. This tool, cryptsetup, provides a simpler interface than dmsetup and was first included in Fedora Core 2 (See Bugzilla #120487.)
The following command creates a plaintext dm-crypt device, /dev/mapper/test, for a backing partition, /dev/hdaX. The AES is used in cipher block chaining mode:
cryptsetup -c aes-cbc-plain create test /dev/hdaX
Once /dev/mapper/test exists,treat it as any other block device. This device and it’s backing unit, /dev/hdaX, are two views of the same device. One view is plaintext and the other is ciphertext. So, if one creates a filesystem on /dev/mapper/test, and then looks at /dev/hdaX, then they will see an encrypted view of the same filesystem. The following command will create an ext3 filesystem on /dev/mapper/test:
This filesystem may be mounted and unmounted using:
mount /dev/mapper/test /mnt/test umount /mnt/test
Finally, after the filesystem is unmounted, its backing device may be removed. This leaves only the encrypted /dev/hdaX. The only way to view the plaintext data is to recreate /dev/mapper/test using cryptsetup -c aes-cbc-plain create test /dev/hdaX and a passphrase. The following command removes /dev/mapper/test:
cryptsetup remove test
The dm-crypt interface and the cryptsetup utility provides the functionality necessary to make encrypted disks usable by the Fedora Project. However, cryptsetup made it difficult to build since users must remember a disk’s encryption parameters, including the cipher used.
Linux Unified Key Setup
Clemens Fruhwirth modified cryptsetup to support a standard he developed called the Linux Unified Key Setup (LUKS). LUKS embeds encryption information in a partition header, simplifying the use of the disk. Now the user doesn’t have to remember the cipher or cryptographic mode used. LUKS also adds support for multiple keys and other features. The cryptsetup-luks utility first replaced cryptsetup in Fedora Core 4 (See Bugzilla #147313.)
The following command places a LUKS header on /dev/hdaX (this command is only executed once, to initialize the header):
cryptsetup -c aes-cbc-plain luksFormat /dev/hdaX
Once a LUKS header exists, a plaintext dm-crypt device may be created for the encrypted backing partition. Because the algorithm AES and mode cipher block chaining were written to the disk’s LUKS header, these parameters do not have to be specified each time the plaintext device is setup:
cryptsetup luksOpen /dev/hdaX test
The plaintext dm-crypt device may be formatted with a filesystem, mounted and unmounted as before:
mkfs.ext3 /dev/mapper/test mount /dev/mapper/test /mnt/test umount /mnt/test
Finally, the following command removes /dev/mapper/test:
cryptsetup luksClose test
LUKS and its encryption parameter partition header provides a great foundation for higher-level tools. For example, LUKS allows the implementation of David Zeuthan’s proposal for an encrypted disk system. It was David’s vision that encrypted disks should be easier to use. He proposed that the Hardware Abstraction Layer (HAL) be modified to detect encrypted disks. When an encrypted disk is plugged into a computer, the system should automatically prompt a user for a passphrase and mount the disk, just as HAL and its helpers mount regular disks.
Fedora Core 5 included this functionality. HAL is now able to pull all encryption parameters from a LUKS header so a user only needs to provide a passphrase. Figure 1 is a screenshot showing that HAL now identifies LUKS-encrypted disks. Notice that the volume.fstype is crypto_LUKS. For more information about HAL’s LUKS support, see Adding encryption support to HAL: A user’s experience with Fedora development.
In order to make formatting LUKS encrypted disks easier, I wrote the luks-tools suite. For example, gnome-luks-format provides a graphical tool to format encrypted disks. The luks-tools suite was accepted into Fedora Extras around the time Fedora Core 6 was released (See Bugzilla #166035.)
Protection of swap
A disk’s swap space poses a problem on systems with encrypted disks. If data from an encrypted disk is loaded to memory and then swapped to another disk, that data is generally written in plaintext to the swap disk. Obviously, this defeats the purpose of the encrypted disk. Although plaintext data in memory is lost when a computer is turned off, data written to a swap disk may survive a power cycle. A BugTraq mailing-list thread titled “Mac OS X stores login/Keychain/FileVault passwords on disk” documents a variant of this problem. One solution to this problem is to encrypt the swap disk.
Support for an encrypted swap disk was implemented in Fedora Core 6 (See Bugzilla #127378.) The system initialization script, /etc/rc.d/rc.sysinit, now looks for a file called /etc/crypttab that defines encrypted disks. The following crypttab defines /dev/hdaY as an encrypted swap device, protected using AES:
swap /dev/hdaY /dev/urandom swap,cipher=aes-cbc-essiv:sha256
The format for a crypttab entry is:
[name] [cryptodevice] [keyfile] [options]
The example above causes the system to create a plaintext dm-crypt device named swap for the encrypted backing device /dev/hdaY. The key file used for this process is /dev/urandom. A random keyfile ensures that swapped data will not survive a reboot because a new random key is used each time the system starts. Because the swap option is specified, mkswap will be run on /dev/mapper/swap and the device will be used as swap space.
Protection of the root filesystem
Thus far, this article has discussed encrypting portions of a filesystem. For example, removable disks may be encrypted to protect their contents. In addition, swap space may be encrypted. In some instances, one may wish to encrypt an entire filesystems, including the files required to boot. Though this feature is not yet supported by Fedora Core, I am contributing to the effort to implement it (See Bugzilla #124789.)
Our effort has created a patch for mkinitrd, the tool that creates a system’s initial ramdisk (initrd.) The initrd is an extremely lightweight filesystem that the Linux kernel uses to boot. The initrd can load kernel modules or perform other actions required before the real root filesystem is mounted. Our modifications to mkinitrd cause the script to detect an encrypted root filesystem and create a special initrd for it. This initrd will obtain a passphrase and unlock the encrypted root filesystem before mounting it.
Currently, one must manually create an encrypted root filesystem using an existing Fedora Core installation and the mkinitrd patch. Instructions for this are included in Bugzilla #124789. Once the Fedora mkinitrd supports this feature, I hope to see anaconda modified so that it can create an encrypted root filesystem as Fedora Core is installed.
More technical details on how a system boots using an encrypted root filesystem may be found in Encrypt Your Root Filesystem, published in the January 2005 issue of the Linux Journal. This article also discusses some of the potential attacks on an encrypted filesystem and how to figure out what needs to be defended against.
In this article we have discussed the past, present, and future of disk encryption within the Fedora Project. After many years of security feature development and testing, the Fedora Project now has a disk encryption platform. Creative developers and administrators can use these tools to secure information, even on the most vulnerable and mobile hardware platforms. From supporting the kernel to encrypting the entire filesystem, the Fedora Project provides solid disk encryption capabilities.