Re: Beheaded LUKS volume pathology

[Milan Broz <gmazyland@gmail.com>]

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