[dm-crypt] LUKS key slots - plausible deniability

Arno Wagner arno at wagner.name
Mon Aug 24 02:44:17 CEST 2015

Hi Mis,

this thing gets asked/suggested/demanded from time to time here.
Please refer to FAQ Item 5.18:

tl.dr: No, it does not work and it is not a good idea. Sorry.
       This is not "Mission Impossible" but th real world.


On Mon, Aug 24, 2015 at 00:10:54 CEST, Mistave wrote:
> Hey,
> New here and bringing some ideas, wondering how these would work out.
> Is it possible to configure LUKS Key Slots in such a way that an
> adversary would be unable to tell how many of these slots are in use?
> For example if I were to enable all of them (except the first two) with
> some "random junk". The first two slots would be the only legitimate
> slots while having the rest of them enabled just for cosmetics so that
> they cannot be distinguished from legitimate ones. The only thing I can
> think of right now is to manually enable the slots one after another and
> enter some long random junk when asked for passphrase (or maybe have a
> script do it). I am unsure what security implications this would have,
> if the adversary was to attack this setup. Would having multiple slots
> enabled speed up the attacks (even though they have been initialized
> with some long binary data as the passphrase)? Is there a way to enable
> and make certain LUKS keyslots reject *any* passphrase input?
> Let's look at a real world scenario where such setup could be used...
> Suppose someone writes a short bash script that creates this kind of
> LUKS setup (let's call it the "setup script" from now on). The script
> creates a LUKS volume and sets up all key slots (except the first one)
> as fakes - either as a dummy entry that rejects all passphrases (not
> currently supported in LUKS?) or by feeding them with some random junk
> passphrase that the user is never shown. The first slot is then set up
> as a legitimate slot that actually takes a known passphrase or keyfile
> and can decrypt the data (rest of the slots "cannot" be used to decrypt
> the volume).
> The user then runs this script to create a LUKS encrypted volume on his
> device and puts some super secret "porn" files inside. But then the user
> gets smart and also manually replaces the second "fake" slot with valid
> credentials as a backup access. Now LUKS slots 0 and 1 can be used to
> access the data (with different passphrases). Finally, he sets up an
> anti-tampering system so that if anyone were to tamper with the device,
> the program would erase the first key slot and power the computer off.
> So then one day the adversary moves in and confiscates the hardware,
> tripping the alarm and the termination script in the process. The first
> key slot gets (securely?) erased, and the hardware powers off. Then a
> forensics team gets their hands on the device to exammine it and they
> find the encrypted container, the setup script and the termination
> script. They also learn that the LUKS container has the first key slot
> disabled (probably a result of the termination script having been
> triggered) while the rest are enabled.
> Now then the adversary wants access to the data, but let's assume they
> are civil enough that they are not going to use a rubber hose attack
> here (which could be made useless, if the user didn't modify the second
> slot earlier). We know that the fake key slots cannot be distinguished
> from real ones so the adversary has no way of knowing which ones are
> real and which ones are fake. When confronted, the user argues that the
> setup script was used to create the encrypted container, the same script
> the adversary found on the device. And surely enough by examining and
> testing the script, they learn that all key slots (except the first one)
> are fed some random/unknown junk and cannot be used to access the data.
> The other thing they learn is that the first key slot is legitimate and
> can be used to access the data, but now it is gone thanks to the
> termination script having been triggered. What they don't know is that
> the user has replaced a fake slot with a real one by doing it off the
> record err... I mean manually outside the setup script.
> Can the user plausibly deny access to the encrypted files in these
> circumstances?
> ~mis
> _______________________________________________
> dm-crypt mailing list
> dm-crypt at saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt

Arno Wagner,     Dr. sc. techn., Dipl. Inform.,    Email: arno at 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

More information about the dm-crypt mailing list