Re: Keyfile Support for GRUBs LUKS

[Glenn Washburn <development@efficientek.com>]

On Wed, 20 Nov 2013 00:43:37 +0100
Ralf Ramsauer <ralf+grub@ramses-pyramidenbau.de> wrote:

> Hi,
> 
> yesterday I realised, that GRUB is already supporting LUKS and even
> simple DSA signature checking.
> 
> I was thinking about the following setup:
>   - fully encrypted harddisk (LUKS) (incl. rootfs).
>   - no bootloader on harddisk
>   - kernel + initrd inside encrypted partition
>   - optionally: signatures of the kernel + initrd

I've had this setup ever since grub had LUKS support, except for the
signature checking.  I don't really see the point of checking
signatures if the kernel and initrd are encrypted.

> For "trusted" booting, I thought about an USB stick, that just
> includes GRUB, a public key for verification and a keyfile for LUKS.
> Using that setup, no password input would be required during boot. The
> USB stick can be considered as "trusted environment".

Can you give more details on what you'd use the public key to verify?
The initrd + kernel?  I'm not sure it'll buy you much unless you're
using it in combo with hardware/firmware.

> Unfortunately, GRUB doesn't support keyfile for Luks up to now. As I'm
> quite familiar with dm-crypt and LUKS I tried to implement the keyfile
> feature to GRUB.
> After spending several hours trying to get a deeper insight into the
> GRUB internas I finally resigned, as I was missing documentation on
> several things...
> 
> I was very confused about the way how GRUB2 is handling its modules
> and about the strategies how functions are exactly called.
> The aim is to implement three additional options to cryptodisk.c resp.
> luks.c:
>  -k keyfile [e.g. (hd2,msdos3)/mysecretkey]
>  -o keyfile offset [optional, default: 0]
>  -s keyfile size [optional, default: keyfilesize]
> 
> Using LUKS, a keyfile can simply be treated like a passphrase, which
> basically is already implemented.

To open and read from a file, use grub_file_open and grub_file_read.
Look at the implementation of ./grub-core/commands/cat.c for
inspiration.  Read in the key data into global memory in
grub_cmd_cryptomount from ./grub-core/disk/cryptodisk.c.  Then in
luks_recover_key from grub-core/disk/luks.c use the keydata instead of
asking for the password if keydata exists.

This seems like one way to do it, but I'm not a grub developer, so it
might not be a method they would except patches for.  While you're at
it, it would be nice to have support for detachable luks headers. :)

Glenn

> I would appreciate, if perhaps someone of you could help me with this
> issue.
> 
> Thanks in advance!
>   Ralf
>