LWN.net Logo

DM-Steg

DM-Steg

Posted Dec 2, 2011 8:48 UTC (Fri) by gmaxwell (subscriber, #30048)
In reply to: DM-Steg by PaulWay
Parent article: DM-Steg

Random fill is the recommended behavior for anyone using any disk crypto— just because it prevents someone without the key telling how much space is used. And disk crypto is super useful due to theft, hardware that fails and gets RMAed, etc.

And what ras says for the free space also applies for the software— if the DM-steg becomes a stock OS component then having the software by itself would not arouse suspicion.

Leaks of the existence of additional layers could be hidden pretty well: In your second hidden aspect put the disk image of another system (perhaps a copy of the tails distro modified for persistent storage http://tails.boum.org/index.en.html). Then you just need to run "<space>dm-stegmountstuff; qemu-kvm --hda /dev/mapper/whatever" and you'll be fairly close to leak free, though some care will be needed to make sure nothing from kvm goes into syslog (and so long as you don't slip up, forget the space, and let that into your shell history— we could make this better if there was a default list of "cryptographic commandlines" which were automatically excluded from the shell history).

Yes of course, someone trying to rubber-hose you could never be sure there aren't more layers to the onion. In _most_ situations this should be directly protective: It makes coercive interrogation more obviously ineffective as there is no 'fair' way to match the force to the cooperation.

In the rare other cases where the steg-hiding means the attacker will simply continue until you die, DM-Steg provides another kind of protection: It creates the ability to pre-commit to dying for your cause. If your Nth aspect contains data which will cause your friends and family to come to harm, the fact that giving the interrogators that key will still not satisfy them and prevent them from killing you may be the motivation you need in order to be successful at withholding the information when the time comes. Gruesome, and hopefully applicable to only very few people. Though again, the interrogators can think this through too, and may reconsider their approach.

More pedestrian is that encryption which protects against more situations is more valuable and the additional situation (even some far off fanciful attack like coercive interrogators, or providing 'cover' for others who face that risk) may be enough to tilt someone's cost/benefit analysis enough to overcome the learning curve get them to adopt encryption which protected them against many common and real threats.

I know many people who have installed and become familiar with Tor because they support the free speech of people in some far off land— but the practice of deploying it gives them skills and builds infrastructure that protects their free speech too.


(Log in to post comments)

DM-Steg

Posted Dec 2, 2011 17:16 UTC (Fri) by jimparis (subscriber, #38647) [Link]

> Then you just need to run "<space>dm-stegmountstuff; qemu-kvm --hda /dev/mapper/whatever" and you'll be fairly close to leak free, though some care will be needed to make sure nothing from kvm goes into syslog (and so long as you don't slip up, forget the space, and let that into your shell history— we could make this better if there was a default list of "cryptographic commandlines" which were automatically excluded from the shell history).

I've never heard of that "leading space prevents it from ending up in your history" -- it doesn't work on my shell (bash 4.1.5).

Of course, leaving it out of your history is just one problem.
If you're trying to hide the fact that you've run kvm, you'll also have to make sure none of it gets swapped, things like the atime of the kvm executable or any loaded libraries don't get touched, the kvm window doesn't end up in your saved desktop session, etc.

DM-Steg

Posted Dec 2, 2011 18:00 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

In zsh it is "setopt histignorespace". I don't see an equivalent in bash.

DM-Steg

Posted Dec 2, 2011 18:01 UTC (Fri) by nybble41 (subscriber, #55106) [Link]

> I've never heard of that "leading space prevents it from ending up in your history" -- it doesn't work on my shell (bash 4.1.5).

You have to set HISTCONTROL=ignorespace to get that behavior. It's not the default.

DM-Steg

Posted Dec 2, 2011 18:28 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]

I've never heard of that "leading space prevents it from ending up in your history" -- it doesn't work on my shell (bash 4.1.5).
Ah! set HISTCONTROL=ignorespace (I've had ignoreboth, which ignores space-prefixed and duplicates for so long that I thought it was a default).
If you're trying to hide the fact that you've run kvm, you'll also have to make sure none of it gets swapped,
Again, I was making assumptions from my own configuration. But it's a hard thing... (In my case "swap /dev/sda3 /dev/urandom swap,cipher=aes-lrw-plain,size=256" in my crypttab makes my swap completely ephemeral, I run noatime on my systems, don't use a session managing desktop environment). It was foolish of me to make it sound so simple— it's not— but nor is it insurmountable.

DM-Steg

Posted Dec 2, 2011 19:40 UTC (Fri) by giraffedata (subscriber, #1954) [Link]

we could make this better if there was a default list of "cryptographic commandlines" which were automatically excluded from the shell history

Bash's HISTIGNORE might be what you're talking about. With it, you can specify in your personal or system Bash profile that commands matching certain patterns won't go into the history.

DM-Steg

Posted Dec 2, 2011 20:48 UTC (Fri) by jackb (subscriber, #41909) [Link]

Or you could just use "ln -s /dev/null ~/.bash_history"

DM-Steg

Posted Dec 2, 2011 21:48 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]

Thats killing a fly with a sledgehammer. Shell history is helpful.
Also, export HISTFILE=/dev/null is probably a more proper way. :)

DM-Steg

Posted Dec 3, 2011 3:35 UTC (Sat) by jackb (subscriber, #41909) [Link]

Now that you mention it I do seem to have a tendency to apply sledgehammer types of solutions to computer problems.

Besides using a symlink to /dev/null for .bash_history I once built a framework for generating initramfs images that avoided the difficulties of static linking all pretenses of elegance or efficiency by just throwing the entire contents of /etc /bin /lib* and /sbin into a giant cpio file.

Then there was the time that I was annoyed by automatic vt console blanking so I found the line in the kernel that stores the default timeout value and patched it to 0 (disabled)...

DM-Steg

Posted Dec 5, 2011 14:07 UTC (Mon) by sorpigal (subscriber, #36106) [Link]

Seems like a waste. Just unset HISTCONTROL and run history -c. From there you get history but it won't be written anywhere (and you don't waste cycles trying to write to /dev/null later).

DM-Steg

Posted Dec 3, 2011 3:46 UTC (Sat) by wdaniels (guest, #80192) [Link]

> It makes coercive interrogation more obviously ineffective as there is no 'fair' way to match the force to the cooperation.

I think this is the main point. The most likely scenario (it seems to me) would be where a court of law attempts to compel the disclosure of an encryption key. I don't see how legally a court could imprison somebody indefinitely merely on unproven suspicion that multiple aspects of some data exist.

DM-Steg

Posted Dec 3, 2011 22:50 UTC (Sat) by GhePeU (subscriber, #56133) [Link]

> I don't see how legally a court could imprison somebody indefinitely merely on unproven suspicion that multiple aspects of some data exist.

Ha! Tell that to H. Beatty Chadwick.

Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds