There is often a fair amount of secret information that a Linux user might
store on their computer—things like passwords for sensitive sites,
private ssh keys, and Swiss bank account numbers. If multiple
applications, typically desktop
applications, need to access that information, there are solutions in the
form of GNOME Keyring and
KDE Wallet, but
those solutions are only available to applications written for those
specific desktop environments. A new freedesktop.org initiative, started by
the developers of those two solutions, aims to create a "Secrets
API" that can be used across desktop environments so that users can
have access to their secrets from any application, regardless of which
desktop it comes from.
The project was announced by KDE Wallet
developer Michael Leupold on the XDG mailing list (as well as on his blog).
The basic idea is fairly straightforward: users will still run Keyring or
Wallet as part of their login session—which will depend on the desktop
they use—but there will be an API that allows applications to extract
these secrets without caring which secret storage program is providing
Not surprisingly, given that it is a cross-desktop API, D-Bus will be used
to implement a protocol for extracting the needed secrets. Applications
will then use the new API so that they are insulated from the underlying
secret storage service. In his blog posting, Leupold notes that he will be
trying to provide backward compatibility: "While I expect a new
client-side API (which I imagine to be more OO style than KWallet::Wallet),
I'll keep an eye on providing something the current class can wrap so even
applications using the old API will be able to use the new system."
It seems likely that Stef Walter, the Keyring developer, will do something
similar for GNOME applications.
In the Secrets API,
secrets are just arrays of bytes that get transferred, possibly
encrypted, between the application and the storage facility. Each secret
is associated with a simple dictionary (i.e. set of name, value pairs)
called "lookup attributes", which are to be used to find the secret. In
addition, secrets have a label and properties associated with them.
Secrets can then be grouped into "collections", which more or less
correspond to today's
keyrings or wallets.
Items and collections can be locked, such that an unlocking process needs
to happen before they can be accessed. In practice, that would generally
mean that the user was prompted for a password before the item or
collection could be retrieved by the application.
Clients can negotiate encryption of the secret information as it is
transferred to or from the storage service. While that may seem like a good
idea overall, the API
documentation comes with some fairly strong caveats:
The encryption is not envisioned to withstand man in the middle attacks, or
other active attacks. It is envisioned to minimize storage of plain text
secrets in memory and prevent plain text storage of secrets in a
swap file or other caching mechanism.
Many client applications may choose not to make use of the provisions to
encrypt secrets in transit. In fact for applications unable to prevent
their own memory from being paged to disk (eg: Java, C# or Python apps),
[transferring] encrypted secrets would be an [exercise] of questionable value.
There are more details, of course, and the API specification is being
discussed and revised on the freedesktop.org
mailing list. In addition, there is discussion of higher-level topics on
such as how browsers will identify
their secrets so that moving between browsers, while still being able
to use the password information stored for the user, is easy. As
that is one of the most likely scenarios for users needing the Secrets API.
With this API in place, GNOME users could use Konqueror and still have
access to their passwords, and the same goes for KDE users and Epiphany.
As Leupold points out in his blog posting, though, Mozilla has not shown
any interest, at least yet. Integrating with the Linux desktop has not
really ever been a priority for Mozilla, so one might expect Firefox, et
al. to lag in this area.
Even for those not running one of the "big two" desktop environments, a
suitably configured system—with D-Bus and one of the secret storage
services enabled—could take advantage of the Secrets API.
Interoperability between desktop environments is a good thing, and not
having to store passwords somewhere external, so that one can "browser hop"
can only be a good thing as well. As it matures, other applications
needing to store secrets will presumably use it too. Having a single,
hopefully well-vetted, location for storing this kind of
information—encrypted and password-protected—may also lead to
security for users.
to post comments)