Encrypted home partition in Linux with DM_Crypt
[ Wednesday, 2 May 2007, lipiec ]
Have you ever wondered what would have happened if all the important data have been stolen from your mobile PC? For example the information about a confidential project you have been working on for the last 2 years in your company … A horrifying vision, isn’t it? If you don’t want it come true, please consider encrypting your home drive. Here is how to do this in Linux.
Author: Marcin Lipiec
This is what you will need to prepare your Linux computer for encrypting your home drive:
- DM-Crypt — open-source tool for encryption the whole HDD partition. It encrypts data before writing them on HDD. Available for kernel 2.6.4 and later.
- LUKS - (Linux Unified Key Setup) — standard HDD encryption system for Linux.
- cryptsetup — enables simultaneous use of LUKS and DM-Crypt.
Necessary software download
The program you will need is cryptsetup with LUKS handling. In order to install it you may either use your distribution’s repositories or use the general method (compilation from sources).
The distro-specific method is recommended. In Ubuntu you only need to type apt-get install cryptsetup in the terminal windows (or use Synaptic Package Manager to do the same in a graphical interface.
If you prefer the source-based way, just open up a terminal and type wget http://luks.endorphin.org/source/cryptsetup-luks-1.0.4.tar.bz2. The installation proceeds as usual:
./configure
make
make install
Done. If all went right, the installation should be now finished and the encryption software ready to be used.
Key cryptsetup options
Cryptsetup enables you to perform different types of encryption and offers some additional options you may be interested in. Here is a brief overview of them.
root@host:~# cryptsetup OPTIONS action name device - general syntax
OPTIONS:
-c - here enter a cipher algorithm, the default is AES with 256-bit key
-h - displays help menu
-y - user verification, you will be prompted twice for the password
-d - loads password from the file. This option is ignored when you
use -y switch
-s - you can enter the key size (in bits)
ACTIONS:
create - creates HDD map
remove - deletes HDD map
reload - reloads HDD map
size - increases or decreases map size
status - displays status
name - map name in /dev/mapper/[device] - [device] is the name of the
HDD you want to encrypt
Now you know all the basic options, so you can get back to your main job — encrypt the home partition. Cryptsetup is a console program and there is no GUI layer available, so if you don’t like working with command line tools… you will have to give it a second chance
Initializing of /home directory
For the purpose of this article, let’s say that the partition which we want to encrypt is /dev/hdc6. Before you will be able to make the encrypted disc partition you have to initialize it first. This is how you do it:
root@host:~# cryptsetup luksFormat /dev/hdc6
WARNING!
=========
This will overwrite data on /dev/hdc6 irrevocably.
Are you sure? (Type uppercase yes): [YES]
Enter LUKS passphrase:
Verify passphrase:
Command successful.
You will be prompted for a password. You need to enter it twice. This password will be used for verification later on, so don’t forget it!
Choosing the encryption algorithm
Then you have to decide which algorithm you will use to encrypt the /home directory. The algorithm you use have to be supported by your kernel version. To check the available algorithms enter:
cat /proc/crypto
If there is no built-in crypto options (algorithms shouldn’t be loaded as modules) configure the kernel before you start the program (crypto options are in the Cryptographic options tab of the kernel configuration).
Next, you type:
root@host:~# cryptsetup -c chosen_algorithm -y luksFormat /dev/hdc6
If you don’t know what algorithm you want just skip -c switch. The default algorithm is AES.
Mapping the drive and creating a filesystem.
The next step is to create the mapping. Type:
root@host:~# cryptsetup luksOpen /dev/hdc6
You will be prompted to enter your password again to verify your identity. If there are no problems, the /home directory map should appear in /dev/mapper.
A good idea is to fill the new drive with random data. This may be a lengthy operation, so only do this when you have a modern computer. Here is an example command to perform this action:
dd if=/dev/urandom of=/dev/mapper/home
Then you should create a filesystem on your virtual directory’s copy:
root@host:~# mkfs.ext2 -m 0 /dev/mapper/home
Here I’ve chosen ext2, but it can be any filesystem e.g. ext3 or reiserFS.
Now copy your current content of /home directory to the mapped drive:
root@host:~# cp -a /home /dev/mapper/home
You are almost done, already
Creating additional user passwords
LUKS has a very interesting feature. Namely, not only root can access the encrypted directory, but also the regular users can, which is very helpful when you want to use the encrypted drive as your home partition. To enable a non-root user the access to the directory you have to add some new passwords for those guys. To add those new passwords run cryptsetup with option luksAddKey:
root@host:~# cryptsetup luksAddKey /dev/hdc6
Enter any LUKS passphrase:
Verify passphrase:
key slot 0 unlocked.
Enter new passphrase for key slot:
Verify passphrase:
Command successful.
You will be prompted for your password which you have set at the beginning and then you enter the new password for the chosen user. Passwords can be the same as the user’s account password of course. This is handy since it doesn’t force users to remember another passphrase, but of course makes the system security a bit weaker because a hacker who knows the user’s password can easily see the content of the encrypted partition.
To list all the added keys/passwords type the following:
root@host:~# cryptsetup luksDump /dev/hdc6
To remove a password type:
root@host:~# cryptsetup luksDelKey key_no
Mounting the encrypted drive
Finally you can mount your partition as a separate drive:
root@host:~# mount /dev/mapper/home /mnt/home/
And that’s all. From now on your /home partition will be encrypted. But what about mounting after reboot? Well… then you will have to map the /home directory again by typing:
root@host:~# cryptsetup -y luksOpen /dev/hdc6
root@host:~# mount /dev/mapper/home /mnt/home
If this seems annoying, read on
Automatic mounting of encrypted drives
As you may suspect, manual mounting can become annoying, especially in case you often reboot or turn off the computer. But there is a way to avoid it. To automate mounting you will need these two programs:
- PAM — lets to combine a few crypto technologies, what’s why the user isn’t bothered by separate implementation of each key encrypted with different algorithm.
- pam_mount — this is a special layer for PAM which enables of mounting separate volumes for each user and what is most important — it handles the crypt as well.
Pam_mount works almost seamlessly because mounting is invisible for the user. Installation of PAM and its plug-in proceeds as usual:
./configure
make
make install
When you have already installed both programs you have to check the content of /etc/security/pam_mount.conf file. I won’t show whole the file because there is everything perfectly described inside. You have to add the following line at the end of this file:
volume * crypt - /dev/hdc6/home /mnt/home fstype=ext2,async,nodev,fsck - -
The general syntax looks like this:
volume username filesystem server volume mounting_point mounting_options \\
encryption_algorithm path_to_key
Next, you have to edit /etc/pam.d/pam_mount. Check if there are following lines (if not, add them):
auth required pam_mount.so use_first_pass
session required pam_mount.so use_first_pass
Eventually, open /etc/pam.d/login and right after the line:
@include common-session
Add this one:
@include common-pammount
And here is the (happy) end of the story. The encrypted partition should now be automatically mounted upon login and you should not worry anymore about potential stealth of your data. I strongly advice you to keep and eye on your laptop anyway since the thief may not be aware of the advanced technologies you just installed
Conclusion
Configuring the drive encryption in Linux isn’t as easy as it should be. That’s why if you don’t have to do it, better leave it alone. Be aware that if — during the encryption process — you are cut off the power supply and you have no UPS, the situation won’t be funny. This is because the encryption is being held on the fly. The files are encrypted before being written on HDD, so in such case you may lose the document you currently work on. But the advantages are also huge enough to consider such encryption. When your PC is stolen, the thieves won’t have any access to your encrypted data (in this case, the whole user partition). This is just a HOWTO, the decision is yours
Bibliography
Subscribe to RSS feed for this article!
22 Comments
- A hyperlink: <a href="polishlinux.org">GNU/Linux for everyone!</a>,
- Strong text: <strong>Strong text</strong>,
- Italic text: <em>italic text</em>,
- Strike: <strike>
strike</strike>, - Code: <code>
printf("hello world");</code>, - Block quote: <blockquote>Block quote</blockquote>
















Good article, readers might be interested in another option ‘Enfcs’, which is a FUSE based implementation.
Can also be gotten via apt-get and intergrated with the login process with ‘pam_encfs’.
I’ve been running encrypted home drive for about a year now without problems.
Simon.
If anyone is looking for a way to encrypt the partition using TrueCrypt instead, stay tuned since another tutorial explaining how to do this will be published soon, of course on PolishLinux.org.
If you want a GUI to configure encrypted partitions, you can use openSuse and Yast. There’s everything you need in it.
Please don’t forget Ubuntu’s not the universal reference.
Could you please add (in your future TrueCrypt tutorial or in this tutorial) a part about encrypting an external USB drive ?
It’s because external USB drive are much more common now and they are easily stolen.
Why the admonishment about not loading the crypto algorithms as modules. Most distros (like FC6, CentOS, Ubuntu) are already distributing the cryto algorithms as modules. Why rebuild a kernel when you don’t have to. Just load the modules. I do this with my “whole hard drive” encryption (boot from CD or USB key) and just load the modules with stock kernels. That makes updating the kernels and the crypto boot system vastly easier and much less error prone.
“If anyone is looking for a way to encrypt the partition using TrueCrypt instead, stay tuned since another tutorial explaining how to do this will be published soon, of course on PolishLinux.org.”
We await your post with bated breath . . . please do explain how to do this with TrueCrypt.
I am curious, doesn’t automounting an encrypted /home or other partition defeat the purpose of encrypting it?
I am just trying to decide does it then fall back to the login system as the primary means of security? If thats the case can we not just assume that the fact that a tiny minority of people use Linux makes it secure enough?
I am not against encryption, rather I prefer to run fully encrypted systems whenever I can, but I think that the automounting or key based decryption nullifies any benefit of the encryption. Please explain to me how I am wrong.
Mr Tex: of course auto-mounting encrypted partitions based on keys that are located on the same hard drive makes hardly any sense. If the key was on an USB stick then it starts to make some sense (a thief would have to steal both your laptop and the stick which is likely but it may not be the case).
The approach described in the article sacrifies some security for convenience. The thing that keeps the thief from decrypting the partition is the user password (the one he uses when logging in). This is a reasonable compromise for a “normal user” I guess. From a corporate laptop I would probably require better security — for instance disable auto-mounting, set another pass-phrase for the encrypted partition, use an external key and so on.
Randomize the raw partition _before_ creating a luks device, and definitely before creating a filesystem. It’s a lot quicker. luksformat will use the first 512 bytes or so of the raw partition and leave the rest for the mapped device as untouched randomness.
When you cat the mapped device it will be different randomness. Doesn’t matter. Now create your ext3 filesystem on the mapped device.
is it possible to do the same for LVM partition ?
michuk sayd:
The thing that keeps the thief from decrypting the partition is the user password (the one he uses when logging in). This is a reasonable compromise for a “normal user” I guess.
This is the only thing which makes sense when using software suspend since the difficulty of breaking into a box from after
suspend is to break the screen saver. Even if the HD is encrypted, it will not protect you since you cannot unmount /home during suspend.
Tex: I setup my system as follows –
/dev/sda - 4 partitions
boot — unencrypted
root — encrypted, password unlock
swap — encrypted, random key on bootup
home — encrypted, key unlock
/dev/md0 — encrypted, key unlock
home and md0 both unlock from keys. These keys are stored in /etc and backed up to an encrypted usb (password unlock). On bootup, I enter the password that unlocks my root partition, and boot continues unlocking the rest of the volumes. I feel this is a safe use of keys that doesn’t require USB.
Nice intro to DM-crypt, thanks.
The command cat /dev/urandom > /dev/mapper/home didn’t work for me though, instead I had to use:
dd if=/dev/urandom of=/dev/mapper/home
Still haven’t figured out why after mounting the encrypted partition as a regular user it still belongs to root, thus making it read-only for the user.
So I have to take the extra step of doing a “chown userX.userX /mnt/blah” after mounting it.
LUKS/dm-crypt appears to be supported in windows as well.
The windows project is:
http://www.freeotfe.org/
michuk said:
“The thing that keeps the thief from decrypting the partition is the user password (the one he uses when logging in). This is a reasonable compromise for a “normal user” I guess.”
But why would anyone encrypt the partition then? To get the user, or even the root password is as easy as inserting a livecd in your drive, it’s almost no effort. If someone wanted to look at the unencrypted disk, he would do so too anyway.
Small errors…
“volume * crypt - /dev/hdc6/home /mnt/home fstype=ext2,async,nodev,fsck - -”
should be:
volume * crypt - /dev/hdc6 /mnt/home fstype=ext2,async,nodev,fsck - -
“Eventually, open /etc/pam.d/login and right after the line:”
Should also be /etc/pam.d/gdm (if you’re such inclined)
“Next, you have to edit /etc/pam.d/pam_mount. Check if there are following lines (if not, add them):”
This should be /etc/pam.d/common-pammount.
Very helpful article, however, except for the slight mistakes, which made everything take a little longer…
Thank You very much for your howto.
Now I have Encrypted home partition
By Obe.
Here is another couple of good tutorials about encrypting filesystems over partitions and files:
How to create a portable encrypted file system on a loop file
How to create a LVM encrypted partition
I had to add the @include common-pammount to /etc/pam.d/kdm so that it worked with kde otherwise it only worked when i did console logins
i also used the /dev/disk/by-id device as i’m using this on an sd card on an eee
Under the section:
Mapping the drive and creating a filesystem.
The command:
root@host:~# cryptsetup luksOpen /dev/hdc6
resulted in the usage notes and the error:
cryptsetup: luksOpen: requires as arguments
The solution was the command:
root@host:~# cryptsetup luksOpen /dev/hdc6 home
I am using openSUSE 10.3 on an IBM ThinkPad A22m
A somehow more straight forward solution for Gentoo linux can be found on http://thewinningmove.blogspot.com/2008/04/encrypting-root-swap-partitions-on.html
It works for my IBM T43, but not for T60. Anyway.
How about ZFS and its ZFS on disk encryption support
http://opensolaris.org/os/project/zfs-crypto/
Maybe I should do a howto on it ?