LUKS storing keyfile in encrypted usb drive

Question

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

Solution

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.

Comments

[Admin]

I don't see why this wouldn't be possible. It may be somewhat involved if you want an encrypted root partition, but it's not like there is any magic happening even before / gets mounted. One critical piece of information that's missing for your question to be properly answerable though is what distribution are you using?.

[Admin]

@MichaelKjörling: updated my question. I don't think the solution is forcefully distribution-dependend since I could adapt it anyway. I'd like to know how (if possible) you'd implement such a solution (on Gentoo, Debian, Ubuntu or even RHEL/Centos). I could always try to adapt it to my distribution in a second time.

[Vignesh]

I already plan to use initrd. Not sure what you mean by putting it and the kernel on the USB though and how that would improve security. Initrd and kernel image should reside on /boot (and I could put that onto the USB) which is unencrypted. The USB drive is permanently attached to the server (from the inside through an internal USB header adapter). Can you elaborate please?

[peterph]

Both initrd and kernel can reside wherever you want - they are only used by the bootloader and running system doesn't need those (except for updates of course). Please check the updated answer, whether the security POV is a bit clearer now.

[Vignesh]

The USB is used because I don't want to do LUKS + LVM + RAID (don't want LVM if possible), though you're right: I could put the key on a separate partition on one of those hard drives (but flash should be more reliable than HDDs if few write operations are involved).

[peterph]

I'm not sure I understand - LUKS, RAID and LVM are sompletely independent. Nevertheless if you just want a flash based device Compact Flash card in ATA adapter (which AFAIK doesn't contain any logic, since CF is using ATA interface) might indeed be interesting for you. Since it is ATA, it behaves just like a HDD and you can easily boot from it.

[Vignesh]

Yeah but if I want to only be prompted for passphrase once during boot I have to use LVM. In all cases I'd have to use RAID + LUKS. In order to avoid using LVM (which in some cases isn't interesting since it adds another layer of complexity) and be asked only once for passphrase I pass through this USB device to unlock a keyfile which I use to auto-mount all other encrypted devices. I could use a CF card as well, though that may need an adapter and may be a bit more expensive (I already own a few USB sticks I could use). I'm not sure there is any advantage of CF over USB in this case ...

[Vignesh]

Maybe wiki.gentoo.org/wiki/DM-Crypt_LUKS#Generating_an_initramfs describes what I want (custom script run at boot time)

[peterph]

Advantages of CF: a) you can boot from it without problems (if that's what you want) - you can do it from USB on recent computers as well, but older hw might have some quirks; b) I would expect CF to have better access speeds. USB stick is very likely to be just fine, but you might want to consider CF next time. :)

[peterph]

as for the RAID/LVM/LUKS issue: no you don't have to use a single one: RAID - only if you want to have some data redundancy/speed increase; LVM - only if you want to grow filesystems easily on the fly when adding a new device (and it's another level of complexity as you pointed out); LUKS - you probably want to use its cryptsetup, since it does a lots for you, that you'd need to implement otherwise. LUKS is storage format for encrypted filesystem metadata and while it has advantages, it also has some drawbacks - the plain mode of cryptsetup is a nice complement to LUKS format.

[Vignesh]

What I wanted to say was that LVM was necessary in order to get a 2 disk RAID-1 (mirror) be mounted while be asked for passphrase once. Otherwise you'd get asked twice for it. Hence the need for this trick (I don't feel LVM is necessary in some situations and it adds another layer of complexity anyway).

[peterph]

Ah, ok - no, it's not like this. LVM isn't necessary for this. First you create the RAID device with mdadm (MD is not part of LVM). After that you set up the encryption on the md-device (/dev/md/device-name). The downside is that the MD supeblock is not encrypted, but that's rarely an issue.

[Vignesh]

I assume this also applies to other level of RAID then (RAID 6 may be interesting as well). I'll have to try this. I assume that with ZFS on Linux the same thing could be done ...

[peterph]

Sure - the md is just a layer between the physical device (a) and the filesystem, pretty much in the same way the encryption and LVM is. It's just a question of the order in which you use them (my personal preference would probably be: physical device - md - lvm - encryption - filesystem).

[Vignesh]

But does a resilvering / refresh of a mirror / raid force also metablocks (such as the ones used by lvm) to be synced? I assume with ZFS + encryption you can't really use the built-in RAID functionality of ZFS + LUKS encryption alone (you have to use mdadm in order to only get asked for passphrase only once).

[peterph]

Once you add a new device into a RAID, mdadm creates its superblock, since it wouldn't know how to deal with the disks next time you try to assemble the array. You can use plain mode without a superblock, but I would not recommend that, since re-assembling the array will be much more error prone. As for ZFS, I don't see why you could not use it, it's more of a question why you should. I would expect a setup md-RAID < LVM < LUKS < ZFS with its internal RAID, LVM and encryption to work, but it seems to be a bit of overkill and performance and maintenance nightmare.

[peterph]

For copying the data from one RAID to another you probably want to use dd between two already set-up arrays instead of copying the whole device including the superblock, since that would be likley confusing mdadm.

[Vignesh]

Thank you for everything you explained me. I think we can close this question now :)