ubuntu-phone team mailing list archive

[Thomas Voß <thomas.voss@xxxxxxxxxxxxx>]

On 18.03.2013 13: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.
> 

Having had a brief look at the API only, but the first question that
comes to my mind is whether the X-centric approach of tying
authentication dialogs to window IDs is feasible. I think we should
rather focus on the application-instance centric approach that we are
implementing for the rest of the system. What are your thoughts on this
aspect?

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

+1!

> So, those above are a few aspects to consider. There are many ways to
> implement the secrets DB, and if you think you have more ideas, you are
> very welcome to list them here.
> I'm bringing up this discussion because this service is essential for
> Online Accounts (right now on UbuntuTouch our password database is not
> encrypted), and if there's something I can do to get this done,
> including writing code, I'd be happy to help.
> Consider this e-mail as me volunteering for this task -- but first we
> need to decide how to do it. :-)
> 
> Ciao,
>   Alberto
> 
> [0]: http://standards.freedesktop.org/secret-service/
> [1]:
> http://en.wikipedia.org/wiki/Subscriber_identity_module#Authentication_key_.28Ki.29
>