On 13-03-19 03:22 AM, Alberto Mardegan wrote: > On 03/18/2013 05:01 PM, Bruno Girin wrote: >> Not all devices will have a SIM, tablets in particular may not. And >> looking forward to 14.04, I assume we'd want this code to be re-usable >> on the desktop (or server even)? > > Might be a good idea, though I'm not thinking of that yet. Sure, I think > we shouldn't make any assumptions that might prevent us from putting the > same service in the desktop if we decide to, but for the time being I > think that the GNOME keyring is doing a very good job. > >> Having said that, maybe there is a case >> for allowing different backends with the default being an encrypted >> store on the device. An alternative backend that would use the SIM could >> be good as an option as long as it doesn't make it difficult for the >> user: say I got tired of Voodoophone and wanted to switch provider to >> Nothing Nowhere, I'd want it to be painless and not lose all my saved >> passwords because I changed the SIM. > > Indeed. What signond supports now is a plugin system for different key > providers and defines an interface for them: > > http://code.google.com/p/accounts-sso/source/browse/lib/signond/SignOn/abstract-key-manager.h?repo=signond > > By using LUKS (or even encfs, with some tricks), it's possible to > associate more than one key to an encrypted partition: that is, there > might be multiple keys which allow unlocking the secrets DB: a SIM card, > a password, a lock code, a fingerprint signature, etc.
I would really hate having a system that relies on mounting an encrypted filesystem. It seems to me there are way too many disadvantages to this to be worthwhile. > > In particular, we would not be restricted to a single SIM: we can easily > think of a way to authorize a second SIM, for instance: > > - user removes current SIM > - a dialog appears explaining that if we wants to authorize a new SIM, > the user has to insert it while the dialog is still open -- otherwise, > dismiss the dialog > - user inserts the new SIM I think this is way too complicated for a user to understand. I'd hate for users to lose all their secrets just because they didn't understand what they were doing. > >> Should that be integrated with the PAM architecture so that different >> keyrings (or collections as called in the freedesktop API) can require >> different authentication methods? > > Our service could be a PAM provider, but I don't think it can use PAM as > a client: AFAIK, the PAM API only allows you to know if the user has > authenticated, but it doesn't let you retrieve the password/token used > to authenticate (and which we could use as key for the encrypted storage). Yes, a PAM module can retrieve the password. Marc. -- Mailing list: https://launchpad.net/~ubuntu-phone Post to : [email protected] Unsubscribe : https://launchpad.net/~ubuntu-phone More help : https://help.launchpad.net/ListHelp
