Disk Encryption on Linux

I finally encrypted some partitions of my hard drive.

An external hard drive that I just bought (320 Gb) that allowed me to back up my entire /home partition and consider encrypting it.

I mainly used this tutorial, but I derived a little from it about the unlocking system : I did not want to input a password while the machine boots, I wanted it to be transparent while I log in. This how to provides more complete information, if needed.

So I will summarize here the actions to get an encrypted volume.

The tools

dmcrypt is a device mapper supported by the 2.6 Linux kernel. Roughly, this is an abstraction layer between the kernel and the real file system, doing all encrypting / decrypt operations. It is a replacement of cryptoloop, which created a loop device in a file within the file system. It can’t encrypt a whole partition and can be considered now as less reliable and secured.

The encryption is based on LUKS is a userland tool aiming to simplify the set-up of dm-crypt. It also stores some set-up information related to the encryption in the partition header, to make easy the transportation of the data from a machine to another, changing the passphrase without having to re-encode the entire partition, and even support having multi passphrases for the same device.

What to encrypt and why ?

The first thing is to decide what you will encrypt and how. Of course, I consider that your drive is rightly partitioned with, at least, the /, /home and swap having each a separated partition.

It is the case on my laptop. I chose to encrypt both the /home and the swap partitions.

In my case, there were little interest in encrypting the / partition. It contains only configuration files (without any password hardcoded), the /temp and applications – nothing to keep secret. But of course it might be different for you, depending on the security level you are looking for.

To the contrary, the /home partitions contains a lot of private data that I wouldn’t like anyone access in any case.

Then, it is rather important to encrypt the swap, because it is roughly a partial of you RAM and therefore contains all kind of information from your opened session. The annoying thing is that hibernation (suspend to disk) will not work anymore. It is anyway worth to be done, as it is well explained by this blogger.

Preparing the software

Using Debian Etch or Ubundu Festy/Gutsy, it is easy though the provided kernel (2.6) already supports device mapper, crypt target and AES cipher algorithm as modules :

$ apt-get install dmsetup cryptsetup libpam-mount

Encrypting swap

UPDATE 2008/04/13 : it is now possible to encrypt the swap in a way that preserve suspend-to-disk.

It is a good test to start with the swap, as there is no risk that you loose some valuable data.

First, let’s deactivate the current swap before any operation :

$ swapoff /dev/hda2

We suppose that hda2 is your swap partition :

$ cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/hda2

add this line to the /etc/crypttab file :

swap    /dev/hda2       /dev/urandom     swap

It means that we are going to create a mapper named swap for the /dev/hda2 device. It will use a random key as a passphrase for the encryption.

There is a choice to do between /dev/random and /dev/urandom. The latter is in theory a little bit less secure (the randomizing is inferior to the /dev/random, as it reuses the internal pool data for the generation), but it is preferable if you don’t want to be blocked at boot time, while the kernel is trying to get more entropy (you can shorten this by pressing some keys, though).

Now starts this script :

$ /etc/init.d/cryptdisks start

It will create a mapper named swap to the /dev/hda2 partition, as set in the crypttab file.
This is equivalent to this command :

$ cryptsetup -y create swap /dev/hda2

Now, we need to create the file system :

$ mkswap /dev/mapper/swap

Now we need to update the /etc/fstab file, commenting the old entry for hda2 and adding a new one for the mapped device :

/dev/hda2       none            swap    sw              0       0
/dev/mapper/swap        none    swap    sw      0       0

Now you are ready to test ! Just reboot, and without any user interaction, you should get an encrypted swap with a randomized key.

Encrypting /home

Now let’s encrypt the /home. Before doing anything, be SURE that you made a BACK UP of ALL your data. The entire /home will be ERASED !

We consider that hda3 is the /home partition :

$ cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/had
$ cryptsetup -y create home /dev/hda
$ mkfs.ext3 /dev/mapper/home

We won’t use neither the crypttab file or the fstab one, because we don’t want to be prompted at boot time for a password. And of course we can’t afford to crypt our data with a randomized key, changing at every boot !

What we want is the encryption to be done at log-in time, without prompting the user for another passphrase. Don’t we have enough passwords to memorize to add one more !?

We are going to use PAM, the Linux authentication mechanism, with its libpam-mount module. It is designed to mount some devices while the user log in, exactly what we need ! The user Linux password will be used as the encryption passphrase.

Of course, the security level will depend on your user password – take a good care on its length and complexity (though it must be already the case, encryption or not). A good compromise is probably an 8 digits password. Of course, if you are looking for the top level security, prefer the boot time passphrase prompting method…

To activate it, create or edit the /etc/security/pam-mount.conf.xml file and add this line :

<volume user="user" fstype="crypt" path="/dev/mapper/home" mountpoint="/home" options="fsck,relatime" />

Also add this at the end of the /etc/pam.d/common-auth file :

# cryptsetup
auth    optional        pam_mount.so use_first_pass

That’s done ! Testing is easy : log off, log in and check that your /home partition is well monted. It should not been mounted or readable for other users, including root.

Encrypting a removable device

We assume that you have a usb key (once again BACK UP your data) inserted, corresponding to the /dev/sda device :

$ cryptsetup luksFormat -c aes-cbc-essiv:sha256 /dev/sda1

We open manually the luks partition :

$ cryptsetup luksOpen /dev/sda1 usbkey

We format it with the filesystem of your choice (here ext3) :

$ mkfs.ext3 /dev/mapper/usbkey

We close the partition :

$ cryptsetup luksClose usbkey

Now every time you insert the key, you will be prompted for the password (at least by Gnome through the keyring manager box, though I haven’t tested yet with a different window manager).

Conclusion

This was a much easier experience than I previously thought. Much work has been made to hide the complex layers behind that, and it now takes only a few steps to get a pretty well secured hard drive.

However I think it really must become more user-friendly for the masses. Most of people will still be scared to open a terminal and type the commands above, so I am looking forward to seeing some graphical front-end to manage all that. Sure there are coming, and if you already know some project, please let me know.

About performance, if encryption must have a resource cost, I could not notice any slow down on a pretty modest hardware (celeron M 1,5 Ghz).

11 thoughts on “Disk Encryption on Linux

  1. Nick

    on 7.10, i get an error trying this:
    # cryptsetup luksformat -c aes -cbc -essiv:sh256 /dev/sda1
    -essiv:sh256: unknown option

    also tried –essiv:sh256 but I get the same error

  2. JC Post author

    Sorry, this is a typo – a space got inserted…
    I should be :
    -c aes-cbc-essiv:sh256

    Now corrected in the article. Thanks !

  3. Robbin

    What is the point? If it gets “unencrypted” at boot, it is still accessable to whoever steals your laptop or hacks your system. It’s not like someone is going to pluck your computer apart and then steal your harddrive.

  4. JC Post author

    You are talking about the swap, right ?
    Because the home partition is encrypted while the user log in.
    Locking your machine while you go away will provide a quite good level of security.
    About the swap, at boot time, it is empty – so nothing to get for someone who would boot your machine.
    Ok, a hacker may access to the swap while the computer is on, but he fisrt needs an account on your machine…
    So, it is globally a strong protection against steal, what is an important matter for a laptop owner nowadays.
    Of course in no way it is a protection against a system hacking, but just another and important brick on your security wall. ;)

  5. anon

    This is so incredibly broken its beyond belief!!!!( For encrypting home)

    I really hope that someone will read this comment before attempting to do encryption like this, because as given all these steps give no more security(ie none) than not using encryption.

    The reasoning is simple, every users password has a “hash” or ID that is stored on the root “/” partition, and you are using this password to decrypt the encrypted /home partition.

    If someone takes your laptop, they can extract the real password from the hash in roughly ~1-5min, then login to the system with it and have access to your “encrypted” home.

    Not a good solution.

    If you want to only use one password then encrypt the entire drive(including root partition) and setup a script to auto-login a user. Leaving the root partition un-encrypted then using information off of it to decrypt home is a recipe for disaster.

  6. JC Post author

    I disagree. The user password is indeed stored in /, but it is a MD5 hash with a salt.
    A md5 hash is not reversible.

    Plus, if the password is strong enough, because of the salt, it will take much much more than 5 minutes to crack. Rainbow tables won’t help you.

    So it is not yet a piece of cake to recover passwords from the /etc/shadow file, and that’s good news, otherwise it would be a major security issue for all Linux distribs (not only considering encryption).

    The only solution left to the attacker is to brute force, but in that case it doesn’t differ much from brute forcing even a full encrypted disk (if the user password is tricky enough, as I recommended it in the article).

    The attacker would better use a cold boot attack.

    The goal of the article was suggestion an encryption that protect the user from 99% of thiefs that could steal a laptop and try to access to personal data (sure, not against government agencies with huge processing power).

    I think it does, though a better alternative is to use hardware encryption.

    Or maybe you have a way to crack the shadow passwords in a very short time ? I doubt, but if so, please share it.

  7. kirm

    Hey! I tried your routine for encrypting a USB key and it worked but I couldn’t access it. I then realized I had to create a partition first and then go through the steps with the partition. So, to anyone out there, make sure you’ve created your partition before encrypting the key.

    Works like a charm. Thanks a million!

    BTW, I’m not to worried about encrypting the swap as I see that, with 4 GBs of memory, it doesn’t seem to be used but I sure would like to encrypt the /tmp and /var/tmp directories. Is there a way to do that in the same manner as your swap method (Don’t want to be bothered with passphrase)? I can do it in OpenSuse through the Partitioner but then I’m going to be prompted for 4 passphrases just to get to the login prompt.

Comments are closed.