Desktop Summit: Crypto consolidation

While it is "boring stuff" at some level, consolidating the various desktop cryptography solutions has the potential to "pleasantly surprise our users and impress them", according to Stef Walter in his presentation at this year's Desktop Summit in Berlin. His talk, "Gluing Together Desktop Crypto" outlined his plan to use PKCS#11 as the "plumbing" that will serve as the foundation for desktop-wide and cross-desktop sharing of keys and certificates. Once the boring parts are taken care of, "we can do more interesting things", he said.

The basic problem that Walter is trying to solve is that many of our applications have their own ideas of where to store keys and certificates, which leads to duplication and, sometimes, user confusion. If two (or more) separate applications are accessing the same site and service (e.g. https), it would be much simpler if they were both using the same cryptographic information. Centralizing the storage of keys and certificates will make it easier for users to migrate that data to new systems as well.

The current crop of desktop encryption tools is good, and many of the tools are very stable, he said, but they need to be glued together to make them more usable. He is involved in both gnome-keyring and Seahorse development and noted that those applications already do some consolidation. For example, gnome-keyring stores both ssh and GPG keys, but it needs to be done "one level lower", he said. There needs to be a single store for keys and certificates, "so the user doesn't have to care about where they live". There is lots of diversity on the desktop, which "should be celebrated" but not pushed out to users, he said.

Fedora is currently porting applications to use Mozilla's Network Security Services (NSS), which has a certificate store, but he has an alternate proposal that will still work with Fedora's solution. He is proposing to use PKCS#11 (p11) as the standard for keys and certificates, because it has a number of different useful characteristics including integrating with hardware crypto devices and smart cards.

There are three steps that need to be taken to hide the complexity of crypto on the desktop from the user, he said. First you need to be able to store keys and certificates in such a way that all applications and crypto libraries can access the same ones. Second is that the framework needs to make consistent trust decisions. Today it is too often the case that one desktop application can connect to a particular service or system, but that others on the same box cannot—or they each may need to be configured separately. Lastly, there needs to be a way for applications to refer to keys and certificates in a consistent way, so that they (and users) can refer to them in standard ways.

Key storage is special, Walter said, so that a simple file or database cannot be used for that purpose. The idea is that some keys never leave the key store, instead the store signs those keys and returns that blob for use elsewhere. According to Walter, p11 makes for a good key store that can be used to glue together the different libraries that are used in various applications.

The p11 standard has "modules" that are something like drivers for different kinds of devices or storage facilities. It has a C API that is "old and baroque", but it does what is needed, he said. It is "not perfectly awesome, but what it has going for it is that it is supported in everything". Gnome-keyring and NSS already support it, while support in GLib, OpenSSL, and others is a work in progress.

When using p11 on the desktop, there are some coordination issues that need to be resolved for a single application that is using multiple libraries which all use the same p11 module. That's where p11-kit comes into play. It will coordinate the access to p11 modules as well as providing a consistent way for applications to determine which modules are installed and enabled on the system. It also handles some configuration duties, for example by telling applications and crypto libraries what key store they should be using.

Any application that is using p11 can use p11-kit because it can be used as a p11 proxy module. Due to the module mode, it can be used in various places without actually integrating it into the code. Walter specifically mentioned Java and Solaris as two possibilities there. It's BSD licensed and has no dependencies other than libc.

Trust decisions are another area that Walter would like to see addressed and he thinks that can be done using p11 as well. A trust decision is a positive or negative assertion about a particular object (e.g. key or certificate). It can also associate a level of trust in the object. The p11-glue freedesktop.org umbrella project, which is where this work is being done, has a proposed specification for storing these assertions.

Since the keys and other objects don't leave the key store, there needs to be a way to consistently refer to them so that they can be reused. There is an IETF RFC draft for p11 universal resource identifiers (URIs) that could be used. Those objects could then be referred to using the pkcs11: URI scheme.

None of the p11 support is "written in stone", Walter said. It is all still being designed and developed so he invited interested parties to get involved and help shape it. Once the code is written and gets into the distributions, users will have a much easier time dealing with crypto objects for multiple applications and desktops.

Several audience questions further explored the possibilities that this work would enable, including Mac OS X and Windows support and how to handle PIN queries for accessing smart cards. One area that is still needing a lot of attention is certificate revocation lists (CRLs). Revocations are essentially negative trust assertions that could be stored. Another possibility is to make a p11 module that exposes a directory of CRLs that can be used by applications. There is "no actual progress there", he said, but there are "solid plans". It is a topic that is under active IETF discussion as well, he said.

Making desktop crypto work reliably, and largely invisibly, across all of the applications on the free desktop would be an enormous boon for users. Having Firefox and Chromium (as well as other browsers) share certificates (and the level of trust the user has in them) would be quite nice, but it reaches out even further than that. Lots of other applications are rendering web content these days, so those could share the same information too. Multiple email clients could hook into the same keys, regardless of whether they were GPG keys or X.509 keys from some other email encryption scheme. Switching to a different desktop environment would no longer necessitate a repopulation of keys and certificates for various services. And so on. As Walter said, it certainly has the possibility of surprising and even impressing users who have likely been bitten by some of these problems in the past.

[ I would like to thank KDE e.V. and the GNOME Foundation for assistance with my travel to the Desktop Summit. ]