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

Sai Emrys noisebridge at saizai.com
Thu Sep 24 10:50:30 UTC 2009


On Thu, Sep 24, 2009 at 3:16 AM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> 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.

If I'm understanding it right, this can't coexist with a preƫxisting
non-RHFS file system (e.g. a random NTFS disk with data that mustn't
be touched).

And it can't work very well with the disk being in use - you have to
unmount and remount.

I want this to be something you can add to any extant file system - no
special prep, no special host file system or meta-filesystem (like
LVM), no files or partitions or anything like that reserved for the
container.

> 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).

I am.

But again, this requires taking up a large, visible, suspiciously
noisy file. If you go away, that file remains until explicitly
deleted, taking up space that the host file system can no longer use.

I want it to be totally invisible.

> 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?

Their website has a pretty good FAQ.

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

Yes, but you know that the areas aren't part of a normal file system.

In my version, *everything* looks like e.g. yet another boring NTFS
drive. No "unpartitioned" space, no large unreadable files.

I know that TC/RHFS/etc provide cryptographic deniability, but they
leave very suspicious telltales. Or for that matter, require you to
have the whole damn partition / disk be suspicious.

Sure you can deny that there are any more partitions on that RHFS -
but in my case there wouldn't even *be* a noticeable FS in the first
place.

> Perhaps I misunderstand. It sounds like you're describing a system that
> sounds like it relies on obscurity for its security properties.

Only partially. It *exists* in obscurity; it uses the space the host
file system isn't using at the moment. The host file system is still
free to allocate a file there whenever it wants.

This isn't really saying anything about how the crypto layer might
work. I'm presuming some sort of TC-like method would be used, though
the file table would need to be distributed across the disk (because
any chunk might get claimed by the host at any time - TC only stores
them at the front or end of the container).

> 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.

Sure, that's good and all. It's just a completely different question.

The thing I'm raising here is a question of *where* you store the
data, not of *what* you store or how you encrypt it.

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

How can't I? It seems to me to be tangentially to the main topic -
hence an "aside".

> I have the right to remain silent.

Not always. The Toorcamp talk by Tyler Pitchford about this was quite
interesting, and gave multiple examples of times when you can be
forced to give up passwords else face indefinite time in prison for
contempt.

I punt to that for details; here's a video of another iteration of it:
http://video.google.com/videoplay?docid=-1692129062873726062 .

> 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?

TC and any other file system that requires either
a) a special volume manager, or
b) a reserved chunk of space (whether a file, partition, or whole disk)
... is suspicious.

Yes you can deny any particular interpretation of that suspiciously
random data through various clever means, but it's still suspicious
and easily identified as such. (Seriously, how many good explanations
are there for why you have a large chunk of your drive "unpartitioned"
or why you have a large file containing "random" data?)

This file system lets another host file system completely own the
drive. It makes no attempt at all to reserve any space for itself.
Every bit of disk space looks like it's already accounted for by a
perfectly normal file system that's in use all the time, currently
mounted, takes up the whole disk, etc.

It just uses the space that the host isn't using.

Proper encryption of that space is a completely separate issue.

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

No. I don't want to change the partition table at all. It can stay
exactly like it came stock from the dealer, with the same file systems
it always had. *No* special raw partitions.

> How do you keep the map secure?

"Secure" as in crypto: make it encrypted, to read it (and even thus
validate whether it *is* a file system map) you need the key. Same as
TC. But as I said, this is tangential.

"Secure" as in data loss: distribute it broadly across the disk, so
it's unlikely that all copies of it will be wiped when (say) some new
large file is downloaded (and thus wipes out a bunch of the "free"
chunks you're using).

So long as you are monitoring churn and can catch it in time, you can
rewrite data that is insufficiently replicated across the disk (note
here I do NOT mean replication as in RAID - it's *intra*-partition)
more widely.

But in the event that the host file system uses up the entire disk -
which it's totally free to do - then the free space file system
disappears. As I said, it does NOT guarantee stability at all.

> That seems rife with issues. Though it does sound a lot like the hidden
> NTFS streams...

... which still take up space on disk. They're just hidden from the
user, not hidden as in not being officially allocated space.


If you still think this directly has to do with crypto, that RHFS /
TrueCrypt / etc do this, or that it involves any chunk of disk you can
easily point to, you're not understanding what I mean, and I don't
think I can explain it better. :-/

Hope that helps,

- Sai



More information about the Noisebridge-discuss mailing list