Unlock LUKS encrypted Debian root with key file on boot partition

Question

I'm trying to decrypt the Debian root with a key file stored in the boot partition (decrypted partition). This will break the security, but it doesn't matter now. I have to conclude this successfully or die trying.

I have created the hooks to the initramfs and the key file is on the /boot directory inside the initrd.img-* file. The path to the key file (/boot/keyfile) is on the /etc/crypttab file.

I updated the initramfs with sudo update-initramfs -u but I received this message: cryptsetup: WARNING: target sdaX_crypt uses a key file, skipped.

Ignoring the message and rebooting results in a unbootable disk. The message Gave up waiting for root device. is displayed and drops to initramfs shell.

In the initramfs environment the cryptsetup don't exists. (It should exists?)

Seens that the update-initramfs -u "thinks" the sdaX_crypt device will be mounted in another way and don't configure to decrypt with the keyfile.

How can I do that?

Solution 1

Keyfiles matching the shell-style (globbing) pattern KEYFILE_PATTERN defined in /etc/cryptsetup-initramfs/conf-hook will be included in the initramfs, but the other keyfiles will not, according to Debian's cryptsetup docs:

• For Debian 9: /usr/share/doc/cryptsetup/README.{initramfs,Debian}.gz
• For Debian 10: /usr/share/doc/cryptsetup{-initramfs/README.initramfs,-run/README.Debian}.gz.

I am not sure about previous versions of Debian.

These files are readable with zless filename.gz, but here it is the relevant part, for convenience and future reference.

12. Storing keyfiles directly in the initrd

Normally devices using a keyfile are ignored (with a loud warning), and the key file itself is not included in the initrd, because the initramfs image typically lives on an unencrypted /boot partition. However in some cases it is desirable to include the key file in the initrd; for instance recent versions of GRUB support booting from encrypted block devices, allowing an encrypted /boot partition.

Among the key files listed in the crypttab(5), those matching the value of the environment variable KEYFILE_PATTERN (interpreted as a shell pattern) will be included in the initramfs image. For instance if /etc/crypttab lists two key files /etc/keys/{root,swap}.key, you can add the following to /etc/cryptsetup-initramfs/conf-hook to add them to the initrd.

KEYFILE_PATTERN="/etc/keys/*.key"

Furthermore if the initramfs image is to include private key material, you'll want to create it with a restrictive umask in order to keep non-privileged users at bay. This can be achieved by adding the following to /etc/initramfs-tools/initramfs.conf.

UMASK=0077

Solution 2

You can use the keyscript option in your crypttab instead (man crypttab). Just create a script that echos your passphrase and set it as the keyscript argument, then regenerate your ramfs. You don't need any hooks, and you don't need to put the script in /boot/.

vg1-root_crypt UUID=94a3b301-123-12-a3-ea0403 none luks,keyscript=/etc/echo-root-luks-pass

I don't know why the initramfs hooks for cryptsetup prohibit you from just having the keyfile listed in crypttab. Probably don't want to condone such behavior.

P.S. I don't think that it breaks the security, it just weakens it more or less depending on how secure your /boot partition is. You could for example /boot off a USB drive, and keep the USB in you socks etc.

Solution 3

To really ignore the message and do not skip the partition, you need (at least) comment out/delete the return 1 in /usr/share/initramfs-tools/hooks/cryptroot after the line where the error message is written (around line 274 - depening on the used cryptsetup version). Beware that this file is by default managed by the package manager, and therefore is overwritten at any update of the cryptsetup package.

Please read also https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=776409 for more information about the issue.

I have not tested it, there could be other reasons than the mentioned why the case of a keyfile is not considered.

Solution 4

If my memory serves me well, your problem is that your fstab is modified to point to the encrypted partition, since you have booted from an unencrypted partition your fstab (while you are executing update-initrd) should point to your unencrypted volume. AFTER you have created the initrd image you can modify your fstab to point to the encrypted partition.

View more solutions

Comments

[spinkus]

"In the initramfs environment the cryptsetup don't exists." Not sure what that means.

[PePa]

That means that the cryptsetup binary did not get included in the initramfs archive.

[MoonSweep]

This should be the preferred answer. It's the easiest to implement, and it works flawlessly (at least on Debian, update-initramfs skips both the keyfile option for the root partition, and keyfiles not located on encrypted partitions).

[Halacs]

I don't understand what you mean. I have one disk with an unencrepted /boot partition on sda1 and the encrypted volume on sda5 partition. Inside the encrepted volume (sda5) there are LVM volumes: root and swap. The two LVM logical volumes are set in /etc/fstab while the luks in /etc/crypttab. Luks key files resides on the /boot/keyFile.bin