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

[Sai Emrys]

On Fri, Sep 25, 2009 at 2:03 AM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
>> That's certainly nicer, but it still has the problem that you're
>> modifying extant files (possibly in ways that are detectable -
>> steganography proper of this kind requires a lot of format-specific
>> hackery which might not work equally for all versions of all readers
>> thereof), or at least leaving around cruft (albeitg more innocuous
>> cruft).
>
> Yeah. You'll always have this problem with slack space too:
> http://www.wikistc.org/wiki/Slack_space_data#Storing_data_in_slack_space

Definitely. This is why I think storing in free space is better - it's
less of a hack and less detectable. I just figured slack space is also
a candidate for the underlying storage layer to use. Potentially it's
a bit more stable than free space, which is good 'cause it's a tricky
issue where to put your indexes if you want it to survive a reboot.

>> A FSFS would have the advantage that if you stop maintaining it, it
>> simply disappears by default. No cruft, no altered files, not much of
>> anything really for forensics to find except (as Alex pointed out to
>> me) that your free space is suspiciously random (rather than being
>> snippets of old files). Of course, that can equally be caused by any
>> number of free-space-wiping security daemons.
>
> Yeah, I mentioned that. It's why lots of systems start with a fully
> random set of data on the platters.

Always useful, certainly.

But in the FSFS case, given that there's a normal file system there,
ordinary churn will wipe out that random preset. (Remember, the host
file system isn't doing anything to try to preserve semblance of
randomness or encryption or the like.)

So you'd need some alibi for the fact that free space is still
persistently random. Any of those free-space-wipers is a pretty good
one.

> http://www.o3one.org/hwdocs/fat_fs/sfs3.pdf

That works, thanks. Will queue.

>> IMHO, it's "okay" only in a cryptogeek sense. The fact that you have
>> it will attract bad attention.
>
> I don't think that's entirely false but I don't see how you avoid this
> issue when someone is looking closely if you keep everything together on
> a single laptop drive.

First off, you at least have a shot at someone not looking closely
*enough*. In this case, the only two telltales are
a) free space is too random and
b) there might be a bootstrapper left lying around

So it's quite possible that even with an ordinary forensics pass they
just won't find anything suspicious enough to bring out the big guns.
Or for that matter, the password subpoenas. (One has to know there's
something there before asking for the password for it...)

> Aren't the tools for mounting the disk now the telltale sign? I mean,
> rather than a partition table or a password prompt?

Certainly - b) is a problem, but it's a standard issue. USB or network
loaded tools that go straight into RAM and don't reside on disk are
the usual responses. I don't really have anything novel to suggest
here.

>> However, it's not present if you don't expect it to be there on
>> reboot. If it lives in RAM, and the cryptokey is never stored to
>> (local) disk (perhaps a remote disk, a la MAID?), then short of a
>> rarely-done power-preserving system capture or cold boot attack,
>> there's no evidence it was ever there.
>
> Hrm, I don't follow. What isn't there? The tools? The data on the disk?

The data. If the bootstrapping tools aren't stored on disk in the
first place, the only evidence - the crypted data in the
soft-allocated "free" blocks - will get wiped out just by normal
churn. No explicit action needed at all; no cruft left over.

See above re tools.

> You can use the disk like a normal file system with overlapping/offset
> mounted file systems. The main file system can be mounted read only and
> then from there, you can mount a second file system. Only one of them
> will make changes to the blocks on the disk.

But that requires you to modify how the host file system is mounted. I
want this to be able to run with the host not knowing a thing about
it.

For instance in the zombie example I gave, it'd be unacceptable to
make the host's c:\ drive read-only, even briefly. That both gives you
away and harms the host. I want the host to never know anything
happened, not even from resource congestion. (At least, not from
exceeding its capacity. Certainly a careful analysis would show it was
running more, and that'd impact MTBF 'cause it's being used *closer*
to capacity more of the time...)

>> I think you're used to thinking in terms of cryptosystems - as I said,
>> my idea simply doesn't really address that layer of things. I'm
>> presuming that it'll be there in any of the usual ways.
>
> What you're saying doesn't really make sense. There isn't 'crypto' in
> any usual way for file systems (unless you count the Ubuntu installers
> option for encrypted disks)...

I meant crypto in the sense that eg TC implements it. So for example,
the index file isn't identifiable as such without a key, nor is any
data.

This is totally unoriginal which is why I'm glossing over it; it
doesn't really have much to do with the FSFS idea directly.

> Slacker by the Metasploit project may be of interest to you:
> http://www.metasploit.com/research/projects/antiforensics/

Neat.

> Strong stenographic systems generally rely on cryptography.

Because they're usually meant in the sense of taking over a host
*file* and twiddling it a bit to add secret data that to the host
isn't perceptibly different.

What I mean here (aside from the potential slack space modules) is
quite weaker - it's just putting data where data isn't expected to be.
Not trying to insert it into a host file.

> I think that FragFS may also be another relevant link:
> http://www.blackhat.com/presentations/bh-federal-06/BH-Fed-06-Thompson/BH-Fed-06-Thompson-up.pdf
>
> Grugqs BH talk (Data Mule FS) isn't bad:
> http://www.blackhat.com/presentations/bh-usa-05/bh-us-05-grugq.pdf

Both quite neat. Looks like I have a bunch of reading to do. :-P

On Fri, Sep 25, 2009 at 2:19 AM, Mountain Sky
<mountainoceansky at hotmail.com> wrote:
> Sorry, that wasn't clear. I mean, have the entire program re-write all its
> data sets, including the re-writing program that keeps reinstalling itself.
> It would do this without taking stock of what data chunks are in short
> supply, and simply evenly distribute all the information equally across not
> only the fragmented places it used to occupy, but also any new niches that
> opened up, making it as dynamic of a system as the file structure inside of
> which it hides.

Attempting to rephrase, tell me if this is accurate:

You're suggesting that the FSFS maintainer daemon just continually
(subject to usage constraints) keep distributing files in free space -
so there should be basically *no* "free" space that isn't quickly
being used for the distribution, ensuring that it's as widely
distributed and thus hard to corrupt as possible.

This would probably work, though
a) I suspect it'd be suspect to thrashing (eg via temp file churning
constantly de- and re-allocating certain sectors); you might need to
come up with some clever constraints (e.g. maybe a chunk has to go
unused for a while before getting soft-allocated?)
b) it'd increase load significantly - though if your load-regulator is
working this oughtn't be a problem

You'd also need some good mechanism for determining which bit to
propagate first, but I suspect that some project like Chord or Tahoe
has already figured out a good solution for this.


Hmm... I wonder if it'd be possible to have a index-less FSFS. It'd
mean that doing the equivalent of 'ls' takes a long time - you'd have
to brute force search every "free" chunk. However, I suspect one could
do something clever like a ring addressing system that makes lookups
reasonably quick (if they're available at all).

I've never heard of something like that being used intra-disk, though;
only contexts I've seen it in are e.g. Freenet's method for
determining where to store and/or look up data chunks, in terms of
full computers. But I suppose that one could conceive of the free
chunks of a hard drive as being similar to the live nodes of a
network; they have some similar properties (constantly coming and
going, for instance). It might be a useful analogy.

- Sai