How do I use dm-crypt (LUKS) with GnuPG to use two-factor for FDE?

Question

When using full disk encryption with Ubuntu (opposed to homedir encryption), dm-crypt with LUKS is used for encrypting the volume. In the installer (at least on 12.04 alternate) you can choose between setting it up using a passphrase or a keyfile. I'd like to use a combination of the two; not either, but require both.

Why? Because this enhances security (two-factor); you'll need to have something and you need to know something to unlock it. Then I want to put the keyfile on a small removable storage device (USB flash drive) and only plug it in during boot time. The result should be that it is required to put in the right flash drive and provide the right passphrase to unlock the root partition.

So, put in other words, I want to be asked during boot for the passphrase to which the keyfile on an external drive is encrypted.

I see a /usr/share/initramfs-tools/hooks/cryptgnupg helper script that may help to accomplish it, but I have no clue how to use it.

_{Just to avoid confusion: I am not asking for a way to add an additional key to the volume to unlock it.}

Solution

I do the same thing, however I'm afraid my answer won't be satisfactory, as for various reasons I went with a completely custom Initramfs.

Instead of GnuPG, which is an extra binary that has to be included in the Initramfs (and in case of GnuPG-2, a rather complex one), I simply used what's already there. And that's obviously dm-crypt/LUKS.

So suppose you have a keyfile. Preferably one with random data.

# dd if=/dev/urandom of=keyfile count=1
1+0 records in
1+0 records out
512 bytes (512 B) copied, 0.000189802 s, 2.7 MB/s

Add encryption for it with LUKS (feel free to add your cipher settings of choice).

# truncate -s 2M keyfile.luks
# cryptsetup luksFormat keyfile --header keyfile.luks

WARNING!
========
This will overwrite data on keyfile.luks irrevocably.

Are you sure? (Type uppercase yes): YES
Enter passphrase: bananas
Verify passphrase: bananas

Now you have a keyfile (512 byte) and a keyfile.luks (2MB, which cryptsetup for some reason needs to write the 192k LUKS header). Since the Initramfs will be compressed anyway, that is not too bad (still smaller than GnuPG).

Now you can decrypt the keyfile:

# cryptsetup luksOpen keyfile --header keyfile.luks lukskey
Enter passphrase for keyfile: bananas

And you have 512 byte of random data in /dev/mapper/lukskey. (You may write to it if you want to change it, so we could have initialized the file with zeroes earlier.)

# blockdev --getsize64 /dev/mapper/lukskey
512

In Initramfs init you could then proceed to open the real LUKS volume with it (assuming you added the key first).

cryptsetup --key-file=/dev/mapper/lukskey luksOpen /dev/yourdisk luksyourdisk
cryptsetup luksClose lukskey # clean up

This approach makes GnuPG entirely superfluous, plus you get all LUKS advantages, such as multiple passphrases for the key, cipher of your choice, et cetera. Not to mention a nice (mostly regular) password prompt with multiple retries.

Comments

[gertvdijk]

I've found one part of the answer myself by... reading the docs. Read up on how to use this in /usr/share/doc/cryptsetup/README.gnupg. I'll try to find some time on changing it to make it use a keyfile from external media.

[gertvdijk]

Cool solution, but how do I integrate this in my initramfs exactly? You state that you use a completely custom initramfs, but wouldn't this be possible just by using a hook?

[frostschutz]

Certainly. Maybe even without a hook if you can think of a way to coerce crypttab to find and open the key somehow first. E.g. it does not have to be a file, you could make a separate partition for it on the USB stick. However since I'm not doing that way I can't make a concrete answer for it... sorry :-/

[gertvdijk]

No problem at all - circumventing GnuPG and reusing LUKS is certainly a superior option. In case I need to rewrite hooks for the GnuPG approach, I'd better rewrite it without using it at all anyway. And yes, I am aware this does not have to be a file.

[frostschutz]

@gertvdijk if you get this going, I'd be interested in your answer for future reference