Voltage's Encrypted Email

Voltage's Encrypted Email October 2004. Report #471 Ferris Research Product Brief Sponsored by Ferris Research, Inc. 408 Columbus Ave., Suite 1 San Francisco, Calif. 94133, USA Phone: +1 (415) 986-1414 Fax: +1 (415) 986-5994 www.ferris.com

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 Cryptography Soon 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 employed 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 symmetric 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 (asymmetric) 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 could cryptographically establish that its sender was who s/he claimed to be, or at least possessed the private key used to sign the message. 2 Visit us at www.ferris.com for market intelligence on messaging and collaboration technologies.

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 equivalently secure symmetric keys) to be employed efficiently to directly 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 compressing 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 decertifying 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 cryptographic 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 cryptographically 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 generation of short-lived public key seeds and corresponding private keys. Using such an approach, an encrypting system merely has to acquire a new public key seed from a PKI, each time a prior public key seed lapses, and a decrypting system has to acquire a new private key from Visit us at www.ferris.com for market intelligence on messaging and collaboration technologies. 3

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 Software Voltage 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) accessible 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. An URL from which Voltage plug-ins can be downloaded. 4 Visit us at www.ferris.com for market intelligence on messaging and collaboration technologies.

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 systems and consumers, over the public Internet. Visit us at www.ferris.com for market intelligence on messaging and collaboration technologies. 5

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 plugin, 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 decrypted 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 organization s server and decrypted by a receiving organization s server. In all four cases, a sending client or server plug-ins will select which public key parameters it requires to encrypt a message, based upon the Internet domain to which each recipient belongs. These will either have been previously sourced and cached, or will need to be sourced from its own organization s Voltage key server (in the federated case), or from the business partner s Voltage key server (in the non-federated case). This requires that each business partners Voltage enrollment and key servers are accessible to a sender. In addition, when email message are decrypted in an inbound server, this server will need access to the 6 Visit us at www.ferris.com for market intelligence on messaging and collaboration technologies.

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 number 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 cryptography 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 communication 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. It is now much easier, and thus much more possible, for an organization to encrypt email messages flowing to consumers, and for consumers to easily decrypt these messages upon receipt. Visit us at www.ferris.com for market intelligence on messaging and collaboration technologies. 7

Cost The software for end-to-end email encryption Voltage SecureMail costs $62,500 for the server plus $50 per user. The software for policybased 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 info@voltage.com, or call +1 650 543 1280. Research Note Sponsored by Voltage Voltage commissioned this document with full distribution rights. You may copy or freely reproduce this document provided you disclose authorship and sponsorship and include this notice. Ferris Research independently conducted all research for this document, retaining full editorial control. 8 Visit us at www.ferris.com for market intelligence on messaging and collaboration technologies.

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. If you provide technical support for an email system, and you are not a member of the User Panel, you can join and learn more about the User Panel at http://www.ferris.com/url/userpanel.html. There is no charge to join. Visit us at www.ferris.com for market intelligence on messaging and collaboration technologies. 9

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 Exchange 5.5 Migrations: Issues and Best Practices How Not To Be Seen as a Spammer