ubuntu-phone team mailing list archive

[Marc Deslauriers <marc.deslauriers@xxxxxxxxxxxxx>]

Hi,

On 13-03-18 08:50 AM, 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.

I think that would be a good idea. Although I have not personally looked
at that API in enough detail to form an opinion on it, I think having a
standard API would make it a lot easier for developers to write
applications that are able to use whatever secret storage is available.


> 
> 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 think Online Accounts shares a lot of the same ideas as a
password/secret storage daemon, and I'm all for having a single security
provider to audit, so I think this makes a lot of sense.


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

I don't think the secrets storage should be tied to the device. Ideally,
it should simply be a database in the user's home directory that can get
backed up and possibly synced across devices. The database should
encrypt itself, much like the current GNOME keyring database, and it
will get an extra layer of encryption when disk encryption is enabled.

The issue here is what to use as the encryption key...GNOME keyring uses
a pam module to seamlessly use the user's account password. Ideally
something similar should be used. Of course, there's the added
difficulty that on phone form-factors, people don't typically use
passwords, but unlock their screen using patterns or PINs.


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

I really hate having stuff that is locked to a particular device, so
hopefully the "some condition" doesn't include something tied to the
hardware/SIM card.

Marc.