CLI Magic: ext2hide veils sensitive files (Linux.com) [LWN.net]

CLI Magic: ext2hide veils sensitive files (Linux.com)

Posted Jun 12, 2006 17:27 UTC (Mon) by ekj (guest, #1524) [Link]

Pointless. Utterly pointless.

This is not in any way hidden, it just adds a small non-mounted filesystem that you require a special tool to easily list.

If you *do* care about hiding information you use for example TrueCrypt with the hidden inner volume. (also GPL). That gives you true plausible deniability like so:

Create say a 10GB image-file, encrypted and loopback-mounted with TrueCrypt.
Put some mildly embarassing, but not illegal material on this filesystem. Say some porn or something.
Use Truecrypt (and this is the clever part!) to create a second encrypted filesystem in the free space of the first volume. If the outer volume is half-full, this inner volume can be 5GB large.
Store the really secret stuff on the inner volume.

TrueCrypt volumes are made so that unless you know the secret key, it is impossible to tell if some amount of data is a TrueCrypt filesystem, or if it is just random noise.

So, if "The Man"(tm) knocks on your door and demand you hand over the encryption-keys to your encrypted files, you can hand over the keys to the outer volume.

There may, or may not, even *be* an inner volume. There's no way for "The Man" to tell. The *default* in TrueCrypt is *not* to have an inner volume. How can they prove that you did *not* choose the default, and that you're really hiding something more than your porn ?

In any halfway modern state you are unlikely to be convicted of withholding the encryption-keys to a filesystem -- when that filesystem and the corresponding keys may not ever have existed.

Morale ? Plausible deniability and cryptographically secure information-hiding is a solved problem. This utility does neither.

CLI Magic: ext2hide veils sensitive files (Linux.com)

Posted Jun 12, 2006 17:36 UTC (Mon) by gdt (subscriber, #6284) [Link]

Wouldn't a journaling fileystem show differing journals between the case where there is an inner volume and where there is no inner volume? Would this lead to a lack of deniability?

CLI Magic: ext2hide veils sensitive files (Linux.com)

Posted Jun 12, 2006 18:24 UTC (Mon) by pflugstad (subscriber, #224) [Link]

If I understand it correctly, the inner volume just uses the "unused" part of the outer volume - and since the whole thing is scrambled/encrypted, it's impossible to tell if that area is being used or not unless you know the key. I don't think there's anything connecting them or protecting the inner volume from being overwritten by the outer volume.

To accomplish this, TrueCrypt requires that you use use FAT for the outer volume (I don't know about the inner) - so that all the data is at the "front", and the outer volume starts at the "back". So no journal.

FYI, TrueCrypt is at: <ttp://www.truecrypt.org/>

This showed up on Schneier's Blog a little bit ago.

CLI Magic: ext2hide veils sensitive files (Linux.com)

Posted Jun 12, 2006 18:33 UTC (Mon) by Ross (subscriber, #4065) [Link]

I think the other poster meant that if this is in a container on another filesystem, like a loop block device on an ext3 filesystem, the fact that the "unused" portions of the fs were being modified would be recording in that filesystem's journal.

At least that's how I read it.

CLI Magic: ext2hide veils sensitive files (Linux.com)

Posted Jun 14, 2006 17:39 UTC (Wed) by ekj (guest, #1524) [Link]

The journal of the "outer" filesystem would show no such thing, as the "inner" filesystem is stored in unused space in the outer one.

One would, with several snapshots of the loopback-file *and* the decryption-key for that volume, be able to tell that for some reason the data in the *unused* parts of the filesystem keeps changing.

This would be highly suspicious, and probably enough to destroy plausible deniability.

But assuming the attacker doesn't have several time-separated snapshots of your loopback-file, and that you changed stuff on the inner volume between these snapshots, the deniability holds.

As to the journal, I think TrueCrypt support "inner volumes" only on FAT outer filesystems, it's easier there because the unused space is continous at the end of the partition/loopback-file.

But in principle it could be done on any filesystem. One would need special drivers for the outer volume to avoid clobbering the inner volume when changing the outer volume.

CLI Magic: ext2hide veils sensitive files (Linux.com)

Posted Jun 12, 2006 17:46 UTC (Mon) by nix (subscriber, #2304) [Link]

The UK is not a halfway-modern state :(((

CLI Magic: ext2hide veils sensitive files (Linux.com)

Posted Jun 13, 2006 20:14 UTC (Tue) by kokopelli (guest, #11341) [Link]

Obstruction of justice.

It has a bit of a bad rep since overzealous prosecutors have abused it, but failing to comply with a lawful search order would definitely get everyone's attention. The prosecutors don't have to prove that a hidden FS actually exists, just that it's not reasonable to believe that it doesn't exist.

Remember that a "jury of your peers" doesn't mean other crypto-friendly geeks, it means that half of them would have voted for Bush and most won't understand why you have even one encrypted FS if you have nothing to hide.

In our countries, a decent lawyer could get that jury to understand the need for overt encryption to protect doctor-patient or lawyer-client communications, and could probably get a jury to understand the need to protect reporter-confidential source communications. You might have to spend time in jail for refusing to comply with a court order, but you don't have to be worried about rubber hoses in a back room. So encryption, per se, isn't necessarily a red flag....

... but if I were on a jury with somebody who was caught chatting up 13-year-old girls online and who had an 10GB "plausible deniability" encrypted FS, I would be asking some hard questions about just how reasonable his explanation was given the other information at hand.

StegFS, was CLI Magic: ext2hide veils sensitive files (Linux.com)

Posted Jun 15, 2006 21:22 UTC (Thu) by Segora (subscriber, #8209) [Link]

See also http://www.mcdonald.org.uk/StegFS/

CLI Magic: ext2hide veils sensitive files (Linux.com)

Posted Jun 22, 2006 7:21 UTC (Thu) by infidel (guest, #38574) [Link]

The point of the tool is really to do neither. I was not seeking to build a cryptographically-secure, plausibly-deniable filesystem for secure data storage when writing this tool, nor would I present it as such. I am well aware of the fact that security through obscurity does not work, do not mistakenly believe as many others do that some homebrew rot-13-type BogoCrypt utility could outdo Blowfish or other well-tested encryption methods, and I would not seek to misrepresent the tool as anything other than what it is. As is noted in all of the accompanying README files, and the author of the Linux.com article also kindly noted early on: the program is a proof-of-concept utility.

Perhaps some history of the tool is in order: I was poring through the ext2 filesystem specifications as preliminary research for an upcoming project, and when examining the details of the superblock, I noticed a section of data that appeared to be free across all of the block groups, and mentioned this to some cow-orkers and a couple of friends. After testing this with 'dd' and seeing that it would indeed be feasible to store files here, it was suggested that I build a tool to do this automatically. Once an early version of the tool was built and worked well, the testers further suggested that I release it, and so I did. I noted in great detail several times in the accompanying documentation the method which the tool uses for storage, the caveats in using it and that it was a proof-of-concept, nothing more.

Joe Barr, the author of the article contacted me a couple of weeks ago to ask me some further questions about the utility, which I gladly obliged. I'm not sure if you've ever been interviewed before, but you generally have little to no influence over the resulting article. The somewhat hyperbolic tone of the article regarding the MPAA and RIAA was Barr's own writing style. I don't mind the increased exposure, though, as I had written a decently complex build system and test harness into the installation routine of the program, and it has given me some wider exposure of the tool from which I have received good additional feedback on this system and the tool in general.

The original name of the tool was actually going to be "sbstash," which I think may more accurately describe its functionality. The name change was suggested by one of the early testers, to go along with the ext2* theme of utilities designed for this filesystem. However, I may change it back to the original when porting it to UFS/UFS2, both because it will no longer be ext2-specific, but it will also allay the possibility of incorrect assessment of the intent of the tool based on reading an executive summary and drawing faulty inferences.

Sincerely,
Jason McManus