Re: To make LUKS detached header even more secure?

On 7 Jun 2022 10:41 +0800, from [email protected] (midnite zandiro):
> 1. How are the volume master key and the keyslot digest generated?
> 
> I have skimmed through the source code. Please correct me if I am
> wrong. I thought the volume masker key was generated from the
> passphrase/the keyfile. But I found out that the volume master key is
> actually generated by random, at /lib/volumekey.c line 141 in
> crypt_generate_volume_key() -
> https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/lib/volumekey.c#L141
> . This makes sense because LUKS enables us to specify the
> --master-key-file directly. If MK is not generated independent to the
> passphrase, we have to work reversely from MK and passphrase to obtain
> the keyslot digest.

There is an even bigger reason for generating the master key
independently of the passphrase: it preserves security when changing
the passphrase without requiring a full reencryption, which on large
media can take _days_. (A read/write pass over 8 TB at an average of
100 MB/s works out to about 1.8 days.) There's also the fact that LUKS
supports more than one passphrase, any one of which can be used to
unlock a container.


> 2. To achieve an even more secure design than the LUKS2 detached header?
> 
> With the header detached onto the USB Key, and volume locked with an
> user passphrase, it is so-called a two-factor authentication setup.

No, that is not proper 2FA. As is clearly demonstrated by your
argument about how the second storage device can be copied (and
relatively easily, at that), both are "something you know".

> However I find a weakness scenario in this setup. An attacker who
> gains a clone of the USB Key

There you have it.

> can start his attack, without the need to
> wait for an acquisition of encrypted disk. This weakness is mainly
> because, with solely the header, we can verify if our passphrase is
> correct.
> 
> IF the volume master key is generated from the user passphrase,

Well, since it isn't, the remainder of that paragraph becomes moot.


> However it is possible to change the user passphrase without
> re-encryption. The setup needs to be tweaked a bit. Similarly we use
> the user passphrase, hashing options, and the salt to generate a MK1.
> With this MK1, we generate a series of random bits (MK). This series
> of random bits is actually the volume master key (MK). MK will never
> be stored plainly on the USB Key. Instead, the encrypted version,
> encrypt(MK1, MK), is stored on the USB Key. Upon passphrase change, we
> generate MK2 with the new passphrase, new hashing options, and new
> salt. With MK1 also unlocked, we simply copy the MK to the new MK2's
> container. Then another encrypted version, encrypt(MK2, MK), is stored
> on the USB Key. This is very similar to the LUKS keyslot digests.
> However, with only one set of hashing options and salt present in the
> USB Key, the attacker is still impossible to verify his guesses of the
> MK.

So, if I understand correctly, what you are proposing is basically a
_split_ header, with part of the data stored in one location and part
of the data stored in another location, and one (but not both) of
those partial headers possibly detached from the container?

This requires storing some header data separate from the detached
header, which either requires some kind of "two detached headers"
setup (at which point we're back to your original threat model about
being able to copy both, since we're already assuming an attacker who
has access to the detached header) or causes a detached-header LUKS
container to no longer be length-preserving.

I'm struggling to see what the benefit of this would be in practice.
You claim increased resistance to passphrase guessing by an attacker
who has access to the detached header but not the encrypted (locked)
container itself, but there's already a simple way to do that:
increase iteration count, passphrase length, or both. Take as an
example a seven-word standard Diceware passphrase, which is hardly
onerous; that already gives you about 90 bits' worth of security,
which on its own is _almost_ sufficient. Throw in a few extra seconds'
worth of key derivation iteration, and that's likely very much
sufficient against a _cryptographic_ attack even by a highly
determined, powerful adversary. (The master key can be assumed to be
sufficiently secure against a cryptographic attack, because if it
wasn't, then the attacker would just go for that and not bother with
the passphrase at all.) Since this would be aimed only or primarily at
users who use a detached header stored on a separate device, who seem
likely to already care more about security than the average user, I
don't think either is an unreasonable assumption. At that point
something simple like a key logger or rubber hose cryptanalysis
appears a more likely threat.

https://xkcd.com/538/ applies.

None of this is to say that the security of LUKS couldn't _possibly_
be improved upon somehow (such a claim would be naiive), but there's
ample reason already to not add complexity based on what appears at
least to me to be a rather contrived threat model.

Some form of TPM integration, possibly coupled with secure
attestation, seems a more reasonable approach to guard against the
kind of attack against a detached header that you postulate.


> I would like to point out that this suggested setup is stronger than
> using LUKS plain mode.

There is no "LUKS plain mode". Sticking to what's reasonably available
in present-day-supported implementations, there's plain dm-crypt
(which is a straight one-to-one mapping between blocks; encryption
metadata is retained elsewhere, such as in /etc/crypttab or on a piece
of paper kept in the user's wallet), there's LUKS 1, and there's LUKS
2; the latter two with integrated or detached headers, for a total of
five combinations.

-- 
Michael Kjörling • https://michael.kjorling.se • [email protected]
 “Remember when, on the Internet, nobody cared that you were a dog?”