May 2001

E-MAIL SECURITY

SIGNED, SEALED & DELIVERED

A cadre of new e-mail security applications aims to solve the problems that have long plagued PGP and S/MIME.

BY FRED AVOLIO & DAVID PISCITELLO

For more than 10 years, secure e-mail has been a standard topic of discussion in the corporate IT and computer security community. Subscribe to any IT, networking or security magazine, and you're bound to read an article on the subject every few issues. Browse through the brochure of any infosecurity conference, and you'll almost always come across at least one session or workshop on the topic. Surf the Web sites of the industry's prominent vendors, and you're sure to come across a white paper or product related to this ever-present consumer and corporate need.

Despite this preponderance of information, advice and technology solutions, only a fraction of corporate and consumer 'Netizens actually use some type of e-mail security. Problems with protocol and product interoperability, scalability and usability have left many users wondering if protecting their e-mail is really worth the headache. That's the bad news.

The good news is that, in the last 10 years, an increasing variety of e-mail technologies has emerged, making secure, portable and user-friendly electronic mail a practical reality for today's extended enterprise.

What's the Problem?

Three primary challenges inhibit the use of secure e-mail.

1. Lack of perceived need. Most e-mail users don't believe their electronic communications are of interest to anyone but themselves. Well, truth be told, most messages aren't. In a corporate environment, however, everyone from the mailroom clerk all the way up to the CEO routinely send sensitive, proprietary information across the 'Net in plaintext.

Most corporate end users are blissfully unaware of the security risks inherent in plaintext e-mail, which are susceptible to four types of attacks: eavesdropping, forgery, denial of origination and replay. Specifically, unintended recipients can read plaintext e-mail as it's sent from one user to another, as it sits on e-mail relay hosts and gateways, when it arrives at the final "post office" system and when it's stored locally on an e-mail client. As with regular snail mail, the sender of an e-mail is easily forged or spoofed. Just as snail mail can be read by anyone handling the mail between the sender and recipient, plaintext e-mail can be sniffed and read as it's transmitted across a network segment. And, a legitimate message can be captured and re-sent, or read again and again. Clearly, plaintext e-mail is vulnerable in more ways than it's secure--whether or not end users recognize it.

2. Lack of interoperable products. This is more perception than reality. The Internet standards for secure e-mail are PGP/MIME and S/MIME. S/MIME--Secure Multipurpose Internet Mail Extension--is the standard that allows users to include documents, programs, pictures and, yes, viruses as e-mail attachments.

Although PGP and S/MIME are competing, incompatible standards, many popular e-mail clients incorporate interoperable implementations of each technology. Moreover, many widely accredited and standardized cryptographic algorithms are available for use in secure e-mail products. Combined with public and government acceptance of digital certificates, this provides the basis for the development of the innovative secure e-mail solutions discussed later in this article.

3. Ease of use. The problem isn't that it's intrinsically difficult to send and receive encrypted and digitally signed e-mail. Rather, the problem involves practical, everyday use of these technologies, such as:

  • The e-mail user has an incorrect combination of security software and e-mail client. Only a few e-mail client software developers also provide the secure e-mail plug-in, add-on or reader.
  • The e-mail sender doesn't have a digital certificate; or, if he does, he doesn't really know its significance or how to use it.
  • The e-mail recipient doesn't have the digital certificate of the sender (again, a problem of distribution and accessibility).
  • Organizations struggle with key-creation, -escrow, -revocation and -recovery requirements, problems that have plagued in-house PKI implementations for years.

Requirements in the Corporate Environment

Before a technology or product can begin to address the above problems, it must lay a foundation for e-mail message security (see "E-mail Security Basics," below). The e-mail must be secure on every router, server and system it traverses during transmission.

Further, if the solution is linked to an outside service--such as those discussed later in the article--the third party's security policy for storage, backup, communications and access must be as stringent as those of the corporate enterprise. When it comes to e-mail security, the old adage is true: A chain is only as strong as its weakest link.

These basics aside, any secure e-mail technology must provide:

1. Ubiquity and interoperability. Anyone must be able to send an encrypted, digitally signed message, which in turn can be verified and decrypted by anyone else (without hassle!).

2. Universal support and transparency. The solution must have a minimal impact on the (extended) enterprise's e-mail infrastructure, including gateway mail servers, desktops and wireless clients. Nearly every corporate user relies on e-mail as a fundamental business tool. The goal is to make secure e-mail similarly de rigueur.

3. Practicality. The secure e-mail solution must be easy to use and support. Further, since it will be used by all employees and partners, it must be very easy to install.

In addition to the older standbys, PGP and S/MIME, a number of e-mail security technologies have emerged to compete for corporate and consumer mindshare. Unlike S/MIME and PGP, which are tightly integrated into the existing corporate e-mail infrastructure, solutions such as ZixMail, Ensuredmail, HushMail and Disappearing Inc. rely on add-on or Web-based software solutions. Let's compare and contrast each of these solutions in light of the above requirements.

E-MAIL SECURITY BASICS

  • Confidentiality: A guarantee to the sender that only the intended recipient(s) can read the message.
  • Integrity: A guarantee to the recipient that the message hasn't been altered in any way during transmission.
  • Authentication: A guarantee to the recipient that the purported sender of the message is the actual sender.
  • Nonrepudiation: The other side of the "authentication" coin, guaranteeing that the sender cannot plausibly deny that he created or sent the message to the recipient.

S/MIME

Current versions of both Microsoft Outlook and Netscape Messenger are configured to use S/MIME. While using S/MIME for encryption and digital signatures is a familiar process for some, here's a brief overview for the uninitiated.

To use the protocol, the user must obtain a digital certificate: a piece of unique digital data that provides message confidentiality, integrity and authentication with nonrepudiation. (VeriSign provides details for this process at http://digitalid.verisign.com/client/help/send_receive.htm.)

Both Outlook and Messenger provide buttons for obtaining a digital certificate. The user must walk through a few steps to obtain a certificate (from an outside provider or vendor) and store his private key on his computer, protected by a pass-phrase. Unfortunately, these steps can be confusing to the average Joe. On the other hand, once the setup process is finished, sending digitally signed e-mail is easy as pie. The user simply creates an e-mail, clicks on the "Security" button and enters his passphrase.

If the user wants to encrypt a message, he must first obtain the digital certificate of the intended message recipient. The software notifies the user of this, and gives him the option of retrieving it from one of the client's preconfigured certificate servers (or, one of the user's choosing). The user has the option of storing certificates locally to circumvent the directory look up later. Alternatively, when sending a signed message using Outlook or Messenger, the user can also send his certificate with the message.

VERDICT: Since solutions exist for most e-mail clients, S/MIME solutions get high marks for ubiquity and interoperability. However, S/MIME gets only an average grade for impact and usability. Until users are routinely issued certificates, using S/MIME will be a confusing process for many. Moreover, S/MIME solutions aren't one-stop shopping; enterprises must administer their own PKI, or outsource digital certificates to a third-party service such as Valicert (www.valicert.com), Baltimore Technologies (www.baltimore.com) or VeriSign (www.verisign.com).

PGP

Despite its modest name, PGP (Pretty Good Privacy, www.pgp.com) provides "pretty excellent security." PGP has been around for more than 10 years, and today works on all desktop OSes running Messenger, Outlook, Eudora and Notes e-mail clients. It's currently licensed as a commercial product by Network Associates Inc. (www.nai.com) and is available as OpenPGP freeware (www.pgpi.org).

PGP is easy to install. At installation time, the software wizard walks you through the process of generating a public/private key pair for encryption and signing. Users that can install any PC software will be able to install PGP. The enterprise version allows the security or IT staff to create specialized PGP kits to enforce security policies related to encryption-for example, requiring a corporate key to be used to recover encrypted data. As with S/MIME, users can configure the software to look up unknown users on a certificate server (i.e., those for whom the user doesn't already have a public certificate).

PGP adds a button to desktop clients (including Outlook) that enables message encryption and digital signing. Signatures can be appended when the e-mail is either queued or actually transmitted.


We tested the PGP plug-in on Eudora version 4.3. Once installed, the PGP plug-in adds buttons for launching the PGP-Keys certificate administration utility, encrypting messages, signing messages, and decrypting and verifying signed messages. To send mail, the user simply composes
a message or reply in Eudora's standard composition/reply window. To encrypt and sign messages, he simply depresses the PGP Encrypt and PGP Sign buttons. A pop-up window informs him of any addresses it can't locate in the local database and, like S/MIME, gives him the option of searching on known (or designated) certificate servers on the intranet or Internet (a popular server is MIT's PGP public-key server--http://pgp.mit.edu). Once PGP has certificates for all recipients, it digitally signs the e-mail on behalf of the user (after the user supplies a passphrase), then encrypts and sends the e-mail.

VERDICT: PGP gets medium to high marks for ubiquity. For Messenger, Outlook, Eudora (Windows and Macintosh versions) and Notes, integration is easy, though not as instantaneous as some Web-based programs. PGP can be used with other e-mail clients, but a lack of integration makes it more difficult to use. PGP interacts well across all PGP products, so it gets a medium mark for ease of use. When it works, it works well. But when it fails, troubleshooting can be confusing.


ZixMail

According to the company's Web site, ZixMail (www.zixmail.com) is a "secure document delivery, private e-mail and message tracking service that enables Internet users worldwide to easily send encrypted and digitally signed communications using their existing e-mail systems and addresses, regardless of whether their recipients have encryption keys or decryption software." In other words, ZixMail is an auxiliary program, and as such is e-mail client and transport independent. The program is invoked separately when the user wants to create and send encrypted and signed e-mail messages.

Like S/MIME and PGP, ZixMail uses public-key technology for e-mail security. The latest version of ZixMail works inside Outlook, but can be used as an add-on to other e-mail clients. By default, ZixMail uses the ZixIt certificate store and server system. Messages can be signed and encrypted by or for anyone with a ZixIt digital certificate.

ZixMail is incredibly easy to install and use, and is easily managed by anyone, without documentation. At installation time, ZixMail generates a public/private key pair and then creates a digital certificate, binding the user's e-mail address with the key pair it generated. The private key is symmetrically encrypted and stored on the local disk using the keys generated from the user-supplied passphrase. The unsigned digital certificate is electronically submitted to the ZixIt key server, where it's encrypted using the preloaded public key of the ZixIt Worldwide Signature Server (WSS).

To send secured e-mail (signed, encrypted or both), the user launches the ZixMail program rather than his customary e-mail client. When encrypted e-mail is sent, the program connects to the ZixIt key store to retrieve the public-key information associated with the recipients. The ZixMail system displays these steps so the user knows what's happening when sending e-mail. ZixMail also offers a "Certified Receipt" feature that certifies when a message was received and opened.

If the intended recipient of the message also uses ZixMail, he'll receive MIME-format e-mail with a ZixMail attachment. Opening the attachment executes the Zix-Mail program. ZixMail asks the recipient for his passphrase and, if correct, decrypts his private key. The private key is then applied to the message to retrieve the secret encryption (session) key, which, in turn, decrypts the ciphertext. The plaintext message is never stored in the user's MUA directory. The only time the message appears in the clear is in the ZixMail application window.

If the recipient doesn't use ZixMail, the sender's client program encrypts it and routes it to the ZixIt mail gateway. The gateway, in turn, sends a plaintext notification of the message to the recipient along with a URL. Clicking on the URL gives the recipient an SSL connection to the gateway, where she can register. Once registered, she can read the decrypted message in the browser window.

VERDICT: Through the ZixMail system, users can easily send encrypted e-mail to anyone, satisfying the important requirement of ubiquity. On the down side, there's no way to digitally sign e-mail without encrypting a message. Also, reading through many ZixMail messages can get tedious, since the program requires the user to type in his passphrase for each one. Finally, there's no way to save the e-mail in decrypted form after reading it (although ZixMail promises this will be added in a future release).


Ensuredmail

Ensuredmail (www.ensuredmail.com) provides free privacy software for all versions of Outlook, Outlook Express, AOL mail and many Web-mail services. It's available for all Windows OSes. Ensuredmail provides automatic read-receipts and adds an anti-forwarding feature, which prevents the recipient from forwarding a message the sender intended only for her.

In Outlook, the user encrypts a message and attachment by selecting the "Encrypt and Send My E-mail" button from the toolbar, presented with each new or reply-to message. The button invokes a pop-up window in which the user enters a password (minimum six characters) for the to-be-encrypted message. Ensuredmail uses symmetric (shared-secret) encryption, in which no digital certificates are needed. Users of the program have two ways to provide a message recipient with the shared secret: offline, or by sending a "password clue" as part of the message. The password clue is displayed in the password window that pops up when the recipient attempts to decrypt a message.

Ensuredmail CEO Fred West explains that the password clue is a piece of information that the sender optionally provides to assist the recipient in determining the actual password. For example, a bank might use a password clue "your debit card account number plus your secret PIN." The recipient has three chances to enter the correct password before the program shuts down. While the software can be repeatedly invoked, a brute-force password crack under such conditions would be painfully slow.

Ensuredmail is free, supported through banner advertisements in the pop-up password windows and trailer ads in e-mail message bodies. Paid versions of the software, sans advertisements, are also available. Ensuredmail Pro, due to be released as Information Security goes to press, will support longer keys. It will also provide organizations with administrative controls over local file encryption and the ability to escrow passwords for future access to encrypted files.

Local file encryption operates through a similar user interface, using Gzip for compression prior to encryption. Again, a password is associated with each file, and only files (not folders) can be encrypted. Users can re-use the same password for all local file encryption.

VERDICT: Ensuredmail gets high marks for usability, passing the "my grandma could use it" criteria. It also gets high marks for impact; users can stick with their familiar e-mail client, and Ensuredmail appears committed to extending support to additional clients, including Eudora and Notes. But for now, it gets a medium grade on the ubiquity/interoperability scale.

Slightly detracting from usability is a limitation in handling reply-to e-mail messages: The message recipient must cut and paste from the pop-up decrypt window if she wants to reply and comment to the sender's message. On the other hand, Ensuredmail tests the user's system to determine if it can support the software prior to download, something missing from the other products in this review. It's a simple installation, and the pop-up window for password submission--while required for each message--is a minor inconvenience.

Hush Communications (HushMail)

Hush Communications (www.hush.com) offers products for both secure mail and PKI. HushMail is a free Web-based e-mail service that provides encrypted e-mail and PKI administration, with online storage of mail for your-account@hushmail.com. The user and any chosen recipients must have HushMail accounts to exchange encrypted messages and attachments. However, HushMail users can digitally sign messages to any recipient, regardless if that person has a HushMail account.

As part of enrollment, HushMail generates a public/private key pair for each user. The private key is encrypted with a pass-phrase and, along with the public key, stored on the HushMail server.

HushMail offers several types of secure e-mail account services, including a free basic account shown here.


When a HushMail user wishes to send
a private message, a Java applet on the user's PC will request his password. The password is securely hashed, and part of the hash is sent to the HushMail server to validate the user. In other words, Hush never sees the entire passphrase, so only the sender can decrypt messages encrypted with his public key. If the user is authenticated, the HushMail server sends the user's plaintext public key and encrypted private key to the Java applet at the user's machine. The applet symmetrically decrypts the private key and uses it for digital signatures. E-mail messages and attachments are symmetrically encrypted using a unique session key for each message. The session key is encrypted using a HushMail recipient's public key, and included in the message before transmission.

When a recipient reads e-mail, a Java applet decrypts the encrypted message (and attachments). If the message is digitally signed, the Java applet downloads the sender's public key and uses it to verify the sender. Non-HushMail users can download a Java applet from the HushMail Web site to verify a Hush-signed message. The URL to verify a digital signature is appended to every signed message.

Hush also offers a Private Label service for enterprises wanting to outsource secure e-mail. Private Label provides essentially the same secure mail and user service, except to a "community" of users rather than a single user. A company that signs up for this service typically hosts a customized home page for secure mail; behind the scenes, users access Hush's servers for the secure mail Java applets. This arrangement is an attractive option for an organization that needs secure e-mail, but doesn't want the administrative responsibility of PKI and mail service.

VERDICT: HushMail is an elegantly conceived secure e-mail solution. The user interface is simple and intuitive. Web-mail services such as Hush are usually attractive because they're "portable"--that is, they permit access from any system that hosts a browser. The limitation, of course, is that users can only access e-mail when online. At the same time, most organizations mandate a standard desktop client, such as Outlook or Notes, and are reluctant to abandon it for a Web-based solution. For some organizations, however, the ease of use and ubiquity of Private Label will solve a lot of the headaches involved in maintaining an in-house PKI and e-mail security infrastructure.

On the downside, Hush's products don't currently support return receipt and key recovery, though the company says both features are under development. Hush also says it's working on integrating the Java applet into popular e-mail clients.

Disappearing Inc.

Disappearing Inc. (www.disappearinginc.com) offers e-mail message and attachment management through policy dictated by an e-mail sender. Disappearing's solution isn't secure in the traditional sense; the analogy Disappearing Inc. offers for its service is a paper shredder. Just as you might shred a paper copy of a sensitive memo--and mark all copies with a policy statement to that effect--local and delivered copies of Disappearing E-mail are rendered unreadable after a user-defined lifetime.

An instinctive reaction to "e-shredding" is that it facilitates coverups. Perhaps, but there are many positive applications, too. Consider the value to an organization that wishes to impose a specific lifetime--say, 45 days--on a promotional, reduced-price offering of its product. Continuing sales at this price beyond the 45th day is undesirable. With e-shredding technology and a centrally administered e-document handling policy, an organization would dramatically reduce the chances that sales staff would offer the product at the discounted price after the promotion had ended.

Disappearing E-mail doesn't seek to solve the problems associated with recipients who create copies in violation of an organization's policy. This, explains Disappearing's CTO Macklen Marvit, is part and parcel of the trust relationship between employer and employees. "The analog to what we offer is that of a phone conversation, and the implicit understanding by both parties that it won't be recorded," says Marvit. "Yes, there are 'Linda Tripps' in the world, but Disappearing Inc. is in the business of risk mitigation, not risk elimination."

Currently available for Outlook 98 and 2000, Disappearing Inc.'s software installs automatically and requires neither configuration nor passphrases. Disappearing Inc. adds a toolbar to both the "New" and "Reply-to" windows of the Outlook e-mail client. When the user selects the "Send Disappearing E-mail" button instead of the conventional "Send," the message is encrypted with a unique 128-bit key obtained from the Disappearing Inc. Access Server. E-mail messages are encrypted locally and during transmission to the recipient, and remain encrypted until the recipient reads them.

Users control the lifetime of the e-mail message by choosing a value (ranging from "under 30 minutes" to "90 days") from an "Expires in ____" pulldown in the toolbar (the lifetime actually applies to the key used to create the message). When the lifetime expires, Disappearing destroys the one and only copy of the key used to encrypt the original message, rendering all encrypted copies permanently unreadable. While Disappearing E-mail messages convey expiry information, attachments do not. Once separated from the e-mail message, it's impossible to determine when the attachment will be rendered unreadable.

Disappearing E-mail is delivered as an HTML attachment to non-users of the software. The attachment in most I-frame-capable e-mail clients automatically contacts Disappearing's Access Server, where the message is decrypted and presented in the recipient's browser window. To read attachments, users must download a free reader. If they wish to include the original message in a reply, they must cut and paste it.

VERDICT: In the broader context of secure e-mail, the e-shredding feature complements secure e-mail solutions that offer message confidentiality, integrity and nonrepudiation. Interoperability and ubiquity are high, owing to the fallback reliance on browser-based technology. Disappearing Inc. also gets good grades for low impact on the organization and ease of use.

No More Excuses

While e-mail security solutions have been available for many years, the non-technical Internet community has been very slow to adopt them. It's not security or availability that's holding things back. And it's not the technology. What's holding e-mail security back is the lack of usability and ubiquity, and its adverse impact on a deeply entrenched installed base.

Generally speaking, secure e-mail is easier today than even a year ago--and more convenient, too. The choices are much broader today than ever. At the consumer level, there's really little reason to put off using secure e-mail as a convenient substitute for certified, registered or courier-delivered snail mail. At the enterprise level, there may not be a single solution that satisfies everyone's needs, but there's certainly a combination of technology solutions that gets organizations closer to secure e-mail than they are today.

FRED AVOLIO (fred@avolio.com) is president and founder of Avolio Consulting Inc., a Maryland-based computer and network security consulting corporation.

DAVID PISCITELLO (dave@corecom.com) is president and co-founder of Core Competence Inc., an internetworking, broadband, security and network management consulting firm.