On keys and users

Secure communication requires encryption keys, but key management and distribution are difficult problems to solve. They are also important problems to solve; solutions that can be easily used by those who are not technically inclined are especially needed. Turning encrypted communications into the default, rather than an option used mostly by the technically savvy, will go a long way toward protecting users from criminals or repressive regimes. Even if these secure communications methods are only used by a subset of internet users, that subset truly needs these tools.

HTTPS

For most users, the only encrypted communication they use is SSL/TLS for accessing web pages served over HTTPS. The keys used for HTTPS are normally stored on the server side in the form of certificates that are presented to the browser when the connection is made. In order to establish the identity of the remote server, to avoid phishing-style attacks, those certificates are signed by certificate authorities (CAs) such that the browser can verify the key that it receives.

This scheme suffers from a number of problems, but it works well enough in practice so that, by and large, users can safely enter credit card and other personal information into the sites. It relies on centralized authorities in the form of the CAs, however, which can be a barrier to web site owners or users who might otherwise be inclined to serve content over HTTPS. In addition, trusting CAs has its own set of dangers. But, contrary to some of the big web players' beliefs, the web is not the only form of communication.

Other protocols

For the most part, things like instant messages, email, peer-to-peer data transfers, and voice over IP (VoIP) are all transmitted over the internet in the clear. Solutions exist to encrypt those communications, but they are not widely used, at least partly because of the key problem. Each protocol generally has its own idea of key formats and storage, as well as how to exchange those keys.

For efforts like the Freedom Box, it will be extremely important to find a solution to this key problem, so that users can more-or-less effortlessly communicate in private. If multiple applications that used keys could agree on common key types and formats, it would reduce the complexity. That may be difficult for a number of reasons, some technical, others social, so perhaps finding a way to collect up all of a user's keys into a single "key bundle" makes sense.

Generally, encryption these days uses public key cryptography, which means that there are actually two keys being used. One is the public key that can be widely disseminated (thus its name), while the other is a private key that must be kept secure. A key bundle would thus have two (or more) parts, the bundle that's shown to the rest of the world for communication and authentication, and the other that's kept secret. This private bundle would require the strongest protections against loss or theft.

Generating the keys, and agreeing upon some kind of bundle format, are fairly straightforward technical problems. Those can be solved rather easily. But the real problems will lie in educating users about keys, the difference between public and private keys, and how to properly protect their private keys. User interfaces that hide most of that complexity will be very important, but there will be things that users need to understand (chief among them will be the importance of private bundle safety).

Storing the keys

It would be a simpler problem to solve if the private bundle could be kept, securely, in one location, but that's not really a workable scenario. Users will want (or need) to communicate from a wide variety of devices, desktops, laptops, tablets, mobile phones, etc., and will want to maintain their identities (i.e. keys) when using any or all of them.

Storing the bundles at some "trusted" location on the internet ("in the cloud" in the parlance of our times) might be possible but it would also centralize their location. If some entity can cut off access to your key bundle, it leaves you without a way to communicate securely. Spreading the bundles out to various locations, and caching them locally, would reduce those problems somewhat. Obviously, storing the bundles anywhere (including locally) would require that the bundles themselves be encrypted—using a strong password—which leads to another set of potential problems, of course.

Since these private key bundles will be so important, there will need to be some way to back them up, which would be an advantage of the cloud scenario. Losing one's well-established identity could be a very serious problem. A worse problem would be if someone of malicious intent were to gain control over the keys. For either of those problems, some kind of revocation mechanism for the corresponding public keys would need to be worked out.

There are already some solutions to these problems, but, like much of the rest of the key management landscape, they tend to be very key and application-specific. For example, GNU Privacy Guard (GPG) public keys are often registered at a key server so that encrypted email can be decrypted and verified. Those keys can also be revoked by registering a revocation certificate with the key server. But, once again, key servers centralize things to some extent. Likewise, SSL/TLS certificates can be revoked by way of a certificate revocation list that is issued by a CA.

Public keys

Most of the above is concerned with the difficulties in maintaining the private bundle, but there are problems to be solved on the public key side as well. Gathering a database of the public keys of friends, family, colleagues, and even enemies will be important in order to communicate securely with them. But, depending on how that public key is obtained, it may not necessarily correspond to the individual in question.

It is not difficult to generate a key that purports to be associated with any arbitrary person you choose. The SSL/TLS certificate signing process is set up to explicitly deal with that problem by having the CAs vouch that a given certificate corresponds to a particular site. That kind of centralized authority is not a desirable trait for user-centric systems, however, so something like GPG's (and others') "web of trust" is a better model. Essentially, the web of trust allows the user to determine how much trust to place in a particular key, but it requires a fair amount of user knowledge and diligence that may make it too complex for non-technical users.

Free software can make a difference

As can be seen, there are a large number of hurdles that need to be cleared in order to make secure communication both ubiquitous and (relatively) simple to use. Key management has always been the achilles heel of public key cryptography, and obvious solutions are not ready to hand. But they are important problems to solve, even though they may only be used by a minority of internet users. For many, the additional hassles required to securely communicate may not be overcome by the concern that their communications may be intercepted. For others, who are working to undermine repressive regimes for example, making it all Just Work will be very important.

This is clearly an area where free software solutions make sense. Proprietary software companies may be able to solve some of these problems, but the closed-source nature of their code will make it very worrisome to use for anyone with a life-and-death need for it. There have just been far too many indications that governments can apply pressure to have "backdoors" inserted into communications channels. With open standards and freely available code, though, activists and others can have a reasonable assurance of privacy.

These problems won't be solved overnight, nor will they all be solved at once. Public key cryptography has been with us for a long time without anyone successfully addressing the key management problem. Recent events in the Middle East and elsewhere have shown that internet communication can play a key role in thwarting repressive regimes. Making those communications more secure will further those aims.