4

I'm setting up an encrypted root fs, which I've done before, but this time I'm using a PGP-encrypted keyfile with a symmetric password to familiarize myself with the process.

There are two places where configuration of encrypted roots seems to occur, in the kernel init options under cryptopts, and in /etc/crypttab, which seems to be used by mkinitramfs to bake certain things into the initramfs.

It's kind of cumbersome to update things in both places; after all, what's the point of having it in two places if the one suffices? I do see the value of having things in /etc/crypttab, as the initramfs can be generated differently with different hooks and scripts if a LUKS volume is present.

Using a previous example emended for this question, here's my crypttab:

picrypt /dev/mmcblk0p2 /boot/diskkey.gpg luks,keyscript=/lib/cryptsetup/scripts/decrypt_gnupg

Presumably, this tells the initramfs that /dev/mmcblk0p2 should be decrypted to use the name picrypt, specifying that we want to use luks and to pass the /boot/diskkey.gpg file to the /lib/cryptsetup/scripts/decrypt_gnupg script to generate a passphrase for the volume.

Next, here are my cryptopts from my kernel init line:

cryptopts=target=picrypt,source=/dev/mmcblk0p2,lvm=pi

Again, we're re-specifying that /dev/mmcblk0p2 creates picrypt, and in this case we're also telling it that there's an LVM volume inside called pi which it should wait for before trying to mount the root filesystem specified by the root=/dev/mapper/pi-root kernel parameter.

This setup isn't working, strangely enough, as it seems to be ignoring the crypttab's key file and key script parameters and not prompting for the GPG symmetric key passphrase, rather directly for a key. I'm going to emend my script to include keyscript and keyfile in cryptopts, but why must I do this?

Is there a way to include all of this (or at least most of it) in /etc/crypttab and not duplicate everything in the kernel init line? It's kind of ridiculous to have to change everything twice. Do these different sources simply provide different functions, crypttab in the form of hooks and cryptopts in the form of actual parameters to cryptsetup?

1 Answer 1

5

Wow. This took me nearly two days to figure out how this all works in Debian/stretch (although I have done this all before). I stumbled over your question and kept it open to answer this in case I find the answer.

And yes there is a crypttab(5) option initramfs which does excactly what you are asking for:

initramfs

The initramfs hook processes the root device, any resume devices and any devices with the “initramfs” option set. These devices are processed within the initramfs stage of boot. As an example, that allows the use of remote unlocking using dropbear.

(Believe it or not, I found this option just by chance by reading a TODO-File in the cryptsetup source.)

So your crypttab line should look like this:

picrypt /dev/mmcblk0p2 /boot/diskkey.gpg luks,keyscript=/lib/cryptsetup/scripts/decrypt_gnupg,initramfs

One more thing: The cryptsetup modules are only added to the initramfs image "when there is a device that needs to be unlocked at initramfs stage (such as root or resume devices)" (See: cryptroot-conf hook; recently renamed to just conf-hook). But this currently only works (reliably) if the root device is not in an LVM. To force the cryptsetup modules to the initramfs image I had to set CRYPTSETUP=y in /etc/cryptsetup-initramfs/conf-hook.

In any case you have to run update-initramfs -k all -u after changing any of the mentioned files.

3
  • 2
    "I stumbled over your question and kept it open to answer this in case I find the answer." That's how you do it. Great job!
    – nh2
    Commented Jul 25, 2019 at 14:28
  • 1
    Backlink to related answer: askubuntu.com/questions/381624/…
    – nh2
    Commented Jul 25, 2019 at 14:29
  • 1
    @nh2: Thank you for updating my answer. It's quite fascinating that the rename from cryptroot-conf to conf-hook took place about 2 weeks after I posted my answer (which is now included in Debian/buster). And what's even more fascinating is the fact, that last week(!) the CRYPTSETUP option has been removed: salsa.debian.org/cryptsetup-team/cryptsetup/commit/…
    – dpat
    Commented Jul 29, 2019 at 1:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .