Software

Protect the Network: Make e-mail encryption a priority before disaster strikes

E-mail encryption products


Michelle Nance

You don't have to be a security expert to know that sending important information via unprotected e-mail is risky. From the moment you click Send, your message travels over unsecured networks where anyone with a nifty little tool called a packet sniffer can search it for specific words or names. Even the federal government has its own official sniffer, which it uses to track the mail of suspected criminals. There's no reason to think your correspondence will escape similar scrutiny. To make sure your e-mail isn't fair game for thieves, you need to encrypt it. Otherwise, your business secrets could be thrown to the dogs.

One increasingly popular approach to securing correspondence is the virtual private network (VPN). A VPN essentially secures the pipes your messages travel on so that no one can sit on the lines and pick out messages as they pass. Using a VPN does help make your correspondence more secure. But when those e-mails get to the recipient, anyone with access to that computer can read the messages, even though the delivery lines were secured. Also, don't forget that there's probably a system administrator or two who can read anything sent across the network. Not to knock the trustworthiness of sys admins, but some may not be able to resist sneaking a peek at a message titled "List of employee salaries" or "Important details of our upcoming merger with AOL."

If you want to make sure that your e-mail communications are truly secure, a VPN isn't enough. You want your employees' e-mail encrypted from the time it leaves their desktops until it arrives on the intended computer.

Check out CNET Enterprise Business
This article has been published as a courtesy of the CNET’s Enterprise Business section, where you can explore IT business solutions on various topics, including ASPs, Linux, groupware, information systems infrastructure, supply chain management, and much more.

Encryption 101
Encryption comes in two basic flavors: symmetric (also called single key) and asymmetric (or public key). With symmetric encryption, both correspondents use the same algorithm key to encrypt and decrypt a message. But the sender of the message has to get the key to the receiver—and that means there's a possibility someone could intercept the key.

Asymmetric encryption is more secure and more commonly used because it has two different keys. Say that Tom in accounting needs to send the annual financials to Sara, the tax attorney. Sara has two keys: a public key, which she gives to anyone sending her e-mail, and a private key, which only she knows and which is required to unlock messages encrypted with her public key. Tom encrypts the financials with Sara's public key before sending them, and Sara decrypts them with her private key. Anyone else trying to decode the message would get nothing but gibberish.

A look at e-mail encryption products
AT&T SecretAgent
Disappearing Email
InvisiMail Enterprise Edition
PGP Corporate Desktop
ShyFile
VeriSign Digital ID


One additional security feature often used with encryption is signing. Signing your message guarantees that it came from you by verifying that the public key you're distributing is yours. Using your private key, you sign a message that the recipient unlocks with your public key. If your public key doesn't unlock the message, the recipient knows the message wasn't signed with your real private key.

You can encrypt e-mail without signing it, and you can sign e-mail without encrypting it, but for maximum security you should do both.

There are two widely used encryption standards, Pretty Good Privacy (PGP) and Secure/Multipurpose Internet Mail Extensions (S/MIME), in addition to several lesser-known ones such as Privacy Enhanced Mail (PEM) and MIME Object Security Services (MOSS). The vast majority of encryption products you'll find are based on either PGP or S/MIME.

PGP has its own standalone products that can be used via a plug-in with many e-mail programs. PGP is a proprietary protocol owned by Network Associates; PGP is a subsidiary company. In 1997, the Internet Engineering Task Force (IETF) created a working group to define a new standard based on PGP called OpenPGP. There are now several companies developing encryption programs based on the OpenPGP standard. S/MIME-based encryption is built in to many popular e-mail programs, including Microsoft Outlook and Lotus Notes. Both standards essentially accomplish the same thing: They use public key encryption to protect data from unauthorized users. They also both have features that verify the sender of encrypted e-mail.

Unfortunately, the two standards use different cryptography algorithms and techniques, making them incompatible with each other. You can't use an S/MIME program to decrypt a PGP-encrypted message, and vice versa.

One major difference in the past has been how the two protocols authenticate users and their keys so that they can sign messages. S/MIME uses a hierarchical certificate system to verify keys: A trusted third-party authority such as VeriSign issues a certificate guaranteeing that the public key belongs to the person requesting the certificate. Since most people trust VeriSign as an authority, they'll trust a certificate issued by VeriSign that says that public key A belongs to person X. If your keys aren't certified by a trusted third party, their validity may be questioned.

PGP uses a more distributed system. Instead of getting a certificate from a third party, it relies on individual users to validate each others' identities by checking a piece of code in their public keys called the fingerprint. Within a corporation, some trusted authority, such as the CTO, would act as the validating authority for the entire company (called an introducer in PGP parlance), signing users' public keys. The CTO will, one assumes, do this for free, so there's no certificate fee involved.

The encryption used by both standards is "fundamentally equally secure," said E. John Sebes, a security consultant with 15 years in the business. And, of course, neither standard is worth anything if the people you correspond with don't have compatible decryption software installed. Both standards claim large markets. S/MIME tends to be integrated a bit better into applications, making it easier for the end user to deal with. However, many security consultants will tell you that S/MIME is harder for the administrator to configure and manipulate than PGP. In the past, there have been difficulties getting various S/MIME e-mail applications to communicate seamlessly with each other.

Deciding which standard to go with isn't easy. Both sides have ardent supporters who are happy to make the case for their standard; the PGP vs. S/MIME debate often sounds a lot like the Mac vs. PC wars. Your best bet is to do a lot of research. Think about the server and e-mail clients your company has installed already. Consider how much knowledge your IT team already has about S/MIME and PGP. Then, quickly survey the business partners your company corresponds with most frequently. What standard are they using?

Two good starting points for a side-by-side comparison are the eMailman site and the Internet Mail Consortium page on encryption protocols. Also, give some thought to bringing in a security consultant for advice on what would work best with your company's setup.

Set up the server
Surprisingly enough, you don't need to install much software on your server to encrypt e-mail. The actual encryption takes place on the user's desktop; the software that encodes an e-mail message lives on the individual's computer. One caveat: If you use Lotus Notes, you must install the encryption software on the server to configure it, and Notes will push the software out to users.

Because the manual tracking of keys and certificates can become unmanageable, you may want to put a key server on your server. A key server is a database that stores and manages your employees' keys and digital certificates. You will most likely want a key server if you plan to encrypt the e-mail of more than 50 or 60 employees. With a key server, employees can generate their own keys.

You can distribute a list of the public keys and certificates to all employees and leave it up to them to manage the public keys of their outside correspondents, or you can use an outside key server such as the MIT PGP Public Key Server or VeriSign's Digital ID Repository.

If you use PGP, you'll install PGP Key Server to manage your user keys. You'll need about 15 to 30 MB of disk space for the software, plus another 10 to 500 MB for the certificate database, depending on how many keys you'll be storing.

If you run Microsoft Exchange and want to use its built-in key management features, you won't need to install anything new, but you will have to configure the Exchange Key Management Server along with the accompanying Certificate Server.

Make sure you set up the Certificate Server; the Key Management Server generates certificates that work only with the Outlook e-mail client. Certificate Server creates certificates that work with all the other S/MIME-compliant e-mail programs.

Potential problems
Keeping e-mail encryption glitch-free takes more than just putting tools in place. Here are a couple of potential pitfalls to keep in mind.
  • 128-bit encryption: If you have branch offices or business partners overseas, remember that 128-bit encryption—the strong encryption favored by most apps—cannot be exported legally outside the United States. Solution: You may need to use weaker 64-bit encryption, which has been publicly cracked.
  • Windows swap file: If you use a Windows-based system, beware of your swap file. Windows stores many of your passwords. If your encryption pass-phrase is in your swap file, anyone who accesses your computer can steal that code and decrypt your mail. Solution: Just say no when an app offers to remember your password. Use a password-protected screensaver to lock your desktop when you're away from your desk. And shut down your computer when you leave; rebooting it will clear the swap file.


Deploy on the desktop
The main work of getting encryption going in your company is installing the necessary software on the users' desktops and getting them to use it.

If you go with an S/MIME setup, chances are you won't have to install any new software. Outlook 98 and above and Netscape Messenger 4.5 and above come with encryption features built in. If you use an older version of Outlook or Eudora, cc:Mail, or Claris Emailer, you'll need an S/MIME-enabling plug-in.

If you use PGP, you must install PGP Corporate Desktop. But first, use the PGPAdmin tool that comes with the package. PGPAdmin lets you configure all the settings you want your employees to use and then creates an installer that you use to load the software on individual computers.

Once the software is up and running, each employee will need a unique digital ID. If you use S/MIME, you can either issue an ID yourself, if you are running your own key server and certificate authority, or you can have employees get them from an authority such as VeriSign.

With Outlook, select Tools | Options, click the Security tab, and select Get A Digital ID. Go to Microsoft's Assistance Center, select a certificate authority, and fill out a few forms. Your ID will be delivered to you by e-mail within an hour or so. Click a few more buttons, and your certificate and keys are installed. You can then use the same Tools | Options menu to customize settings.

If you use PGP, you'll generate your key pair as part of the installation process. Next time you start the e-mail application, there will be a PGP item on your menu bar, where you can customize any additional settings.

Once your IDs and keys are generated and installed, you're ready to send mail. But first, you must determine how many people routinely handle sensitive information—you don't need to encrypt everyone's e-mail. Then, those e-mail users will need training. Remember that a security solution such as this is only as good as the user is competent in using it.

Where to decrypt
One common concern many administrators have is whether to decrypt all mail at the firewall in order to scan for viruses. Although it is technically possible to do so, most security experts say the risk of exposing sensitive data to hackers is far greater than the risk of contracting a virus.
Says Douglas Hurd, senior product manager for PGP Desktop, in order to decrypt mail at the firewall, "you have to give something away at that gateway—a key to all the mail coming in and out. That security risk is a magnitude greater than the risk of a virus coming in."
In addition, the e-mail is now unencrypted on your internal mail network. But if you decide your employees' desktop virus scanners aren't sufficient, you can decrypt mail (or better yet, just attachments) at the firewall using a sendmail box, sending the attachments through your virus scanner, and then forwarding them along to the recipient.

Michelle Nance is a freelance technical writer. Prior to writing for CNET Enterprise, she spent more than nine years in technology publishing, covering everything from software to Internet trends and start-up development.

Editor's Picks