[Authentication] Applications storing secrets in configuration

[Stef Walter]

On 29.05.2013 14:18, Alberto Mardegan wrote:
> Hi Stef, and apologies for joining the conversation this late.
> 
> On 05/22/2013 07:27 PM, Stef Walter wrote:
>> On 22.05.2013 18:06, Anders Rundgren wrote:
>>> Who in the Open Source community is actually working with that?
>>
>> I've been doing some work on it with the p11-glue effort, with a focus
>> on private-keys and certificates.
> 
> Do I understand correctly that your proposal is about writing a thin
> layer on top of PKCS#11?

No that's separate work to do with certificates.

> So what you'd be adding is a way to let each application receive a
> different token, right?

Yes, that's the jist.

But it doesn't have to do with PKCS#11. This master secret (or token as
you call it) could be received via the kernel keyring, or via the DBus API.

I think the former would facilitate use across sandbox boundaries, but I
need to double check.

> Do you already have any idea of how configurable this will be? For
> instance, who and how decides that a certain application should receive
> the null token (to disable encryption)?

Well that's an implementation issue. But here's how I imagined it happening.

 * The Secret Service would contain a list of these tokens it has
   handed out to applications (either via dbus, or via having a helper
   invoked from the kernel keyring request-key.conf).
 * The Secret Service could be configured to hand out one token
   to all apps, hand out null tokens, or different tokens per app.

It may be that a phone has a very simple Secret Service implementation,
that always hands out null tokens.

BTW, in order to keep this implementable separate from the central
storage of the current Secret Service DBus API, we could put this on a
new DBus interface and bus name.

Cheers,

Stef