Hi Mis, this thing gets asked/suggested/demanded from time to time here. Please refer to FAQ Item 5.18: https://gitlab.com/cryptsetup/cryptsetup/wikis/FrequentlyAskedQuestions tl.dr: No, it does not work and it is not a good idea. Sorry. This is not "Mission Impossible" but th real world. Regards, Arno 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@xxxxxxxx > http://www.saout.de/mailman/listinfo/dm-crypt -- Arno Wagner, Dr. sc. techn., Dipl. Inform., Email: arno@xxxxxxxxxxx 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 _______________________________________________ dm-crypt mailing list dm-crypt@xxxxxxxx http://www.saout.de/mailman/listinfo/dm-crypt
