[dm-crypt] LUKS key slots - plausible deniability

[Mistave <mistave@countermail.com>]

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