W H I T E PA P E R
Secure Email Inside the Corporate Network:
Providing Encryption at the Internal Desktop
Table of Contents
Introduction
2
2
Encryption at the Internal Desktop
Current Techniques for Desktop Encryption
3
Compression and Encrypted Attachments
3
Using an S/MIME-based PKI for Desktop Email Security
4
Using PGP on the Desktop
4
Identity-based Encryption
5
The Ideal Solution
5
Ideal User Experience of a Typical Sender
5
Ideal User Experience of Two Typical Recipients
6
Ideal User Experience of a Typical Administrator
6
Tumbleweed Plug-in Coming in 2006
6
7
The Tumbleweed Plug-in Approach
Conclusion
01
Secu re Emai l I nside the C o rpo rate Netwo rk
Copyright©2006 Tumbleweed Communications Corp. All rights reserved.
11
Introduction
Each organization has its own unique security needs when it comes to sending and receiving
sensitive information via email—from complying with government privacy regulations in
Healthcare (HIPAA) and Financial Services (GLBA) to enforcing corporate policies (SOX) and
protecting intellectual property. Although individual implementations vary, current email security
requirements typically fall into two categories: inbound email protection and outbound email
security.
v Inbound email protection. Protecting the inbound email stream from viruses, spam, dark
traffic, and other malicious messages is critical for network efficiency, user productivity, and
policy compliance. A combination of firewall, antispam, anti-virus, anti-phishing, and antihacking products are generally deployed to guard against these threats.
v Outbound email security. Securing the information that exits a corporate network is
as important as defending the inbound email stream, because misuse of corporate
information, data leakage, and delivery of improper content can result in significant
exposure. Content filtering, authentication, and encryption solutions can mitigate these
risks.
An effective approach to both inbound and outbound email security is to apply protection at the
enterprise boundary, where email enters or leaves the corporate network. This strategy simplifies
security by allowing administrators to define and manage security policies and measures centrally
and universally, without requiring individual users to actively implement them. Until recently,
securing email at the gateway to the enterprise has been sufficient for most organizations.
ENCRYPTION AT THE INTERNAL DESKTOP
Securing email between users inside the corporate network has not been a major concern for
most organizations with sufficient security at the gateway to the enterprise. Today, however, a
combination of changing business, regulatory, and technology factors are highlighting the need
for organizations to re-evaluate their email protection strategies and consider implementing a
third type of security: encryption at the internal desktop.
- As business relationships become more distributed and complex, internal networks are
providing email access for more remote users and non-employees. This blurs the line
between internal and external recipients and makes the network less trusted.
- It is becoming increasingly common for users to send sensitive information to a
combination of internal and external recipients who may warrant different levels of security
and have different encryption/decryption capabilities.
- Increased regulation requires greater control over the information exchanged within
internal networks, including encryption to protect against unauthorized access.
- Desktop encryption software has become easier to deploy, making it a viable solution for
protecting sensitive information inside corporate networks.
This paper summarizes several current techniques for encrypting email at the desktop, and
outlines the characteristics of an ideal solution that overcomes their various limitations. It also
provides an overview of the new desktop encryption enhancements that will be available for
Tumbleweed Secure Messenger and Tumbleweed Email Firewall in 2006.
02
Secu re Emai l I nsi de the Co rpo rate Netwo rk
Copyright©2006 Tumbleweed Communications Corp. All rights reserved.
Current Techniques for Desktop Encryption
One of the major challenges with any security solution is to balance the absolute security
requirements with usability. This is especially true for secure email products—if they are not easy to
use and fully integrated into the normal email workflow, the user community will not adopt them.
This is because they don’t pass a simple “Friday afternoon test.” Imagine a busy employee who
has to send an important email two minutes before leaving for the weekend. While assembling the
message, the employee realizes it really should be sent securely. An email encryption system will
only pass the test if it is integrated with the normal workflow, and so easy to use that the employee
will encrypt the message rather than continuing with standard email and hoping for the best.
A variety of encryption technologies and approaches provide different levels of security and
usability. They include:
- Compression and encrypted attachments
- Relying on passwords as a Shared Secret
- Using a full PKI for desktop email security
- Using PGP on the desktop
- Identity-based encryption
COMPRESSION AND ENCRYPTED ATTACHMENTS
A number of desktop utilities enable individual users to create encrypted archives of files that can
be attached to emails and sent to internal or external recipients (e.g. WinZIP™). Some support
only password-based encryption while others allow the use of the recipient’s digital certificate to
perform the encryption.
This is one of the simplest methods for providing email encryption at the desktop, but generally
requires senders to initiate the encryption process outside of the email client. Utilities can be
linked into the sender’s email system relatively easily by adding an “encrypt and send” option to
the menus available on the desktop.
Many of these systems also only support password-based encryption schemes, the limitations of
which are discussed below.
Relying on Passwords as a Shared Secret
Many of the simpler encryption schemes follow three steps:
- The sender gathers the information they wish to send into a package.
- The sender uses some tool to encrypt the package, and creates a password that the
recipient will use to decrypt it on the receiving end.
- The sender emails the package to the recipient(s).
03
Se cure Em ail I nsid e the C o rpo rate Netwo r k
Copyright©2006 Tumbleweed Communications Corp. All rights reserved.
This approach has several limitations:
- It doesn’t account for how senders provide recipients with passwords.
- It doesn’t easily scale beyond a few users.
- It tends to result in very loose security, with either standard known passwords being used
and shared among multiple users, or passwords being included in the emails themselves.
- It doesn’t enable the message body of an email to be encrypted along with the
attachments.
USING AN S/MIME-BASED PKI FOR DESKTOP EMAIL SECURITY
Public Key Infrastructures (PKIs) use virtual IDs, or digital certificates, to validate the identity of
organizations, computers, and individuals before allowing a transaction or communication to
occur. The ability to encrypt and decrypt email using digital certificates and the S/MIME standard
is built into many desktop clients, including Microsoft Outlook and Outlook Express, Lotus Notes,
Mac Mail, and Thunderbird. Yet S/MIME has not been adopted as a universal email encryption
standard. This is because desktop-based encryption solutions that rely on thousands of individuals
installing and consistently using digital certificates have not passed the Friday afternoon test
because they are not only cost-prohibitive, but they are also difficult to use. For example:
v To encrypt a message, the sender must first find a certificate for each recipient. If the
intended recipient does not have a certificate or the sender can’t find it, the encrypted
email can’t be sent. If certificates are found, senders must import each individual certificate
into their email clients. This is time-consuming and difficult to manage, particularly for nontechnical users.
v Who do you trust? Managing individual certificates on the desktop requires that senders
know how to verify certificates from different issuers, and what to do when certificates
become invalid or expire.
vPublishing a certificate directory is a security risk! If a company places a directory of internal
users’ certificates on the Internet or corporate intranet for others to look up, it is opening
the door to Directory Harvest Attacks and other threats from malicious hackers.
These limitations combined with the expense and administrative overhead of deploying a
traditional PKI has prevented widespread deployment of desktop email encryption. It is simply too
cumbersome.
USING PGP ON THE DESKTOP
Using desktop clients to implement PGP encryption between individuals imposes many of the
same limitations as S/MIME-based desktop encryption. While the trust model is usually different,
the requirement that individual senders have pre-existing PGP keys for all intended recipients only
works well for small communities, and does not scale within larger enterprises. As with S/MIME
and X509 certificates, publishing a directory of internal keys on the Internet to improve scalability
is a security risk.
04
Secu re Emai l I nsi de the C o rpo rate Netwo r k
Copyright©2006 Tumbleweed Communications Corp. All rights reserved.
IDENTITY-BASED ENCRYPTION
PGP, S/MIME, and X509-based approaches typically run into deployment problems because of the
need for senders to know in advance the encryption keys associated with each recipient. In the
last few years, some new approaches to PKI have been suggested which remove the need to share
public keys or digital certificates. These approaches, dubbed identity-based encryption, simplify
the process by using some other already-known feature, such as the recipient’s email address, as a
pseudo public key.
The cryptography underlying these techniques is relatively new and has not been subjected to the
same level of peer review as encryption using PGP or X509 certificates. As a result, identity-based
encryption techniques do not have the same standing in the cryptographic community. They also
have some characteristics that make them less attractive than they first appear:
v The encryption scheme actually relies on a single central Master Key. Compromise of this
Master Key has the potential to break system security.
v The recipient’s email address is not enough in itself. Using only the email address as
a pseudo public key does not allow revocation of keys. If a key is compromised, the
recipient must change email addresses or risk a security breach. In practice, the public key
is constructed using a combination of date/time, email address, and information about
the Master Key. This means that a particular recipient may have multiple private keys,
significantly increasing complexity.
vUnlike methods which rely on standards already supported by a variety of desktop and
mobile email clients, this method requires installing proprietary software on every system
you consume email on. This can be very time-consuming and challenging to support for
user who rely on multiple methods for receiving email.
The Ideal Solution
The ideal desktop encryption solution for internal networks will eliminate the weaknesses and
limitations of current techniques. For example, the ideal desktop-to-desktop encryption solution:
- Does not place any administrative burden on the sender, unlike conventional desktop
S/MIME and PGP.
- Can scale to support growing user communities, which is not possible with password-based
techniques.
- Integrates easily into the normal email workflow, unlike encrypting attachments.
- Does not rely on pseudo public-keys, which are unproven and tricky at best.
- Can effectively deal with encrypting email to a combined group of internal and external
recipients.
IDEAL USER EXPERIENCE OF A TYPICAL SENDER
Bob works for Enterprise X. He needs to send secure email to Alice, who is within Enterprise X and
Carol, an external partner. He should be able to send the encrypted message from his existing
email client without having to worry that Alice is internal and Carol is external. He may or may not
have previously sent email to Alice or Carol, and he may or may not have previously sent encrypted
email to anyone. Bob is an executive user who does not have time to understand or manage digital
certificates—he just wants his messages to be delivered securely.
05
Se cure Em ail I nsid e the C o rpo rate Netwo r k
Copyright©2006 Tumbleweed Communications Corp. All rights reserved.
IDEAL USER EXPERIENCE OF TWO TYPICAL RECIPIENTS
Alice receives the secure email from Bob, and may not have previously sent or received secure
email. She should be able to decrypt the email from Bob without worrying about her own software,
certificates, or keys. This means that Alice should either have pre-installed software to handle
the decryption (distributed by the administrator), or the email she receives should include easyto-follow decryption instructions. This might include a link to software she can download and
install on her desktop. Alice should also be able to reply to both Bob and Carol securely, without
concerning herself with who is internal and what encryption method is used. Once any initial
software or key is installed, Alice should be able to read any secure email she receives, even if her
computer is not connected to the Internet.
Carol should be able to receive secure messages from Enterprise X in her preferred encryption
format. She may already use S/MIME or OpenPGP encryption, or she may not have any previous
encryption capability. Carol should not need to know whether Bob and Alice are encrypting from
their desktops or using gateway encryption. She should simply be able to reply to or originate
secure messages using her preferred method and have them delivered to Bob and Alice. In
addition, encrypted messages originating from Carol should be scanned for viruses and policy
violations before being allowed into Enterprise X.
IDEAL USER EXPERIENCE OF A TYPICAL ADMINISTRATOR
Ted is the administrator for Enterprise X. He wants to enable employees to exchange secure email
internally and externally, but does not want to have to issue and manage certificates for internal
and external users. As much as possible, he wants encryption between internal and external users
with and without desktop software to be handled automatically by the gateway server.
Ted does not have time or resources to support complex client installation and setup for each
user who needs to send secure email. Ideally, he will be able to remotely install and enable secure
email for users from his own administration console. In cases where Ted is required to distribute
software for installation, he needs to take into account the profile of users such as Bob, and allow
them to send and receive secure email with minimal knowledge about encryption.
Tumbleweed Plug-in Coming in 2006
Tumbleweed is the leading provider of solutions for securing email communications. In the current
releases of Tumbleweed software, MailGate Email Firewall (EMF) and Secure Messenger (SM) work
together to inspect all outbound email at the network gateway. Based on custom policies that each
Tumbleweed customer administrator defines, it automatically identifies violations based on the
content of the email, and redirects suspect messages to a secure, encrypted channel for further
action. This perimeter-based design ensures that every employee, customer, and partner benefits
from secure email without having to actively implement and manage it on their own desktops.
06
Secu re Emai l I nsi de the C o rpo rate Netwo r k
Copyright©2006 Tumbleweed Communications Corp. All rights reserved.
Encrypted email is delivered to external desktops based on administrator-defined policies that
determine the most appropriate delivery medium for the intended recipient. The major encryption
standards (S/MIME, OpenPGP, SMG) are used for recipients who have encryption/decryption
capabilities in their email clients already, and Secure Messenger and Secure Envelope are used
to deliver encrypted email to recipients without requiring anything beyond an email client and
Web browser. While offering highly secure encryption options, these capabilities are not currently
integrated with standard email clients, reducing their effectiveness at the internal desktop.
In response to the growing need for higher security inside corporate networks, Tumbleweed will
release a desktop encryption plug-in for MailGate Secure Messenger that:
- Is easy to deploy and easy to use, enabling users to encrypt messages from their desktops
using the software they already know.
- Integrates seamlessly with existing workflow and desktop email clients.
- Works effortlessly with other Tumbleweed methods for external encryption, so that senders
do not need to worry about whether recipients are located inside or outside the enterprise.
THE TUMBLEWEED PLUG-IN APPROACH
The Tumbleweed desktop encryption plug-in will provide the proven security of PKI deployments
without the complexity and burden of certificate or key management. Combined with the flexible
Email Firewall, it will allow organizations to manage desktop-to-desktop email encryption in a way
that is most appropriate for each user.
The three diagrams, beginning on the next page, illustrate how the desktop plug-in will work for
three typical use cases:
1. Where the sender (Bob) is a user of the desktop plug-in, and the recipient (John) has also
previously installed the desktop plug-in and enrolled in the system.
2. Where the sender (Bob) is a user of the desktop plug-in, and the recipient (Alice) is an
internal user who has not yet installed the plug-in.
3. Where the sender (Bob) is a user of the desktop plug-in, and the recipient (Carol) is an
external recipient outside of the enterprise.
These diagrams have been separated to show the flow of information in each scenario, but
of course Bob could easily be sending the same message to all three recipients at once. The
approach taken by the desktop encryption plug-in means that Bob doesn’t need to worry about
who is who, and the plug-in will simply chose the right approach for each recipient. Of course once
John, Alice, or Carol have received Bob’s message, they can reply to him by effectively reversing
the processes shown here.
07
Se cure Em ail I nsid e the C o rpo rate Netwo r k
Copyright©2006 Tumbleweed Communications Corp. All rights reserved.

Bob creates an email in Outlook and tags it to be
sent securely.
 Encrypted email is routed through Exchange Server.

Plug-in checks local certificate cache for public key
for John. If key is found, skip to step 5.
 John’s Outlook client receives encrypted email.

Plug-in uses SOAP call to query for a certificate for
John.
 Plug-in uses John’s private key to decrypt the email.

Server checks certificate store. John is an enrolled
desktop user, so his certificate is returned.
 Decrypted email is presented to John.

Plug-in performs encryption of message using
John’s public key.
Figure 1: Bob sends a secure email to John, another internal user who has previously installed the plug-in
08
Secu re Emai l I nsi de the C o rpo rate Netwo r k
Copyright©2006 Tumbleweed Communications Corp. All rights reserved.

Bob creates an email in Outlook and tags it to be
sent securely.
sends message over SOAP directly to
 Plug-in
Tumbleweed Server for delivery.

Plug-in checks local certificate cache for public key
for Alice. Alice has not yet installed the desktop
client, so no key is present.
 disk.

Plug-in uses SOAP call to query for a certificate for
Alice.


Server checks local certificate store. Alice has not
installed the desktop client, so does not have a key.

Server checks whether Alice is an internal or
external user by referencing local rules and/or
Active Directory.

Alice is an internal user without a key. No certificate
is returned.
Secure Messenger stores message encrypted on
Secure Messenger notification is sent to Alice.
Because Alice is an internal user, this notification will
include instructions for Alice to install the desktop
plug-in for future desktop security.
 The notification is routed to Alice via Exchange.
Alice authenticates, and retrieves the email via
HTTPS. Because Alice is an internal user, her
11
authentication can be linked into Active Directory
and use the same credentials.
Figure 2: Bob sends a secure email to Alice, an internal user who has not yet installed the desktop plug-in
09
Se cure Em ail I nsid e the C o rpo rate Netwo r k
Copyright©2006 Tumbleweed Communications Corp. All rights reserved.

Bob creates an email in Outlook and tags it to be
sent securely.
performs encryption of message using
 Plug-in
Server’s public key.

Plug-in checks local certificate cache for public key
for Carol. Since Carol is not an internal user, it does
not find one.
 Encrypted email is routed through Exchange Server.

Plug-in uses SOAP call to query for a certificate for
Carol.

Tumbleweed server checks local store. Carol is an
external user, so there is no individual certificate.

Server checks whether Carol is defined as an
internal or external user by referencing Active
Directory.
11 which will bring her back to the web site to pick up

Carol is an external user, so a general server
certificate is returned to the plug-in to use for
encryption.
12
sees Carol as an external recipient, and
 Exchange
routes via SMTP to Tumbleweed server.
Tumbleweed Server uses its private key to decrypt
 the email. Secure Messenger notification and
delivery are then used to forward to Carol.
A notification is sent to Carol containing a URL
her secure email.
Carol authenticates, and retrieves the email via
HTTPS.
Figure 3: Bob sends a secure email to Carol, a recipient outside of his organization. This example shows Carol
receiving the email using Secure Messenger delivery, but she could equally well be configured to use Proxy
S/MIME or Proxy OpenPGP messages
10
Secu re Emai l I nsi de the C o rpo rate Netwo r k
Copyright©2006 Tumbleweed Communications Corp. All rights reserved.
Conclusion
Shifting business processes and communications needs, expanding internal email networks, and
increased regulatory requirements are prompting many organizations to re-evaluate their email
security strategies. Specifically, they are looking for ways to secure email traveling within their
corporate networks just as they secure email entering and leaving the enterprise.
One approach is to augment existing perimeter-based security with an additional layer of
protection inside the firewall, at the internal desktop. By providing encryption capabilities to
individual users, organizations can ensure that sensitive information is delivered safely to both
internal and external recipients. A host of desktop encryption techniques are currently available,
although they each have certain drawbacks in terms of security, manageability, and ease of use.
As the leading provider of solutions for secure communications, Tumbleweed has the experience
and the expertise to deliver desktop encryption capabilities that provide the strong security
required in today’s business environment without the limitations of existing techniques. In 2006,
Tumbleweed will introduce an encryption plug-in for MailGate Secure Messenger that adds a new
layer of desktop-to-desktop encryption that is easy to deploy, easy to use, and easy to manage
within corporate networks.
11
Se cure Em ail I nsid e the C o rpo rate Netwo r k
Copyright©2006 Tumbleweed Communications Corp. All rights reserved.
ABOUT TUMBLEWEED
Tumbleweed provides security solutions for email protection, file transfers, and
identity validation that allow organizations to safely conduct business over the
Internet.
Tumbleweed offers these security solutions in three comprehensive product suites:
MailGate, SecureTransport and Validation Authority. MailGate provides protection
against spam, viruses and attacks, and enables policy-based message filtering,
encryption and routing. SecureTransport enables business to safely exchange large
files and transactions without proprietary software. Validation Authority is the worldleading solution for determining the validity of digital certificates.
The result: organizations using Tumbleweed security solutions can safely and securely
use the Internet for business, significantly reducing their costs.
California, USA
Corporate Headquarters
Tumbleweed Communications Corp.
700 Saginaw Drive
Redwood City, CA 94063
New York, USA
United Kingdom
APAC
© 2006 Tumbleweed Communications Corp.
Tumbleweed Communications Corp.
245 Park Ave, 24th Floor
New York, NY 10167
Tumbleweed Communications Ltd.
Hurst Grove, Sanford Lane
Hurst, Berkshire RG10 OSQ
UK
Tumbleweed Communications
Centennial Tower, Level 21
3 Temasek Avenue
Singapore 039190
All rights reserved. Tumbleweed is a registered
Phone: +44 (0)118 934 7100
www.tumbleweed.com
Phone: 65-65497143
www.tumbleweed.com
trademark and Tumbleweed Email Firewall and
Tumbleweed Secure Messenger are trademarks
of Tumbleweed Communications Corp. All
other brand names are the trademarks of their
Phone: 650-216-2000/800-696-1978
www.tumbleweed.com
Phone: 212-209-7363/800-696-1978
www.tumbleweed.com
respective owners.
04/06