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

[Sai Emrys]

On Thu, Sep 24, 2009 at 5:45 PM, Jacob Appelbaum <jacob at appelbaum.net> wrote:
> 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.

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

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.

> Take a look at
> the paper by Ross Anderson:
> http://www.cl.cam.ac.uk/ftp/users/rja14/sfs3.pd

That link doesn't work for me (forbidden). Ditto .ps and .pdf. Perhaps
it's a stale link?

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

Sorry, I wouldn't know better than you (probably less) where to find that.

I certainly don't have a spec for my FSFS idea; it's just an idea at
this point. And frankly I don't have the skills (currently?) to
implement it; I've never done anything significant that's system
level.

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

IMHO, it's "okay" only in a cryptogeek sense. The fact that you have
it will attract bad attention.

Whereas if they can't show that you have a crypted file system in the
first place (rather than merely that you haven't given up all the
keys), you're better off.

Yeah yeah, security through obscurity isn't; that's what an additional
crypto layer is for. But it sure helps.

> How will you mount your file system?

By running a daemon. You don't touch the host file system at all
(*maybe* you'd want to add a hook so you know when it allocates blocks
so you can mark 'em as deleted in your FSFS index); it stays mounted
and running the entire time.

FWIW, I don't especially care if the FSFS is a file system proper, or
something more like memcached (i.e. a key/value store). That to me is
a fungible implementation detail.

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

Exactly so. And yes, you'd need something like what Tahoe et al do to
help ensure consistency.

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

That is indeed a vulnerability, as with any such system.

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.

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

Because then you can't use that disk like a normal file system. The
FSFS idea *is* the parasitism.

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.

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

IANAL. Tyler is. I'd be interested in Tyler's opinion of the legal
protection MAID would provide, and whether it'd make you vulnerable to
contempt of court, obstruction of justice, or destruction of evidence
charges. I simply don't know enough to be more than suspicious that it
might.

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

Sure, and vice versa. It's a very contextual right, it seems...

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

It doesn't require one as far as the host file system is concerned. It
just has a daemon that spies on the host.

So eg the host file system could be ye generic Dell Windows box drive,
NTFS, one partition, whole drive. Nothing special wrapping it or the
like (unlike eg LVM).

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

Correct. I've been trying to convince you that this isn't a
cryptographic system idea, it's (if anything) a steganographic one...

> The rub with stego is that covert
> channels often have a specific property and when you change them,
> patterns emerge.

Certainly. As I said, this would have the property that free space
looks suspiciously random rather than looking like bits of random old
files.

Unless you go crazy and somehow have your crypted data look like
random bits of old files, which I suppose is possible, but seems very
difficult to do well.

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

I know you understand this; I was just correcting an imprecision in my
own language ('replication' is usually used wrt RAID). Yes, all I
meant here is error coding.

> I understand the idea. I just think it's half-baked. :-)

Never claimed otherwise. As I said, it's currently just an idea. ;-)

And as I said upfront, I figured that someone else surely had this
idea before - it doesn't seem all that novel to me. Yet nothing you've
mentioned so far (and I suspect you know more than me about related
systems) does this; the closest is the image-steganography, which is
rather different from my POV.

- Sai