Tim Newsom writes: > >On Wed, 21 Mar 2007 9:34, Joe Pfeiffer wrote: >> Tobias Gruetzmacher writes: >> >> Right -- these look like good approaches, but to a different problem. > >/please excuse my direct manner.. Its just how I write (smile)
Likewise -- it's hard to see somebody smile by email, and I never intend to offend. >What do you mean by different problem? Maybe I don't fully >understand. Near as I can tell, these approaches require you to partition up your maching into an unencrypted area and an encrypted jail -- maybe through a physically separate device, maybe through a separate partition, maybe through a file that's mounted as a filesystem. I don't want that -- I want to be able to specify encryption on a file-by-file basis, in a manner that comes as close as possible to being generic across all applications without code changes to those applications. At the moment, I'm wandering around the source code for __libc_read() and __libc_write() to see if there's a good way to hijack a program's read() and write() calls, so if they are to a file that's marked as encrypted the data can go through encrypt() on the way.... >The way I see it you have a few interoperating components... Dbus can >be the primary transport mechanism, some reader plugin which abstracts >the actual source of the data.. Be it the filesystem or a file which >sits on the filesystem that has its own filesystem.. Or a dbfile system >(I have not heard much about that recently)... A writer plugin which >does pretty much the same thing, but for writing and not reading.. Maybe >they are even the same plugin.. /shrug > >Then you have some authenticating system which allows various methods of >authenticating a user.. Be it fingerprint reader or pincode or whatever >based on the currently selected provider/plugin... And you have the >application. > >At the lowest level is the encryption/decryption system.. Right above >the filesystem somewhere. I think we agree here; I'm just trying to avoid having it filesystem-wide. >Now, when the phone is idle long enough or locked and a user tries to do >something, the currently configured login / unlock / whatever you want >to call it authentication plugin is activated and asks for the required >information / gesture / whatever. Agree completely. >Once obtained the user is granted whatever rights they configured for >that action.. By default it can be nothing or a pincode and the default >level can also be set to wide open, no encryption and full access. >That's the state of almost every phone on the market right? As far as I know... >Ok.. So an advanced users phone may have 3 or 4 levels of authentication >and access / encryption.. Maybe even different algorithms are used. Who >knows? When they log in they probably set it to the lowest level of >access.. The notes application can read plain text with no problems and >any unsecured data is visible.. Including contacts, notes, pictures, >music, whatever. > >Now suppose this individual decides to read an encrypted file or runs an >application configured to access an encrypted file or file system.. The >authentication system would then ask for additional authentication and >once granted handle the key pass to the decryption system / whatever to >read the file. > >Now I don't have any experience with truecrypt or LUKS yet.. But they >were mentioned along with encryptfs etc as a means of handling the >encryption part. > >Maybe you can help me with where I missed out on the problem so that I >can get my head around it? (Grin) I would love to make sure I fully >understand what you are saying. Hope my notes above are helpful... _______________________________________________ OpenMoko community mailing list [email protected] http://lists.openmoko.org/mailman/listinfo/community
