I've always wanted to have my personal data stored in a secure way. Using gpg would of course be possible, but cumbersome. Simply encrypting the home partition would have the (slight) disadvantage of having to type an additional passphrase. In this HOWTO I will show you how to solve this problem in an elegant way, that is without requiring an additional password at login.

This is my first HOWTO, so please don't kill me if something's not explained clearly. During the last year I did this whole thing four times, so I should have some experience with it. Nonetheless, I cannot guarantee that every single line is correct. That being said, I don't think there are that many errors in it.

Of course, any feedback is appreciated.

2. Overview

Since I didn't want to repartition I decided to use a file as encrypted loopback device. In the newer 2.6 kernels cryptoloop is deprecated in favour of dm-crypt. Therefore (and because I don't like to change my setup every few weeks) I'm using the cryptsetup utility to setup a device mapper-based encryption (dm-crypt). The problem is of course the automatic mounting.

Fortunately, there is the pam_mount module for PAM. At login the password is acquired by PAM which then sends it to pam_mount. Thereafter pam_mount uses this password to do the actual mounting. In fact, the login password isn't used directly since this would make it impossible to change the password at a later time. (The encryption key of the encrypted home cannot be changed.)
Therefore a master key, which is used to encrypt the home directory, is created and stored in a secure way on the harddisk. More information on how this works can be found at the pam_mount homepage.

Remark
After doing all the work I noticed that some scripts that come with pam_mount could be useful and automate some of the steps that I will present. However I didn't test these scripts. But I don't think Gentoo users will object to the manual (and more flexible) way in which the encryption will be set up in this HOWTO.

3. Installing the necessary software

First you'll have to compile your kernel with support for the device-mapper, the crypt target and some cipher modules. Details can be found in many other HOWTOs (e.g. this one), so I'll skip to the setup of pam_mount.

The pam_mount module is not yet in portage. Download the latest .tar.gz (see Bug 24213) containing the ebuild for 0.9.25 and additional files. Unpack it to /usr/local/portage/sys-libs/, activate portage overlay (uncomment the line in /etc/make.conf) and emerge it:

Code:

emerge pam_mount

You'll have to edit your PAM-configuration to use pam_mount. In this example I'll only consider console and KDM logins.

# /etc/pam.d/kde
# replace the next line by the one with pam_stack:
#auth include system-auth
auth required /lib/security/pam_stack.so service=system-auth
auth required pam_nologin.so
# add the following line:
auth optional /lib/security/pam_mount.so use_first_pass

Since we won't have to type the master password it can (and should) be random data. A nice way to create it is the following:

Code:

KEY=`tr -cd [:graph:] < /dev/urandom | head -c 79`

This way, all non-graphical ASCII characters are discarded, leaving 94 possibilities left. In this example the keyspace corresponds to 512 bits. (512 * log(2) / log(94) = 78.1 digits to base 94)
cryptsetup will hash it to create a 256 bit key that can be used by AES. This method has the advantage that the key is plain ASCII which could be crucial in an emergency situation. Furthermore there won't be any problems with programs which cannot cope with full binary passwords.

In the next step we'll create the block device /dev/mapper/frodo and format it.

In the loop-AES README there are warnings against using a journaling filesystem on a loop-AES-encrypted file. I don't know if this also applies to dm-crypt on a loop device. If somebody could inform me about this I'd be very happy.

Now, we'll encrypt the master key and store it on the hard disk. Use your login password!

Code:

echo $KEY | openssl aes-256-ecb > /home/frodo.key

To make it possible for the user to change his password later on, we'll have to create a backup file and set the correct permissions:

Theoretically, the automatic mounting should work right now. Close all your sessions as frodo, switch to a VT and relogin as frodo. There should be quite a few informational messages but no errors. (As root you can try to copy some files to /home/frodo2 and delete them again.) If everything works fine, we'll move all the data to the new home directory.

Only, after doing all the work I described above, I noticed that there came
some useful scripts with pam_mount:

mkehd could be used to setup an eencrypted home directory

mountehd and autoehd to mount an ehd.

I don't have any experience with them and I leave it to the reader to see if those scripts are useful and work with dm-crypt-based encryption.

The method I've presented has maximal flexibility since everything is done manually. For example, contrary to mkehd, the master key in my setup is plain ASCII, which could be useful sometimes.

Do not forget your regular backups (you do make backups, right?) since an encrypted filesystem might be a bit more fragile when it comes to crashes or power failure etc.

9. How secure is this?

Disclaimer: Although I'm interested in cryptography, I'm by no means an expert!

The block encryption algorithm itself, which in my case is AES, should be as secure as it can possibly get. The big problem is how to design a secure system around this block cipher. Therefore I'll give you some important information that you should be aware of when using this setup. Since the goal of this setup is to guard against theft (or seizure) of your computer, I won't consider online attacks or (hard- or software) keyloggers and so on.
The details on much of the following can be found on Clemens Fruhwirth's excellent page about Linux hard disk encryption settings.

If your login password is weak, you're screwed.

Since it's very difficult to reliably delete a file in your system (especially for journaling filesystems, cf. info shred) an old version of your encrypted master key could still be recovered after you've used passwdehd. Linux Unified Key Setup (LUKS) is designed to avoid this vulnerability by always storing the key(s) in a fixed position at the start of the partition. At this point, I don't know if and how it can be used in combination with pam_mount. I'll investigate this later.

The "plain" IV generation that is used implicitly by cryptsetup when setting up the mapping is very weak and has some shortcomings. For example, it doesn't prevent watermarking. In other words, a specially crafted file that you're lured into storing on your partition would create patterns that are recognizable when analysing the encrypted partition. (However, this does not imply that your data could be decrypted.)
A better choice for IV generation has been introduced in Linux 2.6.10: ESSIV. (e.g. use "aes-cbc-essiv:sha256" as cipher when calling cryptsetup. More info on the dm-crypt homepage.)

Your home directory is not the only place where user information can be found:

Your swap could contain anything that you've worked on and should be encrypted.

For complete security it's also necessary to have an encrypted /tmp, or better make it tmpfs. Of course, to be secure this requires that swap is encrypted!

It's also necessary to take care of /var (especially /var/tmp and /var/spool).

Don't forget that slocate could leak all of your filenames...

To sum up, if your password is reasonably strong, the encrypted data should be quite safe.

still a prob : it will be wizer to encrypt the /home instead of /home/anUser

cause this will require to split ur hard disk or make static file size for each user and slipting the disk space btw users isnt wize : while /home allow more flexibility all the users can have all the space that remain on the /home device will .

Supose u have 3 users
can we make a BIG BIG key and plit it into 3 halves. mounting the encrypted can be done with any of the 3 litle keys since we are linux and file perm (rxw------) sharing and mounting the same home wont be a big prob. but the prob is users key leackage where u loose the benefit of a crypto fs

if u wanted a bit more privacy add a crypted file into ur crypted home mount /dev/maper/WHATEVER ~/mini-sec/ ...blalbla

be SURE to use the same password so it appear clear cause aes_crypt(...)=aes_decrypt(...) rolof_________________

how the hell the ram (a pice of hardware that need refreshing at its own speed [me ddr 333] to keep data can steel have data after computer shutdown ?)

That's true in a working state. But I don't know it can be done, special equipment will be needed. I read somewherelse that gov. specialists are historically 10-20 years ahead of "us". Luckily low/medium-security is good enough for most people.

cause this will require to split ur hard disk or make static file size for each user and slipting the disk space btw users isnt wize : while /home allow more flexibility all the users can have all the space that remain on the /home device will .

This is a deliberate choice: when user A is logged in, there's no need (in fact it's a security problem) for user B's home to be mounted too. If the system is hacked while A is logged in, only A's data will be compromised. Furthermore, nothing bad can happen to a filesystem when it's not mounted. Of course, you're free to do it as you like.

cause this will require to split ur hard disk or make static file size for each user and slipting the disk space btw users isnt wize : while /home allow more flexibility all the users can have all the space that remain on the /home device will .

This is a deliberate choice: when user A is logged in, there's no need (in fact it's a security problem) for user B's home to be mounted too. If the system is hacked while A is logged in, only A's data will be compromised. Furthermore, nothing bad can happen to a filesystem when it's not mounted. Of course, you're free to do it as you like.

whamo i was looking for a speel checker for my firefox but i didnt find any.

LVM2 sound interesting . however if u are loged in or u leave the screensaver on . if u get hacked while ur nice home is mounted ur file are owed buy the hackers =that will then easly find passwords of others users .....

that means if FBI are againts u would better improve ur brain memory to remebre the binary content of ur porn movies,mp3z ..... so u dont need to store then on ur 120GB Hard Disk

+ if u want to setup scripts to miror or backu ur nice 5GB home

that will be a major pain in the ass to tells cron to use password .... and_________________

Last edited by linux_girl on Sun Feb 27, 2005 1:09 pm; edited 1 time in total

how the hell the ram (a pice of hardware that need refreshing at its own speed [me ddr 333] to keep data can steel have data after computer shutdown ?)

That's true in a working state. But I don't know it can be done, special equipment will be needed. I read somewherelse that gov. specialists are historically 10-20 years ahead of "us". Luckily low/medium-security is good enough for most people.

10-20 ahead us that will cost $$$ to develop. knowing that they cant sell this nice teck pice . whil e druging the hacker to reveal the password or using a cluster to brut force will be the hell lot cheaper isnt ???_________________

to simply mount an encrypted partiton using cryptsetup with the login password.

storeing the encryption key of the partiton as an encrpyted file reduces the strength of the encrpyion significantly, why have a random key, when the random key is encrypted with a non random login password.

Is there a way to increase the size of a loopback filesystem file after it's been created and used? Say I make one for a user and it gets almost full. Can I increase the size of the loopback image without copying the data into a new, larger loopback image?

Is there a way to increase the size of a loopback filesystem file after it's been created and used?

Well, I've never tried it, but it should be possible. Files, dm-crypt mappings and filesystems are all resizable. The only "difficulty" should be the order of the commands. I didn't test the following commands. Please don't try them on your real home. Use a test file instead. You have been warned.

Here's what I would try. (Of course, frodo should be logged out, the filesystem unmounted and the mapping removed.)

Now you should be able to log in as frodo and enjoy your enlarged home.

Please post your results.

BTW can loop devices be resized? (That is, without removing the loop device first.) I don't think so, but it would allow to do the resizing while the filesystem is mounted: cryptsetup resize can safely be used, and some filesystems (e.g. Reiserfs, XFS) can be resized while they're mounted.
(For dm-crypt over LVM this is possible!)

7. `e2fsck -f /dev/mapper/whatever` it (if you don't, the next command will tell you to).
8. `resize2fs` (no parameters).

9. `mount` it.

10. That's it!

I tried creating a 1 GB AES-encrypted image with a simple, cryptsetup-prompted password, and filling it with ~180 MB of data. Then I unmounted and un-cryptsetup'ed and un-losetup'ed it. Then I increased the file to 2 GB, then losetup'ed and cryptsetup'ed, then e2fsck'ed and resize2fs'ed and mounted, and all the data was there. I've since added more to it, and it's working perfectly. I'm using the image as a home directory for a user (made the user and his homedir first, then logged out and copied files into the image, deleted homedir, mounted image as homedir).

Your `dd if=/dev/urandom bs=1M count=500 >> /home/frodo_home ` command looks great, and I will have to test it. If it works, it is much better, because it's much less likely that a typo or an early-return-hit would do damage.

This should do the job. If the last two parameters aren't specified pam_mount will use the login password.

qwijibow wrote:

storeing the encryption key of the partiton as an encrpyted file reduces the strength of the encrpyion significantly, why have a random key, when the random key is encrypted with a non random login password.

You're right that this reduces the security to the strength of the password. The random password just makes sure that in every case the login password is the weakest link. You're free to store the key on a USB key instead of your hard disk. The reason for using a master key is to allow changing the login password (and not that it magically increases security).

I just tried this, and it does indeed work fine. It's better in one way, because you don't have to calculate how far to seek with dd. However, if you left off one of the >'s, it'd overwrite the file instead of add on to it. Neither way is typo-proof, but they both work.

I read your how to and I think I found what I'm looking for, but I want you ask some question:

If I gain access to the machine ( e.s. with a live cd) and I stole the encrypted file with the home page of frodo user (/home/frodo_home) and the key file of the user (/home/frodo.key) I will be able to mount on another machine the file?

In any case I search for a solution to crypt some directory installed on customers server (php apache postgres), the customer don't have console or remote access to the machine but can use live cd or open the box to stole the information. The dm-crypt is a sollution but the boot password is a big problem for a server on 24/7.

If I gain access to the machine ( e.s. with a live cd) and I stole the encrypted file with the home page of frodo user (/home/frodo_home) and the key file of the user (/home/frodo.key) I will be able to mount on another machine the file?

Only if you know the password. The key file (frodo.key) is encrypted with the user's login password. (Using openssl with a cipher of your choice.) This makes automatic mounting by pam_mount possible, since normally the user does provide his login password, but with this method it's only required once.

SilentShadow wrote:

In any case I search for a solution to crypt some directory installed on customers server (php apache postgres), the customer don't have console or remote access to the machine but can use live cd or open the box to stole the information. The dm-crypt is a sollution but the boot password is a big problem for a server on 24/7.

There is no boot password involved so I don't quite understand what you mean. In any case, when the machine is turned off it should be impossible to recover the encrypted data without the password. (Provided swap is encrypted etc.)
When the machine is running you'd have to acquire sufficient permissions to access the home directory.