Secure communication requires encryption keys, but key management and
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.
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)
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.
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"
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
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.
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
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
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
revocation list that is issued by a CA.
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
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
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.
to post comments)