E-Mail Security

Security problems hinder the growth of e-mail as a business tool.

In this installment, I'll cover the security problems that users and organizations face when using e-mail, as well as possible solutions to those problems.

Identity Crises

E-mail has several inherent security problems (see "What Ails E-Mail"). When placed in the context of business communications, these problems limit e-mail's potential as a serious business tool. For example, one of its limitations is privacy. Normally, e-mail is sent "in the clear," meaning the message is sent in plaintext. So, anyone who can access the e-mail, whether in transit or in storage, can read the message. Clearly, this is a security problem that may prevent companies from using e-mail to convey confidential business information.

What Ails E-Mail

Here's a list of the main security issues that affect e-mail.

Lack of privacy E-mail is sent in plaintext and can be read by anyone who can access it.

Lack of integrity There is no safeguard to prevent someone from changing the contents of an e-mail message while it's in storage or in transit.

Lack of authenticity Anyone can forge an e-mail message that claims it was written by another individual.

Lack of nonrepudiation Any particular e-mail message can't be bound to its sender, so a sender can deny ever having sent a message to you.

Viruses E-mail messages can contain attachments that are actually viruses in disguise; when you open the attachment, the virus spreads to your PC.

Spam An e-mail account is an open home for spam, those annoying mass e-mail rants and advertisements

Another basic problem revolves around the integrity of a particular piece of e-mail. As mentioned, it's possible for someone to access or intercept a piece of e-mail as it lies in storage or while it's in transit. Since most e-mail messages are in plaintext, anyone who can access the message can also change the contents of the messagewithout the user knowing that the message had been altered . In this case, the integrity of the message has been compromised.

A more complex security problem is one of authenticity. Currently, there is no method built into e-mail that would let a recipient of a message verify that the sender is actually who he or she claims to be. Combined with the integrity issue, this lack of verification means that e-mail is an untrustworthy system.

A related security problem is a lack of nonrepudiation, in which a sender can deny that he or she ever sent a message. Additionally, there is no way to disprove a sender's claim that his or her message has been tampered with so that its meaning has been changed.

E-Mailer ID

Currently, several schemes seek to address e-mail's security woes, specifically those of privacy, integrity, authentication, and nonrepudiation. These solutions are all rooted in public key cryptography technology. (To learn more about public key technology, read "Public Key Cryptography," following this tutorial.)

If you're not familiar with public key technology, I'll give you a brief overview. In a public key system, a user is assigned a pair of keys that work together. One of the keys is the user's private key, which only the user can possess. The other key is his or her public key, which is freely distributed to the public. Both the keys can encode and decode data. However, what one encodes, only the other can decode. They will not work with any other key.

Here's how the system secures e-mail. When User A wants to send a confidential e-mail message to User B, User A encrypts the e-mail using User B's public key. The only key that can decode the message is User B's private key, which only User B possesses. Consequently, no one else can read the message. This takes care of the privacy and integrity problems.

The system also addresses the issues of authenticity and nonrepudiation. On a basic level, if User A wants to send an e-mail message and assure recipients that the message actually came from him or her, User A can encrypt the message using his or her private key. To read the message, recipients use User A's public key to decode it. Since only User A's public key will decode the message, recipients know that the only key that could encode the message was User A's private key. And, since User A is the only person in possession of that private key, the message must have come from User A.

However, for this system to work, and this is a critical point, users must be able to trust that a user's key is valid. To provide this verification, a trusted entity, generically known as a Certificate Authority (CA), assigns each user a unique digital certificate that assures that a certain public key belongs to a certain user.

The Solutions

As mentioned, several schemes for securing e-mail have been developed. All of them are based on public key encryption. However, they differ in the way they implement this technology; specifically, the biggest difference among the schemes is in how they handle key certification.

The hardest aspect of securing e-mail is establishing a valid CA that everyone has access to. Currently, there is no central CA in existence that the general public can use to verify public keys. And, without a governing CA, to whom can a user turn to verify that a particular public key belongs to a particular user? Some organizations that use public key systems internally act as their own CA for their users. However, these organizations can't manage certificates for the public in general.

Privacy Enhanced Mail (PEM), the IETF standard that addresses secure e-mail, proposes using a hierarchy of trusted bodies to reassure users of the validity of a particular e-mail message. At the top level sits the Internet Policy Registration Authority (IPRA), which would be the governing certificate trusted by all. The IPRA would sign certificates for a second layer of trusted bodies called Policy Certification Authorities (PCAs). These in turn would authorize certificates for another layer of bodies called Certificate Authorities (CAs). These CAs would be responsible for authorizing certificates for the public at large.

When a user receives an e-mail message under the PEM model, the e-mail header lists the certificate of the body that authorized the sender's certificate. That way, recipients know that the e-mailer's identity had been verified by the body.

Currently, you can find several products on the market or the Internet that follow the PEM model, including ones from RSA Data Security, Trusted Information Systems, and Michigan State University (called RIPEM). However, because the certificate hierarchy suggested by PEM (the IPRA model) hasn't been established, some of these products use proprietary CA schemes.

Pretty Good Privacy (PGP), a secure e-mail program, offers an alternative take on the CA. Instead of using a hierarchy of authorities, PGP builds something called a web of trust. According to this concept, each user keeps a list of certificates from other PGP users they trust. Each of these certificates contains a list of other trusted certificates. So, when a user receives an e-mail message from someone they don't know, the user can check the chain of certificates listed with the e-mail to see if he or she recognizes a trusted certificate. Or, the user can try to trace a link between certificates listed in the e-mail back to the handful of certificates that the user trusts.

A third secure e-mail scheme is an extension of the PEM standard called MOSS, or MIME Object Security Services, which is still in the debate and development stage within Internet circles. MOSS allows users to secure multimedia messages, using the same principles as PEM. One difference, however, is that MOSS doesn't require certificates to verify keys, although it does support the certificate structure proposed by PEM. Instead, users must verify keys in any way they can.

A fourth scheme is S/MIME, or Secure MIME, which was developed by RSA Data Security. This specification also provides a way to secure e-mail, including MIME messages. Naturally, S/MIME uses RSA's public key cryptography standards to handle encryption and key pairs. S/MIME uses X.509-based certificates in its model, but it actually leaves the whole matter of setting up a certificate structure to the implementing organization.

An Open Door

So far, the security problems I've discussed all stem from the inherent technological limitations of e-mail. However, e-mail also poses a few other security problems. The first problem is one everyone is familiar with: viruses. In the past, viruses were usually spread by floppy disks. E-mail makes the voyage much simpler for viruses. Now, viruses can ride along with an e-mail message as an attachmentright to your desktop. Usually, the virus is disguised as a harmless file. When a user opens the attachment, the virus can spread to the host computer. To combat this problem, you can find several virus scanners on the market that scan incoming e-mail for viruses.

Finally, with the emergence of e-mail comes the birth of spam, otherwise known as junk e-mail. Like junk mail, junk e-mail is a form of advertising in which a person or company sends out a bulk mailing (in this case, via e-mail) to hundreds and thousands of recipients. The contents of the message usually consist of an advertisement peddling some type of service or product, or general ranting and raving.

For businesses, spam is problematic because of the costs it inflicts. On a systems level, spam is an infringement on network resources across the boardincluding processing power, storage space, network bandwidth, and dial-up and leased lines to the Internet. On an employee level, workers face sorting through junk e-mail to get to their business e-mail. Because of these costs, spam can be seen as a security threat to businesses.

Currently, ISPs are trying to combat spam by filtering out known junk e-mail broadcasts from its systems. Aside from that measure, there are a couple of bills being proposed in the U.S. Congress that seek to limit the actions of spammers. The only solutions businesses have are to install their own filters on their e-mail systems and to educate users about the hazards of handing out their e-mail addresses too freely on the Web and to other parties.

The Message Is Clear

By itself, standard Internet e-mail is a security liability simply because of the fact that it's sent "in the clear," and is easily forged. With the solutions I've mentioned, you can see that work is underway to make e-mail a more reliable, trustworthy tool for business communication (see "Resources" for Web sites that deal with e-mail security issues). Additionally, there are products available that businesses can implement internally for their employees . However, such a solution doesn't help when trying to secure e-mail being exchanged with other businesses that don't have a secure e-mail system in place.

The real solution will arrive once someone is able to develop a CA structure that everyone, businesses and the public alike, acknowledges. Without this structure, the privacy, integrity, and authenticity of e-mail will always be an issue.

Resources

Here's a list of Web sites you can browse for more information on solutions for shoring up e-mail's security holes.

Privacy Enhanced Mail (PEM)

kekec.e5.ijs.si/security/pem.html
retriever.cs.umbc.edu/~woodcock/cmsc482/proj1/pem.html
ds.internic.net/rfc/rfc1421.txt to 1424.txt (RFCs 1421-1424)

Pretty Good Privacy (PGP)

www.pgp.net

Secure MIME (S/MIME)

www.rsa.com

MIME Object Security Services (MOSS)

ds.internic.net/rfc/rfc1848.txt (RFC 1848)

Virus and Virus Hoax Alerts

www.antivirus.com
www.drsolomon.com
www. mcafee .com
www. symantec .com

Anti-Spam Sites

www.cauce.org (Coalition Against Unsolicited Commercial E-mail)
www.ftech.net/~monark/spam/index.hts
www.mcs.com/~jcr/junkemail.html

This tutorial, number 114, by Lee Chae, was originally published in the January 15, 1998 issue of Network Magazine.