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

[Jacob Appelbaum]

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

Yeah. You'll always have this problem with slack space too:
http://www.wikistc.org/wiki/Slack_space_data#Storing_data_in_slack_space

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

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

Odd. Here's another (The Steganographic File System. Ross Anderson,
Roger Needham & Adi Shamir) copy:
http://www.o3one.org/hwdocs/fat_fs/sfs3.pdf

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

Make a wikipage and try forming the ideas you're expressing. They're not
bad ideas at all; there's a lot of material that I think you should read
about though! There's a _lot_ of research in this area. Perhaps citing
it and putting it in one place will help to form a better understanding
of the entire problem set. Furthermore, it will certainly help people to
design new systems.

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

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. Are you planning something else? User space tools
on a usb disk? Are those also unencrypted on the disk?

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

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

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

It would probably help at least in the data splitting areas...

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

I disagree with this. It is not a vulnerability that my loop-aes file
system uses tools to mount the disk. In your system, it's an issue as it
points to slack space being filled with possibly important data.

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

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

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.

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

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

I asked a lawyer and without disclosing who they are, I felt good enough
about it to say that it will work until some laws were changed. Even if
it wasn't going to go well for some of the parties involved, if you
don't have the key, you don't have the key. It's a different issues from
refusing to disclose the key. MAID prevents you in the same way that an
active directory system could prevent you from logging on in some
countries, etc. I don't see the law changing to address either of those
issues anytime soon. Perhaps someday though. I sure hope not!

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

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

"Slacker - First ever tool that allows you to hide files within the
slack space of the NTFS file system."

Useful screen captures:
http://synfulpacket.blogspot.com/2008/11/metasploit-anti-forensics-project-mafia.html

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

Strong stenographic systems generally rely on cryptography.

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

I agree.

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

Ok.

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

Slacker may be a good demo for file manipulation.

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

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/20090925/28d97128/attachment-0003.sig>