LUKS Encryption – Storing Keyfile in Encrypted USB Drive

cryptsetupencryptionluks

I already asked once about LUKS unlocking of multiple HDDs in Linux: LUKS and multiple hard drives.

Now I would like to know how to secure store the keyfile used for the automatic unlock of the associated partitions.

My plan is (if possible):

Encrypt a small USB drive with LUKS that requires a passphrase
Unlock it at boot as the first drive by using the passphrase
Mount it to a given mount point, for instance /test (is this possible ?)
Now the keyfile can be safely read: /test/keyfile
Use the keyfile to unlock other drives without needing to ask password for them
LuksClose the USB drive in order to assure a certain degree of safety as soon as other drives have been unlocked
Automount /, /usr, /var and other mount-points as usual

Can this work? Basically I store the LUKS keyfile on a password-encrypted LUKS USB drive that only asks for passphrase once, while all other drives can be unlocked without further action. I'm not sure if there is some way to make the USB drive be unlocked first, then be mounted and only then the other drives try to access the keyfile. Furthermore in what concerns automation I suppose /etc/fstab and /etc/crypttab should be accessible BEFORE the other drives can be mounted, but this is not possible if the whole / file system is LUKS encrypted.

Unless there is the possibility of fully manually configure how LUKS works:

LuksOpen /dev/sdc1 usb_keyfile
mount /dev/mapper/usb_keyfile /keyfile (is this possible ?)
LuksOpen –keyfile /keyfile/key /dev/sda1 disk1
LuksOpen –keyfile /keyfile/key /dev/sdb1 disk2
LuksClose /dev/sdc1

Basically being able to run a shell script just after the required modules have been loaded and disable automatic LUKS password prompt.

Additionnal details

Distribution used: Gentoo GNU/Linux (amd64) or Debian GNU/Linux (amd64) because I'd like to apply this procedure to multiple installations

Best Answer

Your approach looks good. Some remarks though:

If you want to encrypt rootfs, you'll need to use initrd (to have some minimal unencrypted system that will process the encrypted partitions).

If the USB device is removable, both initrd and kernel can be stored on the USB to heighten tamper resistance (supposing you make sure the USB won't get into unauthorized hands) - which is usually why one encrypts rootfs. Once both kernel and initrd are on a removable media, you can ensure that nobody changes the kernel (or initrd) from the running system by simply removing the media.

This is of course not an option if you want to have it inside of a server, but then again the question stands whether it makes sense to have such a device at all and not to use a small partition on one of the hard-drives. If for example all drives in the machine are in RAID, one would probably want to put rootfs on the USB as well. An interesting alternative to an internally connected USB flash device could be a CompactFlash card attached to ATA interface through an adapter, by the way.

Some distributions offer prepared solutions for encrypted root, some don't - but mostly it's question of putting a couple of lines into initrd script before it tries to mount the "real" root (see for example man pages for pivot_root, usually in sections 2 (syscall) and 8 (bonary), if you're not familiar with the process).
remember to backup the keys and passphrases in case your USB drive dies. LUKS follows rather one-sided approach when it comes to damaging its header - once a single sector of its header (key-slot to be more precise) dies, you are unable to mount it. This is to make sure that erasing the header isn't effectively thwarted by block reallocation performed by the device itself (because that's what flash-memory based devices do a lot) - the key is spread over the whole key slot and one needs all of the data to reconstruct it - there is no redundancy. See Clemens Fruwirth's website for deeper discussion.

That said, maybe a simple encrypted device on the USB would be enough (check section PLAIN MODE in man cryptsetup). Or a file encrypted with e.g. openssl enc. The former might actually be an option even for the encrypted partitions themselves.

Related Solutions

Linux: LUKS and multiple hard drives

You can use /lib/cryptsetup/scripts/decrypt_derived in your crypttab to automatically use the key from one disk for another.

The decrypt_derived script is part of Debian's cryptsetup package.

Small example to add the key from sda6crypt to sda5:

/lib/cryptsetup/scripts/decrypt_derived sda6crypt > /path/to/mykeyfile
cryptsetup luksAddKey /dev/sda5 /path/to/mykeyfile
ls -la /dev/disk/by-uuid/ | grep sda5
echo "sda5crypt UUID=<uuid> sda6crypt luks,keyscript=/lib/cryptsetup/scripts/decrypt_derived" >> /etc/crypttab
shred -u /path/to/mykeyfile # remove the keyfile

As it is nowadays very difficult to really delete a file, ensure that /path/to/mykeyfile is on a encrypted drive (sda6crypt would be in my example a good solution).

In general, you can add an additional security layer by using user space filesystem encryption e.g. via encfs.

Linux – Are there more advanced LUKS key schemes, e.g. 2 of 3 keys needed

I don't think something like this exists right out of the box, but it should be possible. I'll put together some references for you.

First there's /etc/crypttab - typically you specify a key file or password in the third slot, but some distros allow you to specify an option in the fourth field called keyscript (debian and opensuse support this: http://linux.frank4dd.com/en/man5/crypttab.htm). This script (which must be in "/lib/cryptsetup/scripts" iirc) can use the third field (what would normally be just the keyfile or password) as an argument. The keyscript's job is to send the actual decryption key to stdout, which cryptsetup then uses as the luks key in the normal fashion.

Second is that you will likely need to write the keyscript. netkeyscript (in github) is an example of a keyscript that listens on a UDP multicast socket for the password; here is another more detailed example of a custom key script, complete with an implementation in sh: http://wejn.org/how-to-make-passwordless-cryptsetup.html. How you code the keyscript (which I'll just call multifactor) I leave as an exercise to you ;)

Third is the secret splitting. you can use an open source tool called "ssss" (google for "ssss-split") to split the luks password in the manner you describe. let's say you split it into 3 pieces (a,b,c) and require any 2 of them. store "a" on the usb drive, "b" in a vault, and "c" you store with the computer (unencrypted partition), or whatever. Of course you don't want "c" to be exposed, so encrypt it with a scheme of your choice using a passphrase you can remember, and call that passphrase "c0", and the encrypted "c" on your disk is "c'". Now your crypttab will look something like

root  /dev/disk/<blah blah>  /dev/<usb>:/path/to/a+$/dev/<blah>:/path/to/c'  keyscript=multifactor

what you actually will have for the third field will of course depend on what your keyscript is willing to accept

Ideally the keyscript should be able to determine that it needs your input to decrypt one or more of the keys (e.g.: c' -> c in this case), but you can use the third field to specify that as desired. In my example above, I used a leading $ to indicate that.

I'm not sure if it's possible to make the keyscript prompt for input, possibly on stderr, since any output on stdout is taken as the luks password. It would be nice if there was a sensible fallback.

Anyway, good luck and happy hacking :)

Best Answer

Related Solutions

Linux: LUKS and multiple hard drives

Linux – Are there more advanced LUKS key schemes, e.g. 2 of 3 keys needed

Related Question