Hey there, The question of plausible deniability has been discussed numerous times before. It is commonly thought of as completely pointless. It does not really matter, if you change the parameters, but remember: https://imgs.xkcd.com/comics/security.png ;-). So even if you have no chance of retrieving the real key, you'll be up to some fun entertainment :-P. On Mon, August 24, 2015 00:10, 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@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt > _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
