Protecting e-mail confidentiality

Encrypting e-mail and other digital communication methods (e.g. IM, P2P, BlackBerrys, etc.) is taking on new importance these days as businesses open new channels for employees, customers, and partners to pass messages to one another. Today’s column will discuss the most common methods for encrypting e-mails and point out some of the advantages and disadvantages of each solution.

Proprietary built-in mechanism

Some e-mail systems, especially older e-mail products, allow e-mail to be encrypted with a single click of the mouse. Normally, you simply enable the encrypt button, input a protective password, and then send the e-mail. The e-mail is encrypted by the inputted password (i.e. the inputted password is used as the random input value to start the encryption cipher process) or protects the stronger secret encryption key that is used to do the real encryption.

These products normally only work with other users on the same e-mail system and/or require that the encryption password be shared with the intended recipient using an out-of-band method (e.g. calling them with the password or sending it in a separate email). Also, because these e-mail systems are older and proprietary, they often use flawed cryptography (if it can even be considered cryptography) or weak, no longer accepted ciphers (e.g. DES, 56-bit SSL, etc.). Proprietary e-mail encryption schemes are becoming a thing of the past.

WinZip and PKZip

Many users are familiar with the abilities of WinZip or PKZip to encrypt e-mail or file attachments. Years ago, these products were flagged as having poorly implemented encryption. This is no longer the case as long as you are using a version from the last few years. Depending on the product, these may encrypt the entire e-mail, not just the file attachment, and work across a wide range of platforms.

Usually the encryption is protected by a user-supplied password, which means the protection is only as strong as the password (as is the case with many other products). Today’s versions use reliable ciphers and strong cipher keys. The biggest drawback is that the regular versions that most users own require manual encryption (sometimes external to the regular e-mail process), and the related problem of how to securely transmit the secret password to the intended receiver and only the intended recipient. Still, if you only remember the bad encryption traits of WinZip or PKZip, you haven’t tried them lately.

Encrypted HTML e-mail

Many companies offer HTML e-mail services with encryption abilities. Like some of the proprietary e-mail encryption products, private encrypted HTML products are often misrepresented. This is not to say that good encrypted HTML e-mail does not exist (it does, even as part of larger, more popular offerings), it’s just a case of “user beware.”

With a third-party system hosting the encrypted e-mail, you are never really sure about who can or can’t read the e-mail. Several companies promising secure e-mail have later been found out to have company-intended backdoors, even though the word “crypto” was in the company’s name.

PGP/GPG/OpenPGP

E-mail encryption based on one of the PGP (Pretty Good Privacy) tools can be a secure option. PGP uses reliable encryption and has nearly two decades of experience in securing data. PGP can be intimidating for first-time users (who often get confused about which keys to send to each other) and requires that both sender and receiver have PGP, with compatible ciphers, installed. Once you’re set up, though, sending encrypted e-mail can be as simple as click and send.

S/MIME

S/MIME is often the enterprise choice for encrypting and authenticating e-mail. S/MIME is supported by most enterprise e-mail systems but has a heavy setup cost. Oftentimes a PKI servicer is needed, keys have to be distributed, and clients have to be configured.

However, all of this can be seamlessly automated, from the end-user’s perspective, in a Windows Active Directory environment and probably so in a Linux/Unix environment using scripts. The harder part can be setting up external users outside of the enterprise’s direct control (as senders need receiver’s keys to send encrypted e-mail). Also, S/MIME doesn’t encrypt e-mail header/subject information by default, which can be a benefit to some, and a negative to others (see below).

Rights Management Service

RMS is a Microsoft-only solution. It allows Microsoft Office, Microsoft Outlook, HTML, and other data content types to be wrapped with asymmetric ciphers. When the receiver attempts to open RMS-protected content (e-mail in this example), the user’s RMS client (installed by default in Windows Vista) will “dial home” and approve the content opening, as well as restrict the user to a predefined set of actions. RMS can be used to prevent the user from forwarding, printing, and copying e-mail unless previously unauthorized. It’s not perfect security, but it works.

Mail encryption appliances and products

Several vendors are offering security appliances and products that focus on encrypting e-mail. One interesting solution, Secure Computing‘s SecureMail appliance, supports seven different types of encryption protocols: S/MIME, PGP, TLS, etc. One of the features I like best with this product is the ability to encrypt e-mails on the fly based upon predefined content and replace outgoing content with a link that is sent to the receiver, giving TLS access to the e-mail after a password is inputted.

I’m sure I missed a dozen other e-mail cipher solutions just as good, but column space is limited, and these options should give you a start.

General concerns

When choosing an e-mail encryption solution, be sure to ask about, and test, your ability to manage encrypted e-mail in the same way as you manage your unencrypted e-mail. For example, can you scan e-mail for malware or unauthorized content if it is encrypted? Can you index and retrieve e-mails based on content if that content is encrypted (for example, S/MIME allows indexing and retrieval based on e-mail headers and subject fields, but not on the message body content)? What about key management and recovery? Any solution without a recovery solution is bound to lose important, mission-critical information that can’t be recovered.

Before implementing any solution, test it on a few of your patient users and learn the benefits and pitfalls of the solution before plunging head long into a large enterprise-wide deployment. It will keep your data secure and your users (and managers) much happier.