On 2/17/06, Jon Masters <
jonmasters@gmail.com> wrote:
> On 2/17/06, Russ Dill <russ.dill@gmail.com> wrote:
>
> > > > Has anyone investigated the issues surrounding encryption and yaffs2?
>
> No, but I've got a fair bit of experience with encrypted block devices
> of various designs.
>
> > > > I realize it may be impossible to solve, but I really don't want to
> > > > have a system that is NAND<->FTL<->dmcrypt<->ext3.
>
> You don't want to do that :-)
I know...but its really no worse than CF<->dmcrypt<->ext3
> The simplest solution right now would be a libc wrapper for your
> application, which could transparently encrypt and decrypt files for
> you as you use them - I used to use something little more crude at
> University to protect my academic files on central servers from any
> prying eyes. Perhaps a FUSE solution is what you want instead though
> these days.
>
> Someone /must/ have written a FUSE layer for doing this, it's just so
> damned obvious. Ah, yes - http://encfs.sourceforge.net will probably
> do what you want. It's not stegnographic, but I would guess encfs
> works with file blocks/inodes so will be secure against trivial
> attack.
Disadvantages
Meta-data: Meta-data remains visible to anyone with access to your
encrypted files. This means that Encfs does not encrypt or otherwise
hide the following information:
o The number of files you have encrypted
o The permissions on the files (readable, writable, executable)
o The size of each file
o The approximate size of each filename (to within 16 bytes
using AES, or 8 bytes using Blowfish)
Thats a lot of information to leak, especially if you have say, a
postgres database sitting on that.
> > > > I understand that it would be very difficult to not leak information,
> > > > encrypting the oob seems impratical (excepting of course the ecc, and
> > > > block state). Let me know if anyone has given this any thought.
>
> You risk a side band attack on any such system - flash is no
> exception. Actually, I'd love to see if anyone has studied failure
> rate of blocks and related that to known locations of certain data
> structures, and other statistical anaysis one could perform against
> flash.
>
> But indeed, to do this at the YAFFS level would potentially take a
> fair bit of work - and unless you work for the NSA (if you do, cool,
> maybe you can pay some of these guys to do the work for you) or have
> time on your hands, I doubt it'll happen soon.
There are some pretty strict security requirements, the fuse solution
would be nice because we could link it against openssl, which is now
actually government approved.
For a yaffs2 solution, I would be hoping that the same key that is
used to encrypt the block could encrypt some of the oob data, like the
block sequence number. I'd really have to study into how cbc works.
> Just use a FUSE-like layer.
There is always the option of making a huge file on a yaffs and using
it to create a loopback device for dmcrypt. I think the fuse-layer
option leaks too much information.
> One thing which did occur to me though is how you will store this key
> - on a typical embedded device with flash, it's hands off. I guess you
> have dongles or something.
An encrypted key would be stored on NOR flash, the users access card
along with a pin would be required to unlock it. The advantage besides
encryption at rest being that the system can be purged by simply
overwritting the key with zeros. (purge option would be necessary
because anyone who obtains the system, and the access card can easily
brute force the pin)
(text/plain)