I think the current version of GRUB2 does not have support for loading and decrypting LUKS partitions by itself (it contains some ciphers but I think they are used only for its password support). I cannot check the experimental development branch, but there are some hints in the GRUB page that some work is planned to implement what you want to do.
Update (2015): the latest version of GRUB2 (2.00) already includes code to access LUKS and GELI encrypted partitions. (The xercestch.com link the OP provided mention the first patches for that, but they are now integrated in the latest release).
However, if you are trying to encrypt the whole disk for security reasons, please note that an unencrypted boot loader (like TrueCrypt, BitLocker or a modified GRUB) offers no more protection than an unencrypted /boot
partition (as noted by JV in a comment above). Anybody with physical access to the computer can just as easily replace it with a custom version. That is even mentioned in the article at xercestech.com you linked:
To be clear, this does not in any way make your system less vulnerable to offline attack, if an attacker were to replace your bootloader with their own, or redirect the boot process to boot their own code, your system can still be compromised.
Note that all software-based products for full disk encryption have this weakness, no matter if they use an unencrypted boot loader or an unencrypted boot/preboot partition. Even products with support for TPM (Trusted Platform Module) chips, like BitLocker, can be rooted without modifying the hardware.
A better approach would be to:
- decrypt at the BIOS level (in motherboard or disk adapter or external hardware [smartcard], with or without a TPM chip), or
- carry the PBA (preboot authorization) code (the
/boot
partition in this case) in a removable device (like a smartcard or an USB stick).
To do it the second way, you can check the Linux Full Disk Encryption (LFDE) project at: http://lfde.org/ which provides a post-install script to move the /boot
partition to an external USB drive, encrypting the key with GPG and storing it in the USB too. In that way, the weaker part of the boot pathway (the non-encrypted /boot
partition) is always with you (you will be the only one with physical access to the decrypting code AND the key). (Note: this site has been lost and the author's blog also disappeared, however you can find the old files at https://github.com/mv-code/lfde just note the last development was done 6 years ago). As a lighter alternative, you can install the unencrypted boot partition in an USB stick while installing your OS.
Regards, MV
According to initramfs-tools(8), one can add programs to the initrd image by adding e.g. the following to a hook script:
copy_exec /sbin/cryptsetup /sbin
Example hook scripts can be found in /usr/share/initramfs-tools/hooks
and on my Ubuntu system, /usr/share/initramfs-tools/hooks/cryptroot
is indeed adding /sbin/cryptsetup
to the initrd
image.
Example:
$ gzip -dc /boot/initrd.img-`uname -r` | cpio -tv 2>/dev/null | grep cryptsetup
=> No cryptsetup included, yet.
$ cat /etc/initramfs-tools/hooks/fde
#!/bin/sh
. /usr/share/initramfs-tools/hook-functions
copy_exec /sbin/cryptsetup /sbin
$ sudo chmod 0755 /etc/initramfs-tools/hooks/fde
$ sudo update-initramfs -u
$ gzip -dc /boot/initrd.img-`uname -r` | cpio -tv 2>/dev/null | grep cryptsetup
-rwxr-xr-x 1 root root 59248 Aug 21 04:04 sbin/cryptsetup
-rw-r--r-- 1 root root 158848 Aug 21 04:04 lib/x86_64-linux-gnu/libcryptsetup.so.4
Best Answer
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 asgptfdisk
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 thecryptsetup
(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.
create an empty file that will hold the file system
create the encrypted device
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 calledencryptedfs
backed by the previously created file. Important option it the-c
which selects the encryption cipher and its mode of operationfill 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).
Create a filesystem
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.for automatic (un)mounting on login/logout, I'll refer you to the pam_mount documentation.