Goals for the Keyring and Seahorse Projects

Here are the current goals for the Gnome Keyring and Seahorse projects and the combined direction in which we're heading. These goals are in various stages of development. Some are a mere vision, while others have been working well for some time.

Want to effect these goals? There's tons to do, and we'd love to have your help. Just ask on the mailing list. We can use all types.

Want to affect these goals? The easiest way is to contribute and become a solid part of the project. Contributors (and sponsors) are the ones who have a say in its direction. Or you can choose a somewhat tougher path of trying to convince the contributors on the mailing lists:

The Open Source Desktop today has many technically excellent crypto and security projects. Our vision is to add glue and missing bits to bring these together into a usable experience. Each of the proceeding goals works toward that.

Goal: Consistent UI for keys and certificates

When interacting with keys or certificates, the look and experience should be consistent across the GNOME Desktop. This should be true for PGP keys as well as X.509 certificates.

Most of this is part of the libgcr library. This library is currently a part of the gnome-keyring module, but may be split out at a later date.

Certificate Widget

A widget that is usable as a simple display of the information that a user needs in order to uniquely identify a certificate, and which also expands to show all the certificate details.

PGP Key Widget

Similar to the certificate widget. In collapsed form it shows basic information about a PGP key useful to uniquely identify it, which can expand to show all the details.

  • Plan: Needs to be able to deal with keys that line in gnupg, and those in files (not yet imported).
  • Plan: Base around gnupg's --with-colons format internally.
  • Task: Implement this widget.
  • Where: Will live in the gcr library in gnome-keyring.

Key Widget

Similar to the certificate widget. Used with PK keys and SSH keys. In collapsed form it shows basic information about a key, which can expand to show all the details.

Certificate or Key Selector

Used when the user needs to select a certificate or a key. Will be usable with PGP keys and X.509 certificates. The design is for a basic combo box style selector, expandable into a full table with more details.

  • Worked with mpt@canonical.com on a design.

  • Plan: Also usable as a PGP recipient selector or PGP signer selector.
  • Plan: Should have an 'import' button or menu so the user can bring in additional keys not listed.
  • Plan: Will take ideas from seahorse's deprecated libcryptui library.

  • Task: Implement this widget.
  • Where: Will live in the gcr library in gnome-keyring.


We need a solid parser for crypto related stuff viewed by the user, or interacted with on the desktop. Must be able to parse certificates, PGP keys, SSH keys, and other unusual formats like PKCS#12. Because of this UI/interactive focus it's constructed very differently than parsers in other libraries.

  • Done: In gnome-keyring for years now.
  • Done: Parses PKCS#1 keys, OpenSSL PEM, PKCS#7 certs, X.509 certs, PKCS#12 archives, PKCS#8 keys
  • Where: Part of the gcr library in gnome-keyring.

  • Plan: OpenPGP parser should produce gnupg --with-colons format.
  • Task: Implement the OpenPGP parser.
  • Task: SSH public key parser.
  • Task: CRL parser.
  • Code: http://git.gnome.org/browse/gnome-keyring/tree/gcr/gcr-parser.h

File Viewers

Any crypto related file on the user's desktop should be able to be inspected easily. If the file is locked or encrypted, the viewer should recognize this. The prompt for unlocking should be intuitive and straight forward.

  • Plan: Will make large use of the gcr library.

  • Plan: Will be built on the parser, widgets, and importer.
  • Plan: Flowable document style, rather than widget look.
  • Plan: Should have an 'import' button or menu so the user can bring in additional keys not listed.
  • Plan: Must be careful not to misrepresent trust in data displayed.
  • Task: Implement file viewers.


Simple importer to store a key or certificate. Used by the selector and file viewers.


Icons for certificate, key, PGP key file, PKCS#12, PKCS#7, etc.

  • Done: Certificate already has one in the standard tango icons.
  • Plan: Perhaps use elemens of the PGP key icons from seahorse.
  • Plan: Reach out to the Gnome Art/Graphics team.
  • Task: Need to decide on a look for other file types.
  • Task: Need to register with MIME database.
  • Where: Will live in the gcr library.

Glue Code

Most of the above widgets and functionality should be usable with any crypto library, such as NSS, GnuTLS or others. There will be a simple set of certificates to implement to glue stuff to a crypto library. The remainder of the compatibility will come through use of PKCS#11 which allows us to have interoperable key and certificate storage.

  • Where: Will live in the gcr library.

  • Done: Interface for certificate is implemented and in use.
  • Code: http://git.gnome.org/browse/gnome-keyring/tree/gcr/gcr-certificate.h

  • Task: Will include helper plugin implementations for popular libraries.
  • Task: Figure out how to include helper code specific to a library without having a link time dependency on that library.

Goal: Common Storage of Keys and Certificates

To give a usable experince to the user, applications and libraries must be able to access the same storage for keys and certificates.

One can accomplish this by using a single crypto library everywhere. This approach can work to an extent, but ends up being an uphill battle when you include multiple desktops, coding philosophies, security reuqirements, and other conflicting issues.

The reality is that on the Desktop today we have many different crypto libraries in use. We need a common standard to unite them so they can interoperate with common storage.

There is already a defacto common way of storing OpenPGP keys: GnuPG. Our aim is to interoperate well with GnuPG for the storage and use of OpenPGP keys.

Using PKCS#11 to Store Keys and Certificates

We provide common storage of X.509 certificates and related keys via PKCS#11. PKCS#11 is a stardard designed for smart cards and crypto hardware. It's not without warts when it comes to utility as a common key and certificate storage. However, these warts are more than outweighed by the widespread implementation and deployment of PKCS#11.

GNOME Keyring is built around PKCS#11 internally. It will provide various modules for storing keys and certificates in different places.

  • PKCS#11 works with: NSS, Java, OpenSSH, QCA, Solaris, TrueCrypt, OpenVPN, GnuTLS

  • Work in progress in the GnuTLS project to integrate PKCS#11 and test it.
  • Task: Need to work work on RSA and DSA key generation, without blocking threads.
  • Where: The 'user-store' and 'xdg-store' components of gnome-keyring.

Storage of Trust Assertions

Decisions about which certificate is trusted is ultimately a complex process. OpenPGP trust decisions are made within GnuPG. X.509 trust decisions are made within their respective libraries and ultimately each application has a different flavor of trust.

The security arena desperately needs new advancements in how trust works. The CA model seen in web browsers has many flaws.

A trust assertion is way of saying that a certain certificate is trusted or untrusted for a given purpose. Trust assertions represent storage of things like CRLs, CA roots, trust exceptions. Future advancements in trust models can use trust assertions to store the results of their decisions.

We use the PKCS#11 Trust Assertion extensions developed by NSS and have been in use for more than a decade. However, no specification or documentation has been completed.

Storage of Keys and Certificates on Removable Media

Build a PKCS#11 module which allows storage of keys, certificates, and passwords on removable media. This can be used as a poor man's smart card, or for mobility.

  • Task: Not yet implemented.
  • Plan: For security reasons, each removable media will need to be configured with a user's desktop session, before that removable disk will be automatically used.

Goal: Common Storage of Passwords

We provide a common standard for the storage of passwords via the Secrets Service DBus API. This API was designed in the arena of XDG in order to provide cross desktop password storage.

New library for accessing passwords

The old libgnome-keyring library is brittle and doesn't adapt well to the new Secret Service DBus API specification. It doesn't support things like notification of clients of changes. The old library is implemented on top of the Secret Service API and uses it to access the password storage. Unfortunatly, this results in a bunch of hacks.

We need a new library (maybe called 'gsecrets'?) to provide access to the password storage via the Sceret Service API. Naturally applications could also use the DBus API directly.

  • Task: Create new gsecrets library.
  • Plan: Should follow the conventions of glib-dbus and other platform librarys that integrate GObjects and DBus.
  • Task: Deprecate libgnome-keyring.

Password storage format

Internally we still use the aging GnomeKeyring format for storage of passwords. It's very brittle and is having a hard time coping with the requirements of other goals. We need to design a better format.

We need to be able to unlock the keyring with multiple keys or passwords. For example the user should be able to log into the desktop with a smart card and have the keyring unlocked.

  • Task: Design a better password storage disk format.
  • Plan: Should allow multiple methods to unlock it: master password, keys (eg: stored on smart cards).
  • Research: Look into whether we can use fingerprint readers to unlock.
  • Where: The 'secret-store' module in gnome-keyring.
  • Plan: Format probably based on ASN.1/DER since the schemes for encryption and PBKDF are well defined.

Goal: Key and Password Manager

The desktop needs a solid key and password management application. Seahorse is the application that fills this role.

OpenPGP Key Management

An OpenPGP key manager requires a lot of functionality as each user is involved greatly in the web of trust. There is no PKI entity to do all the work of revocations, verification, signing, trust assertions. An OpenPGP key manager requires all this functionality.

Password Management

Management of stored passwords has two main focuses. Firstly, the user needs to be able to see and manage passwords stored by applications in the common password store. Secondly, the user should be able to store and retrieve their own passwords there, and use it as a place to keep their secrets, such as PIN codes etc.

Users seems surprised when they realize they can access the passwords that applications have stored in the common password storage. In the user's mind, the application should be able to access the password, but the user themself should not be able to read that password. From a developers perspective this seems like an insane contradiction, but we need a solution.

  • Done: Passwords can be viewed, and deleted.
  • Where: The gkr component of seahorse.

  • Code: http://git.gnome.org/browse/seahorse/tree/gkr

  • Task: Better design to meet the needs of users storing their secrets.
  • Task: Find a solution so user's aren't alarmed when they see their passwords stored.

PKCS#11 Management

The key manager will use PKCS#11 to access the common key and certificate store and generate, delete, or import keys/certificates there.

Smart Cards

Our key manager should be a good way to inspect a smart card and edit it as possible. It will access these smart cards via PKCS#11. We can't incorporate every necessary management feature. Each smart card deployment usually comes with a management interface or scripts to do these sort of things.

  • Where: The pkcs11 component of seahorse

  • Task: Ability to load arbitrary PKCS#11 modules.
  • Task: Testing with smart cards, and working with OpenSC project.

Goal: Seamless Security

User's have differing security requirements. Some users want to be conscious of passing through the various layers of their personal 'vault' and want to 'experience' the security. We should allow for this where possible.

However, for the vast majority we need to find solutions that allow users to be secure while at the same time not getting in their way. This is the way that the vast majority will use encryption and crypto technologies: If they're on by default, and don't get in the way.

This goal is to integrate security components in such a way that we provide a reasonably secure experience to the user without them needing to baby sit their own security. This is all about providing glue where necessary to bridge between security components.

It's also important not to provide the illusion of more security than there actually is. "Security theater" is not a goal here.

Unlocking on Login

We 'unlock' various aspects of the user's key and secret storage when the user logs into the Desktop. We accomplish this by means of a PAM module.

We have a 'login' keyring for storage of passwords that are unlocked when the user logs in. This is where there are stored secrets to seamlessly access keys and other things. The master password for this 'login' keyring is kept in sync with the user's unix login password.

  • Done: Has been a normal part of most people's linux experience and worked quite well.
  • Where: The pam module of gnome-keyring.

  • Code: http://git.gnome.org/browse/gnome-keyring/tree/pam

  • Task: If the user's password does not match the login password, prompt them for it and then change the password on the 'login' keyring to match.
  • Task: Better handle for users who don't use a password to login.

SSH Agent

We automatically make the user's keys (including those in ~/.ssh) available to ssh logins. This is done by having a PKCS#11 enabled SSH agent inside GNOME Keyring.

  • Done: Has been part of the desktop for a long time.
  • Where: The ssh-agent component of gnome-keyring

  • http://git.gnome.org/browse/gnome-keyring/tree/daemon/ssh-agent

  • Task: Match functionality in ssh-agent to prompt user when a key is used. This is useful for ssh agent forwarding.
  • Task: Avoid asking the user for an SSH passphrase if it matches their login password, to get parity with pam-ssh and avoid an extra prompt for new users or new machines. (bug 620761)

GPG Agent

To provide a better experience for GnuPG users, we have a gpg-agent in GNOME Keyring. This agent caches passwords for PGP keys. Can store these passwords short term (for a timeout, or the current session), or permanently in the common password storage.

Goal: Preventing Information Leakage

Today's computers are pretty leaky when it comes to information. Data is cached all over the place and logged in various places. Often security measures are taken when data leaves the computer.

Most users have the expectation that keys and passwords are stored in an encrypted manner inaccessible to those with access to the computer. This expectation isn't always realistic, but we should do our best to defeat offline attacks on the user's keys and passwords.

If the security context is compromised, everything is. We need research into how to run parts of the keyring system in a different security context.

Locking up before hibernate

Before hibernating or sleeping, all unlocked secrets and keys should be purged from the computer's memory. If hibernating, memory will be written to disk, thus defeating any encryption of keys (such as SSH or GnuPG keys). Even when sleeping, a computer has a much greater risk of being stolen, and having memory image attacks performed.

When the screensaver comes up on resume, we unlock.

Using non-pageable memory

Use non-pageable memory to store secrets in memory. This prevents them from being written to a swap file.

  • Done: Implemented our own allocator based on mlock().
  • Where: In the egg component of gnome-keyring.

  • Code: http://git.gnome.org/browse/gnome-keyring/tree/egg/egg-secure-memory.h

  • Done: Applications can use non-pageable memory in libgnome-keyring.
  • Task: Distros often limit each process to a very small amount of non-pageable memory even though the user has gigs of physical memory.

Prevent logging or caching of secrets

Communication between applications via mechanisms such as DBus, are often logged, cached or handled in a variety of insecure ways. We encrypt communication of secrets between applications in order to close these leaks. This encryption does not prevent active attacks by a compromised application or MITM attack.

Goal: Modularity

Distro's with special needs can use parts

Certain open source projects or deployments have requirements such as FIPS, security review, copyright assignment, GNU/Freedom, and others. People using some of the above components should not be forced to use them all.

Usable by other Desktops

We build things so that the various components can be taken apart into their own projects. This will allow use by other desktops or projects. Where possible we write in a UI agnostic manner.

Many of the current libraries live in the gnome-keyring git module for convenience sake, but can and probably will be split out as they develop further.

Testable in different parts

The different parts of the above solutions should be testable on their own. The components should be loosely coupled where possible. This allows more agile development and progress.


Non-Goal: Reinvent Everything

It's not the aim of the GNOME Keyring or Seahorse projects to reimplement a complete crypto library. There are many solid, secure, and technically excellent crypto libraries. It is our aim to integrate well with these and provide a usable experince for the user.

Projects/GnomeKeyring/Goals (last edited 2013-11-26 20:21:43 by WilliamJonMcCann)