26.05 Luks and /dev/zero

Help
1

I’ve been using /dev/zero to provide 0x00 as the keyfile for luks. I saw it in a blog post somewhere and thought it was clever. Well here we are today with a breaking 26.05 update - d’oh. What is the most painless way to handle this? I have about 20 or so machines I’ll need to update (via colmena / flake setup). Some over remote ssh and most production.
Currently this is in my config:

  boot.initrd.luks.devices.root = {
    device = "/dev/disk/by-label/root";
    allowDiscards = true;

    keyFile = "/dev/zero";
    keyFileSize = 1;

    fallbackToPassword = false;
  };
2

Hm, looks like /dev/zero doesn’t get the systemd udev tag by default. You can certainly fix this with:

boot.initrd.services.udev.rules = ''
  SUBSYSTEM=="mem", KERNEL=="zero", TAG+="systemd"
'';

Though, frankly, I would probably recommend just not using /dev/zero, since you can just give the LUKS device an empty passphrase instead of a null byte passphrase and then just enable boot.initrd.luks.devices.<name>.tryEmptyPassphrase (which is just the try-empty-password option from crypttab).

1 Like
3

That is amazing! The tag did the trick. When I have a few more minutes I’ll try the the second solution.
You saved me so much time! Thanks!!

4

Just curious, but what it the purpose of the empty passphrase/null keyfile? Is this just for testing?

5

I thought it was clever because you could remove the key and have data be inaccessible but it didn’t rely on any outside input. It seemed smart at the time but it turns out to not be ha. It got baked into my default boot and nuke installer config and didn’t think about it again until today.

6

I’m not sure I get it: to make the data inaccessible you can just remove all key slots, or even simplier, overwrite the LUKS header with something like dd if=/dev/zero of=/dev/sda bs=10M count=1.

Why should the actual value of the key/passphrase matter? An empty passphrase just means anyone can unlock the disk (if the header is still in place).

7

Yeah you are correct, it wasn’t a great idea. Chalk it up to experience. :flushed_face:

1 Like
8

No, I don’t think it’s a bad idea. The idea is just that a null passphrase doesn’t buy you any security right now, but as long as you’re confident you haven’t leaked the header, it can turn the whole disk into a securely encrypted one later with just a change to the header. That’s useful if you either change your mind about your FS being encrypted later, or if you just want to wipe all the information on the drive without literally wiping the whole thing (just wipe the header). Apple actually does this: FileVault is never really disabled on new Macs; it’s just using a builtin hardware key with no protection, and it changes the key to a hardware+password based one when you enable FileVault rather than having to reencrypt the whole drive. For NixOS this would be more akin to having a TPM2-encrypted slot that isn’t bound to any meaningful security policy, but frankly this is effectively equivalent to just a null passphrase. The only threat model additionally protected against with a policy-less TPM2 slot is one where the drive is separated from the system / TPM2.

5 Likes
9

As an alternative to the udev rule, you can create a new keyfile with echo -en “\x00” > keyfile, add this to some place visible from stage 1 and replace /dev/zero with the path to this file. :slight_smile: