Exchange Mail: Signed, Sealed, Delivered

HOW DID WE GET ALONG WITHOUT EMAIL? It's changed just about everyone'sbusiness--and personal--communication habits. But do you ever wonder whethersomeone else will read, or worse, manipulate, your mail? To guarantee theprivacy and authenticity of email messages to people in your enterprise,Microsoft's Exchange Server offers well-designed, albeit proprietary, solutions:With digital signatures and encryption in a set of tools that Microsoft callsadvanced security, you can ensure that no one else will read yourintra-enterprise Exchange email messages. And if someone alters them, you'llknow about it.

I Am the Key Master
My article, "Secure Enterprise Email" (May 1996), explains thebasic concepts and techniques of digital signatures and envelopes and emailencryption. Digital signatures (which my article, "Digital Envelopes andSignatures," September 1996, covers) show whether someone has tampered witha message since the sender composed it. A digital signature consists of a messagedigest (a 64-bit binary value that is a function of the message's content)encrypted with the sender's private key. So a digital signature is the emailequivalent of the old sealing-wax and signet-ring method of ensuring detectionif anyone tampers with a message while it's in transit and ensuring that thepurported sender really originated the message.

Encryption (or a digital envelope), in contrast, scrambles the contents of amessage so that an interceptor will see only meaningless gibberish (the ciphertext).The intended recipient can view the unscrambled message (the plaintext)because the sender generates a random message key (for example, a 56-bitbinary value that determines the exact way a fast symmetric key algorithm willscramble a block of input) and then the sender uses the recipient's publickey to encrypt the message key. The recipient's private key allowsdecryption of the message key, which allows decryption of the message.

Implementing either digital signatures or encryption in email requires oneparty to obtain the public key of the other party. To verify a digitally signedmessage, the recipient must obtain the sender's public key. For digitalsignatures, the sender's key can accompany the message and signature, but thismethod tends to increase the message's size. To encrypt a message, the sendermust obtain the recipient's public key before sending the message.

To get each other's public key, the best source is a centralized key serverthat provides a public key certificate (which validates a public key and whichthe International Standards Organization--ISO--defines in its ISO X.509standard). Microsoft Exchange email gives you such a key server: ExchangeServer's Key Management (KM) Server manages a library of all user public keysand can provide them to any advanced security user.

Install the Key Management Server
Only one KM Server is allowed for an entire site. To install KM Server, youneed Exchange Server up and running. Although KM Server is part of ExchangeServer and does not cost extra, Exchange Server's setup program does notinstall it. You run KM Server's setup program (setup.exe) from the ExchangeServer CD-ROM in directory setupi386exchkm.

Once installed, the KM Server provides certificate authority for creatingand signing certificates, a public key server for managing distribution ofpublic keys to any client in the enterprise that needs them, and CertificateRevocation List (CRL) management for listing and searching for compromisedkeys. A key is compromised when the private half of a public/privatekey pair is no longer private because someone has discovered it or been exposedto it.

During the install, the system generates a system security key,which you can write to a diskette. Do. When KM Server is installed, you mustenter the system security key every time you restart the Server (i.e., everytime you reboot). This necessity is a serious inconvenience after a powerfailure when the server automatically restarts. The easy way to enter the systemsecurity key is by using the diskette with the copied system security key. Butremember that the computer this server runs on needs ample CPU resourcesbecause some functions are very CPU intensive. If this system security key is onan underpowered computer, you can have a bottleneck in a large system. (As Iwrite this article, Service Pack 1 for Exchange Server has just been released,so check the most recent TechNet CD-ROM or Microsoft's Web site for the latestService Packs to get important bug fixes.)

After you install KM Server, you have to enable security for each user whowill have advanced security. You must generate two public/private key pairs foreach user and create digitally signed certificates that incorporate those publickeys. First, in Exchange Server Administrator, select the server for the user,and then select Recipients and the user you want. Double-click the user's nameto view and edit Properties for the user. Select Security and then EnableSecurity. This process generates a 12-character security token, such asXPQEYRUGTSYR, which you must give to the user in a secure way--not bynonsecure email.

To complete the process, on the Exchange Client main window, the user mustselect Tools/Options. In the options property sheet, the user then selects theSecurity tab. On the Security page, the user clicks the Set Up AdvancedSecurity button and enters the security token that you supplied. Next, theuser chooses and enters a security password that can differ from the emailpassword. The user receives a message that notification will soon arrive toconfirm that security is enabled. (The computations for generating the key pairstypically take 30 seconds to several minutes.) When the user receives a specialemail message that delivers the cryptographic key material to the ExchangeClient, the user must enter the new security password.

The Server's special message contains two public/private key pairs: onepair for digital signing and one for encrypting. Exchange Client stores privatekeys securely on the local disk for future use. Not only is a password necessaryto retrieve a private key, but Exchange Client stores the private keys inencrypted form (by means of a secret key-encrypting key, known only to theExchange Client) to prevent someone from using a debugger or hexidecimal dumputility to look at the programs in memory or the files on your disk--either inperson or via a modem or network connection.

You don't need or want to secure public keys. When you accept the message,you add them to the Key Server's library for retrieval by anyone who needs themto encrypt a message or validate a signed message. When you finish reading thisspecial message and close it, it disappears completely from the system.

Signed, Sealed, Delivered
To add a digital signature to an outgoing Exchange email message, you accessDigitally Sign Message. Exchange Client retrieves your private key fromthe local disk and generates a digital signature to send with the messagecontent.

To encrypt, or scramble, the contents of a message, click Seal Messagewith Encryption. Exchange Client will retrieve the recipient's public keyfrom the KM Server. This public key encrypts a randomly generated message key,which is used to scramble the message (via a fast symmetric-key algorithm). Youclick the Send button to transmit the encrypted message key and the encryptedmessage.

When you receive a digitally encrypted message, the message icon will be anenvelope with a small padlock on the first view line for the message. Click themessage line. You supply your security password to retrieve your private keyfrom the local disk and decrypt the key and the message. (To avoid entering yourpassword every time, by checking Remember, you can request that theclient remember it for the next time you need the private key. The client willrecall your password until you terminate that session.)

When you enter the correct security access password, the client retrievesthe private key from the local disk and decrypts and displays the originalmessage. At this point, the KM Server is not consulted and therefore theCRL--the disavowed list--is not checked. Every time you view the message, youmust re-decrypt it. Of course, if you print or save the message while it isdecrypted in the viewer, the printout and saved version are not secure.

When you receive a digitally signed message, the message icon will be anenvelope with a small pen nib, unless the message is encrypted. In that case,only the padlock appears. You click the message line as usual and use thesender's public key to open the message.

A new toolbar icon, Read Digital Signature, appears in the ReadMessage window toolbar to show that the message was signed and to let youvalidate the signature. When you click this button, you must enter your securitypassword (unless you previously requested that Exchange Client remember yourpassword). Then Exchange Client will retrieve the sender's public key from theKM Server, search the CRL, and display the following information:

Signed by:

Verification results:

Contents altered after item was signed:Yes/No

Signature suspended:Yes/No

Signature issued by unknown security authority:Yes/No

Signature expired:Yes/No

Signature suspended means that the public key was on the CRL, whichmeans that signature's security was compromised. The other items areself-explanatory. You can verify the digital signature any number of times.

Return to Sender
Although secure Exchange email is almost as simple as nonsecure email, keepin mind that Exchange Server does not currently support Secure MIME (S/MIME).So, if you send an Exchange mail message with a digital signature to an Internetmail client through the Internet Mail Connector, the message header and body gothrough, but the signature is stripped off completely. Although you can convincean Exchange Client to send a secure message to an Internet user, no Internetmail client can unscramble an encrypted message or validate a signed one thatyou create with Exchange Client because its syntax is proprietary.

Exchange Server offers good support for encryption and digital signaturesand has done a good job of hiding the complex details from the user. But theseadvantages are shadowed by limiting use to within a given enterprise and only toExchange Client users. Although Microsoft has supported some emerging standards,the proprietary nature of the system makes interoperating with the emergingstandards for secure Internet mail (e.g., S/MIME) impossible. What remains to beseen is whether Microsoft's market clout can overcome this serious problem asthe industry continues to evolve. For more information about secure Exchangeemail, see the sidebar, "Additional Reading."