Problem after detaching the header

Problem after detaching the header

[Darek Hisc]

Hi

I am trying to move my current included header from sda2 to a separate raw (no file system) partition of device sdb1, but after removing the original header the system does not start and stops at the initramfs console.

OS: LMDE 5 (Linux Mint Debian Edition = de facto Debian 11)
Standard LVM installation on LUKS2

I did the following steps:
1. cryptsetup luksHeaderBackup /dev/sda2 --header-backup-file /header.img
2. dd if=/header.img of=/dev/sdb1
3. option luks,discard,tries=3,header=/dev/sdb1 > /etc/crypttab
4. update-initramfs -u -k all
5. cryptsetup luksErase /dev/sda2

Up to this point, everything works fine and the system boots up properly
When, according to the instructions in the https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md I do:
6. cryptsetup luksDump /dev/sdb1 > Data segments: offfset: 16777216 bytes
7. dd bs=512 count=32768 if=/dev/zero of=/dev/sda2
the system no longer starts.

Have I screwed something up or am I missing a step?
Please help!

Darek

Re: Problem after detaching the header

[Arno Wagner]

Looks like the initrd cannot deal with detached headers.
Can you manually map the LUKS container from the 
initrd console? If not, waht errot do you get?

Arno

On Thu, Jun 29, 2023 at 21:17:14 CEST, Darek Hisc wrote:
> Hi
> 
> I am trying to move my current included header from sda2 to a separate raw
> (no file system) partition of device sdb1, but after removing the original
> header the system does not start and stops at the initramfs console.
> 
> OS: LMDE 5 (Linux Mint Debian Edition = de facto Debian 11)
> Standard LVM installation on LUKS2
> 
> I did the following steps:
> 1. cryptsetup luksHeaderBackup /dev/sda2 --header-backup-file /header.img
> 2. dd if=/header.img of=/dev/sdb1
> 3. option luks,discard,tries=3,header=/dev/sdb1 > /etc/crypttab
> 4. update-initramfs -u -k all
> 5. cryptsetup luksErase /dev/sda2
> 
> Up to this point, everything works fine and the system boots up properly
> When, according to the instructions in the https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md I do:
> 6. cryptsetup luksDump /dev/sdb1 > Data segments: offfset: 16777216 bytes
> 7. dd bs=512 count=32768 if=/dev/zero of=/dev/sda2
> the system no longer starts.
> 
> Have I screwed something up or am I missing a step?
> Please help!
> 
> Darek
> 
> 

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: Problem after detaching the header

[Darek Hisc]

> Looks like the initrd cannot deal with detached headers.
Please note that until the luksErase operation everything is fine and the header is read from the detached location (since the original slots no longer exist)

> Can you manually map the LUKS container from the
> initrd console? If not, waht errot do you get?
I'm sorry but I don't know how to do it :(
Can you provide the command to type in the console initramfs?

Re: Problem after detaching the header

[Arno Wagner]

That would be a question for your distribution.

On Fri, Jun 30, 2023 at 11:04:34 CEST, Darek Hisc wrote:
> 
> > Looks like the initrd cannot deal with detached headers.
> Please note that until the luksErase operation everything is fine and the header is read from the detached location (since the original slots no longer exist)
> 
> > Can you manually map the LUKS container from the
> > initrd console? If not, waht errot do you get?
> I'm sorry but I don't know how to do it :(
> Can you provide the command to type in the console initramfs?
> 
> 

-- 
Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno@wagner.name
GnuPG: ID: CB5D9718  FP: 12D6 C03B 1B30 33BB 13CF  B774 E35C 5FA1 CB5D 9718
----
A good decision is based on knowledge and not on numbers. -- Plato

If it's in the news, don't worry about it.  The very definition of 
"news" is "something that hardly ever happens." -- Bruce Schneier

Re: Problem after detaching the header

[Milan Broz]

On 6/29/23 21:17, Darek Hisc wrote:
> Hi
> 
> I am trying to move my current included header from sda2 to a separate raw (no file system) partition of device sdb1, but after removing the original header the system does not start and stops at the initramfs console.
> 
> OS: LMDE 5 (Linux Mint Debian Edition = de facto Debian 11)
> Standard LVM installation on LUKS2
> 
> I did the following steps:
> 1. cryptsetup luksHeaderBackup /dev/sda2 --header-backup-file /header.img
> 2. dd if=/header.img of=/dev/sdb1
> 3. option luks,discard,tries=3,header=/dev/sdb1 > /etc/crypttab
> 4. update-initramfs -u -k all
> 5. cryptsetup luksErase /dev/sda2

Just a comment here:

- luksErase will destroy keyslots (key material), but still keeps LUKS
header on the device, including UUID (so you can reference the device through UUID
even if it cannot be unlocked without detached header)

- after you dd the LUKS header, UUID is of course no longer recognized, but,
as you used another device for LUKS header, the new one will have former UUID
Check that UUID is not referenced in config. (Also you can change it with
luksUUID command)

But as Arno said, this is really question for your distro (note that cryptab
file can be managed by systemd, but there are also non-systemd versions).
Also without console log it is not clear what exactly fails.

Milan

> 
> Up to this point, everything works fine and the system boots up properly
> When, according to the instructions in the https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/FAQ.md I do:
> 6. cryptsetup luksDump /dev/sdb1 > Data segments: offfset: 16777216 bytes
> 7. dd bs=512 count=32768 if=/dev/zero of=/dev/sda2
> the system no longer starts.
> 
> Have I screwed something up or am I missing a step?
> Please help!
> 
> Darek
> 
> 
> 

Re: Problem after detaching the header

[Darek Hisc]

> - luksErase will destroy keyslots (key material)
Does it also destroy the Master Key?

> but still keeps LUKS header on the device, including UUID (so you can reference the device through UUID
> even if it cannot be unlocked without detached header)
From the comments I've received here https://unix.stackexchange.com/questions/750288/properly-detach-the-luks-header-from-the-existing-fdelvm-encryption it also appears that the missing UUID is to blame after destroying the entire header.

> Check that UUID is not referenced in config.
How to check?

> But as Arno said, this is really question for your distro (note that cryptab
> file can be managed by systemd, but there are also non-systemd versions).
If it's not a cryptsetup problem, it probably affects many (or all) distributions. I suggest to add the relevant information to FAQ 2.20 because the current wording suggests that the given procedure is sufficient and it is not (because it causes a UUID problem that needs to be solved somehow)

> Also without console log it is not clear what exactly fails.
Please tell me what to enter in the initramfs console to check it and I will give you the result

Another solution that looks very interesting:
In a comment on stackexchange, someone suggested creating a dummy header instead of the original one, but using a detached one. Do you see any potential problems and is this a good idea?

Re: Problem after detaching the header

[Milan Broz]

On 7/1/23 19:06, Darek Hisc wrote:
> 
>> - luksErase will destroy keyslots (key material)
> Does it also destroy the Master Key?

Volume Key (also known as Master Key) is stored in keyslot(s).
luksErase removes all keyslots, thus removes all keys, see man cryptsetup-luksErase

>> but still keeps LUKS header on the device, including UUID (so you can reference the device through UUID
>> even if it cannot be unlocked without detached header)
>  From the comments I've received here https://unix.stackexchange.com/questions/750288/properly-detach-the-luks-header-from-the-existing-fdelvm-encryption it also appears that the missing UUID is to blame after destroying the entire header.
> 
>> Check that UUID is not referenced in config.
> How to check?

It depends on your distro. Crypttab, bootloader config, old blkid cache, whatever.
I have no idea, it was just a hint.
The FAQ contains generic info, various distros can have various additional steps
(we should update it to mention it, though).

> 
>> But as Arno said, this is really question for your distro (note that cryptab
>> file can be managed by systemd, but there are also non-systemd versions).
> If it's not a cryptsetup problem, it probably affects many (or all) distributions. I suggest to add the relevant information to FAQ 2.20 because the current wording suggests that the given procedure is sufficient and it is not (because it causes a UUID problem that needs to be solved somehow)
> 
>> Also without console log it is not clear what exactly fails.
> Please tell me what to enter in the initramfs console to check it and I will give you the result
> 
> Another solution that looks very interesting:
> In a comment on stackexchange, someone suggested creating a dummy header instead of the original one, but using a detached one. Do you see any potential problems and is this a good idea?

LUKS header after calling luksErase is actually "dummy" header (if it means header without keyslots).
So I think this is what you get after calling luksErase in your steps 1-5.

Your device can be only unlocked with detached header, but data device is still visible marked as LUKS,
that should be enough if your goal is to store key separately.

Milan

Re: Problem after detaching the header

[Darek Hisc]

> > Another solution that looks very interesting:
> > In a comment on stackexchange, someone suggested creating a dummy header instead of the original one, but using a detached one. Do you see any potential problems and is this a good idea?
> 
> 
> LUKS header after calling luksErase is actually "dummy" header (if it means header without keyslots).
I meant to go one step further and instead of luksErase create a fake header (bluff, decoy): Create a temporary container, make a header luksHeadeBackup and then luksHeaderRestore to the location of my original header on disk. It will "pretend" to be a real header, and in fact I will be using another detached one. If my computer is stolen, I wish good luck to the opponent who tries to brute-force a drive with a fake header (the real header at this time will be on a USB in my pants pocket). Do you see any possible problems in the operating system due to the fake header?