[Authentication] Current State and Future of Secret Service API

[Stef Walter]

On 18.08.2014 21:47, Valentin Rusu wrote:
> On 16/08/14 19:29:37, Gary A Mort wrote:
>>
>> To sum up my longish email:
>> 0) Avoid implications that the api has anything to do with actual storage of
>> data.
>> 1) Assume that higher level api's as provided by Gnome Keyring and KWallet
>> are not being replaced as they are easier to program for
>> 2) Add an method to allow the server to give the client a list of preferred
>> encryption methods, sorted by preference. 
>> 3) Leverage existing documented api's for session encryption for SSL already
>> included with most desktops instead of documenting specific ones for this
>> api
>> 4) Discourage unencrypted secret transmission
>> 5) Add a method to allow the server to provide a list of alternate ipc
>> mechanisms for data transfer - use the existing URI specifications as most
>> desktops already have common uri parsing libraries.  IE
>> unix://socket=/opt/secretservice/run/service-sock
>>
>> ----the nitty gritty ----
>> 0) The trivial, "The Secret Service API allows client applications to store
>> secrets securely in a service running in the user's login session."   I've
>> been looking into PKCS#11 in order to create an open hardware HSM.  This has
>> led to also looking into many other similar technologies and one thing as a
>> novice that I find confusing is the way the api's are worded.  Generally
>> they refer to "storing in" or "saving" when they don't actually address
>> storage at all.  These API's are a method to store and retrieve secrets
>> using a specific methodology - but where the data is stored is irrelevant. 
>> I could have a PKCS#11 shared library which merely acts a link/conduit to
>> the KWallet API, with KWallet using the SecretService DBUS API to talk to
>> Gnome Keychain which for that particular storage slot is configured to
>> connect up to Mozilla's SoftHSM tool over PKCS#11 and finally accesses an
>> SQLITE3 database for the data.  Please avoid implications that the api in
>> any way specifies some practice for actually storing data to make the lives
>> of novices easier. :-)

Sure. Semes to make sense. Could you provide a patch to the
documentation for this? The markup is here, in the 'secret-service'
directory:

http://cgit.freedesktop.org/xdg/xdg-specs/

Or if you prefer github:

https://github.com/stefwalter/xdg-specs

>> 1) The service is abstracted to a point to be difficult to program for.  
>> This is not a bad thing though, since I think most applications should
>> instead be written to integrate with the native KWallet and Gnome Keychain
>> API's.   Only when extremely finicky levels of control over the service are
>> needed should one resort to programming directly to the API.

Yes perhaps. The client libraries like libsecret do mitigate this:

https://developer.gnome.org/libsecret/0.18/examples.html

>> 2) The current API spec lacks some basic security negotiation.  You have a
>> choice between no encryption or one encryption model,
>> http://standards.freedesktop.org/secret-service/ch07.html and the client has
>> no way of checking to see what methods are preferred/supported - so it can
>> merely try them in sequence.    There should be a query point for the API to
>> allow client to retrieve a list of supported encryption methods in order of
>> server preference.   There should also be a query point to retrieve a list
>> of any additional parameters.
>>
>> Something like
>>
>> GetEncryption (	IN Array<ObjectPath> methods,
>>  	OUT Dict<ObjectPath,Encryption.> methods);
>>
>> Where if the input is an empty array, the return is a list of methods
>> without parameters, sorted by preference.  And if it is an array of methods,
>> the return is a dictionary of the supported methods along with optional
>> parameters.

True. Not a bad idea. Would you like to propose such a change to the
spec, along with a patch? But see below for reasons the encryption stuff
should probably be deprecated long term...

Keep in mind that the encryption isn't that much of a protection in any
case. It only protects against very specific leaks and not many attacks.

>> 3) Specifying encryption methods is pointless.  Since Gnome and KDE, as well
>> as most current operating systems, includes some form of built in web
>> browser - just reuse the SSL session libraries that already exist and point
>> to the appropriate RFC's for how to handle encryption.   Stick with
>> dh-ietf1024-sha256-aes128-cbc-pkcs7 as a MUST support and leave all others
>> as options, including plain.

No, that's not the point of this encryption. It's just to prevent
logging and leaking to disk as the DBus message passes through various
daemons etc... You can see this here:

http://standards.freedesktop.org/secret-service/ch07.html

In fact once kdbus becomes mainstream, and solves these leaks, then we
should likely deprecate the encryption all together.

>> 4) Plain should  be discouraged for use in production.  Despite the numerous
>> other entry points for accessing secret data, there is no reason to create
>> yet more attack surface for security issues.

See above.

>> 5) Honestly, DBUS is the wrong way to communicate secrets.   It is ok to
>> have GetSecret/StoreSecret as a fallback that must always be there, but it
>> should also be flexible enough to allow for alternates.   There is nothing
>> wrong with falling back to other methods of message passing when they fit
>> the bill better.  As such, allowing for alternates and leaving it open ended
>> would allow for more security.  Simply add one more command to the api:
>>
>> GetSessionEndpoints(	IN String protocol,
>>  	OUT Array<String>);
>>
>> Where out is an array of URIs where secrets can be retrieved from.  For
>> example: dbus://org.freedesktop.Secret.Service would be the one currently
>> being used.  However, individual developers are free to extend this with
>> more specific endpoints in addition, such as
>> dbus://org.freedesktop.Secret.Service.GmortPasswords which can only access
>> my password database, or dbus://[randomlongcharectorstring] which the server
>> could create at the time GetSessionEndpoints was invoked and which would
>> only send/reply to messages sent by the same processid with the same userid
>> that invoked the method.
>>
>> More importantly though, it allows the api to be extended to go outside of
>> dbus.  https://localhost:[randomport] is also a valid uri as is
>> unix://socket=/opt/secretservice/run/service-sock
>>
>> Alternate communication methods should support the GetSecret/StoreSecret
>> methods in a similar manner as dbus.  IE once the connection is made, the
>> same string value that would have been sent over dbus is instead sent over
>> the alternate method.

This seems hopelessly complex, and I wouldn't be for including something
like this in the API.

The DBus mechanism for out of band communication is to pass a file
descriptor over DBus, and then communicate over the file descriptor. I
wouldn't be against adding a file descriptor based secret passing if
that solves some use cases.

Cheers,

Stef