Security Issues in Email
The most common threat to email is invasion of privacy. You don't want
anyone but the intended recipient to read the message. Another threat is to
message integrity. You don't want anyone to tamper with, or change, the contents
of the message while it's in the mail system. The third major threat is to the
authenticity of the sender. You want to ensure that a message really came from
the person it claims to be from, not someone else. Let's look at these three
issues.
Privacy: The privacy threat is simple to understand and
deal with. In most cases, you don't want people privy to the contents of your
email. This threat is analogous to tapping a phone conversation. Unlike with
phone taps, however, no laws currently restrict the interception of email. In
fact, email messages are often considered the property of the organization that
owns the email system, rather than of the message sender or receiver. Your best
bet is to assume that sending non-secure email is equivalent to posting a notice
on a public bulletin board.
Rumor has it that the US National Security Agency (NSA) can monitor all
email--at least all that crosses US borders--and scan for key phrases (e.g.,
bomb, kill, assassinate). If you encrypt your mail, however, an NSA snoop--or
any snoop, for that matter--needs to decrypt the message before reading it. With
a strong algorithm and carefully chosen and managed keys, you can make this task
overwhelmingly difficult, expensive, and time-consuming.
You can address your privacy requirements in two ways. You can manually
encrypt all messages and give your recipients the decryption keys.
Unfortunately, this approach puts the responsibility for security on your
shoulders. Or, you can automate encryption by using secure email servers. With
the eventual implementation of address book servers that also support public key
management, and client software that can obtain public keys with email addresses
(e.g., X.500), similar automation will be possible.
Secure email servers encrypt messages as they are transmitted over an
unsecured channel, such as the Internet. Secure clients encrypt messages in
transit. They can also store email in encrypted form, decrypting it only when
the recipient reads it. Because both approaches are automatic, the chance for
human error is removed. They are not, however, free from drawbacks.
Many people are surprised that deleting an email message doesn't remove all
occurrences of it from the email system. Maintaining privacy through deletion is
not a valid option.
Integrity: The integrity threat is similar to the privacy
threat. Unfortunately, email is an impersonal medium. Because it lacks many
traditional cues such as handwriting, stationery or letterhead, signature, and
sealed envelope, detecting email tampering without authentication technology is
almost impossible.
Encryption can also handle the tampering threat. To change encrypted mail,
you must decrypt the message, make your changes, and then re-encrypt it with the
original key. This process is more difficult than just trying to decrypt it.
Authentication: The authentication threat is a little
different. You can put mail on the Internet that is indistinguishable in
every way from mail really sent by someone else, but it's more difficult.
Encryption--with certain key-management techniques--can also handle this threat.
For example, if Bob receives a message encrypted with a key that only he
and Arnold have, Bob can be highly confident that the message came from Arnold.
However, if the mail system automatically generates and exchanges keys, Bob
knows only that it came from someone with a compatible mail system.
Digitally signing email without encrypting the contents is also possible so
that the recipient can detect any tampering and determine whether the message
really came from the person who claims to have sent it. Both Privacy Enhanced
Mail (PEM) and Secure Multipurpose Internet Mail Extensions (S/MIME) routinely
authenticate all messages, although encryption is optional. Digitally signing a
message requires only that you can access your own secret key; it doesn't
interfere with anyone's ability to read the message with or without public keys
or secure mail clients. The digital signature is just a special text string
added to an otherwise normal-text email. Of course, you cannot verify that
digital signature without the signer's public key and a secure email client that
supports the digital signature algorithm.
Client-Based Solutions
A client-based solution adds extensions to the email system but requires no
changes to existing Internet mail servers. Messages that the extended clients
send must comply with the syntax defined in the Request for Comments (RFC) 822
standard. (You can retrieve RFCs from the Internet at
http://www.internic.net/ds/dspg0intdoc.html.) The three primary standards are
Pretty Good Privacy (PGP), PEM, and S/MIME.
- PGP is an informal standard that relies on an unconventional decentralized
scheme for establishing trust. PGP doesn't fit into hierarchical--corporate or
government--organizations very well.
- PEM is an Internet Engineering Task Force (IETF) standard (RFCs 1421
through 1424). It supports digital signatures using Rivest-Shamir-Adelman (RSA)
algorithms and various encryption algorithms. One implementation of PEM is Mark
Riordan's Internet Privacy Enhanced Mail (RIPEM). Unfortunately, PEM was never
widely adopted, mostly because of the difficulty vendors had creating
interoperable systems.
- S/MIME has emerged recently as the primary standard for interoperable
secure email. Essentially, RSA refined the PEM specification using the Public
Key Cryptography Standards (PKCS) so that any mail package meeting that standard
is more or less guaranteed to interoperate with other PKCS-compliant products.
In the next few months, you'll see release of several S/MIME-compliant Internet
mail clients.
Client-based solutions have several advantages.
- Existing Internet mail servers need no changes.
- The solutions provide end-to-end security; the entire path from the sender
to the receiver is secure.
- You can implement client-based solutions either to automatically decrypt
incoming mail and store it in plain text form or to store it in the received
encrypted form, requiring decryption each time it's read. This approach secures
even your local message store against unauthorized access.
- Digital signatures can provide good authentication.
Client-based solutions also have some real disadvantages.
- The client software that the sender and the receiver use must be totally
interoperable.
- If the sender selects encryption and the receiver doesn't support the
encryption scheme, the system doesn't automatically drop back to plain text
because that would breach security. Instead, the receiver ends up with an
unreadable message.
- The sender, receiver, subject, and other fields in the mail header are not
encrypted. They are in plain text, which could be a serious security breach.
- The user must understand a fair amount about security to use the client and
must manage public keys. For example, to send me an encrypted message, you must
obtain my public key. In the future, Internet Directory Systems will be able to
look up any email address and public key and supply them to your client; X.500
is such a scheme. At present, though, obtaining and managing public keys can be
a hassle.
Server-Based Solutions
Instead of putting the security burden on the client software, you can place
it on the mail-server software. Specifically, with the Secure Simple Mail
Transfer Protocol (S/SMTP) instead of the usual unsecured SMTP protocol, you can
automatically secure mail-server-to-mail-server traffic. To use S/SMTP, two
sending and receiving mail servers determine whether they both support S/SMTP.
If so, they negotiate the strongest encryption algorithm they have in common.
Then, they do a Diffie-Hellman key exchange to securely share common key
information. After the two servers conclude negotiations, all traffic over the
connection is encrypted--not just the message body, but all header information,
including names, email addresses, and the message subject.
The primary application for this security approach is protecting email over
the Internet. This approach doesn't secure the client-to-server traffic,
however. It is currently delivered over a private network link, sent over a
non-TCP/IP network (e.g., an Internet Packet eXchange--IPX--network), or
protected by a firewall.
The advantages of server-based security are
- It works with all existing SMTP/Post Office Protocol version 3 (POP3)
clients User Agents.
- You don't need to worry about key management; key generation and exchange
occur automatically when the server-
to-server connection is established.
- All message headers and the message body are encrypted.
- The negotiation phase lets secure servers interoperate with non-secure
servers, and domestic-version secure servers can communicate with export-version
secure servers.
- No users need to know that a secure server is in use; no disruption of
existing Internet mail occurs when you introduce secure servers.
The two major disadvantages to server-based security are that the
client-to-server link is not secure and the basic S/SMTP protocol does not
address the authentication threat. One minor disadvantage is that you need from
five to 25 se-
conds of CPU time--depending on key size and CPU type--to
perform the Diffie-Hellman calculations on each connection.
Safe and Secure
A secure email system must protect mail-message privacy and integrity and
sender authenticity. Encryption is the key to the first two. Symmetric-key and
public-key algorithms each have a place in security systems. Neither is
inherently superior or inferior; a combination of the two is more useful than
either alone. If authentication is a concern, use S/MIME-compliant mail clients
to sign all messages digitally.
In addition, you can choose either a client-based or a server-based
solution. Each has pluses and minuses. A client-based solution provides
end-to-end (i.e., sender-to-receiver) security but requires interoperable client
software at both ends. A server-based solution allows interoperability with
non-secure servers, but the client-to-server link is not secure.
A secure mail system consists of several components. Your enterprise will
need a firewall between its internal sites and the Internet (see the sidebar, "Up
Against the Wall," Windows NT Magazine, September 1995) or
at least use a non-TCP/IP protocol (e.g., IPX) internally. And use at least one
secure mail server at each site as a gateway to and from non-secure internal
servers.