Re: [Full-disclosure] ESFS - The encrypted steganography filesystem



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.

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.

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.

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.


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.

Regards,

Peter Maxwell



On 12 January 2011 19:08, Tomás Touceda <chiiph@xxxxxxxxxx> 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/

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

Relevant Pages

  • Re: [Full-disclosure] ESFS - The encrypted steganography filesystem
    ... but in this case you can erease the driver whenever you don't ... of a FS could be either random data, or it could be a hidden partition. ... in hopes that it'll become a fully featured filesystem. ... encryption in a filesystem, so you can say "oh, yes, I have encrypted ...
    (Full-Disclosure)
  • Re: RFC: pefs - stacked cryptographic filesystem
    ... filesystem. ... I've got to ask a probably dumb question...how is this better then geli ... Stacked filesystem is likely to be slower due to extra overhead ... thing in common - encryption - everything else is different. ...
    (freebsd-current)
  • Encrypted Filesystem
    ... - Seamless application to the root filesystem ... accordingly by the encryption layer ... all with varying degrees of modification to the kernel ... - NFS-based (CFS, TCFS) ...
    (Linux-Kernel)
  • Re: Encrypted Filesystem
    ... Bounce kernel & fs ideas off the kernel ... > - Seamless application to the root filesystem ... > accordingly by the encryption layer ... not as well accepted or tested as CFS ...
    (Linux-Kernel)
  • Re: RFC: pefs - stacked cryptographic filesystem
    ... filesystem. ... I've got to ask a probably dumb question...how is this better then geli ... Stacked filesystem is likely to be slower due to extra overhead ... thing in common - encryption - everything else is different. ...
    (freebsd-current)