Encrypted Root File System During Install in openSuse 10.3
Introduction and Motivation
Most laptop users do not begin to think about the problems associated with laptop theft until after they 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. 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.
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 as well as other software, some of which even runs in user space. 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 or ext3 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, 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 openSUSE specific instructions for working with an encrypted root file system. In doing so this HOWTO draws on previous work from other distributions and tries to suggest the minimal amount of changes to the openSUSE installation and boot processes so as to create a procedure that easily works with mainstream openSUSE. (Although designed for use with openSUSE some variation of these procedures may work for other Linux distributions as well, but have not been tested on anything else.)
Preliminaries
Prerequisites
- An openSUSE 10.3 installation source media.
- A computer that meets the system requirements of openSUSE 10.3.
WorkflowSince the openSUSE 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.
Note: An openSUSE 10.3 Live CD has been released. Unfortunately, an x86_64 edition has not yet been released, so this method is still necessary for those computers.
A high level view of the workflow for the proposed procedure is:
- Install openSUSE, designating one partition temporarily as root.
- Make sure we have all the tools we need to continue.
- Create an encrypted swap partition.
- Create an encrypted partition on one of the remaining partitions.
- Copy the root file system into the new encrypted partition.
- Create a new initial ram disk (initrd) to boot the system
- Test the system to see that the boot procedure works for the new partition.
- Erase the original root partition and replace it by another encrypted file system for holding the user file system.
Installing openSUSEAs 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, openSUSE 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:
| device | mount point | notes |
|---|---|---|
| /dev/sda1 | /boot | |
| /dev/sda2 | swap | This will become the encrypted swap. |
| /dev/sda3 | /home | This will become the encrypted root. |
| /dev/sda4 | / | This will become the encrypted home. |
(As noted before, the idea is to first install the root partition on sda4, then create an encrypted file system on sda3, copy the root system from sda4 to sda3 and finally create another encrypted partition on sda4 for the users file system.)
In the package selection, ensure the package “cryptsetup” is installed.
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”, “loop-aes” and “truecrypt” . This HOWTO discusses the procedure for cryptsetup as it is the simpler package to use . (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.)
Preparing the tools
In openSUSE 10.3, mkinitrd works out of the box if we correct a typo in the script /lib/mkinitrd/scripts/setup-luks.sh .
In the line,
luks_blockdev="$luks_blockdev $lucksbd"
We must replace “$lucksbd” by “$luksbd” (notice the letter “c”). After that everything should work fine.
NOTE: This issue has been resolved with mkinitrd-2.1-36.2. So an alternative to this is installing this package.
CAVEAT: As of 2008-02-02 and mkinitrd-2.1-36.4, there is still a problem that prevents using a Linux soft RAID partition as the partition where the LUKS encrypted partition resides on, see https://bugzilla.novell.com/show_bug.cgi?id=358341. The problem is easy to fix by applying the patch to /lib/mkinitrd/scripts/setup-luks.sh that is attached to this Bugzilla report, but be aware that updates to the mkinitrd package will overwrite that change and then, after another kernel update, your system will no longer boot.
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 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 may not have been loaded by default. (Later these will loaded by initrd.)
modprobe dm-mod modprobe dm-crypt modprobe aes modprobe sha256
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/sda2
Fill the swap partition with random data. (This will take a few minutes.)
dd if=/dev/urandom of=/dev/sda2
Initialize the encrypted swap device using the command:
cryptsetup -v --key-size 256 luksFormat /dev/sda2
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 NISTand the NSA (though it must be added that neither the NSA nor the NIST have endorsed this particular software package) as well as other experts.
Important note: If you get a “Command failed” error, be certain you read the instructions very carefully and follow them, regarding the confirmation.
To view the LUKS partition header information use:
cryptsetup -v luksDump /dev/sda2
Now open the new encrypted partition:
cryptsetup -v luksOpen /dev/sda2 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/sda3
Fill /dev/sda3 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/sda3
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/sda3
To view the details of the encrypted partition use:
cryptsetup luksDump /dev/sda3
Now open the encrypted partition
cryptsetup luksOpen /dev/sda3 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. (ext3 is the default file system for openSUSE 10.3, but one should use the same file system used when the system was originally installed.)
/sbin/mkfs.ext3 -O dir_index,resize_inode /dev/mapper/root
Or, if you use reiserfs:
/sbin/mkfs.reiserfs -j /dev/mapper/root /dev/mapper/root
stem 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
mkdir /mnt/root/media
mkdir /mnt/root/mnt
cd to /mnt/root/etc and open fstab in any text editor. Change the entry for /dev/sda3, the former home-partition, into:
/dev/mapper/root / ext3 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/sda4, the former root-partition, should be written as:
/dev/sda4 /home ext3 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). (One could also use an initial ram file system (initramfs), though this requires recompiling the kernel.) Normally, openSUSE 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, 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 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.
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 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 the boot menu and create a NEW entry which contains the new parameters. It might look something like this:
/boot/grub/menu.lst
###Encrypted root### title openSUSE 10.3 - encrypted root (hd0,0) kernel /vmlinuz-VER-default root=/dev/mapper/root luks_root=/dev/sda3 luks_swap=/dev/sda2 luks="root swap" vga=0x317 resume=/dev/mapper/swap splash=silent showopts initrd /initrd-VER-default
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. You will have to type in your password once for each 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/sda4 dd if=/dev/urandom of=/dev/sda4 cryptsetup -v --key-size 256 luksFormat /dev/sda4 cryptsetup luksOpen /dev/sda4 home /sbin/mkfs.ext3 -O dir_index,resize_inode /dev/mapper/home mount /dev/mapper/home /home
Edit fstab and add an entry for /home, e.g.
/dev/mapper/home /home ext3 acl,user_xattr 1 2
Re-run mkinitrd to add the information for /home to the initrd.
mkinitrd
Now edit the bootloader menu to decrypt home at startup.
/boot/grub/menu.lst
###Encrypted root### title openSUSE 10.3 - encrypted root (hd0,0) kernel /vmlinuz-VER-default root=/dev/mapper/root luks_root=/dev/sda3 luks_swap=/dev/sda2 luks_home=/dev/sda4 luks="root swap home" vga=0x317 resume=/dev/mapper/swap splash=silent showopts initrd /initrd-VER-default
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 relatively safe to configure the system to directly initiate a session for the user once the system is booted. This saves entering an additional password.
Note: The user account should still have a password, but a convenience auto-login can be enabled.
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 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, has been solved for dm-crypt with the introduction of the ESSIV cipher mode.
Osvik et al., 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 weakness, 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.
Loading ...