[Authentication] Applications storing secrets in configuration

[Anders Rundgren]

Having application-local secrets is fine but there are tons of applications
that rather needs ACL-protected secrets (keys).

It would for example be awesome dropping the gazillion key-passwords
stored (usually in clear) in various config files when you for example
deploy TLS-using application servers like JBoss.

On the mobile scene, doesn't Android effectively offer sandboxed applications
including protected storage?  Encrypting the data should IMO be a minor
OS addition and not particularly related to GCR.

I guess this really boils down to what "market" you are looking at, right?

Just my 2 öres.

Anders


On 2013-05-10 19:20, Stef Walter wrote:
> 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
>