I want to have a full system encryption on my laptop. But I have two users, one for home and one for work and want a separate encryption for both. Sure I could do a full disk encryption with dm-crypt and use a second encryption layer with ecryptfs to encrypt the home directories. However this seems not to be a good idea for performance reasons. So how can I setup a system such that:

the entire hard drive is encrypted

when user 1 is logged in and user 2 not, the data of user 2 is encrypted for user 1 and vice versa

I need to type in one password on boot which decrypts the system (like in a usual LVM/dm-crypt setup) and only a second one which logs in user x and decrypts his partition

the performance is similar to a simple full disk-encryption

the solution should work together with an ssd i.e. it should support TRIM

2 Answers
2

Don't encrypt the whole hard drive (as in /dev/sda, do it per partition (or more precisely per file system - see below).

Have separate file systems mounted at homes for the two users. I'm intentionally avoiding writing separate partitions, since while that is the usual way of doing things, it is constraining in some aspects. It might be more convenient to have one large home partition, which holds big files that contain the encrypted file systems and are mounted as necessary. The advantage is easier resizing of users' homes while keeping them separated.

Automounts on login are possible through PAM. Note that you don't want to use the same password for login and for the actual data encryption. Instead, you either use LUKS or imitate it by storing the encryption key in a file that itself is encrypted with the login password. That ensures that a change of the login password won't affect the encrypted data but only the encrypted key and thus yo won't have to take care of re-encrypting whole users home).

General instructions:

partitioning use gdisk (also known as gptfdisk sometimes), parted or any other appropriate program, read man pages for details (partitioning is a bit out of scope of this QA)

encrypted file-based file systems - I have some objections to the design of LUKS, so I'm generally using cryptsetup in the "plain" mode, which imitates LUKS in some aspects. If you choose LUKS, than you can just reduce the steps to the cryptsetup (with appropriately modified options)

prepare the encryption key and password. This is an interesting part - for encrypting the data you want something with enough randomness (8 letter password really isn't enough) and for password something that you can change easily (without needing to re-encrypt the whole filesystem) and is reasonably easy to remember and type in. These requirements go quite against each other. Hence we'll use the same trick that LUKS does (and which can actually be considered a variation of a hybrid cryptosystem in some sense)). The encryption key can be more or less random - either use some really random data (e.g. from /dev/random), or a reasonably long hash like SHA-2 or SHA-3 (the first one was designed by NSA, if you wonder whether to use it or not in light of the recent events) of a reasonably long passphrase.

Reasonably long in the first case (and in the case of really random data) means, that the length should be about the chosen key length for the cipher used plus the length of the initialization vector. In the second case it means that it should be difficult to brute-force it. Using a hash has the advantage of being able to recover the key if it gets damaged or lost (provided you remember the initial passphrase that was hashed, of course). This key is then encrypted and stored in a file. The passphrase for the encrypted key in your case will be the same ass the login password.

openssl dgst -sha512 -binary produces binary form of the SHA-512 hash from its standard input, openssl enc -bf encrypts it using Blowfish - feel free to choose hash and cipher to your liking (Twofish or Rijndael are both rather well-tried, but other ciphers available in the kernel should be fine too).

Keeping the key outside of the encrypted device has a disadvantage of needing additional thing apart from the encrypted data itself - LUKS stores the key in its headers, so it's self-contained. On the other hand you are bound to a particular set of tools. While it is not designed carelessly and is present on most installations, you need the special tools to access it.

With a separate file on the other hand, you are free to choose any method of storing the key. You can even put it on removable media, insert it before login and remove it once the file system is mounted (you could probably even hook automatic login on the event of attaching the media to the computer). Of course all this should be well thought through since the security maxim "Do not invent your own crypto" applies (see e.g. this post on Security SE) - which might actually be an argument for using LUKS. Backing up the key is obviously easy.

openssl enc -bf -d asks for password on stdin and tries to decrypt the encryption key. cryptsetup create ... encryptedfs /path/to/backing_file.enc created encrypted DM device called encryptedfs backed by the previously created file. Important option it the -c which selects the encryption cipher and its mode of operation

fill the device with zeros - this effectively puts "random garbage" into the backing file and makes it less obvious, what the contents of the file might be (otherwise, you could tell where things have been written by scanning for blocks that are not zeroed from step 2).

dd if=/dev/zero of=/dev/mapper/encryptedfs bs=1M

Create a filesystem

mkfs.[favourite_filesystem] [tuning options] /dev/mapper/encryptedfs

Put a corresponding line into /etc/fstab in case you want to do everything on your own, or into /etc/crypttab if you want some sort of integration with system tools.

Thanks, can you add the details how to actually set this up?
–
studentOct 3 '13 at 7:36

Thanks for the details. Does this solution works together with TRIM for ssd's? Are there any performance issues to keep in mind compared to encrypt a separate fixed partition with dm-crypt?
–
studentOct 6 '13 at 8:12

Performance wise it should be negligible, especially when you create the backing files on an empty (or mostly empty) partition on a reasonable filesystem which will try to keep file's blocks together. As far as SSD trimming is concerned I haven't got a clue, but given the black magic the SSD firmware is doing these days, I wouldn't be overly concerned - it's so many levels above the physical flash, that I personally wouldn't expect too much additional degradation. A lot depends on the SSD's firmware, I guess.
–
peterphOct 6 '13 at 20:55

I can think of two valuable ways to achieve such a system w/o encrypting you home twice.

separate home partition: create a separate partition that gets mounted to /home. Each user then encrypts its home via encfs.

separate home partition for each user: every user gets a separate partition for his home which is itself encrypted using dm-crypt. This partition then gets mounted to /home/user when he logs in.

Of course, plus encryption of / ;-)

In both cases the homes can be automatically mounted during the login process if you use the same password for login and encryption. (can be configured in e.g. /etc/security/pam_mount.conf.xml, there are plenty of howtos)
While the first method doesn't encrypt the names of the folders of your users, using the second method really everything gets encrypted. So I'd prefer (and actually use) method two ;-)