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
community lists.openmoko.org
http://lists.openmoko.org/mailman/listinfo/community
|
