Ferris Research, Inc.
408 Columbus Ave., Suite 1 San Francisco, Calif. 94133, USA Phone: +1 (415) 986-1414
Voltage's Encrypted Email
October 2004. Report #471
Ferris Research Product Brief
Introduction
Voltage offers innovative cryptographic products. More specifically, they provide server software and client plug-ins that support the encryption and decryption of:
• Email Messages
• Stored Files
• Instant Messages.
In this report, we will focus on the encryption and decryption of email messages.
Customers include Dynamic Mutual Funds, Electric Insurance, UC Irvine Medical Center, Waterfield Mortgage, XL Capital.
A Brief History of Cryptography
Symmetric Key CryptographySoon after the invention of writing, correspondents sought ways to keep their communications private. They did this by employing a
secret key to encrypt, and thus mask the contents of, a message prior to
transmission, and that same secret key to decrypt, and thus reveal the contents of, a message upon receipt. Because the same key is em-ployed to encrypt and decrypt a message, this form of cryptography is referred to as symmetric, or shared, key cryptography.
While methods employed to encrypt and decrypt a message using sym-metric keys have become progressively more unbreakable over time, the fundamentals remained the same. Both a sender and a recipient needed to know the same secret key, and they needed to keep it secret – keep it from either being physically compromised (stolen, captured, etc), or reconstructed through the analysis of encrypted messages.
Asymmetric Key Cryptography
In the 1970s, a method was discovered in which two separate (asym-metric) keys could be employed – one (a public key) to encrypt, and mask the contents of, a message, and a second (a private key) to decrypt it. This was a major breakthrough, as the key employed to encrypt a message no longer had to be kept secret. It could be openly communicated.
Asymmetric key cryptography also provided an additional new capability. It supported cryptographic signature. A message encrypted with a private key, could only be decrypted with its corresponding
public key. This provided a means by which a recipient of a message
Unfortunately, while public key cryptography offered a significant breakthrough, things were not quite as perfect as they first appeared. There were three major problems:
1. Asymmetric keys were too long (16-32 times longer than equiva-lently secure symmetric keys) to be employed efficiently to dir-ectly encrypt & decrypt long messages.
2. A means was needed to establish that a public key, and therefore, by implication its corresponding private key, really belonged to one’s intended correspondent and not to someone else.
3. A means was needed to signal that a public key should no longer be employed, because its corresponding private key had been compromised (been captured, stolen, reconstructed, etc.).
Dealing with the first of these problems required the development of a hybrid approach to encryption – a message is rapidly encrypted using a per-message symmetric key, and then this per-message symmetric key is encrypted for each recipient using their public key. Similarly, cryptographically signing is performed efficiently by rapidly compres-sing a message into a short digest (or hashed) form, and then encrypting this digest with the sender’s private key.
Dealing with the latter two problems required the establishment of a Public Key Infrastructure (PKI). A PKI provides a means of certifying that a public key belongs to a named entity, and a means of de-certifying a previously certified public key.
It is deploying, and then interacting with, a PKI that has proved the Achilles heel of most asymmetric key cryptography schemes. Before employing a public key to encrypt a message or verify a cryptographic signature, a user has to a) acquire a certified public key for their correspondent, b) verify that the certification is valid, and c) verify that the certification, though valid, hasn’t been subsequently revoked. This has proved too heavy weight for all but the most pressing crypto-graphic requirements.
Identity-Based Cryptography
Recently, an alternative form of asymmetric key cryptography has been invented. It is called identity-based cryptography (IBC), because it enables a public key to be dynamically generated, by cryptograph-ically combining a correspondent’s identity (for example, his or her email address) with a shared public key seed.
When employing IBC, a PKI is still required to generate private keys, and a public key seed, but one is no longer required to generate, certify, de-certify and store individual public keys. Somewhat surprisingly, nor is a PKI required to certify or de-certify a public key
seed. This is because another approach is now possible – the
a PKI each time it encounters a public key generated with a new public
key seed. It is up to the operator of an IBC based PKI to determine the
validity period of a public key seed, and therefore, how rapidly or slowly it should lapse.
Voltage Encrypted Email
Voltage SoftwareVoltage has implemented a set of software products that allow organizations to employ identity-based cryptography (IBC) to encrypt and decrypt email messages. These take the form of:
• A Voltage SecurePolicy Suite. This is a set of web (HTTP) acces-sible Voltage servers that can be hosted on a single shared, or on multiple distinct, computer systems, and which provide:
o An enrollment service, which authenticates a user using organizationally specified credentials such as a name and password.
o A key service, that issues private keys, and public key seeds and associated information. Voltage refers to public key seeds and this associated information as public key parameters. o A management service, that controls enrollment, specifies the
interval over which public key seeds remain valid, and enables/disables a user’s rights to acquire a private key, etc. o A decryption service, for email recipients that cannot or have
not installed a decryption plug-in (see below).
• Email client plug-ins, currently available for IBM Lotus Notes, Microsoft Outlook and Microsoft Outlook Express. These support both the encrypting and decrypting of email messages by individual users.
• Email server connection software, currently available for Sendmail (employing the milter APIs). This supports both the encrypting of email messages on exit from an organization, and/or the decrypting of messages on entry to an organization, based on policy.
• A Windows plug-in that supports the decrypting of Voltage encrypted email message attachments in the absence of an email client plug-in.
Voltage Encrypted Email
A Voltage encrypted email message consists of a cover message with an HTML attachment containing the encrypted message.
The cover message contains:
• Text indicating that the original message has been encrypted.
• A block of encrypted and encoded (base64) data that is used by a Voltage plug-in for various purposes, without first having to access the HTML attachment.
The HTML attachment has been very cunningly constructed. It consists of HTML text, that issues an HTTP POST command, that automatically transfers the encrypted message embedded in the HTML to a specified Voltage web-based decryption service (see preceding section).
If the receiving user has a Voltage email client plug-in installed, then all of the above will be opaque to them, and the plug-in will decrypt the encrypted message behind the scenes, and display the decrypted message as if it had never been encrypted. This of course assumes that the plug-in has access to an appropriate private key, either on-line or locally cached.
If the receiving user does not have a Voltage email client plug-in installed, they will need to manually open the HTML attachment. In almost all email clients, this will cause a browser to be launched with the HTML attachment as input.
If the user has a Voltage Windows plug-in installed, it will intercept all browser launches, and examine the provided input for embedded Voltage encrypted email. If one is found, the Windows plug-in will extract and decrypted the encrypted message and then pass it as input to the browser for immediate display. Again, this assumes that the plug-in has access to an appropriate private key, either on-line or locally cached.
If the receiving user does not have either an email client, or a Windows, plug-in installed, a browser will be launched with the HTML attachment as input. This will in turn automatically HTTP POST the Voltage encrypted message to a Voltage web-based decryption service. After suitable credentials (a name and password, or a previously provided cookie) are presented and validated, the Voltage web-based decryption service will return the decrypted message as an HTML page for display by the browser.
Deployment Options
An organization can deploy Voltage secure email software to satisfy a number of different objectives.
1. To encrypt and decrypt email flowing between internal senders or systems and internal recipients, over an internal email system. 2. To encrypt and decrypt email flowing between internal senders or
systems and recipients at business partners, and between senders at business partners and internal recipients, over the public Internet. 3. To encrypt and decrypt email flowing between internal senders or
Encrypting Internal Email
To encrypt internal email, an organization will need to install an internal Voltage SecurePolicy Suite, and plug-ins in their user’s email clients.
For users that employ IBM Lotus Notes, Microsoft Outlook, or Microsoft Outlook Express, this will be an email client-specific plug-in, which provides support for both encrypting and decrypting email. For users that employ another, or web based, email client, this will be a Windows plug-in, which only provides support for decrypting email.
Encrypting Business Partner Email
The approach adopted will depend upon whether a business partner has deployed a parallel Voltage email infrastructure or not. If they have not, then business partner based recipients will be treated as if they were consumers (see below). If they have, then the two organizations can also opt to federate their Voltage infrastructures. If and when they do so, then the key servers in each organization will serve as a source of public key parameters for both organizations. In either case, there are then two points at which encryption and/or decryption can be performed.
• In client plug-ins, previously deployed to encrypt and/or decrypt internal email, or
• In server plug-ins, deployed to encrypt and/or decrypt email as it exits or enters an organization’s internal network.
Depending upon the approach adopted by each organization, email can then be:
• Encrypted end-to-end – encrypted by a sending client and de-crypted by a receiving client.
• Encrypted gateway-to-end – encrypted by a sending organization’s server and decrypted by a receiving client.
• Encrypted end-to-gateway – encrypted by a sending client and decrypted by a receiving organization’s server.
• Encrypted gateway-to-gateway – encrypted by a sending or-ganization’s server and decrypted by a receiving oror-ganization’s server.
recipient’s private key, on whose behalf they are decrypting an inbound email message.
Encrypting Consumer Email
An Organization that wishes to encrypt email destined for consumers, or for business partner based recipients that lack a suitable Voltage email infrastructure, must treat those recipients as belonging to its own Voltage security domain. Stated another way, these email messages must be encrypted using a public key generated from a recipient’s email address in combination with a sending organization’s Voltage public key parameters. This differs from the business partner case described in the preceding section, in which a public key is generated from a recipient’s email address in combination with the receiving organization’s Voltage public key parameters. As in the business partner case described in the preceding section, encryption can also be performed in a sending email client or in an email server.
In order to decrypt such a message, a receiving consumer has a num-ber of options.
• Install an email client Voltage plug-in.
• Install a Windows Voltage plug-in.
• Employ the sender’s web-based decryption service
These have already been described in some detail above (see “Voltage Encrypted Email”). If a consumer wishes to send encrypted email back to the sending organization, then they will have to install an email client Voltage plug-in.
Summary
Voltage is producing software that exploits identity-based cryptog-raphy to radically simplify the deployment of an email encryption and decryption infrastructure. This has three impacts:
• It is now much easier, and thus much more possible, for users and systems to encrypt and decrypt internal email messages – for example, salary advice notices and other forms of commun-ication that need to be kept private.
• It is now much easier, and thus much more possible, for an organization to encrypt and decrypt email messages flowing to, and received from, business partners.
Cost
The software for end-to-end email encryption—Voltage SecureMail— costs $62,500 for the server plus $50 per user. The software for policy-based encryption—Voltage IBE Gateway—costs $55,000 per server plus $25 per user for every user protected from compliance violations. There is an additional cost for modules that secure BlackBerry messaging.
Contact
For more information, please visit www.voltage.com, email [email protected], or call +1 650 543 1280.
Research Note Sponsored by Voltage
Ferris Research
Ferris Research is a market research firm specializing in messaging and collaborative technologies. We provide business, market, and technical intelligence to vendors and corporate IT managers worldwide with analysts located in North America, Europe, and Asia/Pacific.
To help clients track the technology and spot important developments, Ferris publishes reports, white papers, bulletins, and a news wire; organizes conferences and surveys; and provides customized consulting. In business since 1991, we enjoy an international reputation as the leading firm in our field, and have by far the largest and most experienced research team covering messaging and collaboration.
Ferris Research is located at 408 Columbus Ave., Suite 1, San Francisco, Calif. 94133, USA. For more information, visit
www.ferris.com or call +1 (415) 986-1414.
The Ferris Research User Panel
The User Panel consists of IT professionals who work with messaging and collaborative technologies, providing services to their organizations’ users. People join to share experiences with other people like themselves, learn from each other, and keep current on news and trends.
Recent Reports From Ferris Research Gwava and GroupWise Security
The OEM Market for Anti-Spam Solutions Spam: Corporate Practices and Priorities in 2004
Email Records Management Survey: Guidelines, Technologies, and Trends
New Trends in Spam
The Impact of CAN-SPAM on Legitimate Direct Marketers Upgrading From Exchange 5.5 to 2003: A Financial Case Study Bonded Sender: A Program for Legitimate Emailers
Spim: Spam Over Instant Messaging
Gmail: Google’s Entry Into the Webmail Market Microsoft Tech-Ed 2004: A Messaging Perspective
The Cost of Migrating From Exchange 5.5 to Exchange 2003 Exchange Server Reliability
Electronic Privacy and Security Regulations A Survey of Exchange Installations: Key Statistics CIO Messaging Concerns and Priorities
Recent Innovations in Macintosh Collaboration
FrontBridge TrueProtect Email Boundary Security Service
Cloudmark’s Spam “Immune System”: Fighting Spam With Genetic Algorithms
The State of Email Denial-of-Service Attacks Instant Messaging: Current Status, Key Trends How Not To Be a Spammer – Updates
The Growing Threat of Questionable Patents Bayesian Filters for Spam Control
Another Alternative to Exchange Servers at Branch Sites Lotusphere 2004
TCP/IP Bandwidth Shaping as an Anti-Spam Measure URL-Based Spam Filtering
Reputation and Spam Control Are Spam Laws Working?
Microsoft’s Caller ID for Email Proposal
LinuxWorld NY 2004: A Messaging Perspective Update on IBM/Lotus Workplace
TotalBlock: New Challenge/Response Anti-Spam Technology Microsoft Exchange Edge Services