Tell me more ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.
up vote 13 down vote favorite
3

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)

Update:

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).

Hope this helps to clarify the question.

share|improve this question
yes, there is an excellent howto here: wiki.archlinux.org/index.php/… – Evaggelos Balaskas Nov 14 '10 at 20:04

migrated from stackoverflow.com Jan 27 '12 at 1:30

7 Answers

up vote 8 down vote accepted

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.

However, if you are trying to encrypt the whole disk for security reasons, plese 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 has 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:

  1. decrypt at the BIOS level (in motherboard or disk adapter or external hardware [smartcard], with or without a TPM chip), or
  2. 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 USB memory, 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).

Regards, MV

share|improve this answer
1  
Decrypting at the BIOS level would be a very good solution indeed (I have considered this as an option)... – Grodriguez May 19 '11 at 15:49
I don't know any working implementation, but EFI/UEFI has the option to include a custom EFI Boot Manager to replace a common boot loader, maybe adding a decryption layer to decrypt the data (of course then you'll need an EFI platform). Or maybe some of the project related to CoreBoot (ADLO, SeaBIOS, OpenBIOS, etc.) can be modified to do that. Just ideas. – MV. May 24 '11 at 8:40
3  
Just to add more information about the weakness of using a non-encrypted /boot partition (but it also apply for an non-encrypted boot loader): twopointfouristan.wordpress.com/2011/04/17/… (how to modify the boot partition in 10 minutes of physical access, to retrieve the mount passphrase plus any other file in the encrypted partition) – MV. Jul 21 '11 at 2:16
lfde.org seems to be down :( – sampablokuper Jan 25 at 8:31
Yes, lfde.org has been down from some months (and the author blog is gone too). Pity is all the work done by the author of the LFDE project is gone, as it was all hosted in his personal website (another reason to leverage sites like SourceForge, Google Code, GitHub or similar). – MV. Jan 25 at 11:24
up vote 3 down vote

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.

share|improve this answer
Yes, there is still an unencrypted boot loader. This would be acceptable for me. – Grodriguez Apr 28 '11 at 19:00
The evil maid can infect the boot loader to do a fake password prompt to fool you, then just load the unencrypted trojanized kernel. Encrypting the kernel gains very little without encrypting the boot loader. – Skaperen Jan 27 '12 at 2:56
up vote 2 down vote

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.

share|improve this answer
up vote 1 down vote

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...

share|improve this answer
2  
Most Linux distributions, including Ubuntu, include some sort of support for encrypting partitions, but they require /boot to be unencrypted. What I'm looking for is a boot loader that can handle a completely encrypted disk. – Grodriguez Nov 14 '10 at 23:47
1  
At least some part of the bootloader needs to be unencrypted, otherwise the CPU couldn't run it. Is there any particular problem you have with leaving /boot unencrypted? – Baffe Boyois Nov 15 '10 at 4:27
2  
The boot loader and /boot are different things. I am looking for a boot loader than can boot a fully encrypted disk. TrueCrypt can do that for Windows, but not for Linux. – Grodriguez Nov 15 '10 at 7:11
The difference is that the windows bootloader is contained in the mbr itsself while on linux the mbr just links to the /boot files necessary. – J V Nov 15 '10 at 9:30
1  
"Pre-boot authentication is handled by the TrueCrypt Boot Loader, which resides in the first track of the boot drive" - aka, on windows it creates a mini-/boot. Again, grub itself is contained in /boot, the mbr is only 512 bytes, not enough to store a decryption algorithm. However it's done, a portion of the hard drive must be supplied unencrypted. You might be able to start grub on an encrypted partition from a bootloader on a completely different one but that would require some seriously messy code... – J V Nov 15 '10 at 9:43
up vote 0 down vote

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.

share|improve this answer
2  
Yes, I need to encrypt /boot. Everything must be encrypted except for the boot loader itself. – Grodriguez Nov 15 '10 at 9:59
Please explain why you believe there are no bootloaders supporting full disk encryption. – this.josh May 18 '11 at 17:58
@Grodriguez: if you consider /boot to be part of the boot loader, then everything is encrypted - all binaries used at runtime, all user data, etc – MarkR May 19 '11 at 14:00
2  
As noted in a comment on another answer: I know that there must always be "something" that is not encrypted -- I just need this "something" to be the boot loader (MBR + boot sector), instead of a /boot partition. – Grodriguez May 19 '11 at 15:48
up vote 0 down vote

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.

share|improve this answer
2  
Sorry, but I don't see why this should be "impossible". The article I link to in my question proves that it can be done. A proof of concept was implemented using a modified version of GRUB 2. I know that there must always be "something" that is not encrypted -- I just need this "something" to be the boot loader (MBR + boot sector), instead of a /boot partition. – Grodriguez Nov 15 '10 at 19:58
@Grodriguez: Your requirement makes no sense. Is your requirement met when using a virtual machine inside another OS? If so, then boot OS one, decrypt the drive and launch the VM. – Zan Lynx Nov 15 '10 at 21:14
2  
Have you actually tried to read the article I linked to? The fact that you don't understand the requirement does not mean that "it makes no sense". I have valid reasons for this (which I don't want to get into). – Grodriguez Nov 16 '10 at 7:54
The article makes it clear in paragraph 3 that it does not improve the situation. So it makes no sense to me to follow the rest of it, which focuses on how to set it up, rather than how it works. Think about what is going to tell you that I have replaced your kernel, or the whole /boot, with my own (when acting as evil maid). – Skaperen Jan 27 '12 at 3:01
up vote 0 down vote

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.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.