[Authentication] Applications storing secrets in configuration

[Stef Walter]

This is an early broad concept ... don't expect to be able to bike shed
details yet :)

There's been lots of discussion of sandboxed applications, some of which
want to store secrets securely.

In these cases the model we've been using in the Secret Service API does
not really match reality. Ideally secrets such as passwords, should be
stored with the applications other (configuration) data, and not
necessarily in a central database.

Having a central database shared between applications of significantly
different privileges requires somewhat complex ACL semantics, which lead
to leaks and security issues.

As a solution for these applications we really want to be able to
provide the application (or a library it's linked to like libsecret) a
master key which it should use to encrypt information it wishes to
persist securely on disk, in its databases, or settings. The application
(or the library like libsecret) can then later request the same master
key from the system and use it to decrypt passwords/secrets it has
previously stored.

Advantages:

 * Such a model has far fewer moving parts than a central
   database of secrets.
 * Information is stored where it makes sense, along side other
   related non-secret information (think account config info).
 * The system (per policy) could provide a 'null' key to the app
   which would mean it would store its secrets unencrypted (eg: an
   encrypted or otherwise secure file system is in use).
 * The system could hand out different keys per application (again
   as per policy).

There are also some advantages of the shared database of secrets model
that we currently see on our Linux desktops. The main one is the ability
to share secrets between applications.

That said, what applications really want to do is share configuration
and account information, not just the secrets. And to do that, they need
more than just a shared secret database.

I'm thinking of documenting this concept and implementing it in libsecret.

The central secret database (ie: gnome-keyring) wouldn't necessarily go
away any time in the forseeable future. But this allows new use cases to
be fulfilled and applications to migrate over to this new concept as it
makes sense.

Some implementation ideas:

 * Make this available to non-DBus using applications using the Linux
   kernel keyring. This is a good way to allow the system to provide
   applications with keys securely. The kernel can call out to a user
   application to fill in keys that don't yet exist. This is light
   weight, secure, and dependency agnostic.

 * Perhaps use the Secret Service API a compatibility mode to
   store/retrieve such keys application master keys non-Linux platforms?

 * The system provides a public key identifier along with the key which
   the application would store in/along-side its encrypted data. When
   it wants to decrypt previously stored secret data, it passes that
   identifier to the system when requesting its master key. This allows
   for migration of keys, per-application keys, and future expansion.

Soliciting comments from others interesting in using this, or
coauthoring this spec, and implementing it? I'm hoping to implement this
in libsecret (glib, gobject based). A QT based implementation would be
sweet, and perhaps others.

If we want we could add this to the Secret Service API spec.

Cheers,

Stef

-- 

stef at thewalter.net
http://stef.thewalter.net