Current State and Future of Secret Service API

[Gary A Mort]

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.

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.

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.