Proposal: Personal Data Encryption (maybe SoC?)

[Joe Pfeiffer]

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...