Encrypted Root File System with SUSE HOWTO 10.2

From openSUSE

Introduction and Motivation

Most laptop users do not begin to think about the problems associated with laptop theft until after the first theft occurs. If the laptop happened to contain the source code for a new product, or company confidential documents, or the notes for an newspaper article on political corruption, or maybe just a private love letter, then there is a potential for catastrophe if the data falls into the wrong hands.

To counter the potentially damaging affects of laptop theft, one can either choose not to use a laptop, use hardware encryption devices, or use software encryption to protect the data [1] [2][3] [4] [26] [28]. The latter approach is particularly attractive because a software solution is more flexible than a hardware approach and with a modern CPU, most users will not notice the performance penalty associated with on-the-fly software encryption/decryption [19] [20][21].

Why encrypt the root file system?

At first glance one is inclined to encrypt only the most sensitive files, or perhaps the entire user file system (/home) containing the sensitive information. If one is not encrypting the root file system, then this is a simple enough exercise which is supported by the SUSE installation procedure [5] as well as other software, some of which even runs in user space [6] [23]. However, the problem with such an approach is that the contents of an encrypted file tend to leak out of the encrypted area into other areas, e.g, swap, /tmp, and /var. Furthermore, editors or other programs used for working with the data may create swap files in other locations as well. Finally, metadata related to the file, such as its size, permissions, access time etc. may not be stored in the same encrypted area and modern journaling file system like Reiserfs [14] (SUSE's default file system) only compound such problems. In general, then, it is not easy to fully prevent the leakage of information from the user's file system into the root file system

To understand how big the problem can be, suppose a company has installed a web server on its intranet for the purpose of distributing company confidential information. If an employee is viewing a doc file from this web server with Firefox using the OpenOffice plugin, then the complete file is stored in /tmp and remains there until it is erased. Hence, while there maybe only bits and pieces of a sensitive document in swap, the entire document could be available in /tmp.

For this reason the only appropriate course of action is to encrypt the entire root file system along with the file system containing the sensitive data.

The only drawback to encrypting the root file system is that it is not currently supported by the SUSE installation routines. There are several articles on the Web discussing various procedures for encrypting the root file system for other Linux distributions[8] [8] [9], unfortunately, these instructions do not quite work in their entirety for SUSE. On further inspection this is not surprising, since working with an encrypted root system requires some tinkering with the boot process and this is one of the areas in which the various distributions compete against each other for market share.

The main purpose of this HOWTO then, is to set forth the SUSE specific instructions for working with an encrypted root file system. In doing so this HOWTO draws on previous work from other distributions [8] [8] [9] and tries to suggest the minimal amount of changes to the SUSE installation and boot processes so as to create a procedure that easily works with mainstream SUSE. (Although designed for use with SUSE some variation of these procedures may work for other Linux distributions as well, but have not been tested on anything else.)

Preliminaries

Prerequisites

A SUSE 10.1 installation source media and an Internet connection to download one missing package.

Workflow

Since the SUSE installation procedure does not yet support encrypting the root file system, the next best approach would be to use a live CD for running Linux, then create the encrypted root partition on the hard disk. However, a live CD is not included in the standard SUSE distribution and creating one is more time consuming than the procedure described here. (An alternative approach which is less work than creating a live CD would be to install SUSE on a USB flash drive, run Linux from there, then create the encrypted disk partitions.) Finally, the pragmatic approach taken here is to create two partitions, install SUSE on one partition, encrypt the other, then copy SUSE from the first partition to the second [9].

A high level view of the workflow for the proposed procedure is:

1. Install SUSE, designating one partition temporarily as root.
2. Create an encrypted swap partition.
3. Create an encrypted partition on one of the remaining partitions.
4. Copy the root file system into the new encrypted partition.
5. Create a new initial ram disk (initrd) to boot the system
6. Test the system to see that the boot procedure works for the new partition.
7. Erase the original root partition and replace it by another encrypted file system for holding the user file system.

Installing SUSE

As a laptop is generally a single user machine, one can use a relatively simple disk partitioning scheme, e.g., one partition for swap, one for the root file system mounted at "/" and one for the user file system mounted at "/home". Generally the largest partition is reserved for "/home"; however, due to the limitations of the installation procedure, the root file system will first be installed into the partition that will later be used for the user file system (normally, the largest partition), then copied onto the smaller partition once the encrypted file system is in place.

Each of these three partitions will be encrypted, therefore to boot the system we require an additional small, unencrypted partition containing the boot files. This partition will be mounted at "/boot". There are two options for creating the boot partition, either put it on the same disk, or on an external media such as a USB flash drive (USB memory stick). (See the #FAQ for a discussion of the various alternatives.)

For correct partitioning one needs to enter the expert partitioner mode when the installation process is started.

For the boot partition, reserve at least 40 MB, or more if multiple kernels are to be available. (75 MB is probably the safer choice and on most modern laptops there is enough room to spare on the hard disk.) This partition needs the mount point "/boot".

For those using a USB flash drive, plug it in before booting the computer with the installation CD in the disk drive, SUSE should recognize the USB flash along with the computer's other disks, displaying it in the list of disks from the "Expert partitioner" menu. The USB flash drive should be formatted using a Linux file system (ext2 will suffice) and it should be mounted at "/boot". Furthermore, in the "Fstab Options" dialog, click the box "Do Not Mount at System Start-up". This is necessary because the USB devices are created after the boot.localfs tries to mount the entries in fstab. (You can always remount the USB flash drive later if you need it.)

For the sake of discussion assume the partition table looks like this:

(As noted before, the idea is to first install the root partition on hda4, then create an encrypted file system on hda3, copy the root system from hda4 to hda3 and finally create another encrypted partition on hda4 for the users file system.)

Now continue with the standard installation process to the point of selecting the software packages to install. The following packages are not installed by default, but will later be required for compiling the "cryptsetup" package and creating initrd:

• the kernel source,
• the development version of e2fsprogs, and
• the development version of popt.

Now complete the installation and log in as root. (Do not log in as a normal user since the mount point for the user's file system will be changed.)

At this point one has to select the encryption software. There are several options for Linux available, such as: "cryptsetup-luks" [10], "loop-aes" [2] and "truecrypt" [3]. This HOWTO discusses the procedure for cryptsetup-luks as it is the simpler package to use [1] [4] [8] [22][28] . (For system managers, the main advantage of using the LUKS system lies in the ability to configure multiple passwords for encrypting a single partition. This helps in recovering encrypted data when users forget their passwords.)

If you're using openSUSE 10.2 or newer, install the package "util-linux-crypto" from your installation medium which will contain "cryptsetup". In case of older SUSE distributions have a look at the LUKS Homepage [10], there are some openSUSE RPMs provided by packman [29] or similar projects. Otherwise download the "cryptsetup-luks" source code from [10], compile and install it. (Note: There is no need use a statically linked version, as it will only add bulk to the initrd which will be created later.)

Create an encrypted swap partition

To gain familiarity with the encryption software, practice by encrypting the swap partition. (If anything goes wrong it is easy to repair.)

One of the advantages of using the LUKS system [10] [28] is that it does not use the supplied password directly for the encryption, rather a random key with a default size of 128 bits is generated and this key is encrypted using the supplied password (along with a randomly generated salt). For this reason, it is safe and convenient to use the same password to protect the master key of each separate partition. (The alternative, using a different password for each partition is very inconvenient and offers little in the way of increased security.) Therefore, before proceeding, select a good password which is immune to dictionary attacks and infeasible to guess using a brute force attack.

First one needs to load some kernel modules which were probably not loaded by default. (Later these will loaded by initrd.)

   modprobe dm-mod
   modprobe dm-crypt
   modprobe aes
   modprobe sha256 
   modprobe sha1

The first module is the device mapper module, the second is the device mapper cryptography module, the third is the default cipher, the fourth is the default hash algorithm and the fifth is the default LUKS hash spec.

Turn off the existing swap:

   swapoff /dev/hda2

Fill the swap partition with random data. (This will take a few minutes.)

   dd if=/dev/urandom of=/dev/hda2

Initialize the encrypted swap device using the command:

   cryptsetup -v --key-size 256 luksFormat /dev/hda2

This will command will first ask for the password, then create a new encrypted partition using the aes cipher, in the cbc-essiv mode. These default settings are recommended by the NIST [11] and the NSA [12] [13] (though it must be added that neither the NSA nor the NIST have endorsed this particular software package) as well as other experts.

To view the LUKS partition header information use:

    cryptsetup -v luksDump /dev/hda2

Now open the new encrypted partition:

   cryptsetup -v luksOpen /dev/hda2 swap

This should have create a new mapped device in /dev/mapper called swap. To use this as a swap device, add a swap file system and turn the swap back on.

   mkswap /dev/mapper/swap
   swapon /dev/mapper/swap

If you use the command, "free", you should be able to see the new swap space.

The device mapper is a thin software layer responsible for all I/O to the underlying device. In this case its job is to perform data encryption and decryption.

Create an encrypted file system on one of the remaining partitions

Having practiced with swap it is now time to proceed to the root file system.

Unmount /home, to prepare the new root file system.

   umount /dev/hda3

Fill /dev/hda3 with random data: (Depending on the size of the partition and the speed of your CPU this my take from tens of minutes to a couple of hours.)

   dd if=/dev/urandom of=/dev/hda3

Once the dd command has finished, create the device mapping for the root partition following the same procedure for swap: (be sure to use the same password to enable a single sign-on)

   cryptsetup -v --key-size 256 luksFormat /dev/hda3

To view the details of the encrypted partition use:

   cryptsetup luksDump /dev/hda3

Now open the encrypted partition

   cryptsetup luksOpen /dev/hda3 root

As before this should have created an entry in /dev/mapper, but this time called root.

Again one needs to create a file system on the new device. (Reiserfs is the default file system for SUSE, but one should use the same file system used when the system was originally installed.)

   /sbin/mkfs.reiserfs -j /dev/mapper/root /dev/mapper/root

Copy the root file system into the new encrypted partition

Once, the new encrypted system is created, the complete root file system must be copied to this new file system. First it has to be mounted somewhere:

   mkdir /mnt/root
   mount /dev/mapper/root /mnt/root

Here is one method for copying all files from one directory tree to another which preserves permissions, symbolic links and other special files (note, there is no need to copy the special file systems /dev, /proc and /sys since these will be re-created when the system is booted.)

   cd /
   find bin boot dev etc home lib* opt root sbin srv subdomain tmp usr var\
           -depth -print0 | cpio -pmd --null /mnt/root
   mkdir /mnt/root/proc
   mkdir /mnt/root/sys

cd to /mnt/root/etc and open fstab in any text editor. Change the entry for /dev/hda3, the former home-partition, into:

  /dev/mapper/root     /      reiserfs   acl,user_xattr        1 1

Now, when this partition is mounted, all I/O to the root file system passes transparently through the device mapper.

Likewise, add an entry in fstab for the encrypted swap, deleting any other swap entries which might be present:

  /dev/mapper/swap   swap  swap  defaults  0 0

In addition, the entry for /dev/hda4, the former root-partition, should be written as:

  /dev/hda4           /home   reiserfs   acl,user_xattr        1 2

Create a new initial ram disk (initrd) to boot the system

In order to use the new encrypted root file system, it must be decrypted when the system is booted. This job is best handled by a specially crafted initial ram disk (initrd) [15]. (One could also use an initial ram file system (initramfs) [8] [27], though this requires recompiling the kernel.) Normally, SUSE creates the initrd to perform operations like loading device drivers specific to the computer being booted. This enables them to ship a generic kernel, then use loadable kernel modules to configure the kernel for specific user needs.

While one can in principle create the initrd by hand [15] [16], this is an error prone procedure requiring regeneration whenever the hardware configuration or kernel changes. It is also not necessary since SUSE provides the mkinitrd package [17] for automatically generating the initrd. The approach taken here is to modify the driving script, mkinitrd, to automatically create the necessary initrd required for an encrypted root file system.

The modified mkinitrd (which is a drop in replacement for the mkinitrd shipped with SUSE 10.1) can be downloaded from here [18]. In SUSE 10.2, the mkinitrd file is located in /sbin. Starting with OpenSUSE 10.3, this is no longer necessary, as LUKS support works out of the box.

CRITICAL: When installing the new mkinitrd script, place a copy in both /sbin and /mnt/root/sbin. If you do not put a copy of the new script in /mnt/root/sbin, you will not be able to boot your system after the "Erase the original root partition and replace it by another encrypted file system" step below.

Before using it the first time it would be wise to make a backup of the existing initrd residing in /boot. The best approach would be to copy it to another file (e.g., init-orig) in /boot so that it can be used as a backup in case something goes wrong.

To use the new mkinitrd type:

   mkinitrd -d /dev/mapper/root

The option "-d /dev/mapper/root" denotes the location of the new root device and must be given the first time this version of mkinitrd is run. Once the system is using the encrypted root partion, this option is no longer necessary.

What the new mkinitrd does is to examine the devices in "/dev/mapper" to determine which ones use encryption and what ciphers need to be loaded into the kernel at boot time. It then adds a small section to the init script to query the password during the initial boot phase and decrypt all the file systems.

Create an entry in the bootloader menu for the new root file system

The final step is to create a new entry in the Grub menu for the encrypted partition. Edit /boot/grub/menu.lst and create a NEW entry which contains the new parameters. It might look something like this:

   ###The encrypted root partition
   root (hd0,0)
   kernel /vmlinuz root=/dev/hda3 vga=0x314 splash=silent showopts
   initrd /initrd

It is recommended, NOT to delete the old entries, until one is sure the system is booting properly. (Note: One needs to modify the old entries to use the old initrd which was saved for exactly this purpose.)

Now, close all open files and try to boot using the encrypted partition.

Note: If you are using a docking station, you may have to use the laptop keyboard to enter the decryption password.

Note: If you are using a USB flash drive, you may need to adjust your BIOS settings so that the USB device comes before the hard disk in the boot order.

Erase the original root partition and replace it by another encrypted file system

After checking that everything is working, proceed to erase the original root partition and replace it by another encrypted file system:

   umount /dev/hda4
   dd if=/dev/urandom of=/dev/hda4
   cryptsetup -v --key-size 256 luksFormat /dev/hda4
   cryptsetup luksOpen /dev/hda4 home
   /sbin/mkfs.reiserfs -j /dev/mapper/home /dev/mapper/home
   mount /dev/mapper/home /home

Edit fstab and add an entry for /home, e.g.

   /dev/mapper/home   /home  reiserfs  acl,user_xattr  1 2

Re-run mkinitrd to add the information for /home to the initrd.

   mkinitrd

Add a user account

   Reboot, add a user account and enjoy. Note: since a laptop is generally
   a single user machine, and since the decryption password was given at
   boot time, it is safe to configure the system to directly initiate a
   session for the user once the system is booted. This saves entering an
   additional password.

FAQ

Exactly what types of attacks is this procedure design to protect against?

The procedure described herein can protect a laptop (or other computer) against the following attacks.

• A laptop is the subject of a random theft followed by serendipitous profiteering. Generally, the thief has not targeted the laptop specifically, but simply stole a laptop thought to be of some value. Such a thief would typically sell the laptop to a fence who might have the expertise to search an unprotected laptop for valuable data as well as the contacts necessary to profit from any such data.

• A second common attack is where the thief has specifically targeted the laptop because they suspect it contains valuable data. In this case the thief also knows how to find the data and what to do with it.

Should one use an external USB flash drive for booting?

Using an external USB drive prevents an attacker from tampering with the boot partition, e.g., someone could accesse the computer when it is turned off, installed a new kernel containing a Trojan horse capable of capturing the master key and storing it somewhere on disk where the attacker can find it later once the computer is stolen. Moving the kernel to a USB flash drive can prevent this type of attack, though it also shifts the problem from protecting the computer to protecting the flash drive. This attack pattern is far more sophisticated than the ones described above and is therefore of lower probability -- unless the user happens to fall into into a high risk category such as: union organizers or other human rights workers, government whistle blowers and workers in industries where industrial espionange is common. If one is at a high risk of being the victim of sophisticated attacks of this nature, then one should consider booting from a USB flash drive.

The drawback of using a USB flash drive for booting is the need to carry the USB flash drive separately from the laptop and the consequent risk of losing the drive. If you lose it while on a trip, you may not be able to boot your computer until you return home, where your backup drive is hopefully in good working order.

What are the known vulnerabilities for the procedure suggested here?

Fruhwith [4] [26] discusses a range of cryptographic vulnerabilities associated with hard disk encryption. In particular, he notes that one of the most serious problem, namely the watermark vulnerability [24], has been solved for dm-crypt with the introduction of the essiv cipher mode.

Osvik et al. [25], discuss a successful side-channel attack on dm-crypt while it is running. In this attack, the computer is running and a specially designed script is able to steal the master key for any mounted partition. Although a serious weekness, the procedures discussed here are designed to work against attacks described in #FAQ.1 and #FAQ.2, i.e., when the system is turned off. Securing a running system requires firewalls, access control and software integrity checks -- topics beyond the scope of this HOWTO.

References

1. dm-crypt: a device-mapper crypto target, http://www.saout.de/misc/dm-crypt/
2. J. Ruusu,"loop-AES", http://sourceforge.net/projects/loop-aes/
3. "True Crypt", http://www.truecrypt.org/
4. C. Fruhwirth, "Linux hard disk encryption settings", http://clemens.endorphin.org/LinuxHDEncSettings
5. J. Arnt, et al., "SUSE Linux Start-Up", http://en.opensuse.org/Distribution/SL-10.1/inst-source/docu/en/startup_en.pdf
6. "EncFS Encrypted Filesystem", [http://encfs.sourceforge.net/
7. C. Devine, "Encrypted Root Filesystem HOWTO", http://tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/
8. "SECURITY System Encryption DM-Crypt with LUKS", http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS
9. M. Petullo,"Encrypt Your Root Filesystem", http://www.linuxjournal.com/article/7743
10. "LUKS - Linux Unified Key Setup", http://luks.endorphin.org/
11. M. Dworkin, "Recommendation for Block Cipher Modes of Operation", http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
12. "CNSS Policy No. 15, Fact Sheet No. 1", http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf
13. "Fact Sheet NSA Suite B Cryptography", http://www.nsa.gov/ia/industry/crypto_suite_b.cfm
14. "Reiserfs", http://www.namesys.com/
15. W. Almesberger and H. Lermen, "Using the initial RAM disk (initrd)", file:///usr/src/linux/Documentation/initrd.txt
16. "SECURITY System Encryption DM-Crypt with LUKS/initrd", http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS/initrd
17. "mkinitrd", http://www.novell.com/products/linuxpackages/suselinux/mkinitrd.html
18. "SUSE mkinitrd for Encrypted Root File Systems", http://www.ccrl-nece.de/~greg/linux/mkinitrd-lerfs.tar.gz
19. "Performance of Encryption Algorithms", http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio
20. "dmcrypt versus loopaes", http://deb.riseup.net/storage/encryption/benchmarks/dmcrypt-v-loopaes
21. M.-J. O. Saarinen, "Encrypted Watermarks and Linux Laptop Security", http://docs.indymedia.org/pub/Local/UkCrypto/wisa2004.pdf
22. "Encryption Ideas for IMC UK", http://docs.indymedia.org/view/Local/UkCrypto
23. "Encrypt filesystems with EncFS and Loop-AES", http://security.linux.com/print.pl?sid=06/03/13/1656228
24. J. Ruusu,"Re: Oopsing cryptoapi (or loop device?) on 2.6.*", http://marc.theaimsgroup.com/?l=linux-kernel&m=107719798631935&w=2
25. D.A. Osvik, A. Shamir and E. Tromer, "Cache Attacks and Countermeasures: the Case of AES", http://www.wisdom.weizmann.ac.il/~tromer/papers/cache.pdf
26. C. Fruhwirth, "New Methods in Hard Disk Encryption", http://clemens.endorphin.org/nmihde/nmihde-A4-os.pdf
27. J. Gustedt, "Early LUKS", http://www.loria.fr/~gustedt/early/
28. C. Fruhwirth and M. Schuster, "Hard disk encryption with DM-Crypt, LUKS, and cryptsetup", http://www.linux-magazine.com/issue/61/Hard_Disk_Encryption_DM-Crypt_LUKS_cryptsetup.pdf
29. Packman "cryptsetup-luks" RPM packages for older openSUSE distributions http://packman.links2linux.de/package/841