3

Is there a way to detach/remove a header from a existing cryptsetup volume? So that I have to specify --header when I want to open (cryptsetup luksOpen ...) the volume?

I haven't found a solution to "move" the header from A (Volume) to B (what ever else)

U. Windl
  • 943
Marc
  • 529

1 Answers1

1

Disclaimer: one should backup important data. If the present instructions have a mistake or are improperly used, loss of data can occur. That said...

This answer doesn't deal with boot process or system configuration. It's only using manual commands.

Let's assume the LUKS device is /dev/loop0 (it could be for example /dev/sdb9 instead) and currently mapped as /dev/mapper/myluks and an unrelated other device's filesystem is mounted on /mnt. Just adjust to the actual case.

setup with a sparse file for test:

# truncate -s $((16 * 2**30)) /tmp/myblock.img
# losetup -f --show /tmp/myblock.img 
/dev/loop0
# cryptsetup luksFormat /dev/loop0

WARNING!


This will overwrite data on /dev/loop0 irrevocably.


Are you sure? (Type 'yes' in capital letters): YES
Enter passphrase for /tmp/myblock.img: 
Verify passphrase:


cryptsetup luksOpen /dev/loop0 myluks


Enter passphrase for /tmp/myblock.img:

Adding some data directly on the LUKS block device (of course, creating a LVM or a filesystem would have worked too):

# echo test-data > /dev/mapper/myluks
# head -1 /dev/mapper/myluks
test-data

Copy the LUKS header by doing a LUKS header backup:

cryptsetup luksHeaderBackup /dev/loop0 --header-backup-file /mnt/headerbackup.luks

Close the LUKS device and attempt to reopen it using the detached header:

cryptsetup close myluks
cryptsetup luksOpen --header /mnt/headerbackup.luks /dev/loop0 myluks

Check the offset of the data to know how much to wipe in the partition. Normally this offset should be the same size as the freshly created /mnt/headerbackup.luks. On a LUKS2 output this should be similar to:

cryptsetup luksDump /dev/loop0

[...]


Data segments:
  0: crypt
    offset: 16777216 [bytes]
    length: (whole device)
    cipher: [...]
    sector: [...]


[...]

So there's 16777216 bytes to wipe (I think older LUKS1 might have used 4194304 by default instead):

dd if=/dev/zero of=/dev/loop0 bs=16777216 count=1

If done directly on the file image rather than a device, this should probably include conv=notrunc.

Check this is still working, but only with the detached header (if not... use backups):

# cryptsetup close myluks
# cryptsetup luksOpen /dev/loop0 myluks
Device /dev/loop0 is not a valid LUKS device.
# cryptsetup luksOpen --header /mnt/headerbackup.luks /dev/loop0 myluks
Enter passphrase for /tmp/myblock.img: 
# head -1 /dev/mapper/myluks
test-data

And that's it. There's nothing to relocate since the offset was kept.

If the LUKS device had been created directly with a detached header, then by default no offset would exist, the actual data would start at byte 0 of the underlying device. To create directly a detached header but still reserve the space for later change (or to reserve the room for a fake LUKS header for some kind of auto-detection) one should use at initial creation something like:

cryptsetup luksFormat --header /mnt/header.luks --offset $((16777216/512)) /dev/loop0

Final remark: depending on the underlying device technology, there's no guarantee that the freshly erased LUKS information can't be retrieved with advanced technology because there could be leftovers (eg: due to SSD's FTL relocation or hard disk magnetic remanence ...). If that's part of the threat to be avoided, the header should be created directly detached, or the data be re-encrypted once the header is detached (which is quite easy for LUKS2, using cryptsetup reencrypt ...).

A.B
  • 6,306