Home page logo
/

fulldisclosure logo Full Disclosure mailing list archives

Re: ESFS - The encrypted steganography filesystem
From: Tomás Touceda <chiiph () gentoo org>
Date: Thu, 13 Jan 2011 14:54:46 -0300

Hi Peter,

2011/1/13 Peter Maxwell <peter () allicient co uk>:
Hi Tomás,

Not to be facetious but there are several generic problems with this concept
(independent of implementation):
i. A user will require your drivers to access their data and hence the
presence of the drivers will alert any attacker to the potential of hidden
data.  To hide the drivers creates a "chicken-and-the-egg" scenario.

True, but in this case you can erease the driver whenever you don't
use it. Say, if you want to save file A, you copy it to the ESFS
partitions, then erease the driver, and copy those images in a pen
drive, or whatever medium you want. When you want to retrieve it, you
can just download the driver and cat the file. So, may be the "FS"
part of the name is wrong, since you use it as a filesystem, but it
isn't intended to be there all the time. Currently, it uses a kind of
cache of objects in memory, so the idea isn't that while you are using
it, if someone is lurking through your RAM, he/she won't be able to
find anything, the protection will be present once you just have the
images.

ii. Any file system will require a set methodology to store and retrieve
data, which runs somewhat contrary to the idea of hiding data so that an
observer cannot determine the existence thereof; in other words it is
usually easy to check for standard structures.

I think I answered to this part above.

iii. The presence of encrypted data is often obvious.  There are situations
when you can hide encrypted data "in plain sight", e.g. products like
TrueCrypt - afaik - use slackspace at the end of filesystems to store a
second layer of encrypted data; the secrecy is provided by the property of
most encryption algorithms producing data that is (ideally)
indistinguishable from random data.  So for an attacker the data at the end
of a FS could be either random data, or it could be a hidden partition.
 However, if an adversary finds a TrueCrypt volume then they may just as
well assume you are hiding another partition in there anyway and either
detain you until you decrypt it, or torture you until you do.  Even if you
have not created a hidden partition, your adversary doesn't know that and
the safest course of action for them is to put pressure on you - in other
words, you are either jailed/tortured regardless.  So the mere potential of
having a hidden partition along with the inability to prove there is not one
there could land you in a very problematic position.

Yes, if someone has in his mind that you are hiding something,
whatever, you can be tortured or put in jail, etc, etc, for no reason.
So nothing is perfect in this sense. Recent (and passed) history has
taught us that you don't need to be guilty to be accused of something
and be charged with it.

Be that as it is, ESFS isn't intended to be a replacement or a
competition to fine pieces of software as TrueCrypt. So if you intend
to encrypt your home directory, or the whole root partition, please
don't use ESFS. On the other hand, once we have work a lot more in
ESFS, and you want to save some files in kind of a "locker", *then* I
would say that you can use this.

iv. Traditional steganography usually requires a massive amount of plaintext
data in which to hide your secret, this will make any file system horribly
inefficient, if not you end up using iii. with the problems outlined there.

Of course, the techniques I've used have their disadvantages. Right
now, yes, it's horrifly inefficient, but for now it's kind of a toy,
that may be with some time and hard work it will become a fine piece
of security software.


In your implementation, I am not quite sure what the mechanism is: the
"concepts" file is certainly not sufficient, and I'm not going to trawl
through Python code to try and determine your design.
Bottom line, and this isn't meant to be harsh, is that if you are designing
a security product that you want others to trust then you must define it
thoroughly and provide good arguments as to why it works.  Then they will
test it and pull it to bits to determine whether it does what it says on the
tin.  You have not done that here.

I tried to define it as thoroughly as I could, but evidently that
isn't sufficient yet. I'll work on that, thanks for pointing that out.
But, I'm not sure that "it works" from the point of view of something
that will assure the safety of your data. I've designed this as
careful as I can, but I'm not by far an expert in all this, so I've
probably missed a lot of things. That's why I made it public.

I'm learning here, I didn't planned to teach anybody anything with
this project, but I wanted to make it public so I can hear opinions
like yours, and learn from them. So, thanks a lot for taking your time
to answer.

Currently, someone I really respect and has a lot more experience that
I do in security, has accepted to audit the whole project. So I hope
with his hand and everybody else that wants to help us, we will make
ESFS a better project, or kill it completely if it's trash for real :)

Regards

Regards,
Peter Maxwell


On 12 January 2011 19:08, Tomás Touceda <chiiph () gentoo org> wrote:

Hello everyone,

I wanted to announce this little pet project that was born a couple of
weeks ago, and now it sees the light in the form of a proof of
concept, in hopes that it'll become a fully featured filesystem.
Here's an extract of the main README text:


============================================================================

What's this?

Just like the title says, it's a filesystem. Particularly, it's a FUSE
filesystem that's implemented entirely in Python (for now), and it's a
proof of concept in alpha state, so don't save stuff only within this
filesystem just yet. A couple of weeks ago, I started reading about
and playing with encrypted filesystems (LUKS + dmcrypt, encfs, etc). I
came across an email (actually, a friend of mine tossed me the link)
from the now well-known Assange, about a Linux kernel module he and
other people were working on that provided different layers of
encryption in a filesystem, so you can say "oh, yes, I have encrypted
data in here", but in a deeper layer you'd have more encrypted data,
with another key, and nobody but you would know about it. And I
thought it was a really cool idea. I started looking for the code, but
it was too old to be used with the current kernel. A couple of days
before that, I read about StegFS, a filesystem that uses steganography
to hide your files within your other files. And again, I thought it
was a really cool idea, BUT I didn't like the fact that (and please
correct me if I'm wrong) when you copied a file in StegFS, there's a
chance you'll lose some other file. So, this one is usable, but this
drawback didn't suit me. I started bouncing ideas with a lot of
friends, and then it hit me: a filesystem, hides its data in images
and encrypts this data. I wanted to build a FUSE filesystem since I
first learned about it, so I finally had an idea to work with. This
idea gives you the same advantages of Assange's kernel module: you
have a bunch of images that seem like regular files, but when you
mount the filesystem with certain parameters BAM! you have lots of
files that nobody knew were there.


============================================================================

You can find the rest of this README, a more detail design document,
and the actual code in: https://github.com/chiiph/esfs

If you find any bugs, please let me know.
Any comments and critics are more than welcome.

Regards,
--
Tomás Touceda
Gentoo Developer
Herds: Qt, Scheme, Lisp

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/





-- 
Tomás Touceda
Gentoo Developer
Herds: Qt, Scheme, Lisp

_______________________________________________
Full-Disclosure - We believe in it.
Charter: http://lists.grok.org.uk/full-disclosure-charter.html
Hosted and sponsored by Secunia - http://secunia.com/


  By Date           By Thread  

Current thread:
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]