How Safe Is Your Mail System?

Many of us make false assumptions about the security of our "personal" or "private" communications. For example, when we phone a friend, we don't think about someone monitoring the call. When we send a letter, we don't consider that someone can intercept it. And when we send email, we don't expect anyone to alter its contents.

The truth is that all these communications methods are subject to interception and intrusion. Analog phone lines can be tapped. Cellular phone calls can be picked up on wireless scanners. Letters can be intercepted, compromised, and re-mailed. And email can be monitored, altered, or forged.

Some people don't worry because they don't send particularly valuable information. However, since worldwide email has emerged as an important component in today's business world, people have been transmitting increasingly important--and extremely valuable--information through the Internet and other public networks (see the sidebar, "Internet Email Architecture," ). Fortunately, new email standards and extensions are emerging to address the need for secure email delivery.

Concepts and Techniques
The most important technique in computer security is encryption. Secure or scrambled voice telephone lines and satellite television signals, and the secret codes that the military uses are examples of encryption. Encryption algorithms, such as the Data Encryption Standard (DES), the International Data Encryption Algorithm (IDEA), and RC2, transform data until no trace of it is left. IDEA is a symmetric-key block-cipher algorithm newer than, but similar to, DES. RC2 is a variable key-size, symmetric-key block-cipher algorithm also similar to DES and popular for exportable cryptographic systems because of its variable-length key.

An encryption key is required to return encrypted data to its original form. An encryption key is a binary value 40 or more bits long. With a good algorithm, you must have every bit of the key correct to retrieve any encrypted information. Even if you have 55 of 56 bits correct, decryption cannot occur. The longer the key is, the stronger the security is.

No encryption scheme can claim to be secure forever. Today, a home computer can crack World War II's best encryption algorithms in just a few minutes. In 100 years, some new device may crack today's algorithms just as easily. Fortunately, most secrets don't need to be kept forever. A monetary consideration is that the value of encrypted information determines whether accessing it is worth the price: If you can ensure secrecy either until no one cares about the information or so that cracking the code costs more than the information is worth, it's "secure enough."

For example a 40-bit key takes about $10,000 worth of supercomputer time and two weeks to crack. Although this key may be adequate to protect my checking account, it's probably not large enough for the accounts of a major corporation.

A slightly longer key of 56 bits re-quires millions of dollars to crack and should protect the information for years to come. A 56-bit encryption key has 256--or 72 quadrillion--possible keys. With 1000 computers, each trying 1,000,000 keys per second, trying them all would take 833 days. On average, you find the key halfway through your search.

An even longer key of 168 bits requires more money and potentially extends the data's secrecy for hundreds of years. With 168-bit keys, there are 2168 possible keys. This number is so staggeringly large that nothing can give you a feel for it. Suffice it to say that 1000 computers wouldn't be even close to trying all the keys by the time the sun finally burns out. That's probably secure enough for anything you want to protect.

The two basic kinds of encryption algorithms are symmetric key and public key.

  • Symmetric-key algorithms require that both the person encrypting and the person decrypting have the same key. A real problem with how to securely share keys between two or more parties is that most security systems based solely on symmetric-key algorithms break down in the area of key management. Symmetric-key algorithms, however, are a lot faster than public-key algorithms. DES, IDEA, and RC2 are symmetric-key algorithms.
  • Public-key algorithms use two keys: a public key and a private key. The public key is available to everyone you want to have access to your system. Your private key is your secret. For example, you might use your private key to digitally sign your email; then anyone with the public key will know that you--and only you--signed it. Unfortunately, public-key algorithms are extremely slow. To get around the speed issue, you can use a faster technique, such as a message-digest algorithm, to reduce the amount of data and then use a public-key algorithm to encrypt that smaller amount.

One public-key algorithm, the Diffie-Hellman key exchange, lets the sender and the receiver share a symmetric key securely. Thus, you can use a symmetric-key algorithm to encrypt the message. This combination achieves both speed and security.

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.