Re: gnome-keyring keyring brainstorm

[Michael Leupold <lemma confuego org>]

2009/4/3 Stef Walter <stef-list memberwebs com>:
> Michael Leupold wrote:
>> It's the what konqueror uses for storing form data on web pages, probably
>> mostly because putting all non-secret fields' names and values into the item
>> name (KWallet doesn't provide attributes, just one name) makes it look strange
>> when editing :) Most other applications just use a secret string. With those
>> KWallet operates pretty similar to keyring. Item names (= mangled attributes)
>> are stored as hashes for searching as well as in the secret part.
>
> Interesting. So I guess we can continue this state of affairs. Since
> KWallet already stores everything as a secret, then it can continue to
> store stuff in the secret, am I right?

Yeah, I agree. Most programs will only need the password stored
secretly anyway because they'll have parts of the fields stored in
their config (eg. mail/im accounts). If an application needs to store
multiple secrets we could very well use a string to do so. It would be
great if we could have that in the spec instead of applications/client
libraries doing their own marshalling because like that we'd have
better cross-desktop compatibility (imagine a kde application's
secrets showing up as gibberish in the gnome keyring management
application or vice versa).

In KDE we currently have string secrets, map secrets (string->string)
and binary secrets (which aren't really used). I'll have to think
about mapping these types to a string on the D-Bus interface
(including the encryption) - will do this weekend when I have more
time.

> Attributes in gnome-keyring are specifically used to find a secret.
> These are not secured. The hashing of these (in gnome-keyring) is a not
> for security in any way, it's a performance boost.
>
> It'd be a big bunch of snake oil to hash individually them for security
> reasons :) Even if we did use a crypto strength hash algorithm, the
> values are far too small, far too repetitive, and it's trivial to brute
> the guessed values, as well as use them for rainbow tables etc...

Yeah, I agree. I think it is acceptable if it stays like this (afaik
fields are hashed and stored secretly for retrieval at the same time,
right?).

>> Partly, yes. At least that's how I stumbled upon the bug. For all KDE
>> applications I can however adjust the timeout because they're using an API
>> wrapping the DBus calls instead of calling DBus directly.
>>
>> I remember the following things that were inconvenient to implement:
>> [...]
>> - There might have been an issue with detecting the timeout on the server-side
>> but that might have been qt-specific (I just don't remember exactly)
>>
>> Overall manageable, but it adds extra complexity that has to be taken into
>> account.
>
> But do you agree that the complexity is less than designing another
> layer of operations handles + async calls into our API?

Yes, I agree. :-)

>> I finally came up with two other things I had been wanting to implement for
>> KWallet:
>>
>> (1) syncing collections (aim: multiple PCs):
>> As keyring already provides mtime this should be a matter of providing a GUI
>> for it.
>
> True, that makes mtime a first class citizen. I was thinking of
> relegating it to an additional desktop specific interface. But this
> shows that we should include this in the main API.

I wonder how much is actually left for the non-main API. It sounds
like we fitted almost everything into it already in which case it
might make sense to have only 1 API.

>> (2) multiple methods to unlock a collection:
>> I think it would be awesome if we could provide a way to unlock a keyring not
>> only using a password but also using a smartcard (and possibly even
>> biometrics) - if possible several authentication methods on the same keyring.
>> This would however require the format to be changed as well.
>
> Not sure how KWallet works, but most of these methods don't work with
> gnome-keyring at all. We're not doing 'authentication' when we're
> prompting for a password, we're actually unlocking something. The
> password that the user types actually decrypts the keyring data. [1]

KWallet currently works the same. My idea goes like this:
- Secret data is not encrypted using a hashed password but using a
randomly generated key (let's call it master key).
- The master key is generated on creating the keyring.
- The master key is stored inside the keyring and is encrypted itself,
eg. by using a hashed password or using a smartcard (or both).

So a keyring would look like this (approximately, forgive my missing
knowledge about the actual format):
(1) header
(2) hashed fields
(3) payload (encrypted using master key)
(4) master key encrypted using password hash
(5) master key encyrpted using a smartcard
(6) master key encrypted using XYZ

Like this you could attach/detach authentication methods to an already
unlocked keyring. The actual decryption would have to be done using
keyring-ask. Changing the password would simply mean reencrypting the
master key using the new password hash.

Not sure if one should be able to invalidate the master key - doing so
would remove all current authentication methods.

> I'm glad were moving forward on all this. Should we put this API up on a
> wiki somewhere and start finalizing it?

Yeah, good idea. I've already been asking for modalities and we can
just use the fd.o wiki to put the draft there. As soon as we have put
something halfway final together we can ask for even more input (I'm
sure other KDE developers would like to have a peek on it - otherwise
they might feel like something's being forced down their throats, not
sure about Gnome devs).

Regards,
Michael