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

[Jacob Appelbaum]

Sai Emrys wrote:
> 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).
> 

Well it's an abandoned project. The implementation is full of details
and most of them are specific to the 2.2 Linux kernel. I don't remember
the on disk layout.

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

I don't believe that's the case. I don't recall though.

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

I understand the general idea you're discussing and it's basically a
reinvention of a deniable file system. In your hypothetical
implementation, you want to consider blocks on the disk almost in the
inverse manner that the dominate file system consider blocks.

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

The loop back or something like fuse is a way to map things onto the
VFS. The loop is very simple and uses a file or a few files. You can
stack and chain them. As an example... It would be possible to make a
raid array of loop devices that are backed by innocuous files on the
"normal" file system. It wouldn't be a binary blob either. It could be
just the low bytes of an icon file for example. That's the idea behind
many stenographic file systems that have been theorized. Take a look at
the paper by Ross Anderson:
http://www.cl.cam.ac.uk/ftp/users/rja14/sfs3.pd

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

An FAQ is not a specification. I want to see byte level layouts and
concrete definitions.

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

That's not entirely true.

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

I understand. You're discussing a deniable file system. You're making a
distinction of implementation details. The RHFS uses slack space as well
but the idea is that it's _OK_ to tell someone you're using RHFS. So yes
there are tools that mount this file system and ask for a password. I
don't think you can solve this issue. How will you mount your file system?

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

I think so far it's entirely obscurity. You have not defined a threat
model, an adversary or any security properties other than hiding the
data. That in itself is powerful but is certainly not _secure_ in a
meaningful sense.

Yes, it would probably require erasure coding because of the relation to
the "master" file system. In a sense, this is a parasitic file system.
To ensure that data is reliable, you should take a look at the
Tahoe-LAFS project for a good example implementation of erasure coding.

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

And how would you use those tools? This present a chicken/egg problem.
Isn't having the tools the same as having a dedicated partition now?

And if not, why can't you have a disk filled with noise and then simply
mounting the disk at an offset?

It's possible to have two normal file systems and as long as you never
overwrite the master file system, you can mount another directly on top...

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

I don't think it's a different question. I see it as part of the main
question. It is very important to define a threat model, an adversary
and then to show how your ideas can withstand such an attacker.

Where you store the data isn't important if it totally stands out. If
you make a graph of the data and you see extreme noise or obvious
compressed data (say with zlib like details), it's not going to bode
well for the user...

Just putting data into the slack space is a known technique, the key is
to do it in a useful way that provides some kind of actual protection...
That's part of why I linked to the sleuth kit project in my previous email.

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

Ha! Of course it depends on legal context! In a "free country" I have
right to remain silent. Yes, a grand jury can violate this right. And I
bet in very very extreme situations, it _does_ happen. Commonly in the
USA, I believe though that this is the exception to the rule. And the
idea behind M.A.I.D. is that if they don't know you're using it, it may
be too late when they discover it.

There are court cases that have reaffirmed that the fifth amendment
applies to passphrases.

YMMV.

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

Your idea also requires a special volume manager. How else do you access
the file system slack space?

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

I can have a single large encrypted partition with noise. I can have a
single unencrypted large partition and mount an encrypted file system
with a given offset. In either case, I probably have to have specialized
tools to do this.

I encrypt my entire drive and I am not fearful of the consequences of
this. I have crossed over fifty borders in the last year.

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

You can do this with an overlapping file system. A partition and a file
system aren't the master of all the blocks if you have another system
running on top. I think that idea isn't new but I certainly think that
it can be powerful.

> It just uses the space that the host isn't using.
> 
> Proper encryption of that space is a completely separate issue.
> 

I don't think they're _entirely_ separate. It will become obvious that
you have a covert channel by looking at the disk. Just because your
master file system doesn't say those blocks are a file doesn't mean that
a forensics person won't say that. It's obscurity and not actually in
the realm of cryptographic security. The rub with stego is that covert
channels often have a specific property and when you change them,
patterns emerge. For a long time, people suggested putting data into the
least significant bits of images. The argument was that it didn't change
the image when humans viewed it. The critical error was that a human
will use software and that the designers of this software won't look at
it the way that normal software will display it. Random data will stand
out! Rachel Greenstadt discussed this at Defcon 12 on page 35-37 of her
presentation:
http://althing.cs.dartmouth.edu/secref/resources/defcon12/dc-12-greenstadt.pdf

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

Yes. I understand that. You want to mess with the raw _partition data_.
You don't want to change the partition _table_ though. You might even
want to use the partition table and so on to predict the blocks to be
allocated by the host file system. Perhaps if you can, you can use them
in reverse order. You'll end up with the noise problem though.

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

You can't effectively hide things when you just side step this question.

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

This will also be detectable.

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

Yes, you're speaking of error coding. Multiple copies of data. I
understand the distinction of this idea and RAID. RAID applies the idea
in a very general and high level way.

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

Sure.

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

Well. Sorta. Read up on NTFS Alternate Data Streams. Yes, it's true that
the space is accounted for. But it's basically a not so covert channel:
http://www.windowsecurity.com/articles/Alternate_Data_Streams.html

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

I understand the idea. I just think it's half-baked. :-) It's not a bad
idea though! It's related to a lot of areas of study and I suggest you
read some of those links.

I believe that if you wanted, you could do what you suggest by simply
creating a map of blocks on the disk that you want to allocate or
ignore. I do not believe it will actually be hidden from an attacker
who's looking. Furthermore, I do not believe it will provide real
security if the end game starts with detection.

I think you can make such a system but we've not arrived there in this
discussion...

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/90f95cd3/attachment-0003.sig>