Voltage's Encrypted

Transcription

1 Voltage's Encrypted October Report #471 Ferris Research Product Brief Sponsored by Ferris Research, Inc. 408 Columbus Ave., Suite 1 San Francisco, Calif , USA Phone: +1 (415) Fax: +1 (415)

2 Introduction Voltage offers innovative cryptographic products. More specifically, they provide server software and client plug-ins that support the encryption and decryption of: Messages Stored Files Instant Messages. In this report, we will focus on the encryption and decryption of 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 for market intelligence on messaging and collaboration technologies.

3 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 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 for market intelligence on messaging and collaboration technologies. 3

4 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 Voltage Software Voltage has implemented a set of software products that allow organizations to employ identity-based cryptography (IBC) to encrypt and decrypt 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 recipients that cannot or have not installed a decryption plug-in (see below). client plug-ins, currently available for IBM Lotus Notes, Microsoft Outlook and Microsoft Outlook Express. These support both the encrypting and decrypting of messages by individual users. server connection software, currently available for Sendmail (employing the milter APIs). This supports both the encrypting of 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 message attachments in the absence of an client plug-in. Voltage Encrypted A Voltage encrypted 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 for market intelligence on messaging and collaboration technologies.

5 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 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 client plug-in installed, they will need to manually open the HTML attachment. In almost all 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 . 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 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 software to satisfy a number of different objectives. 1. To encrypt and decrypt flowing between internal senders or systems and internal recipients, over an internal system. 2. To encrypt and decrypt 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 flowing between internal senders or systems and consumers, over the public Internet. Visit us at for market intelligence on messaging and collaboration technologies. 5

6 Encrypting Internal To encrypt internal , an organization will need to install an internal Voltage SecurePolicy Suite, and plug-ins in their user s clients. For users that employ IBM Lotus Notes, Microsoft Outlook, or Microsoft Outlook Express, this will be an client-specific plugin, which provides support for both encrypting and decrypting . For users that employ another, or web based, client, this will be a Windows plug-in, which only provides support for decrypting . Encrypting Business Partner The approach adopted will depend upon whether a business partner has deployed a parallel Voltage 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 , or In server plug-ins, deployed to encrypt and/or decrypt as it exits or enters an organization s internal network. Depending upon the approach adopted by each organization, 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 message are decrypted in an inbound server, this server will need access to the 6 Visit us at for market intelligence on messaging and collaboration technologies.

7 recipient s private key, on whose behalf they are decrypting an inbound message. Encrypting Consumer An Organization that wishes to encrypt destined for consumers, or for business partner based recipients that lack a suitable Voltage infrastructure, must treat those recipients as belonging to its own Voltage security domain. Stated another way, these messages must be encrypted using a public key generated from a recipient s 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 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 client or in an server. In order to decrypt such a message, a receiving consumer has a number of options. Install an 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 ). If a consumer wishes to send encrypted back to the sending organization, then they will have to install an client Voltage plug-in. Summary Voltage is producing software that exploits identity-based cryptography to radically simplify the deployment of an 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 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 messages flowing to, and received from, business partners. It is now much easier, and thus much more possible, for an organization to encrypt messages flowing to consumers, and for consumers to easily decrypt these messages upon receipt. Visit us at for market intelligence on messaging and collaboration technologies. 7

8 Cost The software for end-to-end encryption Voltage Secur 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 or call 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 for market intelligence on messaging and collaboration technologies.

9 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 , USA. For more information, visit or call +1 (415) 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 system, and you are not a member of the User Panel, you can join and learn more about the User Panel at There is no charge to join. Visit us at for market intelligence on messaging and collaboration technologies. 9

10 Recent Reports From Ferris Research Gwava and GroupWise Security The OEM Market for Anti-Spam Solutions Spam: Corporate Practices and Priorities in 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 ers 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 Boundary Security Service Cloudmark s Spam Immune System : Fighting Spam With Genetic Algorithms The State of 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 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