Proposal: Personal Data Encryption (maybe SoC?)

[Joe Pfeiffer]

Tim Newsom writes:

>Ok.. Lets assume for a moment that there is an encryption / security 
>engine.. And its hooked through dbus somehow..  Lets also assume there 
>is a mechanism that handles all requests to save data from any 
>application... Will just call it the save data mechanism.. (Grin)...
>
>So on the encryption / security engine it seems like there should be the 
>ability to define user selectable levels of encryption / security.. Such 
>as no encryption but password required.. Light encryption password 
>required... Heavy encryption picture/gesture required (and maybe a 
>certainty level for fuzzy matching like 90% /shrug).. or no password and 
>no encryption.. Etc.
>
>Ok. There should be some kind of configuration for the save data 
>mechanism which says select the published security levels (I.e. Those 
>the user created in the security config) and then select which 
>applications follow those rules.. So notes could be no security/no 
>password or it could be 'ask me each time'... Calendar could be the 
>same.. File browser could be heavy encryption with picture.. Etc.. Then 
>each application does not need to know anything about the security 
>levels at all. It just calls the save information api (whatever that is) 
>and hands dbus the data to save.  The save mechanism looks at the 
>request and notes the application its coming from and then hands it off 
>to the security engine to encrypt appropriately.. And then it hands it 
>back at which point the save data mechanism can write it to the file 
>system..
>
>Reading is the same.. Except the read data mechanism looks at the 
>application making the request and in the case of ask me data looks at 
>the data to see if its encrypted/secured.. If so it tells the security 
>mechanism which asks the user for the appropriate level of password 
>information and then decrypts or authenticates the read action and the 
>user gets to read the data.
>
>Combined with the sudo idea about a configurable amount of time for 
>authorized idleness... And add to it the ability elevate permission 
>levels..  So that once you have authorized to read highly sensitive 
>information you can also just read password protected but not encrypted 
>info.. And then I think it might meet everyones needs.
>
>By default no security is provided and none required..  Once configured 
>it could handle almost any level of detail for encryption assuming 
>someone wanted to go through the trouble of making it happen that way.
>
>And you could build new security mechanisms that plug into the 
>architecture and allow for some people gesture authentication and for 
>others hand writing codes or voice codes or numeric codes or anything.
>
>Um... Yeah.. Ok so that might be 10 cents worth.

I like this -- except it doesn't quite match my sample-of-one user
study.  My degree-of-security-wanted is by data, not by application.
The same app is used for things like VINs and tire sizes and oil
filters for cars (no security) and for student presentation grades.

It's also not clear to me that more than two levels of security
(open/password protected) are needed -- where password protected means
encrypted using whatever scheme we've got.