Linux boot loaders supporting full disk encryption?
Are there any Linux boot loaders supporting full disk encryption (a la TrueCrypt). I know there was work towards adding encryption support to GRUB2, but this does not seem to be ready yet. Any other options?
(Note that I am really referring to full disk encryption here—including /boot)
Most of the answers describe a setup where /boot is not encrypted, and some of them try to explain why an unencrypted /boot should be OK.
Without getting into a discussion on why I actually need /boot to be encrypted, here is an article that describes exactly what I need, based on a modified version of GRUB2:
The problem with this is that these modifications apparently are not supported in the current GRUB2 codebase (or maybe I am overlooking something).
I believe most of them do, what you need is instruction on how to install the OS with encrypted HD in the first place.
Ubuntu has a nice page with instructions on making encrypted partitions, LMVPs, folders etc, just google your distros version of that…
Make your Initial RAMdisk, and /boot folder not use encryption.
This will bring up a “minimal” kernel, with drivers and support to switch to the “actual” root filesystem which is encrypted.
Before you claim “this is a hack” – remember – most (if not all) Linux distros boot this way today by default. This explicitly allows your system to boot and load your root FS, using modules that it needs to load from a filesystem. (Sort of a chicken-and-egg problem). Like for example, if your root filesystem was on a hardware RAID volume, and you needed to load it’s driver before you could mount your root FS.
No, I think there are not.
Do you really need to encrypt /boot? I suspect not. The rest of the filesystem can be encrypted by normal Linux software which resides on an initramfs in /boot and prompts the user accordingly.
You seem to be asking for something that is impossible to do and comparing it to a Windows solution which hides the implementation from you but in reality is doing the same thing Linux is doing.
The closest solution that I can think of is to use a hard drive which implements a security password and encryption. Some of the Thinkpad laptops use these hardware solutions.
I reviewed the link you posted – although there is no boot partition, there is still an unencrypted boot loader on the hard disk which could be accessed and compromised using an evil maid attack. I’ve been looking into a similar setup, in which there is no unencrypted data on the hard disk, but so far I’ve only come up with running a boot loader from a removable drive.
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
/bootpartition 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
The answer is hinted at by the article. “This is now possible with extensions to the next generation GRUB2 bootloader, which has been patched to support not only” and “we wish to install our new luks enabled grub2 image later on” and “Now we compile the LUKS-enabled GRUB2 source.” It seems there is an patch or extension you need to get and include with GRUB2, or a forked GRUB2 source.
Grub2 version 2.02~beta3 can do a lot things that Grub2 version 2.02~beta2 can not do, tested by me:
- Boot using Super Grub 2 disk
- Type ‘c’ key to go to command line
- Type commands to mount encrypted partition i want
- insmod luks
- cryptomount (hd0,#) // where # represents the encrypted partition
- Type the passphrase and type some commands more
- multiboot (crypto0)/grub/i386-pc/core.img
- boot
That will load another Grub2 that is inside an encrypted partition, an evil mad attack has no sence in here… i am booting from a CD (read only medium), then mounting an encrypted partition (with not the passphrase how dare can anyone inject anything!), then booting from inside encrypted partition and loading a Grub2 with its own menu, etc.
Note: Such Grub 2.02~beta3 boot (i use Super Grub 2 cd) can be on a USB stick, USB HDD, etc.
Warning: Grub2 version 2.02~beta2 can not do the same since has some BUGs (that seem to be fixed on Grub2 version 2.02~beta3) related to command cryptomount…
beta2 bugs, i talk about, are:
- It does not really mount the encrypted partition, so it does not let you access (crypto0)/*
- If there is more than one encrypted partition, using
cryptomount -aonly asks for one passphrase - After running cryptomount one time it it is runned again does nothing
on beta 3:
- It really mounts encrypted partition and let you access files through (crypto0)/* or (crypto1)/* etc if more than one mounted at same time
- It asks for each passphrase (one per encrypted partition)
- It allow you to run it as many times as you need, you can mount one, then another, etc.
Side note: I did not figure how to unmount them, except reboot or boot another or same grub2 / other bootloader, etc.
Hope this helps to clarify things, and hope Grub2 version 2.02~beta3 will be integrated on LiveCDs so all we can install it without need to compile it by our selfs.
P.D.: With Super Grub 2 disk i can not see any way to install Grub2 version 2.02~beta3 onto the MBR /boot partition etc.