[systemd-devel] Thoughts about /etc/crypttab keyscript options

[Paul Harvey]

I've just been pointed to this discussion from #debian-systemd, where I dropped in to suggest that Debian packaging of systemd should probably abort installation if incompatible config like this is detected (I ended up with a non-booting test server, no harm done).

I thought I'd help elaborate on a couple of use-cases.

 > On Fri, Aug 15, 2014 at 01:30:32PM +0200, Lennart Poettering wrote:
(snipped)
 > > > > > > I fear I don#t have an easy suggestion. What kind of device do you
 > > > > > > actually want to make work here? some smartcard or so?
 > > > > >
 > > > > > That's the vision, yes. At the moment, my keyscript unlocks a small
 > > > > > LUKS partition on the disk and takes the key for the root fs from
 > > > > > there. That's just a placeholder for a future more complicated setup.
 > > > >
 > > > > Not following. You place a key for a LUKS partition on another LUKS
 > > > > partition? What's the benefit of that? Inception? ;-)
 > > >
 > > > It's actually part of a two-factor-authentification for the poor. The
 > > > part to know is the key to the LUKS parition, the part to have is an
 > > > USB key.

There are different motives for encrypted disks. For servers, you want to make the disks in your RAID opaque to anyone who picks them up as a result of theft, loss, re-use, disposal, etc. In this scenario, in-built TPM on the motherboard can keep the key secret much better than any filesystem device while still avoiding the need to manually babysit boot-up with passphrase questions - particularly handy if you have dozens of disks in the rack...

Because luks-tpm doesn't allow combination with passphrases (last I checked?), this isn't good enough for laptops where you're likely to lose the whole machine (TPM and all). In order to make the disk opaque to whoever posses the laptop, we need to separate the key from the machine. Passphrases are standard but easily snooped, and perhaps inconvenient.

This is where physical tokens get interesting - and diverse; there's a plethora of options out there. USB tokens (ePass, YubiKey) are easy, some have PIN pads (to mitigate lost tokens), Bluetooth tokens, SIM card applets... My favourite would be contactless smartcards, in some companies the employee ID cards are already some ISO-14443 thing for building access and Kerberos/Windows auth. They're usually capable of running a custom applet, so all the user has to do is swipe at their NFC or card-reader enabled workstation/laptop which sends some challenge text (done from the keyfile script, perhaps taken from TPM) to the SC which then hashes it with an internal secret, the result of which is used as the luks key.

I've even seen some code floating around on github where each invocation of the keyfile script actually deletes the last used luks key and creates a new one, at every boot! This appeared to be an attempt at "strengthening" the use of a plain old usb storage device (each boot would re-write the keyfile with the next key) in lieu of a real token.

Regards

--
Paul