Why does the installer add a paswordless key to LUKS-encrypted partition?

Support
9

I’m assuming you destroyed Key Slot 1 (as I believe Key Slot 0 is the passphrase you created at install). Prior to that, systemd-boot was reading the contents of your initrd (small initramfs located on your ESP) in order to find a file named crypto_keyfile.bin, which it used to unlock Key Slot 1, which is then used to decrypted the Master Key, which is what actually decrypts your system partition.

I highly recommend you investigate the following to better gauge what’s going on:

  • Contents of /etc/mkinitcpio.conf
    – Look for an entry named FILES=()
    – It lists what files to copy into the initrd.img when generating a new image
    – I’m pretty sure you’ll see FILES=(/crypto_keyfile.bin)
    – This means it copies that file into the initrd, so that systemd-boot has access to it (in order to automatically decrypt your system partition)

  • The existence of the actual keyfile located at /crypto_keyfile.bin
    – Without this keyfile laying around in the open, mkinitcpio’s FILES=(/crypto_keyfile.bin) would have nothing to copy to the initrd in the first place! :open_mouth:

  • The number of key slots in your LUKS header
    – You originally had two (which I assume are automatically created during installation with Calamares)
    – The first of these two (Key Slot 0) is based on your passphrase
    – The second of these two (Key Slot 1) is based on crypto_keyfile.bin (which the installer automatically generated behind the scenes)
    – You destroyed Key Slot 1, which means crypto_keyfile.bin is useless from now on
    – You can leave crypto_keyfile.bin alone, but it serves no point if you destroyed Key Slot 1

  • Additional crypttab references to key slots or keyfiles
    – One thing that can clue you is /etc/crypttab (must read as “root”)
    – The crypttab is used for everything but the system partition, since the bootloader is responsible for passing the options
    – This entry (for the system partition) is automatically generated and can be commented out (remember, it’s not even accessible to systemd-boot or Grub, since it lives on an encrypted partition, yet you can still boot your system with no problems, read below)
    – If you want to specify and pass options to other LUKS partitions, crypttab is where you add entries, in similar fashion to fstab (name, device, options, etc)
    – If you want to specify and pass options to your encrypted system partition, you do this in the bootloader entries (Grub or systemd-boot), for example to allow SSD trims to pass through LUKS: rd.luks.options=allow-discards can be appended to the “linux” line in Grub or systemd-boot entry.

  • The bootloader options
    – Grub and systemd-boot use their own options to identify, unlock, and apply options to the encrypted system parittion
    – Run the command as root: bootctl list or read the file (esp)/loader/entries/manjaro.conf
    – Look for any lines that mention the keyfile or other LUKS options
    – Look for options named something like “rd.luks”, which stands for ramdisk LUKS options
    – An example might be rd.luks.key=/crypto_keyfile.bin
    – The above example is moot if you destroyed the corresponding key slot, or deleted the file crypto_keyfile.bin, or removed the entry for FILES=(/crypto_keyfile.bin) from mkinitcpio.conf

Perhaps there’s a confusion of terms? crypto_keyfile.bin is equivalent to a passphrase: it’s used to unlock a key slot, which is used to decrypt the master key, which is then used to actually decrypt the partition.

  • Master Key
    – The 256-bit randomly generated key that is used in the AES cipher process which is the unique thing (to your LUKS partition) that encrypts/decrypts data.
    – You don’t choose it. It’s randomly generated for you the first time you initialize a LUKS device.
    – It’s not stored anywhere in the open
    – An encrypted form of it is stored in the LUKS header
    – This encryped (and useless) form of the Master Key needs to be decrypted back to its original form and loaded into RAM (useful!) to be used for encrypting/decrypting data on the LUKS device

  • Keyfiles and Passphrases
    – These are used to actually encrypt (and decrypt) the Master Key itself
    – They can be in the form of a passphrase or an actual file (such as crypto_file.bin)
    – You can even use a photo from Google Image search as a keyfile! (No joke, I’ve done it!)
    – While the LUKS device is currently unlocked, the actual Master Key lives in RAM
    – The Master Key is combined with a new passphrase or keyfile, runs through a complex and straining derivation process, which generates a key slot
    – In order to reverse this process against the key slot (to access the Master Key), you must provide a valid passphrase or keyfile
    – Upon doing so, if correct, the key slot is reversed, and thus it is used to decrypt the Master Key, and thus decrypt the data on the partition

  • Key Slots
    – LUKS supports multiple key slots
    – They start from 0 and incrementally count up to 7 (maybe more with LUKS2?)
    – At initial creation of the LUKS device, at least one key slot must be used (or else no access, whoops!)
    – These key slots can be generated from a passphrase or keyfile
    – Any of them can be destroyed at any time, which will void the passphrase or keyfile associated with that key slot
    – If you destroy the wrong one by mistake, you could potentially lock yourself out forever
    – You cannot destroy the last one, or else your data is gone forever. At least one key slot must exist

At no time when using LUKS are you ever directly dealing with the Master Key. You don’t create it, you don’t provide it, you don’t save it.

You only interact with your own passphrases and keyfiles, which are saved as key slots (encrypted forms of your passphrases and keyfiles). By providing a valid passphrase or keyfile, the rest is handled by dmcrypt/LUKS.

Your passphrase or keyfile is processed through a complex function through many iterations, against each key slot to find a match. If a match is found, the key slot is decrypted, and this new decrypted string is fed into an algorithm to decrypt the Master Key, which is then loaded into RAM to be used for the cipher (decrypt / encrypt data being read / written to the LUKS device.)

Addendum:

  • Passphrases can never be “lost” or “deleted”, as they live in your mind’s memory. This is why they are less volatile and easier to deal with. (While they can’t be “lost” they can be “forgotten”.)
  • Keyfiles can be lost (or deleted). If you don’t make a backup of your keyfile(s) then there’s no way to decrypt the key slot(s) associated with the former keyfile(s).

This illustrates why I believe passphrases are superior. You must use extra care and caution if solely relying on keyfiles.

You should always delegate at least one of your LUKS key slots to a passphrase, in case you lose access to (or delete) any associated keyfiles.

6 Likes