Hi Mark,
On 5.2.2014 19:35, Mark De Roussier wrote:
I'm talking about the equivalent of Ubuntu's Encrypted Home.
> If an App, running in the previously established context of
> a particular user profile, wished to store data, then it
> would do so in a 'home' directory which was encrypted
> using user-profile specific credentials.
Per-user encrypted home using eCryptFS is quite straightforward to
implement and is already supported by number of distributions.
For these purposes, filesystem level encryption like ecryptfs is very
suitable.
Block device encryption is more suitable for system level (not per-user)
partition encryption. In those cases I would suggest use of LUKS
(cryptsetup).
In the original Qt-based SSO we used LUKS for the encrypted storage, but
in the glib port we switched over to eCryptFS because it was supposed
the be the Tizen choice. In any case, switching the type is just matter
of new storage manager subclass.
So are you suggesting that my 'previously established context' is
in fact achieved via gSSO, and that establishing that context will
> ( via a gSSO plugin ) cause an appropriate ecryptfs mount to occur ?
gSSO would be suitable in case you would like to have per-application
encrypted storage, since it allows either storing data directly (smaller
amounts) or it can be used as storage medium for per-application
(filesystem) encryption keys. Usually in these cases the problem is
where to store the per-application key and gSSO solves that problem with
it's per-application access control system.
You could also use gSSO as a generic encryption engine by storing a key
there and writing a plugin that performs encryption/decryption for given
data using the key. This way application doesn't have to posses the key
in it's memory space. You could also allow other applications to perform
encryption but not decryption while still using just a symmetric key
system. By default, application cannot retrieve the stored information,
they can only perform specified operations with it.
You could also use gSSO as generic front-end for hardware engines (TEE
or smart card). In these cases plugin would just talk to the hardware
engine using what ever hardware specific API while exposing common API
towards applications.
Best regards,
- Jussi
_______________________________________________
IVI mailing list
[email protected]
https://lists.tizen.org/listinfo/ivi
