On 2/17/06, Russ Dill 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 :-) 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. > > > 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. > > I am not clear if you want the information in NAND Flash to remain > > unintelligible to others who read it without authority, or never to be > > readable by any others. If the latter, is it others using the same > > YAFFS that you are concerned about, or others remote from that YAFFS ? > > I'm not sure what you mean here, so I'll clarify. Encrypted as in, > using aes256 per block, and and some kind of hash across the blocks. > Reading and writing to the filesystem would require the kernel to have > the proper key. Just use a FUSE-like layer. 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. Jon.