Secure Messaging and Exchange

I appreciate the feedback I get from readers and often try to incorporate your ideas into this column. This week, by special request from Brian Ko of Minnesota, I want to touch on the problematic subject of using Exchange to provide secure (i.e., digitally signed or encrypted) email.

Exchange implements secure messaging through the Advanced Security subsystem. This subsystem supports two key functions: signing (i.e., digital signatures for message nonrepudiation) and encryption/decryption. In fact, the Exchange infrastructure and services play a supporting role in secure messaging; the Exchange client (e.g., Outlook, Outlook Express) plays the main role. For secure messaging to work, you need a supporting infrastructure, Exchange services, and client extensions that implement support for digital signing and encryption.

The infrastructure required for Exchange secure messaging—a public key infrastructure (PKI)—includes many pieces (e.g., directory, Certificate Authority—CA). If you want to extend secure-messaging functionality outside the boundaries of your firewall, secure messaging—and your PKI—become much more complicated. In Exchange Server 5.5 all the necessary infrastructure pieces exist within the Exchange system, so to implement secure messaging through Exchange, you must either deploy an Exchange 5.5-only solution or invest in a third-party solution from a vendor such as VeriSign or Entrust. Because most secure-messaging functionality depends on client capabilities, third-party solutions (which are more easily integrated with both Exchange 5.5 and a variety of clients) are the more likely choice. Exchange 2000 Server and Windows 2000, however, open things up a bit. Exchange 2000—and its clients—can go outside of the Exchange system to use 1) a non-Exchange directory such as Active Directory (AD) or another Lightweight Directory Access Protocol (LDAP) directory, or 2) a Win2K-implemented CA (i.e., Microsoft Certificate Server). Of course, you can still choose a third-party solution, or you can build a hybrid scenario.

Exchange's Key Management Service (KMS) provides an additional piece of the infrastructure. Whereas earlier versions of Exchange (i.e., Exchange 4.0 to Exchange 5.5) use the KMS and the Exchange Directory Service (DS) as the sole service providers for a PKI infrastructure, Exchange 2000 changes the KMS's role to one that complements the chosen directory, CA, and the rest of the PKI. KMS provides the Certificate Revocation List (CRL), the Certificate Trust List (CTL), and, most importantly, a key-recovery ability for Exchange users. However, an outside (i.e., non-Exchange) source—Win2K, a third-party solution, or a combination of the two—provides the bulk of the PKI functions.

Perhaps the most complicated part of secure messaging—encryption and signing—is performed by the client and has little to do with Exchange. This fact is one reason that plugging-in a third-party secure-messaging solution is relatively easy. The only thing that Exchange does for this aspect of secure messaging is provide Secure MIME (S/MIME) support. S/MIME adds additional MIME content types to messages to provide confidentiality, integrity, and nonrepudiation. Clients use a scheme called asymmetric encryption to secure email messages. This technique uses a pair of keys, one public and one private, that are mathematically related according to a specified algorithm. When you want to send an encrypted message to someone, your email client retrieves the recipient's public key (from his or her X.509v3 certificate, which is stored in the directory) and uses that key to encrypt the message body and attachments. When the recipient receives the encrypted message, he or she simply uses his or her private key to decrypt the contents. Signing works in similar fashion: The sender uses his or her private key to sign a message, then sends the message. When the recipient receives the message, the recipient's email client locates the sender's public key and uses it to verify the sender's authenticity and the message's integrity.

Secure messaging should be 100 percent business-driven, not just implemented for the sake of using the technology. To use secure messaging outside of your organization, you must open up your directory (or some portion of it) to partners and customers with whom you want to exchange secure messages. In other words, you essentially must publish your users' public keys—something that many organizations don't want to do because this step is rather difficult and full of potential security risks. This problem exists even when you use third-party solutions. Another challenge is interoperability with partners' secure-messaging systems. Not everyone uses Exchange as a messaging system and Win2K AD as a directory. You can resort to an LDAP directory as a lowest common denominator, but this approach has its problems as well. Finally, the list of mail clients that can participate in secure messaging is limited. For example, there is really no viable solution for a PDA-type client's participation in secure messaging. Even Microsoft Pocket PC devices have no real S/MIME solution (although some solutions are on the horizon).

These concerns have led many organizations to give up on secure messaging. However, some have persevered, including a rag-tag group spearheaded by The Open Group Electronic Messaging Association (EMA) Forum. The EMA Forum has successfully demonstrated that secure messaging can work across organizations, OSs, PKI providers, and messaging systems. For more information about this project, see
http://www.ema.org/challenge/SecureMessagingChallenge1-21-02_files/frame.htm