7

There is scattered information on how to set up a detached header for a LUKS-encrypted disk on Stack Exchange.  And by searching the web using Google, I found limited information.  Some of the best information I found is linked to at the bottom of the question.  Some of it was helpful, even to a newbie like me.  But some seemed incomplete and I was therefore motivated to write this.  Please see if you can help with the question below, to make it complete and working.

I assume the reader has used lsblk to find that the drive of header that should be detached is sdb, and stored on some other drive sda.


Method 1: Making a header into a partition

  1. Find out the size of the header, and make a partition the correct size.  The following command will give you a lot of information.  Take note of the number next to offset under Data segments:

    $ cryptsetup luksDump /dev/sdb
    ...
    Data segments:
      0: crypt
        offset: 16777216 [bytes]
        length: (whole device)
        cipher: aes-xts-plain64
        sector: 512 [bytes]
    ...
    

    Execute fdisk (install it if you do not have it) with $ fdisk /dev/sda.

    Give it the command n and press Enter.  Make a primary partition with the default partition number; say it is X.  Choose and take note of the value of the default first sector (say it is the number M).  It will prompt you for the last sector; let's call it K.  To find a suitable number K to enter (and assuming that the size of a sector is 512 bytes), calculate K = M + offset/512; where offset is the number you found above using the luksDump command of cryptsetup.  It will make a partition that is exactly the size of the luks-header. Finally, write the changes with w. Now export the luks-header to ~/some/file/path/header.img and write it to the partition that you made:

    $ cryptsetup luksHeaderBackup /dev/sdb --header-backup-file ~/some/file/path/header.img
    $ dd if=~/some/file/path/header.img of=/dev/sdaX count=K bs=512 status=progress
    

    where X and K are the numbers that were chosen with fdisk above.  Now the header is stored on sdaX, and for fun, if you open (and if necessary install) the gparted program, you will see that gparted thinks sdaX is a tiny LUKS-encrypted partition!  You will see with lsblk -f that the UUID of /dev/sda1 is the same as that of /dev/sdb1. So you have to generate a new UUID (search Google for a 'uuid generator'). Suppose the newly generated UUID is newuuid; then change it by

    $ cryptsetup luksUUID /dev/sda1 --uuid newuuid
  2. Now we have to enter this information into /etc/crypttab.  Open the file with your text editor, and find the line that refers to sdb.  In the fourth column add the option header=/dev/sdaX.

    See the answer of frostschutz for how to do this much better by setting header=/dev/disk/by-uuid/UUID.  Be sure to make this modification and upvote their answer.

    Then write $ update-initramfs -u -k all.  If there were no errors, then I think you are good.


Method 2 : Letting the header be a file on a file system

The documentation and other sources say that it should be possible to just copy the header to a file system on sda and refer to it from there. Say we say that the file system of the partition sda1 has

UUID=###########-############-####-########

And relative to sda1, the header is in /some/path/header.img.  Then crypttab(5) says that in the fourth column of /etc/crypttab I should write

header=/some/path/header.img:UUID=###########-############-####-########

But if I do that, update-initramfs complains that the header isn't found.

QUESTION: CAN YOU PLEASE HAVE A LOOK AND QUOTE WHAT TO WRITE.  MY INSTALL OF DEBIAN IS FRESH, AND I CAN'T GET IT TO WORK UNFORTUNATELY.


In closing; you can erase the information in the existing header with cryptsetup luksErase /dev/sdb. If you ever want to apply cryptsetup to access information about the encrypted partition, you will now have to pass it the --header /dev/sdax-option. I have done my best to make sure everything is correct and detailed. But there could be a bug. Please feel free to edit. Of course, there is no warranty in case you lose your data or break something.

Sources/other reading:

2 Answers 2

4

Detached headers is a special use case. Since few people use it, support for it may also be lacking in some places. So I don't recommend using them. I also don't recommend using a drive without a partition table. This setup has too many pitfalls.


If header=UUID=x does not work, try header=/dev/disk/by-uuid/x.

For header=/some/path/file:UUID=x, the path is relative to the specified filesystem. So, if you mount UUID=x /mnt/somewhere, then it looks for /mnt/somewhere/some/path/file.

Regarding luksErase (or alternatively deleting all keys through luksRemoveKey or luksKillSlot). A LUKS header without any remaining keyslots can not be opened anymore (you have to use your detached header for that). But it still provides the UUID so you can identify the encrypted device.

If your detached header is also on a partition and has the same UUID, it will conflict. You'll have to change one of them with luksUUID, in order to be able to identify both header, and encrypted device, by UUID. In case of LUKS2, you can also set a label.

Alternatively if you use GPT partitions, you can use PARTUUID or PARTLABEL to identify it.

4
  • Your kind reply helped a lot, and I updated the question. But it seems there could still one problem: The things about keeping the header as a file on a file system still doesn't works. For example, my header is now /boot/header.img and the header option of crypttab reads header=/header.img:UUID=fc0321e2-3614-e643-fd8e-1b0c8b57863a, with fc0321e2-3614-e643-fd8e-1b0c8b57863a is the partition where root is stored. I am getting cryptsetup: WARNING: nvme0n1p1_crypt: /header.luk:UUID=e2fc0321-1436-43e6-8efd-7863a1b0c8b5 does not exist.
    – Mikkel Rev
    Oct 8, 2022 at 14:03
  • @Mikkel : Did you find a solution ? I have the same issue. I tried 4 different syntaxes (header=/test.header:UUID=uuid, header=UUID=uuid:/test.header, header=/test.header:/dev/disk/by-uuid/uuid and header=/dev/disk/by-uuid/uuid:/test.header, all resulting in the same error while doing initramfs-update -u : test.header does not exist
    – ChennyStar
    Feb 7, 2023 at 14:01
  • @ChennyStar I have been successful with the following line in my crypttab. If course, you have to change the names around for your case : nvme0n1p1_crypt UUID=8b4e3ada-fb0c-4aa3-b09f-8b3cc9e477d8 none luks,discard,header=/dev/disk/by-uuid/c51f2669-b26c-4033-9e1d-1a5e3e3df1fc
    – Mikkel Rev
    Feb 18, 2023 at 22:11
  • @MikkelRev : Thanks. Yes, that's what I ended up doing too, dd-ing the header directly to a partition and bypassing the filesystem. I was just wondering if there was a solution to store the header as a file on a filesystem. I guess the answer is no. A solution would maybe be to have a script to temporarily mount the filesystem, in a way similar to what Debian's passdev script does to get a key file from a filesystem. But a similar script doesn't seem to exist to managed detached headers.
    – ChennyStar
    Feb 19, 2023 at 6:18
-1

It is not required to configure any hooks or parameters with initramfs-tools or other configurations in Debian?

In Arch Linux, it is necessary to configure hook scripts with mkinitcpio in order to configure initramfs to decrypt LUKS disks and mount filesystems in a LVM for example. Also other kernel parameters are passed with grub configurations in /etc/default/grub (if this bootloader is used)

*Arch Linux reference:

https://wiki.archlinux.org/title/Dm-crypt/Specialties#Encrypted_system_using_a_detached_LUKS_header

You must log in to answer this question.

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