ubuntu-phone team mailing list archive

[Bruno Girin <brunogirin@xxxxxxxxx>]

Hi Alberto,

See comments inline.

On 18/03/13 12:50, Alberto Mardegan wrote:
> Hi all!
>   I'd like to discuss about our plans for a password/secret storage
> service which could be used by applications to store and retrieve secret
> data.
>
> On the desktop, we are currently using the GNOME keyring, which we
> cannot use as-is on UbuntuTouch given its dependency on Gtk+. The GNOME
> keyring itself implements part of the "Secret Service" freedesktop.org
> API [0], which AFAIK is also implemented by KDE's KWallet.
>
> Whatever solution we choose, I'd recommend to expose an API compatible
> with the freedesktop.org's one; it might not be exactly what we need,
> but on the other hand I don't see a strong reason to do things differently.
>
> That said, the next question is what we want to use; given that the
> "Secrets Service" API is not terribly complicated, and that the GNOME
> keyring is tied to Gtk+, I don't think that the effort of extracting and
> reusing the non-Gtk+ parts of the GNOME keyring is worth it.
>
> Someone suggested that we could implement the freedesktop API inside the
> signond daemon, which is at the core of Online Accounts; given that the
> daemon is easily extensible (it already provides an extension API for
> plugins), it might not be a bad idea, considering also that signond will
> be one of the main users of this API (it needs it to store account
> passwords and authentication tokens).
> However, while not being against the idea, I'd like to give it some more
> though before pushing it forward.

I agree that using the freedesktop API is a good idea. For two reasons:
1) it exists and would make things compatible with other implementations
and 2) it's simple. Having had a look through it, I don't think there's
anything missing in order to provide the same functionality as GNOME
Keyring and it would allow other applications to use the same service
(one of the most used app on my phone is a password safe + generator
which could be easily re-created if it had access to such an API).

We may yet still find use cases that would require an extension to the
API in which case, we can always add an additional DBus interface (and
even submit the extension back to freedesktop).

> Another question is how the secrets DB should be stored. In MeeGo we
> were using the SIM "Run GSM algorithm" [1] to obtain a byte array which
> would be unique to the user's SIM, and use that as a LUKS key to decrypt
> the secrets storage which was mounted in its own loop partition.
> So the plan was to disable the password storage when the SIM was removed
> or deactivated.
> At the end we had to disable this feature because of problems with the
> SIM service (which from time to time reported that the SIM was being
> removed while in fact it was still there), but the infrastructure was
> all in place -- and as far as Online Accounts is concerned this is still
> usable, since we took off from the MeeGo code. Only the SIM interface
> needs to be re-written for oFono (provided that it can offer the same
> functionality).

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)? 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.

Looking forward, allowing different backends could enable support for
hardware storage modules: e.g. you could have all your passwords stored
on an IronKey [0], if the key's not inserted, no password, if the key is
there, once it's unlocked you have access to your passwords.


> Anyway, regardless of what the access key is (whether it's the SIM or
> anything else, like a lock code or screen gesture), it might be a good
> idea to consider the possibility of having the secrets storage being
> made unavailable when some conditions are not met.

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?

Cheers,

Bruno

[0] http://www.ironkey.com/