1

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
  • 492
  • 4
  • 25
Marc
  • 265
  • 1
  • 3
  • 14
  • That works, no problem with that. But how do i remove the header & re-shape the filesystem? – Marc Mar 20 '21 at 14:40
  • "But if you make a mistake you might lose data", And thats why i asked here ;) A guide on how to do that might be helpful. Like: "take that value x from the header dump and write y bytes there, then use `resizefs` to adjust the filesystem" And so on... – Marc Mar 20 '21 at 15:14
  • "Usually that's to improve security" 100% correct! i played around and created the volume, to increase the security i want to remove/move the header. – Marc Mar 20 '21 at 15:44
  • Made an answer that can be verified on a fake device. – A.B Mar 20 '21 at 17:26
  • @A.B Thank you very much. have seen it. will try it later on a spare drive. Out of curiosity, and to "make it more interesing" ;) is there a way to set the data/header offset to 0? – Marc Mar 20 '21 at 18:36
  • A clever use of dd to move data of the partition over itself might work. Have a backup ready... but then there's the offset to adjust in the header. I don't know how to do that. Maybe by recreating a new header while reusing the master key (--master-key-file). – A.B Mar 20 '21 at 18:43
  • I don't see the point of changing the offset. It's rather better to keep room before the data. For example to write there a fake LUKS header to have autodetecting tools detect the partition as a luks device and then read an adequate config (which would have to include the --header option) – A.B Mar 20 '21 at 18:55

1 Answers1

0

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
  • 5,338
  • 1
  • 17
  • 20
  • The cryptsetup man page suggests `--align-payload=` should be used to specify an offset when using a detached header, rather than `--offset` which is only for plain or loopaes mode. – meuh Oct 08 '22 at 15:42