May 1996
By Raph Levien, University of California, Berkeley
Protecting Internet E-Mail From Prying Eyes
Several schemes for keeping e-mail safe are under development. Here's how they stack up.
[
Inside Internet E-Mail Encryption
]
It's Friday afternoon, and you have just received e-mail from the
company president: You're fired. You put the house on the market, call
the headhunter, start scanning the want ads--and then find out that you
are the victim of a hoax perpetrated by a hacker with a warped sense
of humor.
Farfetched? Unfortunately, it isn't. As the use of the Internet
goes on booming, companies are increasingly turning to Internet mail
packages for their corporate needs. But unlike corporate e-mail
packages, most Internet mail packages don't have built-in
authentication or confidentiality. As a result, it's disturbingly easy
to read e-mail traveling over the 'Net--and even easier to forge mail
convincingly. Firewalls can't help, and even secure private networks
aren't much good, since one of the big advantages of Internet e-mail
is that it reaches anyone, not just people on the virtual corporate
net.
There are a lot of options. Standards bodies and individual
implementors have come up with five different protocols for e-mail
encryption. These schemes all basically do the same thing--protect
e-mail as it travels over the Interne
t--but they use different
encryption algorithms and authentication techniques. Further, they
take different approaches to handling such issues as key
management--issues that are just as important as encryption in ensuring
the safety of data. Finally, the design decisions vendors make to
implement these protocols can determine just how easy they are to use
and administer, especially on a large network.
All of these protocols are standards or standards in the making,
and they are in various stages of implementation: Some are now
commercial software packages, while others exist only on paper. But
vendors are likely to be shipping all of them within the next few
months, which means that it is important to understand how they stack
up. Now is the time to find out what the protocols are, how e-mail
encryption schemes work in general, and why the protocols differ in
specifics.
FIVE PROTOCOLS
Perhaps the most significant of the five protocols is called secure
multipurpo
se Internet mail extensions (S/MIME), which a group of
companies led by RSA Data Security Inc. (Redwood City, Calif.) is
currently developing. S/MIME is likely to become an IETF (Internet
Engineering Task Force) standard by year-end. In many ways, it is one
of the most fully featured secure e-mail protocols: For example, it
supports the encryption of multimedia data rather than just straight
text. Unlike some other schemes, S/MIME also guarantees
interoperability between any two implementations; rival protocols
allow implementors to choose noninteroperable encryption options.
Finally, many Internet mail vendors say that they plan to support the
scheme, though commercial versions of it aren't available yet.
Another popular scheme is called Pretty Good Privacy (PGP).
Developed by Philip Zimmermann, an independent security consultant
based in Boulder, Colo., and released as freeware in 1991, it has
since become the de facto standard for mail encryption on the
Internet. PGP is also commerc
ially available from Viacrypt (Phoenix.)
This year will see the release of Version 3.0.
One of PGP's biggest drawbacks is its inability to handle
multimedia data. PGP/MIME attempts to remedy this problem by adding
the ability to handle MIME objects. The spec is currently wending its
way through the IETF standards process and will most likely be
finished by the time of the June IETF meeting in Montreal. There are
currently two implementations of the PGP/MIME draft: premail
(developed by the author) and the PGP/MIME reference implementation by
Michael Elkins of Aerospace Corp. (San Diego). Neither has been sold
commercially.
Yet another attempt to encrypt multimedia data is MIME Object
Security Services (MOSS), currently defined in RFCs (Requests for
Comment) 1847 and 1848. No full-fledged commercial implementations
have been available to date, but there is broad support for adapting
some parts of MOSS--especially the multipart/signed message format--for
use with other cryptogr
aphic protocols. (The multipart/signed format
allows different parts of a message to be individually encrypted and
signed.)
Finally, the Message Security Protocol (MSP) attempts to refocus
the secure e-mail protocols developed by the NSA (National Security
Agency) for use with its Defense Secure Data Networking System so that
they can be used with Internet and MIME mail. The underlying protocol
is standardized in the SDN.700 series of documents from the National
Institute of Standards and Technology (NIST, Washington, D.C.), while
MIME integration currently is an IETF Internet draft. MSP has actually
been around for a while--especially in X.400 environments--but
specifications and implementations for native Internet e-mail have
emerged only recently.
MSP contains two features that are lacking in any of the other
proposals, and both could be quite important in a business or,
especially, a government context. The first is a cryptographically
strong signed-receipt capability (so
metimes called a non-repudiation
of receipt), which offers proof that the recipient actually received a
message and that the message received was identical to the message
sent. The second feature is the ability to classify messages--as
top
secret,
for example. An MSP mail client rejects messages if the users
do not have the ap- propriate authorization to read them.
One problem with MSP is that different implementations aren't
guaranteed to interoperate, because two implementations may choose
different and nonoverlapping sets of algorithms. Before communication
is possible, users must agree on both the use of the MSP protocol and
a specific algorithm set. The two main algorithm suites implemented
for MSP are the Mosaic suite (the encryption used with the Clipper
chip) and RSA with DES (Data Encryption Standard).
A few implementations of MSP already are shipping, and several more
are in progress. For interactions with the government, this is
probably a good choi
ce.
KEY PRINCIPLES
Although e-mail encryption protocols differ in particulars, any
such protocol must provide two things: confidentiality and
authentication. Confidentiality means that only the authorized
recipient of a message can read it. Authentication is a guarantee that
a message is really from its stated originator.
To provide these services, all five protocols rely on secret-key
encryption to encrypt the message, public-key encryption to encrypt
the secret key, and a hash function to provide authentication.
The basic idea behind secret-key encryption is to encrypt a block
of data using an encryption algorithm and a number called a
key,
known only to the sender and the recipient. Thus, even if it is known
that a particular message has been encrypted using a particular
algorithm, such as DES, it is impossible to decrypt that message
unless the key too is known.
But both the sender and the recipient must know the key ahead of
time--a logistical challenge if the two have never exchanged e-mail
before. That's where public-key encryption comes in. Public-key
encryption relies on two keys--one public, the other private--and both
are needed to decrypt a message. Yet to encrypt a message, only the
public key is needed. That's where the confidentiality comes from: A
sender who knows a recipient's public key can encrypt a message using
it, and only the person holding the private part of the key can
successfully decrypt the message.
The catch? Public-key encryption is computationally expensive,
which means that it's not practical for encrypting an entire message,
at least with the hardware and software available on typical corporate
desktops. So instead of using public-key encryption to encrypt the
actual e-mail message, these protocols use public-key encryption to
encrypt the secret key. Then a secret-key algorithm encrypts the
message.
Public-key encryption also works in conjunction with a hash
functio
n to provide authentication. Essentially, a hash code (also
called a message digest) is a small chunk of data unique to a
particular message but much shorter than the message itself. Think of
it this way: A hash code is like a digital fingerprint that makes it
possible to distinguish one message from another, even if the two
differ by only a single bit.
To provide authentication, an encryption protocol extracts a hash
function from the message, encrypts it with the sender's private key,
and appends the encrypted hash code to the message. The hash code can
be decrypted by anyone who knows the public key, but the fact that the
decryption is successful proves that whoever originated the message
had the private key and therefore was the person he or she claimed to
be. (Once again, encrypting the entire message with public-key
encryption would provide this kind of authentication but would be too
expensive computationally.)
SOUND CHECK
One of the first differences am
ong the five protocols is the size
of the keys used to encrypt messages. Key size is an important factor
in ensuring cryptographic soundness: The larger the key, the stronger
the encryption. In fact, many algorithms are considered
cryptographically sound only if they're used with fairly large keys.
One potential drawback with S/MIME is that it permits the use of
keys that are too small to ensure adequate security. All S/MIME
implementations must include RC2, a proprietary cryptographic
algorithm from RSA with a 40-bit key. Because RC2 represents a lowest
common denominator, any two S/MIME implementations can definitely
communicate with each other--something that isn't necessarily true with
some other schemes. The trade-off is that because 40-bit RC2 is the
default algorithm, communications will probably be insecure.
In a presentation at a conference this past November hosted by the
Business Software Alliance (Washington, D.C.), an industry consortium,
a panel of security e
xperts said that 40-bit keys offer virtually no
protection. In fact, they claimed that a hacker could easily crack a
single 40-bit message in a weekend using borrowed computer time.
According to the panel, a corporate engineering department with a
$300,000 budget could build a machine that could crack five messages a
second. Thus, any encryption scheme that calls for 40-bit key sizes--or
that can operate with 40-bit keys--shouldn't be considered guaranteed
secure. (For more information about the impact of key sizes on
security, net managers can check out the paper
Minimal Key Lengths
for Symmetric Ciphers to Provide Adequate Commercial Security,
by
Matt Blaze, Whitfield Diffie, Ronald L. Rivest, Bruce Schneier,
Tsutomu Shimomura, Eric Thompson, and Michael Wiener. It is available
as http://theory.lcs.mit.edu/~rivest/bsa-final-report.ps ). Other
algorithms with larger key sizes can be used, however; S/MIME also
supports two different flavors of DES, with 56- and 168-bit keys.
Another cryptographic weakness of S/MIME--one that also affects MSP
but not the other schemes--is that eavesdroppers can distinguish
between encrypted and signed-and-encrypted messages. More important,
they also can tell who signed the message. If, for example, Netscape's
Marc Andreesen and Microsoft's Bill Gates were to exchange a number of
signed messages, an eavesdropper might be able to draw conclusions
about the possibility that the two companies were forging a business
relationship.
PGP's underlying cryptography is quite sound: For message
encryption, it uses the International Data Encryption Algorithm (IDEA)
with a 128-bit key. In fact, there is no mode of operation with a
smaller key size, which makes PGP exceptionally safe. MOSS is mostly
cryptographically sound. But since it doesn't mandate the choice of an
encryption algorithm or a key size, a MOSS implementation can use a
key that's too small or fail to interoperate with other MOSS
applications.
MANAGEMENT
METRICS
Key management is another differentiator. The way these e-mail
security schemes keep track of keys helps determine not only how easy
they are to use and administer but also how much protection they
ultimately provide.
With a public-key system, key management has two aspects: first,
finding the public key of any communications partner and, second,
guaranteeing that the public key really corresponds to that party.
Without such a guarantee, attackers who can convince users that their
phony keys really belong, say, to the president of a company can wreak
just as much damage as they could if they were able to break the
encryption algorithms.
Consider the so-called man-in-the-middle attack, in which an
intruder inserts a relay process into the network between
communicating parties, pretending to be both of them. Thus, when one
party sends a message to the other asking for his or her public key,
the attacker intercepts it and returns his or her own public key.
He
or she does the same thing with the intended recipient. As a result,
each side thinks it's communicating with the other, but the attacker
is actually intercepting and decrypting all of the messages and then
re-encrypting them or different substitute messages. This kind of
attack is particularly dangerous because it can go unnoticed for quite
a while. Avoiding such attacks is one of the goals of key
management.
Two main approaches to key management now exist: certification
hierarchies, originally developed for the Privacy Enhanced Mail (PEM)
standard, and the web of trust, generally associated with PGP. (PEM
has recently been moved to
historical
status by the IETF, meaning
that it is no longer being implemented.)
As the name implies, certification hierarchies take a hierarchical
approach to key management; in fact, this model can be thought of as a
client-server take on the entire issue. The web of trust is a more
distributed, or peer-to-peer, approach.
Certification hierarchies are based on a central certification
authority that is implicitly trusted by all e-mail users. Physically,
the certification authority can be many things, including dedicated
hardware or software running on a server. It can even be a government agency, albeit indirectly: The U.S. Postal Service (Washington, D.C.) plans to issue certificates on floppy disks to users who request them. In practice, however, for most secure
e-mail applications, the certification authority is likely to be
software running on the mail server.
To get a public key, a user queries the certification authority
(see Figure 1). It returns the key, which it has signed.
Signing
in
this context means notarizing the key to indicate that the
certification authority guarantees its validity. Typically, this is
accomplished by means of a digital signature.
Figure 1: Keying in to Security
Internet e-mail encryption relies on an exchange of public keys. Typically, the sender obtains the recepient's public key from a certification authority, which validates it. The public key is used to encrypt the message.
|
A variation on this idea is the so-called certification chain. In
this scheme, a root certification authority signs certificates
designating other authorities to certify keys on its behalf (see
Figure 2). Those authorities in turn can certify other authorities,
and so on. At the bottom of the certification hierarchy is a
certificate that signs the user's individual public key.
Figure 2: Chain of Trust
With a hierachical cert
ification authority, the root authority certifies other authorities. Its designates, in turn, certify clients.
|
Certification hierarchies tend to work well in structured
organizations, such as corporate networks. But for this scheme to be
used in communications among different organizations, they must all
agree on a certification authority that can be trusted by all--and this
isn't easy. For example, corporate users aren't likely to trust
certificates signed by the certification authority of a competing
company or by an authority run by governments of hostile
countries.
The alternative to certification hierarchies is the web of trust. In this model, users decide for themselves which keys are valid. In other words, a user decides to trust keys that come from a trusted source and arrive via a secure or reasonably se
cure route that ensures they haven't been tampered with. For instance, a worker might trust a key, sent by a known co-worker, that arrives over a secure private network--but not a key purporting to be from an employee at another company arriving via the Internet. Users also can sign the keys of other users, which leads to the
web
part of the web of trust. For example, Alice can sign Bob's key, and Peter can configure his e-mail client to trust all keys signed by Alice.
BOOTSTRAPPED TRUST
In both
models, the problem of bootstrapping trust remains. At some point,
whether the certification mechanism is a hierarchy or a web of trust,
the local e-mail client must be configured to specify which
certification authorities and users are trusted and which aren't.
In
the certification hierarchy, a single root authority is hard-wired
into the client. The client software is preconfigured to use a
particular certification authority (or set of trusted users), and this
configuration cannot be changed by users. When a user first installs
the e-mail package, the software therefore
knows
whom to trust.
Recently, however, it has become clear that a single root authority
just isn't flexible enough. The answer is configurable certification
authorities, which let users configure certification authorities on
their own. But how are users to know that the certification authority
itself is authentic? It's not sensible to send the user e-mail saying
trust this certification authority,
since that user has no way of
knowing whether or not this message itself is trustworthy. As a
result, the authority must be verified through some reliable outside
channel--for example, an employee policy guide.
THE PRACTICAL PART
The big advantage of certification hierarchies is that they make it fairly
easy to enforce a consistent policy. On the downside, organizations
that want to control who gets authenticated will need to set
up and
maintain their own certification authority, a process that requires
specialized administration.
The web of trust tends to offload many
administrative headaches to end-users, which also has its advantages
and drawbacks. On the plus side, sophisticated users are likely to
feel more in control, since they're the ones determining whom to
trust. The minus side is that key management can be quite a
challenge--it can make schemes that implement the web of trust model
frustratingly difficult to use.
The certification hierarchy most
commonly used by secure e-mail schemes is the X.509 spec from the
ITU-TSS (International Telecommunication Union-Telecommunications
Standards Sector). The X.509 spec, which defines the relationship of
the certification authorities, is part of the X.500 series of
recommendations for a global directory structure using
distinguished
names
to track users and other objects stored in a directory.
S/MIME's key management scheme, f
or example, calls for the
hierarchical structure defined in the latest update of X.509--Version
3, the most flexible to date. This explicitly allows certification
paths to start in the local security domain (the certification
authorities controlled by an organization) of the public-key user
system. The other notable feature of X.509 Version 3 is its ability to
bind keys directly to Internet e-mail addresses rather than only to
X.500 distinguished names.
S/MIME's key-management model is in some ways a hybrid between certification hierarchy and the web of trust: As
with the web of trust, net managers have to configure each client with
the list of trusted keys. In this case, they are the keys of the
certification authorities.
Full certificates are included in every
S/MIME signed message. This makes messages a few hundred bytes larger
but also makes key management a little easier. Whenever a user
receives a signed message, the key of the signatory goes into the
local key databas
e, where the keys are stored. If the key is signed by
a trusted certification authority, trust can be established for that
key, and it can be used in the future without remote database
operations. Thus, end-users don't have to authenticate the key each
time they employ it.
As noted earlier, PGP uses the web of trust
model. Its key management tends to be one of the scheme's biggest
drawbacks, especially in business settings. Overall, PGP's key
management is hard to learn, time-consuming, and dependent on a great
deal of manual intervention. Every time a new key is needed, either
for checking a signature or encrypting e-mail, users must perform
several manual operations. First, they have to get the key; it could
be on their partner's Web page. Then they must put the key into the
local PGP key database, called a
keyring
in PGP terminology. Next
they have to check to make sure the key is valid. In PGP's current
implementation, these steps require fairly complex and tricky co
mmand
lines. But this complexity is not inherent in PGP; key management may
eventually become easier.
MOSS supports two modes of key management:
X.509 and manual, using the web of trust. Users get more options, but
one feature that's missing is a cryptographic hash of the public key.
Without it, users either have to trust the mechanism that delivered
the key or examine the entire key to be sure it hasn't been tampered
with. This creates a serious problem.
MSP, which closely resembles
S/MIME, is based on the X.509 certification hierarchy and raises
similar issues about signed message formats. At present it's still
unclear whether MSP will be implementing X.509 extensions that make
the handling of certification more flexible.
IMPLEMENTATION ISSUES
A major issue with all of these schemes is how they are integrated with
mail packages. In some cases, the encryption scheme is an add-on
application; for example, PGP is packaged in a single app that can
wor
k with existing mail packages--an important reason for its
popularity. In general, however, these schemes are best integrated
directly into the mail package.
One reason for this approach is the
fact that it makes it possible to integrate key management and users'
address books. Unless the encryption protocol is integrated with the
mail application, two address books are required: one to select e-mail
addresses, the other to map e-mail addresses to keys. Because this
requires users to keep track of two separate databases, the approach
can be cumbersome.
Raph Levien is a graduate student in computer science at the University of California, Berkeley, and the author of a PGP/MIME package called premail.
[
Home
]
[
Registration
|
Subscriptions
]
[
Contact Us
|
E-Mail
]
|
