Search:  
Gentoo Wiki

SECURITY_FileSystem_Encryption_without_ROOT

This article is part of the HOWTO series.
Installation Kernel & Hardware Networks Portage Software System X Server Gaming Non-x86 Emulators Misc
This article is part of the Security series.


Please format this article according to the guidelines and Wikification suggestions, then remove this notice {{Wikify}} from the article



This article is outdated. Please update this article with new information to match with the current portage tree and gentoo releases, and remove information about really old versions of software, then remove {{Update}} from this article's source.


Contents

Introduction

There currently exist a lot of HOWTO's out there that explain how to encrypt partitions, including the ROOT partition. So why am I writing this HOWTO?

Initially I was using loop-aes, with the encryption process described in (** place link here **) which worked great on my last notebook.
When it died, I obviously tried the same process on my new notebook. It didn't work!!
After 2 or 3 days of struggle, I finally found out, far as I can tell, that the standard GENTOO 2.6.12 kernel no longer directly supports initrd images, you have to use initramfs.
After having spent another 2 or 3 days trying to figure out what initramfs was and how to build an image, with no success, I finally gave up on the encryption scheme (I even tried building by hand the image generated by genkernel, using the files genkernel created, and it wouldn't even boot).
I still haven't figured out initramfs, so I'm using the genkernel to generate the images, but since this notebook is my life, I couldn't live without encryption. I finally found a link SECURITY System Encryption DM-Crypt with LUKS (which is also my main source of inspiration for writing this HOWTO), which showed another process to encrypt the root.
After having encrypted all of my partitions, and when I was trying to figure out how I was going to build the initramfs image (I was planning on modifying the *.cpio.gz file genkernel uses, before it created the image) is when I realized that, considering my current partition scheme, there was really no need to encrypt the root partition, since it had basically nothing that could be considered a security risk.

Basically, encrypting the ROOT partition is a non-standard process. What do I mean by non-standard? By non-standard I mean that root file system encryption is not normally supported by the various distros out there including GENTOO. By support, I mean a feature that can be used without having to step out of the standard configuration files, or modify the basic required system files (init.d, conf.d, etc) by hand.

If you're curious about ROOT File System encryption, I have included a set of reference links which all of them describing an approach that can be taken to encrypt the ROOT filesystem and the required changes for it to work correctly.

So what is our objective?

  1. To encrypt all the partitions (filesystems) on our hard drive, without encrypting the root filesystem.
  2. To create a security level as good (or almost as good) as if we had encrypted the root filesystem.
  3. To do all of this, without using non-standard methods in the GENTOO System.

Disclaimer

Warning: " The author of this guide assumes no responsibility for anything done with this document, nor does he make any warranty, implied or explicit. If you break it, it's not my fault. "

Basic Rules:

  1. BACKUP EVERYTHING, before TRYING ANYTHING. If it's important you definitely don't want to lose it.
  2. Read the MANUAL PAGES for the commands you are going to use, to make sure that I haven't made a mistake.
  3. BEFORE you hit enter, make sure the commands you type MAKES SENSE.

Requirements

This Lists not the requirements but my system platform, since I really have not tried this out on any other systems.

Note: As I far as I know, neither the Gentoo LIVECD or Knoppix contain a version of the cryptsetup with the luks patch that we will be using, but since we are not encrypting the root, you should always have access to the binary if you need to mount by hand the partitions.

Steps

Step 1: Preparing the Disks

Follow the steps in the Gentoo HANDBOOK Installation Handbook, UP TO, the chapter on Preparing the DISKS.

Note: The secret to how we are going to fulfill all our objectives, is in how we are going to partition the hard drive.

The partition scheme I use is:

hdc1 : Windows XP
hdc2 : extended partition
  hdc5 : NTFS (Data Partition)
  hdc6 : /boot
  hdc7 : LVM2 Logical Volume (LVM2 Resource Page)
Note: I use LVM2, but unless you are using LVM2 you should probably avoid using it (atleast until you have figured out what is, and how it works)

The following scheme, is the PREFERRED scheme that we will be using for the configuration of the system that follows. It is based on my hard drive (you will have to adapt it to your capacity):

hdc1 : Windows XP
hdc2 : extended partition
  hdc5  : NTFS (Data Partition)
  hdc6  : /boot   (512 MB) EXT2
  hdc7  : swap    (512 MB)
  hdc8  : /       (256 MB) EXT2
  hdc9  : /tmp    (  1 GB) EXT2
  hdc10 : /usr    ( 10 GB) ReiserFS
  hdc11 : /var    (  5 GB) ReiserFS
  hdc12 : /opt    (  4 GB) ReiserFS
  hdc13 : /home   ( 15 GB) ReiserFS

which leaves me with 9 GB Free.

Note: You have to leave some free space (minimum of of around 5 GB) because we will be converting the standard partitions to encrypted partions only after you have completed the installation of GENTOO, and we will be needing a scratch partition in the convertion process.

Partitions hdc6, hdc9, hdc10, hdc11, hdc12, hdc13 will be mounted onto our root partition at the respective mount poins. Therefore when we mount partition hdc8 under /mnt/gentoo (Step 4e in the Handbook) we will also have to create the mount points in the root filesystem (tmp,usr,var,opt,home) and mount these partitions into there respective mount points, BEFORE you continue with anything else.

Note: I specified that the root partition (hdc8) is formatted using EXT2. This is required to be this way [Why does the root partition have to be EXT2? - My root partition is EXT3 and I have not encountered a problem.] so don't format it with any other filesystem (especially considering the size it has). You will see why later. [You should just tell us now, there is no reason to be coy.]

Step 2: Configuring the Kernel

In the chapter on Configuring the Kernel in the Gentoo Handbook, we will need the following extra modules configured.

Linux Kernel Configuration: Extra modules
Device Drivers -->
  Block Devices -->
    Multi-device support (RAID and LVM) --->
      CONFIGURE ALL OPTIONS as MODULES "<M>"
Cryptographic options -->
  CONFIGURE ALL OPTIONS as BUILTIN "<*>" except Testing module
  (you can choose if you want, but it it is better to have everything)

Note: The experimental modules can be left out and the raid level modules (RAID-0, etc), unless you need RAID.

Note: When I mean configure as modules, that means configure as modules, and not as kernel built-in modules. Atleast in the case of the crypt module, dmsetup and cryptsetup won't recognize it any other way.

Note: On my system, even though I have AES set to compile the module into the kernel cat /proc/crypto does not show the AES cypher and it is not recognized by cryptsetup (BUG?). (EDIT by JG - try "#modprobe aes")

Step 3: Emerging the required modules

This step can be applied as part of the installation, but it is better to wait until you have finished the rest of the installation and have a stable running system.

EMERGE the following packages:

emerge sys-fs/multipath-tools (usefull programs for multipath)
emerge sys-fs/cryptsetup-luks (might require ACCEPT_KEYWORDS="~x86" and should USE="-dynamic" see man emerge )
Warning: Do not emerge, by mistake, the cryptsetup package, as this doesn't have luks support (which we will be using in the rest of the setup).

Note: The use of "-dynamic" for cryptsetup is optional, but desirable since it creates an executable with no lib dependencies (which is always usefull in case you need to rescue the system).

Emerging the cryptsetup-luks, will bring with the GENTOO support for encrypted partitions (i.e. a new file cryptfs will be created under /etc/conf.d to support automatic loading of encrypted partitions during the boot process).

What are the benefits of LUKS over the standard cryptsetup?

  1. Multiple Passwords per encrypted filesystem.
  2. Being Able to add/delete/modify a password without having to re-encrypt the partition.
  3. Potential portability of the encrypted filesystems across platform (see truecrypt.org), even though I haven't tried this.
Note: Everything said above about using cryptsetup-luks instead of cryptsetup ist obsolete as cryptsetup-luks ist no longer in portage. cryptsetup now has luks included.

Step 4: Considerations

1. Passwords

The 1st thing we have to consider is that, the encryption process requires passwords, and there are 2 basic types of passwords:

  1. User defined
  2. Random Generated Password.

In terms of security, random generated password are always best, since there is no possible dictionary attack against them, and the character set used is greater than is normally used for user defined password.
The only problem is that, since they can't be entered by hand, we have to use a key file to store them, which will have to be saved somewhere!

User defined keys, are more user friendly, but considering that we will be encrypting 5 partitions, this implies that we will have to enter this password correctly atleast 5 times. Which makes these passwords very user unfriendly.

2. A single password for all partitions or not?

The next thing we have to consider is that, since we are encrypting each partition individually, are we going to use one master password for all the partitions or one password per partition?

Using only a single password increases the security risk, but using multiple passwords can be more complicated.

Using LUKS partially solves this problem because:

  1. The master password, the password used to encrypt the file system is always random. The password we choose will only be used to encrypt the master password (which is stored along with the file system on the partition, please see (** add linkhere **)).
  2. We can have more than one password per partition.

But in reality, the security of the master password is only as good as the security of the password you use to encrypt it!

So how are we going to solve these problems?

If you are like me, you hate entering passwords. So what I wanted was a system in which I wasn't required to enter any passwords at all!

With that in mind, I implemented the following system (I will only describe it here and leave the implementation till later on):

  1. I bought a USB PenDrive (memory stick, or what ever they are called these days).
  2. I created a encrypted filesystem on the memory stick.
  3. I stored the random generated keys, created to encrypt the partitions, on the USB drive.
  4. I kept the random generated key used to decrypt the USB drive on my root (un-encrypted) partition.
  5. Modified cryptfs so that it 1st mounts the USB Drive, and then decrypts the rest of the partitions.

This basically creates an interlinked authentication between the PenDrive and the Notebook (without both you can't start the system).

(See Security Considerations Later on for Potential Problems).

Step 5: Encrypting SWAP and TMP Partitions

We will start the encryption process by "encrypting" the SWAP and TMP partition.
The SWAP partition doesn't contain any real permanent data. The TMP on the other hand does, but like it says it's should only contain temporary information (information that does not have to be maintained between sessions) so we will be treating them basically the same.

All that is required to encrypt these 2 partitions is to modify the cryptfs and fstab files, examples follow.

Changes for the CRYPTFS:
For SWAP:

swap=crypt-swap
options='-c serpent -s 256 -h sha1 -d /dev/urandom'
source='/dev/hdc7'

For TMP:

target=crypt-tmp
options='-c serpent-cbc-essiv:sha256 -d /dev/urandom'
source='/dev/hdc9'
pre_mount='/sbin/mke2fs ${dev}'
post_mount='chown root:root ${mount_point}; chmod 1777 ${mount_point}'

NOTE: Using -d /dev/urandom does not work with 1.0.4-r3(at least) it will read /dev/urandom till it Seg Faults. I assume you will need to create a key file like the rest of the FSs

These example come directly from the example configurations in the cryptfs file.

You will see from the examples that I am using the SERPENT cypher to encrypt both partitions. Considering the temporary nature of these partitions SERPENT is probably an overkill and you're probrably better off using the faster (but still secure) AES.

Note: As of version 1.0.5 the config file is no longer 'cryptfs' but 'dmcrypt' (/etc/conf.d/dmcrypt).

Note: As of version 1.0.4 the syntax has changed from 'mount' to 'target'. If you use a version <1.0.4 use mount=crypt-tmp instead.

Note: See /proc/crypto for the available ciphers.

Note: In both cases we are not using LUKS support in cryptsetup. This because, both system are going to be encrypted at the start of each session with some random key generated during the boot process (different every time).

Note: There is a note in the cryptfs about having the SWAP as the 1st Entry in the cryptfs file (please follow it).

Note: You can see that, the tmp partition is formatted on each boot (which is required since the encryption is being randomaly generated every time) and so YOU SHOULD NOT USE THE TMP PARTITION TO STORE ANYTHING ACROSS SESSIONS.

Changes for the FSTAB:

/dev/mapper/crypt-swap		none		swap		sw			0 0
/dev/mapper/crypt-tmp		/tmp		ext2		noatime			0 1

you will notice that the table now refers to the encrypted partitions and not the original devices. That's all that is required to encrypt both the SWAP and TMP.

You should now REBOOT the system to verify that the system is now in fact using the new encrypted partitions.

The mount and swapon -s commands should list the tmp and swap partitions as being mounted on /dev/mapper/crypt-tmp and /dev/mapper/crypt-swap respectively.

Step 6: Converting Existing Partitions to Encrypted Partitions

Warning: Up until now, we haven't really done anything that can stop your system from booting. This will change with this STEP so from now on, VERIFY EVERYTHING BEFORE HITTING ENTER.

What I outline below is actually a TEMPLATE of the steps that are to be applied to encrypt a single partition. This template than has to be applied repeatedly to all the partitions (usr,var,opt,home). I will be using the /usr partition (/dev/hdc10) as the basis for the template.

Note: Remember to make the appropriate changes according to the partition that is going to be encrypted.

To begin with, the empty space you should have left on your hard disk, is now needed.
Therefore:

  1. Using fdisk, create a new partition out of the free space you have left.
  2. Create a mount point for the new partition (i.e. /mnt/free).
Note: From now on the new partition created out of the freespace on the harddisk will be called /dev/hdc14

TEMPLATE (we will create the template using the /dev/hdc10 or usr partition):

1. Format and Mount the Free Space

mke2fs /dev/hdc14
mount /dev/hdc14 /mnt/free

2. Copy the partition to be encrypted to /mnt/free, you can use:

cd /usr
cp -ax . /mnt/free

OR

cd /usr
tar cvpf usr.tar .
cd /mnt/free
tar xvpf /usr/usr.tar
Note: I used cp -ax to backup the partition, even though I haven't had any problems, I'm not really sure if the cp -ax maintains the file permitions correctly across the copy, so tar might be the preferred method (or something else that guarantees the permissions).

Note: You have to backup the partition and not just simply tar gzip the directory, since /dev/hdc14 will have to take the place of the original partition in the fstab, so that we can reboot the system and have free access to the original partition.

3. Modify the fstab file, as in the following example: CHANGE

/dev/hdc10		/usr		reiserfs	noatime,notail		0 1

TO

/dev/hdc14		/usr		reiserfs	noatime,notail		0 1

4. Reboot the system, so that partition /dev/hdc14 takes the place of the old partition.

5. SHRED the old partition (for security reasons) before using:

shred -n 4 /dev/hdc10

(I overwrote my data with shred 4 times. [25 times, the default, would really take a really long time...]) ESSIV= "encrypted sector salt initial value" By combining the key with a salt that is different for every block of data on disk the known plaintext and watermark attacks become impossible: Identical blocks of data encrypt to different ciphertext due to differing salt values. Note that since ESSIV is not the default DM-Crypt, it is insecure by default, you must explicitly enable ESSIV mode to create a secure encrypted filesystem.

6. Encrypt the file system:

head -c 256 /dev/urandom > /etc/conf.d/usr.key (KEY FILE)
cryptsetup -c serpent-cbc-essiv:sha256 luksFormat /dev/hdc10 /etc/conf.d/usr.key (KEY FILE)
Note: It may seem a little strange to store the KEY FILE on the un encrypted root, but we will be taking care of that a little later on.
Note: If this command fails and it complains about missing cipher support I recommend that you check if modules cryptoloop and dm_crypt are loaded or just do
modprobe dm_crypt
modprobe cryptoloop 

7. Create dm (device-map) for the partition:

cryptsetup -c serpent-cbc-essiv:sha256 -d /etc/conf.d/usr.key luksOpen /dev/hdc10 crypt-usr

8. Format and Mount the encrypted file system:

mkreiserfs /dev/mapper/crypt-usr
mount /dev/mapper/crypt-usr /mnt/free

9. Copy the files back to the newly encrypted partition:

cd /usr
cp -ax . /mnt/free

OR

cd /usr
tar cvpf usr.tar .
cd /mnt/free
tar xvpf /usr/usr.tar

10. Modify the /etc/conf.d/cryptfs:

# Encrypted USR
target=crypt-usr
source='/dev/LINUX/usr'
type=luks
options='-c serpent-cbc-essiv:sha256 -d /etc/conf.d/usr.key'
Note: Notice the luks modifier.

11. Modify the /etc/fstab:

/dev/mapper/crypt-usr		/usr		reiserfs	noatime,notail		0 1

12. Reboot AGAIN.

If everything ran okay, the original partition /dev/hdc10 should now be encrypted (verify using mount: /usr should now be mounted on /dev/mapper/crypt-usr).

Note: In case of a problem (remember that you have a backup copy of the partition you where encrypting in /dev/hdc14, just modify the fstab to restore the system to a working condition).

All you have to do now, is repeat this step for all the other partitions. Don't forget to take into account the changes in the steps above, required for each partition (i.e. /usr to /home, /dev/hdc10 to /dev/hdc13, etc).

AFTER, you have converted all the partitions to encrypted partitions and before using fdisk to release the space on the /dev/hdc14 partition, do the following on it:

shred -n 4 /dev/hdc14

No use leaving any potential juicy information around :)

Step 7: Creating the USB Token

Creating the USB token is relatively easy by now. I'm just going to list the steps directly (most should now be self explanatory). I will be assuming that the USB Pendrive is on /dev/sda.

# You will lose everything on the PenDrive, so make sure it's empty
shred -n 4 /dev/sda
# Create KEY File for Encrypting the PenDrive
head -c 256 /dev/urandom > /etc/conf.d/token.key
# Encrypt the PenDrive (Notice we are using LUKS)
cryptsetup -c serpent-cbc-essiv:sha256 luksFormat /dev/sda /etc/conf.d/token.key
# Create the dm entry for the PenDrive
cryptsetup -c serpent-cbc-essiv:sha256 -d /etc/conf.d/token.key luksOpen /dev/sda crypt-token
# Format the Encrypted Partition
mke2fs /dev/mapper/crypt-token
# Mount the PenDrive
mkdir /mnt/token
mount /dev/mapper/crypt-token /mnt/token
# Copy the KEY Files for the partitions to the PenDrive
cp /etc/conf.d/*.key /mnt/token
# List to make sure we have everything
ls /mnt/token
# Unmount the Pendrive and Close the Device Mapper Entry
umount /mnt/token
cryptsetup luksClose crypt-token

So the only thing left is to put are PenDrive to use. We, again need to alter the /etc/conf.d/cryptfs to add the following entry:

# Encrypted PENDRIVE (Required for Mount)
target=crypt-token
source='/dev/sda'
type=luks
options='-c serpent-cbc-essiv:sha256 -d /etc/conf.d/token.key'
pre_mount='mount -o ro /dev/mapper/crypt-token /mnt/token'
post_mount='umount /mnt/token; cryptsetup luksClose crypt-token'
Note: This Entry has to come before the entries of the other encrypted partitions but after the SWAP and TMP entries (that don't require the pendrive to boot).

Basically this will mount the encrypted LUKS partition on /mnt/token (pre_mount option), during the boot process and before the other partitions are decrypted.

A little further on, after the mount process for the local partitions has completed, it will close and free up the USB Token (post_mount option). As of the moment that the post_mount commands have been executed, you can and should remove the USB Token. This token should only be inserted during the boot process, at all other times it should be secured somewhere else (you key chain, etc.).

Before going any further, you should reboot the system (again) with the pendrive plugged in to verify that the pendrive works!!! you should see an entry for crypt-token appear during the boot process.

If you are sure that the PenDrive is being mounted correcly, then all we have to do is alter the rest of the entries in cryptfs so as to refer to the new location /mnt/token/???.key: FROM

 options='-c serpent-cbc-essiv:sha256 -d /etc/conf.d/home.key'

TO

 options='-c serpent-cbc-essiv:sha256 -d /mnt/token/home.key'

Rebooting, should prove that the PenDrive is now being used.

Warning: Don't do anything else until you have read the Next Section (on Backup).

Step 8: Backup

If you have reached this step, you should have all the linux partitions encrypted, except the root. But, in terms of security you still have all the passwords that are required to decrypt the partitions on the root, unencrypted partition.

So why don't we just delete them?

  1. Because you really should delete anything, you should SHRED them!
  2. Because if you lose the token, without having a backup system YOU LOSE EVERYTHING.

So how do we create a backup?
By creating a secure encrypted volume, with everything we can't lose.

For this backup we will be using a loop partition mounted on file in our file system. Again I will only be listing the steps there is nothing really new here.

# Create a 280M file to store the backup (I use a 256M USB PenDrive
# so this create an image file a little larger than the drive, alter
# the size according to you PenDrive Size i.e. PenDrive+10M more or less)
# Note: /home/root is not the same as /root (the /root is store in the
# un-encrypted root partition, where /home/root is on the encrypted /home
# partition)
dd if=/dev/random of=/home/root/backup bs=1024 count=286720
# Shred the Backup to guarantee it contains garbage
shred -n 4 /home/root/backup
# Mount the backup file under a LOOP Device (requires modprobe loop if the loop
# device not built into kernel)
losetup /dev/loop1 /home/root/backup
# Encrypt the PenDrive (Notice we are using LUKS)
# Notice that we are not using a KEY FILE so you will prompted for a PASSWORD
# This PASSWORD has to guarantee the security of the BACKUP (So make it good)
cryptsetup -c serpent-cbc-essiv:sha256 luksFormat /dev/loop1
# Create the dm entry for the PenDrive (Again the PASSWORD Prompt)
cryptsetup -c serpent-cbc-essiv:sha256 luksOpen /dev/loop1 crypt-backup
# Create and Mount the File System
mke2fs /dev/mapper/crypt-backup
mkdir /mnt/backup
mount /dev/mapper/crypt-backup /mnt/backup
cd /mnt/backup
# SAVE an IMAGE of the USB PenDrive
# Note: THAT WE ARE SAVING THE IMAGE DIRECTLY FROM THE PENDRIVE
# (LUKS FORMAT and ALL) and not a decrypted image as we would get
# from /dev/mapper/crypt-token
dd if=/dev/sda of=pendrive.img
# Backup the keys
cp /etc/conf.d/*.key .
# Close Everything
cd /home/root
umount /mnt/backup
cryptsetup luksClose crypt-backup
losetup -d /dev/loop1

Done, or almost done, we now have a file called /home/root/backup (which really is an encrypted file system that contain our USB Token image and all the KEY Files required to decrypt the partitions, including the KEY file to decrypt the USB Token).

All we to do now, if write this file to some permanent medium (i.e. a CD, but not CD-RW). If you use the NASA philosophy you will write this file to 3 CD (one for a safe in your home/office, one for a safe offsite, and one for you to use on need to basis).

Warning: Even though you might be tempted to only write a single CD, remember that if you LOSE the TOKEN and the CD, everything you have on the computer is gone. So atleast 2 CD should be made, one for use, one for safe storage.

Warning: Remember to use GOOD Quality, long lasting CDs, and to verify that the CD has Been written correctly. If you use K3B, make sure to set the checkbox to verify the written data. Otherwise compare the md5sum of /home/root/backup with the ones written on the CD. You might even want to save the md5sum on the CD, so incase of problems you can verify the CD somewhere else.

Step 9: Removing the Evidence

Warning: You should only do this, completed Step 8 and verified Everything. TWICE.

All we have to do is remove all the KEY files in /etc/conf.d directory, except the "token.key" file, which is required to decrypt the USB PenDrive during the boot process.

To remove the files we use:

# Shred and Remove the KEY FILE
shred -u /etc/conf.d/usr.key

Finally DONE. Reboot to verify everything is working okay.

Troubleshooting

One of the benefits of not encrypting the root, is that if you make a mistake, or an update messes with your system, you will still be able to mount the system to a minimal rescue prompt. If you have completed all the steps in the previous section you can test this, by booting the system without the USB token plugged in. The boot process will eventually get you to a place where you're prompted for the root password, and once entered you will have a command prompt with complete access to your system configuration (i.e. /etc directory) and installed binaries. This will save you a lot of trouble, since you don't have to use Bootable CD with the potential hassel of different kernel/binary/module versions.

On my system, I didn't have to alter /etc/modules.autoload.d/kernel-2.6 to automatically load dm-crypt (but this might be because of the genkernel initramfs). So if cryptsetup is giving you problems, the first thing to verify is if the dm-crypt module is loaded (i.e. lsmod or dmsetup targets).

Sometimes the cryptsetup will refuse to run, giving you an "invalid parameters" errors. Sometimes the parameters are correct but it still refuses, so try the command by hand (after reading man cryptsetup) to see which parameter is giving you problems. I had a problem with the aes cypher, that I had set as built-in kernel module not being available, so things like aes-cbc-essiv:sha256 wouldn't work for me.

The step by step approach I use, should basically never leave you in a situation in which the system doesn't boot. But in the case that something happens, REMEMBER, you should still have access to a boot prompt on your system (see above) and the complete set of configuration for your system, so just try to alter the files back to their original state and reboot.

REMEMBER, that in the encryption process for the partitions, you should always have a backup of the partition that you are trying to encrypt (either in encrypted form, or in it's original form).

REMEMBER, that the boot prompt that you should still have available, allows you to manually boot any of the partitions AND you should still have access to cryptsetup and the KEY files to decrypt any of the partitions.

REMEMBER, to mount an encrypted partition you have to use:

 cryptsetup -c serpent-cbc-essiv:sha256 luksOpen /dev/.... crypt-.....

The luksFormat is only required when you want to FORMAT the partition (and is not needed when you are just trying to mount the partition).

As a last RESORT you can always use the GENTOO LIVECD to get to a point where you can access the partitions on your HARD Drive.

Other Security Considerations

First, you're only secure as the security of your weakest link. In this case, I would have to consider the USB Token as the weak point (others might consider the un-encrypted root as a the weak point).

The system works on the concept that, for your system to be comprimised somebody will have to have access to both your computer and usb token. This does not imply that this access has to be at the same time.

As an example:

1. You leave you USB token alone.
2. Some "spy" takes your token and makes an image of it (just like we did)
   and places your token back (without you noticing).

Now the "spy" can make a copy of the image to another USB drive and he will have complete access to your system, without you knowing it, using his USB Token.

another Example:

The "spy" steals your notebook with the USB Token attached (that you forgot to remove).

Potential Solution to this Problem:

  1. When we made our USB Token, we used a random key, that we stored in the KEY FILE on the un-encrypted root partition. This isn't required. We could have created the key using a password we chose (no KEY File on the root partition). The only difference will be that the system, during the boot process, will prompt you for a password. So without your password, there is no use to copying the USB Token.

Problems with the above Solution:

  1. The way the cryptfs system is implemented, you have no failsafe, if you make a mistake on the password you will not be prompted again, and the system will continue with the boot process and drop you into the minimal shell.
  2. User defined password are inherently weaker than random password, therefore easier to crack, if the "spy" had access to your token.

We can solve one of the problems above by using a 3 step system (which I describe)

  1. Create an encrypted filesystem on the USB token using a random key (as we did).
  2. On the encrypted device (crypt-token) create another encrypted filesystem using our keyword.
  3. Alter the cryptfs to mount the second encrypted filesystem (and prompt us for our password), before continuing.

This creates a 3 way dependency (computer, USB Token, user), with our weaker user defined key, being protected by the random key stored on the root filesystem (but again this is relative).

Second, some of you may feel uneasy about leaving the root partition unencrypted. The solution to this is to move basically everything that is not required for booting to one of the other partitions and linking them to the original source.

Example (for the /root directory):

  1. Create a /home/root directory, with root only privilegdes.
  2. Move all the files in /root to /home/root (rememeber to shred the originals).
  3. Link all the files in /home/root back to /root (Even on a fail boot, the only thing that will be visible is links).

an identical process can be used with the /etc directory, leaving only those files required to boot in /etc and moving all others to an encrypted partition.

Note: Some applications don't like links, so this has to be done with caution.

Final Words

I have tried for a more step-by-step aproach to this HOWTO without trying to explain everything. For those of you who need an explanation, which should basically be all of you, you can refer to SECURITY System Encryption DM-Crypt with LUKS and [1].
The first site, as I said, served as the model for this HOWTO and has series of great links to other sources of informations. The second site, is the reference site for LUKS (Linux Unified Key Setup).
I haven't really had more time to dedicate to this WIKI, but it might be interesting to set up a forum for people who would like to discuss problems or share their implementation stories. If somebody does setup a forum for this HOWTO, please alter this WIKI by placing a linkk to the forum for easy access.
I noticed that AnMaster took the trouble to cleanup the formatting of this WIKI, for which I am realy gratefull.

Retrieved from "http://www.gentoo-wiki.info/SECURITY_FileSystem_Encryption_without_ROOT"

Last modified: Mon, 14 Jul 2008 10:54:00 +0000 Hits: 16,191