unlocking dm-crypt from grub - kernel in crypted volume

Hi all,

There seems to be some support for dm-crypt in grub, such that you can store the kernel in the encrypted volume, and only have grub unencrypted. This makes the attack vector a lot smaller, however, it is unclear to me if there is any development on this subject. For example passing the password in a safe way from grub to the kernel might be useful to make such a solution acceptable for end users.

Is there news on this development?

Olivier

Quite frankly, I doubt this increses security significantly.

An attacker could just manipulate the grub image and pretend to do decryption while really loading a compromised kernel. It would also be possible to patch grub so that it runs a kernel-patcher after decryption and before starting the kernel.

I think both options are not really more difficult than patching a not encrypted kernel.

The bottom line is still that if an attacker has access and then you continue to use your computer, you are screwed. Disk encryption only protects you if you know that the attacker had access, e.g. when your laptop is stolen. If you do not realize an attacker had access, anything is possible.

Arno

Arno Wagner, Dr. sc. techn., Dipl. Inform., CISSP -- Email: [email protected] 
GnuPG:  ID: 1E25338F  FP: 0C30 5782 9D93 F785 E79C  0296 797F 6B50 1E25 338F
----
Cuddly UI's are the manifestation of wishful thinking. -- Dylan Evans

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier 

from a theoretical point of view I agree with you. However, given that the attacker does not yet know which kernel is going to be started, has very limited space for attack code, and has to change something (grub) that needs to change the next thing (kernel) instead of directly changing the kernel, it's really more difficult in my opinion. It's beyond the level of a regular good C programmer I would say, while changing the kernel is something any good C programmer should be capable of.

Given that this is the most common setup (kernel in unencrypted /boot and the rest of the OS in dm-crypt volume) I think it would be worthwhile to make this setup work in a smooth way (but I can understand it is a lot of work and people don't have the time to do it).

Olivier

IMHO without full implementation of "trusted boot" this will just add some small amount of work for attacker without real security increase.
And with "trusted boot" (whatever it means) grub loader integrity should be verified before you enter passphrase.

In fact, it is just few instruction to add to grub module to store entered passphrase somewhere on disk, CMOS, flash, whatever is available for later use by attacker. (Just another variation to "Evil maid" attack.)

Anyway, LUKS implementation in GRUB2 is completely independent from upstream, so you can ask on grub devel list - they did not tried to contact upstream if there is possibility
to share some code, so it contains full LUKS reimplementation (but it is good for other reasons, though).

For kernel dm-crypt - I really do not want here things like "encrypted passphrase" or similar concepts. (Until some certification process forces me:-)

But I would like to add here concept of "passphrase handle" IOW userspace will just hand over handle (id)
to some other subsystem where the key is stored (Could be kernel keyring, some token, whatever).

Milan

And the kernel recently gained support for TRUSTED_KEYS for storing stuff sealed in a TPM.

Regards,

Yves-Alexis