Weekly Edition
Return to the Kernel page
| |||||||||||||
DM-Steg
DM-Steg is a kernel module
that adds steganographic encryption to the device mapper. "Steganographic"
means that the encrypted data is hidden to the point that its very
existence can be denied. "Steg works with substrates (devices
containing ciphertext) to export plaintext- containing block devices, known
as aspects, to the user. Without having the key(s), there is no way of
determining how many aspects a substrate contains, or if it contains any
aspects at all." The initial release of this module has just been
announced.
"The code has only ever been tested on my PC, but it works very
nicely for me and has stopped eating my data, so I figure it's ready for
public consumption!" See this document [PDF] for details.
(Log in to post comments)
DM-Steg Posted Dec 2, 2011 0:02 UTC (Fri) by PaulWay (✭ supporter ✭, #45600) [Link]
I keep thinking: I'm sure these are clever and probably well-written attempts to give people deniably-encrypted storage, but is it really answering the problem? The very existence of random data on your hard disk is probably a sign to some organisations that you're hiding data - sure, you can tell them what the first aspects are but it's not going to get you off the hook. And when they realise that there's multiple possible aspects, they're going to apply pressure to get what they think you're hiding. Denying the existence of another level is like denying that the data is encrypted in the first place: it only satisfies people who believe you're innocent and only works where you can say "Right, I've divulged all my information, I can go now".
Even a system that works invisibly - it hides data steganographically in your existing files in such a way that you can't even be sure that the data is there - doesn't help if there's a known block device that provides access to that data. The evidence of crypto drivers on your machine is going to be enough to make you suspicious. Even a driver which itself is steganographic - a hidden, unpublished set of switches allow you to use it as a steganographic driver - isn't going to work if the source code is published, and even probably if it isn't.
The fundamental problem here is that once you're suspected it's impossible to prove your innocence. Any attempt can be seen as hiding your guilt. Even the existence of a perfectly clean file system with no suspicious random patches could be considered suspicious. Are we really protecting those people?
Maybe, though, it's good enough just to provide this kind of encryption for people like you and I who want to keep our emails private and our bank account details even more so.
Have fun,
Paul
DM-Steg Posted Dec 2, 2011 1:23 UTC (Fri) by ras (subscriber, #33059) [Link]
There is a simple answer to random data problem: just have distributions write random data to every unused sector on the disk in the background after install. Maybe have it as a opt-out checkbox.
I am pleased to see dm-steg and the like for a similar reason. If you've gone to the trouble of installing specialised software (eg, TrueCrypt) then plausible deniability is pretty hard. But now just about every linux default install comes with the tools that can do the job so that particular issue has gone away.
DM-Steg Posted Dec 2, 2011 8:48 UTC (Fri) by gmaxwell (subscriber, #30048) [Link]
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.
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.
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.
|
|||||||||||||