Current State and Future of Secret Service API

Mon Aug 18 12:47:24 PDT 2014

On 16/08/14 19:29:37, Gary A Mort wrote:
> 
> 
> Looking over the code of the two implementations of the secret service API I
> believe the following is accurate:
> 
> Gnome Keychain currently can act as a Secret Service server[not sure how
> closely it follows the api]
> 
> KSecretService does not seem to be released yet.

KSecretService is still in early development, in KDE's playground.

> 
> KWallet can act as a Secret Service client - but only if compiled on a
> system where KSecretService is installed.
> 
> 
> This leads me to consider the API still in draft mode so I wanted to take a
> moment to comment on some shortcomings I find with the service.

Please note that there is a list to discuss Secret Service API - I put
this list in CC. Hope you'll get some answers from that list, also.

> 
> 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. :-)
> 
> 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.
> 
> 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.
> 
> 
> 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.
> 
> 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.
> 
> 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.
> 
> 
> 
> 
> 
> 
> --
> View this message in context: http://free-desktop-dbus.2324887.n4.nabble.com/Current-State-and-Future-of-Secret-Service-API-tp13509.html
> Sent from the Free Desktop - dbus mailing list archive at Nabble.com.
> _______________________________________________
> dbus mailing list
> dbus at lists.freedesktop.org
> http://lists.freedesktop.org/mailman/listinfo/dbus