[Noisebridge-discuss] M.A.I.D. was: Freespace / slackspace file system

[Jacob Appelbaum]

Sai Emrys wrote:
> On Thu, Sep 24, 2009 at 1:52 AM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
>> "Rubberhose is a deniable cryptography package that lets someone not
>> wanting to disclose plaintext data corresponding to their encrypted data
>> show that there is more than one interpretation of the latter."
> 
> AFAICT, RHFS is essentially the same conceptually as Truecrypt's inner
> / outer containers - it takes over some chunk of hard drive space
> (whether a file or partition), spams it with random data, and adds in
> its crypted data such that the data hides within the random noise in a
> deniable way.

Sorta.

The entire disk is filled with noise. You decrypt a part of the disk
with a given passphrase and a different part of the disk with another
passphrase, etc.

> 
> This is not what I want, though it has definite similarities. I want
> something that lives *within* another perfectly normal, unencrypted,
> naïve file system. So not just can you deny that any particular chunk
> is data (vs. random noise), you have an eminently plausible cover
> story - namely, that that chunk of disk is already owned by another
> file system! (... although that file system claims it's free space,
> and secretly we're using it to store data)

To make that happen, you basically have to create the same disk full of
random data that the RHFS starts with... You're starting from a place
with no password and I think you can even configure the RHFS to have no
boot password. You'd just remount/bind with a different password to
access the other parts of the system.

Are you familiar with a loop back file system? If you aren't, you can
just stuff an arbitrary binary file somewhere on the file system and
mount it with a passphrase (using dm-crypt or loop-AES, etc).

> 
>> Generally, I believe that you want to read about Deniable Encryption:
>> http://en.wikipedia.org/wiki/Deniable_encryption
>> http://en.wikipedia.org/wiki/Deniable_encryption#Software
> 
> AFAIK, this is 'deniable' as in Truecrypt - you can offer multiple
> interpretations of a chunk of noise (e.g. an outer container, an inner
> container, plain randomness). It's not 'deniable' as in 'this space
> isn't even being reserved, it's part of an extant normal partition'.
> 

Truecrypt certainly did not invent this idea. I'm not sure of their
solution's security level either. Is there a specification that I can read?

> Perhaps I misunderstand it, but that sort of deniability seems
> significantly weaker to me, because you have to reserve chunks of disk
> for the crypted data. And it's rather suspicious when you have e.g. a
> mutli-gig file that isn't readable, or a portion of your hard drive
> that claims to be unpartitioned.
> 

I disagree. The entire disk is filled with random data from the start.
You don't know what areas belong to which unlocking key.

> 
> Perhaps that's an unclarity in my description, since there're two
> different meanings of 'free space'.
> 

I understand the difference.

> Truecrypt (and, AFAIU, Rubberhose) partitions use 'free space' as in
> free according to the partition table, i.e. chunks of space that claim
> not to have a file system on them at all, which is thus a stable chunk
> of space that Truecrypt has a de facto exclusive lock on. Or they use
> files, which are still reserved chunks of space. It provides
> deniability through stuff like two-layer file systems where one can
> expose the outer layer without admitting the existence of the inner
> layer - but still Truecrypt has to have the lock on the whole thing.
> One can't say "look, the main file system already has that part".
> 

Sounds like Truecrypt didn't design this to hide that Truecrypt is being
used. That's a hard thing to even try to get right.

> What I mean is 'free space' as in free according to the file system,
> i.e. chunks of space that aren't currently allocated to a file but ARE
> already claimed by a perfectly normal, non-crypto file system, which
> will be fragged and dynamically changing all over the host partition,
> and which this hidden file system would *not* have any lock on at all.
> 

Sounds like what I remember of the RHFS or of Phonebook (a RHFS clone):
http://www.freenet.org.nz/python/phonebook/diagram1.png

This of course assumes that you're using the Phonebook FS rather than
say EXT3 as your root file system.

> My version is much less stable - one can't depend that files that are
> saved will stay there, and one might need to move 'em around a lot -
> but it's also much more deniable, and much nicer to the host in that
> it allows the host to use the entire disk space if it wants. Truecrypt
> et al require suspiciously random-looking reserved chunks of space,
> and take up space that the host then can't use.

Perhaps I misunderstand. It sounds like you're describing a system that
sounds like it relies on obscurity for its security properties. I am
very wary of such a system. Without cryptography, it's absolutely a
matter of reassembling files. With cryptography, the slack space is
filled with encrypted bits. It will stand out from the non-encrypted
file system bits. This is why most disk crypto systems fill the entire
disk with noise.

> 
> My version is intended to be operable such that one could have a file
> system on someone's computer without them even knowing about it,
> having any less space for themselves, being able to detect it, or
> otherwise interfering with their operation. It'd look like a perfectly
> normal disk - with all space accounted for by perfectly normal file
> systems. It'd just secretly have something living in the cracks.

I understand. I think the idea is nice but very difficult to specify and
very difficult, if not impossible to do in a secure fashion.

> 
> FWIW, I like and use Truecrypt, and I suspect that some of it might be
> portable to use with this concept. It's just different.

I don't use it. When last I checked, it wasn't free software and it
didn't have a free build chain. We also broke it during the Cold Boot
research project.

> 
>> If you do this, you can simply have a key
>> that expires. You can fully comply with the law, telling a password when
>> required by a court.
> 
> Legal aside: wouldn't this count as destruction of evidence, if you
> know that it will expire (and destroy the data) but don't disclose
> that knowledge and/or intentionally stall?
> 

How can you ask that question and preface it with "legal aside?"

I have the right to remain silent. Sometimes forensics work will not
take place for many months. If I have a threshold of two weeks, I will
not even be asked for a passphrase for a longer time than my personal
threshold. As I said in the talk, changing the threshold when you know
you're under investigation is probably obstruction of justice. YMMV.

> Very neat idea, though. I like it, and it'd potentially work well
> together with mine.
> 

I don't see how your idea is workable. I don't understand your threat
model nor how your system is actually secure against someone who
understands how it works. Can you explain the threat model and a general
overview of the specification?

> Blackhat example: you have a zombie on someone's computer that you're
> using as a distributed database storage node. You want to encrypt the
> data on disk and store the key in RAM, but not store the key on the
> hard drive anywhere. So you insert the key to *other* computers in the
> botnet, and the zombie has to request it from them to be able to
> unlock its own database. Of course there are lots of attacks on this
> [e.g. anything that nabs it while in use], but it'd be a nice deadman
> layer. And with my sort of free space file system (FSFS?), you
> wouldn't even be able to tell there was a file system ever there in
> the first place - not even any large files of "random data",
> "unpartitioned" spaces on the disk, etc.

(Hrm. So I generally don't care for the terms "blackhat" or "whitehat"
as they're largely meaningless. What's a whitehat who gets a speeding
ticket in a car with fly by wire controls? What's a blackhat that helps
overthrow a theocracy by leaking sensitive information gained by illicit
means?)

I see. You want to stuff data into a raw partition and keep a map
somewhere...

> 
> It'd completely disappear when not used - the natural churn of the
> host file system would destroy it entirely if it's not actively being
> maintained.
> 

How do you keep the map secure?

> Whitehat example: you want to take advantage of your network of
> various regular computers. They're being used by developers, execs,
> etc etc - they're not dedicated machines, and you don't want to
> interfere with them. But you can siphon off a bit of their CPU (when
> it's not peaking) and disk speed (when it's not in use), and treat 'em
> as a big distributed memcache / bigtable / whatever cloud. So you can
> use whatever disk space they're not using, without ever having to
> worry about impinging on the user's preeminent right to use all of the
> disk they want - it'd be totally transparent to them.
> 

That seems rife with issues. Though it does sound a lot like the hidden
NTFS streams... Also you may be interested in Sleuth Kit. They look for
simple versions of this (such as sequential data in unused blocks, etc).

Best,
Jake

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 155 bytes
Desc: OpenPGP digital signature
URL: <http://lists.noisebridge.net/pipermail/noisebridge-discuss/attachments/20090924/cae7c8cc/attachment-0003.sig>