|
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.
|
|