[dm-crypt] How to attach a LUKS header to an encrypted container?

[dm-crypt] How to attach a LUKS header to an encrypted container?

[Mikhail Morfikov]

I created an encrypted volume with the following command:

cryptsetup luksFormat /dev/sdb1 \
--type luks2 \
--cipher aes-xts-plain64 \
--key-size 512 \
--hash sha512 \
--pbkdf argon2i \
--pbkdf-force-iterations 2 \
--pbkdf-memory 1048576 \
--pbkdf-parallel 1 \
--label some_label \
--subsystem "" \
--use-random \
--verify-passphrase \
--verbose \
--header /boot/luks/head.img

So the header was created on the /boot/ partition instead of the sdb1 partition.
The /boot/ partition is placed on a micro sd card, but unfortunately my laptop
isn't able to boot from the sd card, and now I have to "reattach" the header to
the encrypted partition.

The question is how to do it properly, of course if it's doable at all? Will the
"luksHeaderRestore" command be useful in this case, or do I have to do some
magic to attach the header to the encrypted container?

I checked what will happen when I issue the "luksHeaderRestore" command giving
it the header file, but it gives me the following warning, and I don't know
whether I should say "YES" to that question.

WARNING!
========
Device /dev/sdb1 does not contain LUKS2 header. Replacing header can destroy
data on that device.

Are you sure? (Type uppercase yes):

Re: [dm-crypt] How to attach a LUKS header to an encrypted container?

[Ondrej Kozina]

Hi,

On 02/15/2018 03:56 PM, Mikhail Morfikov wrote:
> 
> So the header was created on the /boot/ partition instead of the sdb1 partition.
> The /boot/ partition is placed on a micro sd card, but unfortunately my laptop
> isn't able to boot from the sd card, and now I have to "reattach" the header to
> the encrypted partition.
If there's real data on /dev/sdb1 it won't be easy. The LUKS header is 
supposed to be placed in the head part of your device. The restore 
process would overwrite your ciphertext data (usually filesystem 
superblock plus some data). In fact, that's what the message was trying 
to warn you about.

> 
> The question is how to do it properly, of course if it's doable at all? Will the
> "luksHeaderRestore" command be useful in this case, or do I have to do some
> magic to attach the header to the encrypted container?

You would have to shift the filesystem/data and make a free space in the 
head area of /dev/sdb1 for the LUKS header. It's possible but in my 
opinion it's not worth the risk. So, If you have a spare drive I'd 
perhaps copy all data to a new drive and later luksFormat the /dev/sdb1 
again with luks header placed in the head of /dev/sdb1. But sure it 
depends what's the size of your data and so on.

> 
> I checked what will happen when I issue the "luksHeaderRestore" command giving
> it the header file, but it gives me the following warning, and I don't know
> whether I should say "YES" to that question.
> 
> WARNING!
> ========
> Device /dev/sdb1 does not contain LUKS2 header. Replacing header can destroy
> data on that device.

The warning is correct. Don't answer yes if you have real data on /dev/sdb1.

Regards
Ondrej

Re: [dm-crypt] How to attach a LUKS header to an encrypted container?

[Mikhail Morfikov]

On 2018-02-15 16:38, Ondrej Kozina wrote:
> Hi,
> 
> On 02/15/2018 03:56 PM, Mikhail Morfikov wrote:
>>
>> So the header was created on the /boot/ partition instead of the sdb1 partition.
>> The /boot/ partition is placed on a micro sd card, but unfortunately my laptop
>> isn't able to boot from the sd card, and now I have to "reattach" the header to
>> the encrypted partition.
> If there's real data on /dev/sdb1 it won't be easy. The LUKS header is supposed
> to be placed in the head part of your device. The restore process would
> overwrite your ciphertext data (usually filesystem superblock plus some data).
> In fact, that's what the message was trying to warn you about.
> 
>>
>> The question is how to do it properly, of course if it's doable at all? Will the
>> "luksHeaderRestore" command be useful in this case, or do I have to do some
>> magic to attach the header to the encrypted container?
> 
> You would have to shift the filesystem/data and make a free space in the head
> area of /dev/sdb1 for the LUKS header. It's possible but in my opinion it's not
> worth the risk. So, If you have a spare drive I'd perhaps copy all data to a new
> drive and later luksFormat the /dev/sdb1 again with luks header placed in the
> head of /dev/sdb1. But sure it depends what's the size of your data and so on.
> 
>>
>> I checked what will happen when I issue the "luksHeaderRestore" command giving
>> it the header file, but it gives me the following warning, and I don't know
>> whether I should say "YES" to that question.
>>
>> WARNING!
>> ========
>> Device /dev/sdb1 does not contain LUKS2 header. Replacing header can destroy
>> data on that device.
> 
> The warning is correct. Don't answer yes if you have real data on /dev/sdb1.
> 
> Regards
> Ondrej

Thanks for the answer. I see what I can do about it.

Re: [dm-crypt] How to attach a LUKS header to an encrypted container?

[Mikhail Morfikov]

On 2018-02-15 16:46, Mikhail Morfikov wrote:
> On 2018-02-15 16:38, Ondrej Kozina wrote:
>> Hi,
>>
>> On 02/15/2018 03:56 PM, Mikhail Morfikov wrote:
>>>
>>> So the header was created on the /boot/ partition instead of the sdb1 partition.
>>> The /boot/ partition is placed on a micro sd card, but unfortunately my laptop
>>> isn't able to boot from the sd card, and now I have to "reattach" the header to
>>> the encrypted partition.
>> If there's real data on /dev/sdb1 it won't be easy. The LUKS header is supposed
>> to be placed in the head part of your device. The restore process would
>> overwrite your ciphertext data (usually filesystem superblock plus some data).
>> In fact, that's what the message was trying to warn you about.
>>
>>>
>>> The question is how to do it properly, of course if it's doable at all? Will the
>>> "luksHeaderRestore" command be useful in this case, or do I have to do some
>>> magic to attach the header to the encrypted container?
>>
>> You would have to shift the filesystem/data and make a free space in the head
>> area of /dev/sdb1 for the LUKS header. It's possible but in my opinion it's not
>> worth the risk. So, If you have a spare drive I'd perhaps copy all data to a new
>> drive and later luksFormat the /dev/sdb1 again with luks header placed in the
>> head of /dev/sdb1. But sure it depends what's the size of your data and so on.
>>
>>>
>>> I checked what will happen when I issue the "luksHeaderRestore" command giving
>>> it the header file, but it gives me the following warning, and I don't know
>>> whether I should say "YES" to that question.
>>>
>>> WARNING!
>>> ========
>>> Device /dev/sdb1 does not contain LUKS2 header. Replacing header can destroy
>>> data on that device.
>>
>> The warning is correct. Don't answer yes if you have real data on /dev/sdb1.
>>
>> Regards
>> Ondrej
> 
> Thanks for the answer. I see what I can do about it.
> 
I have a few question concerning the detached headers.

1. Is there a way to change data offset? I'm asking because the detached header
has the data offset set to 0 (if I'm reading it right):

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

And if I just placed the header in front of the encrypted container, it would
give some error: "Reduced data offset is allowed only for detached LUKS header".
So this data offset should be changed somehow in order to make the header work.

2. Is there a way to set the data offset during the creation time of the
encrypted container? I really thought that when the header is detached, some
zeroes (or something else) is written to the header's area. Is such case, it
wouldn't be a problem to attach the header to the encrypted container.

3. The header is 4 MiB in size, so the data offset should be 4 MiB, right?

4. I have 2 GiB of free space at the beginning of the drive (just in case of
creating a /boot/ partition for this disk), so there's no problem with enlarging
the main partition. Would it work if I resized the partition (+4 MiB for the
header), and then create a normal LUKS header with the key extracted from the
detached header?

Re: [dm-crypt] How to attach a LUKS header to an encrypted container?

[Arno Wagner]

Hi Mikhail,

1. The offset is not protected, You can just edit it.
FAQ item 6.12 should give you an idea where the 
repective number is.

The FAQ is here:
https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions

2. Best make a regular container, and then remove the
header by copying it out and zeroing where it was.
You can make a new header with the same master-key
for your existing container when you have shifted the
data, see FAQ item 6.10. You may have to correct
the offsets for the IVs though.

It is much easier to get a second disk and copy everything 
over to the format you want. And you need backup anyways
(FAQ Item 6.1), so you can just do a backup and then
restore into a new LUKS container. (You have backup, right?)

3. Essentially yes, but there is some alignment. Best way to 
be sure is to create a new LUKS container and check the values 
there. Can be done iin a file, say 100M in size, as LUKS
on-disk format does not care about device size. 
See FAQ Item 2.6

4. Maybe. Depends on the offset calculation for IVs.
I think they are relative to the start of the data area, but
they may be relative to the start of the header. Since LUKS
generally has a very sane design, I would expect the former,
but I do not actually know.

Regards,
Arno

On Fri, Feb 16, 2018 at 01:33:29 CET, Mikhail Morfikov wrote:
> I have a few question concerning the detached headers.
> 
> 1. Is there a way to change data offset? I'm asking because the detached header
> has the data offset set to 0 (if I'm reading it right):
> 
> ...
> Data segments:
>   0: crypt
>         offset: 0 [bytes]
>         length: (whole device)
> ...
> 
> And if I just placed the header in front of the encrypted container, it would
> give some error: "Reduced data offset is allowed only for detached LUKS header".
> So this data offset should be changed somehow in order to make the header work.
> 
> 2. Is there a way to set the data offset during the creation time of the
> encrypted container? I really thought that when the header is detached, some
> zeroes (or something else) is written to the header's area. Is such case, it
> wouldn't be a problem to attach the header to the encrypted container.
> 
> 3. The header is 4 MiB in size, so the data offset should be 4 MiB, right?
> 
> 4. I have 2 GiB of free space at the beginning of the drive (just in case of
> creating a /boot/ partition for this disk), so there's no problem with enlarging
> the main partition. Would it work if I resized the partition (+4 MiB for the
> header), and then create a normal LUKS header with the key extracted from the
> detached header?
> 
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

-- 
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: [dm-crypt] How to attach a LUKS header to an encrypted container?

[Mikhail Morfikov]

On 2018-02-16 02:34, Arno Wagner wrote:
> Hi Mikhail,
> 
> 1. The offset is not protected, You can just edit it.
> FAQ item 6.12 should give you an idea where the 
> repective number is.
> 
> The FAQ is here:
> https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions
> 
> 2. Best make a regular container, and then remove the
> header by copying it out and zeroing where it was.
> You can make a new header with the same master-key
> for your existing container when you have shifted the
> data, see FAQ item 6.10. You may have to correct
> the offsets for the IVs though.
> 
> It is much easier to get a second disk and copy everything 
> over to the format you want. And you need backup anyways
> (FAQ Item 6.1), so you can just do a backup and then
> restore into a new LUKS container. (You have backup, right?)
> 
> 3. Essentially yes, but there is some alignment. Best way to 
> be sure is to create a new LUKS container and check the values 
> there. Can be done iin a file, say 100M in size, as LUKS
> on-disk format does not care about device size. 
> See FAQ Item 2.6
> 
> 4. Maybe. Depends on the offset calculation for IVs.
> I think they are relative to the start of the data area, but
> they may be relative to the start of the header. Since LUKS
> generally has a very sane design, I would expect the former,
> but I do not actually know.
> 
> Regards,
> Arno
> 
> On Fri, Feb 16, 2018 at 01:33:29 CET, Mikhail Morfikov wrote:
>> I have a few question concerning the detached headers.
>>
>> 1. Is there a way to change data offset? I'm asking because the detached header
>> has the data offset set to 0 (if I'm reading it right):
>>
>> ...
>> Data segments:
>>   0: crypt
>>         offset: 0 [bytes]
>>         length: (whole device)
>> ...
>>
>> And if I just placed the header in front of the encrypted container, it would
>> give some error: "Reduced data offset is allowed only for detached LUKS header".
>> So this data offset should be changed somehow in order to make the header work.
>>
>> 2. Is there a way to set the data offset during the creation time of the
>> encrypted container? I really thought that when the header is detached, some
>> zeroes (or something else) is written to the header's area. Is such case, it
>> wouldn't be a problem to attach the header to the encrypted container.
>>
>> 3. The header is 4 MiB in size, so the data offset should be 4 MiB, right?
>>
>> 4. I have 2 GiB of free space at the beginning of the drive (just in case of
>> creating a /boot/ partition for this disk), so there's no problem with enlarging
>> the main partition. Would it work if I resized the partition (+4 MiB for the
>> header), and then create a normal LUKS header with the key extracted from the
>> detached header?
>>
>> _______________________________________________
>> dm-crypt mailing list
>> dm-crypt@saout.de
>> http://www.saout.de/mailman/listinfo/dm-crypt
> 
Yes, I think it will be better to copy everything to some other disk and then
recreate the container with a new header attached to it. And yes, in the future
I will always create a container with it's header and then detach the header if
needed because it's a way easier to handle such containers.

Anyways, I'm gonna make a test container and see how reattaching the heder works
in practice because I don't really want to loose the data on my disk, and I want
to know what happens when such header is reattached. :)