SDB:Encrypted root file system (deprecated)
/home on deprecated (old and unsupported) Opensuse versions. If you are using Opensuse 11.2 or newer please ignore this page and go straight to SDB:Encrypted_root_file_system
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 [citation needed].
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 [8] [8] [9] 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 (or newer) installation source media.
- A computer that meets the system requirements of openSUSE 10.3 (or newer).
Workflow
Since 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 [citation needed] 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 onto a USB flash disk, 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].
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.
LINUXLAPTOP: For openSUSE 11.1 installed on an external USB disk, a summary of the commands is given at the end of this article.
Installing openSUSE
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 disk
(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 disk, plug it in before
booting the computer with the installation CD in the disc 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 disk 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 script tries to mount the entries listed in fstab. (You can always
remount the USB flash disk 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 that 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” [10], “loop-aes” [2] and “truecrypt” [3]. This HOWTO discusses the procedure for cryptsetup 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.)
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 doing this, 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.
ICEBERG: As of 2008-05-12 and mkinitrd-2.1-36-5 luks encrypted partitions are not automatically found by mkinitrd. Workaround: open /lib/mkinitrd/scripts/setup-storage.sh and add your partitions to the variable blockdev in the last line of the script, e.g.:
blockdev="$(resolve_device Root $rootdev) $(resolve_device Resume $resumedev) $(resolve_device Journal $journaldev) $(resolve_device Dump $dumpdev) /dev/mapper/home /dev/mapper/swap"
LINUXLAPTOP: A similar extension was required for encrypting an openSUSE 11.1 laptop installation on an external USB drive (see [30]),
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, but 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 modprobe sha1
[N.B. - with stock 11.1 I had to use `modprobe sha256_generic; modprobe sha1_generic`.]
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_rescue /dev/urandom /dev/sda2
Initialize the encrypted swap device using the command:
cryptsetup -v --key-size 256 luksFormat /dev/sda2
This command will first ask for the password, then create a new encrypted partition using the AES cipher, in the cbc-essiv mode [citation needed; the manpage is unclear about defaulting to ESSIV]. 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.
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 created 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
Filling Disks with random Data
Warning: All of the following commands will delete the data on your partitions, so use with caution!
There are a few different options available as to how the partition should be filled with random data. This eventually protects the encrypted partitions against full cryptoanalytic attacks, should the disks ever be lost, stolen, or try to be compromised. Some options are better than others, and more or less time consuming depending on the hardware being used. Methods currently available are: semi-random /dev/urandom, encrypted /dev/zero, or the shred/wipe method.
Option 1: /dev/urandom
This will fill the following device or partition with kernel generated semi-random data. It is the easiest method to use, but is seven times slower than the method below on modern hardware, because it uses a PRNG to gather data instead of doing actual encryption.
Option 2: encrypted /dev/zero
The fastest method is to initially fill the beginning (e.g. 2 MB) of the disk with /dev/urandom:
dd_rescue -m 2M /dev/urandom /dev/sda3
and then run luksFormat and luksOpen (see below). Now you can fill the decrypted logical disk (/dev/mapper/my_encrypted_partition) from /dev/zero
dd_rescue /dev/zero /dev/mapper/my_encrypted_partition
This will fill the decrypted disk with zeros which will be encrypted and saved to your physical device. This will be indistinguishable from semi-random data on the physical disk and is much faster.
On an 64-bit Dell M4400, this method wrote at approximately 50MB per second, whereas reading from /dev/urandom ran at approximately 7MB per second. This is an improvement of over seven times, although it is potentially somewhat less secure for high-resource attacks against the disk encryption[citation needed]. (I.e., supercomputer cryptographic attack against the disk key, although this does not matter unless you plan to use at least a 40 character disk password for LUKS along with using /dev/urandom.)
Option 3: shred/wipe
One of the slowest options, but perhaps more secure. Name: "shred - overwrite a file to hide its contents, and optionally delete it" Description: "Overwrite the specified FILE(s) repeatedly, in order to make it harder for even very expensive hardware probing to recover the data."
shred can do many writes (or passes) on the disk depending on what options are given, although still taking input from /dev/urandom (with the default options, this can be changed). What I also find useful with shred is the -v option which actually shows the fill progress of your drive and or partitions. On the other hand using default options for dd_rescue mentioned in this HOWTO is the faster method than the above mentioned shred method.
Doing it
So now we will start filling /dev/sda3 with random data using option 1 from above: (Depending on the size of the partitions and the speed of your CPU, this my take from tens of minutes to a couple of hours.) On my Intel Core2Duo E8400 it took me around 3 to 3.5 hours to write 60 GB of data using SATA 3.0 HDD's
dd_rescue /dev/urandom /dev/sda3
Once the dd_rescue command has finished, create the device mapping for the
root partition by 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 [citation needed].)
/sbin/mkfs.ext3 -O dir_index,resize_inode /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
There are many methods for copying files, but of the top common ones, only rsync preserves all attributes including ACLs/Xattrs, sparse mode and a progress-meter. Note that there is no need to copy the special file systems like /dev, /proc and /sys since these will be re-created when the system is booted.
This rsync invocation will not traverse filesystems, but will create the various mount points and preserve all attributes:
rsync -AHSXax / /mnt/root/
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) [15]. (One could also use an initial ram file system (initramfs) [8] [27], 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 [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.
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 -f "dm luks"
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. The option '-f "dm luks"' tells mkinitrd to enable the luks feature.
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.
Note: I had to use: "yast2 --> system --> editor for /etc/sysconfig --> system --> kernel --> initrd_modules --> add dm-mod dm-crypt aes_i586 blkcipher" to enable the right modules while booting. Maybe you also need the "lrw" module, if you wanna use a cipher like aes-lrw-benbi.
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_rescue /dev/urandom /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
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 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.
Summary of commands for openSUSE 11.1 installed on an external USB drive
In the following a summary of the steps described above is given including some modifications ([30]) for openSUSE 11.1 installed on an external USB drive. NOTE: The modifications made in [30] for mkinitrd 2.4 are a port of the changes included in [18] for mkinitrd 1.2.
# ------------------------------------------------------------------------------
# Install OpenSUSE 11.1 from DVD
# ------------------------------------------------------------------------------
- Create Partition Setup
+ Custom Partitioning (for experts)
- Delete all existent partitions
- Create primary partition (sda1), ext3, 200 MB, mount point '/boot'
- Create primary partition (sda2), swap, 4 GB, mount point '/swap'
- Create primary partition (sda3), ext3, 20 GB, mount point '/home'
- Create primary partition (sda4), ext3, <remaining>, mount point '/'
- add package 'emacs'
# ------------------------------------------------------------------------------ # backup boot files, i.e. initial ramdisk, etc. # ------------------------------------------------------------------------------ mkdir /BACKUP cp -ax /boot/* /BACKUP mv /BACKUP /boot
# ------------------------------------------------------------------------------ # create an encrypted swap partition # ------------------------------------------------------------------------------ swapoff /dev/sda2 dd_rescue /dev/urandom /dev/sda2 cryptsetup -v --key-size 256 luksFormat /dev/sda2 cryptsetup -v luksDump /dev/sda2 cryptsetup -v luksOpen /dev/sda2 swap mkswap /dev/mapper/swap swapon /dev/mapper/swap
# ------------------------------------------------------------------------------ # create an encrypted file system for the new root partition # ------------------------------------------------------------------------------ umount /dev/sda3 dd_rescue /dev/urandom /dev/sda3 cryptsetup -v --key-size 256 luksFormat /dev/sda3 cryptsetup luksDump /dev/sda3 cryptsetup luksOpen /dev/sda3 root /sbin/mkfs.ext3 -O dir_index,resize_inode /dev/mapper/root mkdir /mnt/root mount /dev/mapper/root /mnt/root
# ------------------------------------------------------------------------------ # copy files from old to new root partition # ------------------------------------------------------------------------------ cd / find bin boot dev etc home lib* opt root sbin srv 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
# ------------------------------------------------------------------------------ # update /etc/fstab # ------------------------------------------------------------------------------ cp /etc/fstab /etc/fstab.ORIG emacs /etc/fstab --- /dev/mapper/swap swap swap defaults 0 0 /dev/mapper/root / ext3 acl,user_xattr 1 1 /dev/sda1 /boot ext3 acl,user_xattr 1 2 /dev/sda4 /home ext3 acl,user_xattr 1 2 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 --- cp /etc/fstab /mnt/root/etc/
# ------------------------------------------------------------------------------ # update scripts for creating a new initial ram disk # ------------------------------------------------------------------------------ # back up original files cp /lib/mkinitrd/scripts/boot-luks.sh boot-luks.sh.ORIG cp /lib/mkinitrd/scripts/setup-luks.sh setup-luks.sh.ORIG cp /lib/mkinitrd/scripts/setup-storage.sh setup-storage.sh.ORIG cp /sbin/mkinitrd mkinitrd.ORIG
# update mkinitrd scripts (phase 1 --- w/o encrypted 'home' partition) tar -xvzf mkinitrd-ut.tar.gz
cp mkinitrd-ut/mkinitrd-2.4-34.1-ut_scripts_boot-luks.sh /mnt/root/lib/mkinitrd/scripts/boot-luks.sh cp mkinitrd-ut/mkinitrd-2.4-34.1-ut_scripts_setup-luks.sh /mnt/root/lib/mkinitrd/scripts/setup-luks.sh cp mkinitrd-ut/mkinitrd-2.4-34.1-ut_scripts_setup-storage-phase1.sh /mnt/root/lib/mkinitrd/scripts/setup-storage.sh cp mkinitrd-ut/mkinitrd-2.4-34.1-ut /mnt/root/sbin/mkinitrd
cp mkinitrd-ut/mkinitrd-2.4-34.1-ut_scripts_boot-luks.sh /lib/mkinitrd/scripts/boot-luks.sh cp mkinitrd-ut/mkinitrd-2.4-34.1-ut_scripts_setup-luks.sh /lib/mkinitrd/scripts/setup-luks.sh cp mkinitrd-ut/mkinitrd-2.4-34.1-ut_scripts_setup-storage-phase1.sh /lib/mkinitrd/scripts/setup-storage.sh cp mkinitrd-ut/mkinitrd-2.4-34.1-ut /sbin/mkinitrd
# ------------------------------------------------------------------------------ # create a new initial ram disk # ------------------------------------------------------------------------------ mkinitrd -v -d /dev/mapper/root -f "dm luks"
# ------------------------------------------------------------------------------ # edit '/boot/grub/menu.lst' # ------------------------------------------------------------------------------ emacs /boot/grub/menu.lst # add new entry to '/boot/grub/menu.lst': ###Encrypted root### title openSUSE 11.1 - encrypted root (hd0,0) kernel /vmlinuz-2.6.27.7-9-pae 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-2.6.27.7-9-pae
# ------------------------------------------------------------------------------ # reboot # ------------------------------------------------------------------------------ # check that everything is working ... # free --> swap space # suspend-to-disk # ...
# ------------------------------------------------------------------------------ # encrypt the 'home' partition (and delete the up to now original root partition) # --> good luck, this is the point of no return ;-) # ------------------------------------------------------------------------------ umount /dev/sda4 dd_rescue /dev/urandom /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
# ------------------------------------------------------------------------------ # update /etc/fstab # ------------------------------------------------------------------------------ emacs /etc/fstab --- /dev/mapper/swap swap swap defaults 0 0 /dev/mapper/root / ext3 acl,user_xattr 1 1 /dev/sda1 /boot ext3 acl,user_xattr 1 2 /dev/mapper/home /home ext3 acl,user_xattr 1 2 proc /proc proc defaults 0 0 sysfs /sys sysfs noauto 0 0 debugfs /sys/kernel/debug debugfs noauto 0 0 usbfs /proc/bus/usb usbfs noauto 0 0 devpts /dev/pts devpts mode=0620,gid=5 0 0 ---
# ------------------------------------------------------------------------------ # update scripts for creating a new initial ram disk (now for all partitions encrypted) # ------------------------------------------------------------------------------ # update mkinitrd scripts (phase 2 --- with encrypted 'home' partition) cp mkinitrd-ut/mkinitrd-2.4-34.1-ut_scripts_setup-storage-phase2.sh /lib/mkinitrd/scripts/setup-storage.sh
# ------------------------------------------------------------------------------ # create a new initial ram disk # ------------------------------------------------------------------------------ mkinitrd -v -d /dev/mapper/root -f "dm luks"
# ------------------------------------------------------------------------------ # edit '/boot/grub/menu.lst' # ------------------------------------------------------------------------------ emacs /boot/grub/menu.lst # replace entries in '/boot/grub/menu.lst' by: ###Encrypted root### title openSUSE 11.1 - encrypted root (hd0,0) kernel /vmlinuz-2.6.27.7-9-pae 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-2.6.27.7-9-pae ###Encrypted root failsafe### title Failsafe -- openSUSE 11.1 - encrypted root (hd0,0) kernel /vmlinuz-2.6.27.7-9-pae root=/dev/mapper/root luks_root=/dev/sda3 luks_swap=/dev/sda2 luks_home=/dev/sda4 luks=root,swap,home ide=nodma apm=off noresume nosmp maxcpus=0 edd=off powersaved=off nohz=off highres=off processor.max_cstate=1 x11failsafe vga=0x317 showopts initrd /initrd-2.6.27.7-9-pae
# ------------------------------------------------------------------------------
# reboot and have fun ;-)
# ------------------------------------------------------------------------------
# Thanks also to Mathias Grimmberger for the bug-fix in 'boot-start.sh' and the
# corresponding adjustments of the kernel parameters in '/boot/grub/menu.lst'!
# ('luks="root swap home"' --> 'luks=root,swap,home')
# ------------------------------------------------------------------------------
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 access 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 espionage 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 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.
References
- dm-crypt: a device-mapper crypto target, http://www.saout.de/misc/dm-crypt/
- J. Ruusu,"loop-AES", http://sourceforge.net/projects/loop-aes/
- "True Crypt", http://www.truecrypt.org/
- C. Fruhwirth, "Linux hard disk encryption settings", http://clemens.endorphin.org/LinuxHDEncSettings
- J. Arnt, et al., "SUSE Linux Start-Up", http://en.opensuse.org/Distribution/SL-10.1/inst-source/docu/en/startup_en.pdf
- "EncFS Encrypted Filesystem", [http://encfs.sourceforge.net/
- C. Devine, "Encrypted Root Filesystem HOWTO", http://tldp.org/HOWTO/Encrypted-Root-Filesystem-HOWTO/
- "SECURITY System Encryption DM-Crypt with LUKS", http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS
- M. Petullo,"Encrypt Your Root Filesystem", http://www.linuxjournal.com/article/7743
- "LUKS - Linux Unified Key Setup", http://luks.endorphin.org/
- M. Dworkin, "Recommendation for Block Cipher Modes of Operation", http://csrc.nist.gov/publications/nistpubs/800-38a/sp800-38a.pdf
- "CNSS Policy No. 15, Fact Sheet No. 1", http://www.cnss.gov/Assets/pdf/cnssp_15_fs.pdf
- "Fact Sheet NSA Suite B Cryptography", http://www.nsa.gov/ia/industry/crypto_suite_b.cfm
- W. Almesberger and H. Lermen, "Using the initial RAM disk (initrd)", file:///usr/src/linux/Documentation/initrd.txt
- "SECURITY System Encryption DM-Crypt with LUKS/initrd", http://gentoo-wiki.com/SECURITY_System_Encryption_DM-Crypt_with_LUKS/initrd
- "mkinitrd", http://www.novell.com/products/linuxpackages/suselinux/mkinitrd.html
- "SUSE mkinitrd for Encrypted Root File Systems", http://www.ccrl-nece.de/~greg/linux/mkinitrd-lerfs.tar.gz
- "Performance of Encryption Algorithms", http://www.saout.de/tikiwiki/tiki-index.php?page=UserPageChonhulio
- "dmcrypt versus loopaes", http://deb.riseup.net/storage/encryption/benchmarks/dmcrypt-v-loopaes
- M.-J. O. Saarinen, "Encrypted Watermarks and Linux Laptop Security", http://docs.indymedia.org/pub/Local/UkCrypto/wisa2004.pdf
- "Encryption Ideas for IMC UK", http://docs.indymedia.org/view/Local/UkCrypto
- "Encrypt filesystems with EncFS and Loop-AES", http://security.linux.com/print.pl?sid=06/03/13/1656228
- J. Ruusu,"Re: Oopsing cryptoapi (or loop device?) on 2.6.*", http://marc.theaimsgroup.com/?l=linux-kernel&m=107719798631935&w=2
- 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
- C. Fruhwirth, "New Methods in Hard Disk Encryption", http://clemens.endorphin.org/nmihde/nmihde-A4-os.pdf
- J. Gustedt, "Early LUKS", http://www.loria.fr/~gustedt/early/
- 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
- Packman "cryptsetup-luks" RPM packages for older openSUSE distributions http://packman.links2linux.de/package/841
- "openSUSE 11.1 mkinitrd and scripts for Encrypted Root File Systems", http://www.mtsports.de/linux/mkinitrd-ut.tar.gz