Proposal: Personal Data Encryption (maybe SoC?)
Tim Newsom
cephdon at gmail.com
Wed Mar 21 18:03:15 CET 2007
On 2007年3月21日 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)
What do you mean by different problem? Maybe I don't fully understand.
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.
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.
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?
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.
--Tim
More information about the community
mailing list