Beheaded LUKS volume pathology

Beheaded LUKS volume pathology

[Mistave]

Hello, hypothetical question.

Suppose there is an empty and functional hard drive that has been 
overwritten with random data. Then, an encrypted LUKS/2 volume with 
detached header is created on the entire device by using cryptsetup with 
a strong passphrase (defaults to LUKS2 header on newer distros, but the 
question is valid for both LUKS versions). The /dev/sdb is the HDD, and 
the luksheader.bin file will be later put on a small USB flash drive.

# cryptsetup -h sha512 -s 512 --use-random -y --header 
/root/luksheader.bin luksFormat /dev/sdb

Provided, that an adversary obtains physical access to both devices (the 
HDD and the USB flash drive), how difficult is it for them to 
forensically link the two pieces together?

How easy is it to figure out that *this* particular detached LUKS header 
belongs to *that* particular hard drive (assuming there are other HDD's 
present with "random data" on them, and the USB flash drive has multiple 
detached LUKS/2 headers on it that may belong to different devices)?

Does the LUKS/2 header contain any identifiable or relatable metadata to 
the volume body it belongs to?

Thanks in advance.

Re: Beheaded LUKS volume pathology

[Milan Broz]

Hi,

On 2/2/24 09:12, Mistave wrote:
> Hello, hypothetical question.
> 
> Suppose there is an empty and functional hard drive that has been
> overwritten with random data. Then, an encrypted LUKS/2 volume with
> detached header is created on the entire device by using cryptsetup with
> a strong passphrase (defaults to LUKS2 header on newer distros, but the
> question is valid for both LUKS versions). The /dev/sdb is the HDD, and
> the luksheader.bin file will be later put on a small USB flash drive.
> 
> # cryptsetup -h sha512 -s 512 --use-random -y --header
> /root/luksheader.bin luksFormat /dev/sdb
> 
> Provided, that an adversary obtains physical access to both devices (the
> HDD and the USB flash drive), how difficult is it for them to
> forensically link the two pieces together?

LUKS format operation does not depend on data outside the header area.

It needs only to determine if the data device supports the requested
block size, data alignment, etc.

You can even create a detached LUKS header without the presence
of a data device (then it is up to you to set proper parameters).

So if the user does not deliberately write some information elsewhere
(like pair detached header and data device using storage UUID
in /etc/crypttab), there should be no information that logically connects
the detached LUKS header and data device (for default config).
  
> How easy is it to figure out that *this* particular detached LUKS header
> belongs to *that* particular hard drive (assuming there are other HDD's
> present with "random data" on them, and the USB flash drive has multiple
> detached LUKS/2 headers on it that may belong to different devices)?

It should be impossible for a default configuration.

But this applies to LUKS partition that does not use authenticated
encryption and it is not in reencryption state.
(In this case, it is more complicated, but I think it is outside of the scope
of your question.)

> Does the LUKS/2 header contain any identifiable or relatable metadata to
> the volume body it belongs to?

As said above, not by default. The detached header was designed exactly
for this situation.

Milan

Re: Beheaded LUKS volume pathology

[Mistave]

On 2/2/24 11:16, Milan Broz wrote:

> So if the user does not deliberately write some information elsewhere
> (like pair detached header and data device using storage UUID
> in /etc/crypttab), there should be no information that logically connects
> the detached LUKS header and data device (for default config).
> 

Hello,

So, just to confirm, there is no metadata present in the LUKS header 
that would allow an adversary to perform guesswork (such as the size of 
the encrypted volume)?

For example, if I have a bunch of encrypted disks with detached headers, 
and only one of them is 10TB, but the rest are 1TB. You're saying 
there's no way that a particular header can be singled out based on 
guesswork because it's the only header that has a bigger encrypted 
volume body?

How does an encrypted volume know what size it's supposed to be? Does it 
always span across the entire partition or block device?


Kind regards!
M.

Re: Beheaded LUKS volume pathology

[Milan Broz]

On 2/3/24 13:52, Mistave wrote:
> On 2/2/24 11:16, Milan Broz wrote:
> 
>> So if the user does not deliberately write some information elsewhere
>> (like pair detached header and data device using storage UUID
>> in /etc/crypttab), there should be no information that logically connects
>> the detached LUKS header and data device (for default config).
>>
> 
> Hello,
> 
> So, just to confirm, there is no metadata present in the LUKS header
> that would allow an adversary to perform guesswork (such as the size of
> the encrypted volume)?

For LUKS1, there is no attribute to store device size in the header.

For LUKS2, we can store a fixed size, but the default format
set it to "dynamic", the size is determined according to data device size.

See luksDump, for dynamic size you should see

Data segments:
   0: crypt
...
         length: (whole device)

Milan

  
> For example, if I have a bunch of encrypted disks with detached headers,
> and only one of them is 10TB, but the rest are 1TB. You're saying
> there's no way that a particular header can be singled out based on
> guesswork because it's the only header that has a bigger encrypted
> volume body?
> 
> How does an encrypted volume know what size it's supposed to be? Does it
> always span across the entire partition or block device?
> 
> 
> Kind regards!
> M.
> 

Re: Beheaded LUKS volume pathology

[Mistave]

On 2/3/24 15:23, Milan Broz wrote:> For LUKS2, we can store a fixed 
size, but the default format
> set it to "dynamic", the size is determined according to data device size.
> 
> See luksDump, for dynamic size you should see
> 
> Data segments:
>    0: crypt
> ...
>          length: (whole device)

Ah, thank you! That answers my question.

Best regards!
M.