Stefan Schönleitner wrote: > > Hi, > > is it possible to add a self-destruct passphrase to the encrypted > filesystem ? > Are there any intentions to implement a self-destruct solution ? > > This would be wonderful if one is forced to mount the crypto-fs. > IMHO there exist at least two possibilities for this case: > (1) the "a gun is pointed at your head" situation > (2) the more likely situation, where local law enforcement (or other > legal > forces) try to get your data > > A litte bit on situation (2) (might not be true for all countries): > one can say that law enforcement has no right to force you to show > them > your personal encrypted data (like emails, source code, whatever). > However, it might be the case that they have reasonable suspicion > (or at > least they say so) and you would get the maximum penalty in case you > do not > show the data to them. > It's comparable to drunken driving: If you agree to do a > field sobriety test (FST) you'll get your justified penalty, but if > you > disagree you get maximum penalty. > Of course, this is just an example and there might be numerous other > similar > "legal" situations. > > note: What information is stored on the encrypted disk and if it's > legal or not > should not be point of discussion here. > > > My idea for self-destruct would be the following: > There are two passphrases for an encrypted partition: the "real" one > and the > self-destruct passphrase. > The "real" one just mounts the encrypted disk of course. > The self-destruct passphrase will set up a new filesystem (thus no > real secure > self-destruct) and then run some encrypted script or program which > will > populate the newly created filesystem with "nonsensitive" but > meaningful data > (like some kernel source or newsgroup messages). > > The goal is that the attacker believes to get what he wants (access > to the > encrypted data). > To achieve an even higher level of security, the previous disk > content would > have to be overwritten multiple-times with random trash and the > self-destruct > mechanism would have to be removed as well, so that the newly > created > filesystem containing the "nonsensitive" data works like expected. > > I'm currently implementing some dirty-hack solution which is based on > encrypted shell-script execution. > (To be more specific, the cryptsetup tool passes the passphrase to the > shellscript decryption routine (the shellscript resides on the root-fs) > and > executes the script if the passphrase was right (thus self-destruction). > Otherwise execution returns to the cryptsetup routines which set up the > crypto-filesystem). > Needless to say, that this solution is neither very secure (security > through > obscurity) nor does it work if the harddisk is used on another system. > > For a real solution, I would suggest the following: > * The encrypted script is stored on the disk itself > * some solution will have to be found, so that the > self-destruct mechanism works a bit more hard- and software > independant. > > I think that it is extremely difficult to impossible to implement a > system-independant solution. > The only ways to implement it is on userspace (cryptsetup) or kernel-space > (dm-crypt). > Unfortunately, if the attacker does not have the right kernel or > cryptsetup-tools self-destruct will not work. > > Maybe it would be better to just store 2 data-partitions in one (real) > partition ? > The idea would be the following: > There would be 2 passphrases and 2 virtual partitions: a storage > partition and > a fake partition. > The fake partition is mounted with the fake-passphrase and vice- > versa. > Both partitions have the size of the (large) storage-partition (thus > they > overlap), so if the fake partition is mounted the space the storage > partition > takes will be free-space. > If there is no real-space on the fake-partition left, the > fake-partitions starts to overwrite the storage-partition (which > is then > unuseable). > The storage-partition does of course not have this feature. > > Please let me know what you think of it. > I've thought about a self destruct feature too. It's probably something that would be best implemented in LUKS. Rather than having the complication of trying to create a new valid file system though, I'd rather it just destroy the LUKS master key rendering all data completely useless. Sure this might get you shot in case 1 and a maximum sentence in case 2 but some users may have data important enough that having it compromised is worse than other consequences. Of course, most of this discussion is a moot point if your attacker takes an image of your hard drive before attempting decryption (A very likely case). If you destroy the data or present fake data, they are going to know and just restore their backup and continue to coerce you. Brandon -- Brandon Enright Network Security Analyst UCSD ACS/Network Operations bmenrigh@xxxxxxxx --------------------------------------------------------------------- - http://www.saout.de/misc/dm-crypt/ To unsubscribe, e-mail: dm-crypt-unsubscribe@xxxxxxxx For additional commands, e-mail: dm-crypt-help@xxxxxxxx
