HOW DID WE GET ALONG WITHOUT EMAIL? It's changed just about everyone's business--and personal--communication habits. But do you ever wonder whether someone else will read, or worse, manipulate, your mail? To guarantee the privacy 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 calls advanced security, you can ensure that no one else will read your intra-enterprise Exchange email messages. And if someone alters them, you'll know about it.
I Am the Key Master
My article, "Secure Enterprise Email" (May 1996), explains the basic concepts and techniques of digital signatures and envelopes and email encryption. Digital signatures (which my article, "Digital Envelopes and Signatures," September 1996, covers) show whether someone has tampered with a message since the sender composed it. A digital signature consists of a message digest (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 email equivalent of the old sealing-wax and signet-ring method of ensuring detection if anyone tampers with a message while it's in transit and ensuring that the purported sender really originated the message.
Encryption (or a digital envelope), in contrast, scrambles the contents of a message 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-bit binary value that determines the exact way a fast symmetric key algorithm will scramble a block of input) and then the sender uses the recipient's public key to encrypt the message key. The recipient's private key allows decryption of the message key, which allows decryption of the message.
Implementing either digital signatures or encryption in email requires one party to obtain the public key of the other party. To verify a digitally signed message, the recipient must obtain the sender's public key. For digital signatures, the sender's key can accompany the message and signature, but this method tends to increase the message's size. To encrypt a message, the sender must obtain the recipient's public key before sending the message.
To get each other's public key, the best source is a centralized key server that provides a public key certificate (which validates a public key and which the International Standards Organization--ISO--defines in its ISO X.509 standard). Microsoft Exchange email gives you such a key server: Exchange Server's Key Management (KM) Server manages a library of all user public keys and 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, you need Exchange Server up and running. Although KM Server is part of Exchange Server and does not cost extra, Exchange Server's setup program does not install it. You run KM Server's setup program (setup.exe) from the Exchange Server CD-ROM in directory \setup\i386\exchkm.
Once installed, the KM Server provides certificate authority for creating and signing certificates, a public key server for managing distribution of public keys to any client in the enterprise that needs them, and Certificate Revocation List (CRL) management for listing and searching for compromised keys. A key is compromised when the private half of a public/private key pair is no longer private because someone has discovered it or been exposed to 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 must enter the system security key every time you restart the Server (i.e., every time you reboot). This necessity is a serious inconvenience after a power failure when the server automatically restarts. The easy way to enter the system security key is by using the diskette with the copied system security key. But remember that the computer this server runs on needs ample CPU resources because some functions are very CPU intensive. If this system security key is on an underpowered computer, you can have a bottleneck in a large system. (As I write 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 latest Service Packs to get important bug fixes.)
After you install KM Server, you have to enable security for each user who will have advanced security. You must generate two public/private key pairs for each user and create digitally signed certificates that incorporate those public keys. 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 name to view and edit Properties for the user. Select Security and then Enable Security. This process generates a 12-character security token, such as XPQEYRUGTSYR, which you must give to the user in a secure way--not by nonsecure email.
To complete the process, on the Exchange Client main window, the user must select Tools/Options. In the options property sheet, the user then selects the Security tab. On the Security page, the user clicks the Set Up Advanced Security button and enters the security token that you supplied. Next, the user chooses and enters a security password that can differ from the email password. The user receives a message that notification will soon arrive to confirm that security is enabled. (The computations for generating the key pairs typically take 30 seconds to several minutes.) When the user receives a special email message that delivers the cryptographic key material to the Exchange Client, the user must enter the new security password.
The Server's special message contains two public/private key pairs: one pair for digital signing and one for encrypting. Exchange Client stores private keys securely on the local disk for future use. Not only is a password necessary to retrieve a private key, but Exchange Client stores the private keys in encrypted form (by means of a secret key-encrypting key, known only to the Exchange Client) to prevent someone from using a debugger or hexidecimal dump utility to look at the programs in memory or the files on your disk--either in person 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 them to encrypt a message or validate a signed message. When you finish reading this special 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 access Digitally Sign Message. Exchange Client retrieves your private key from the local disk and generates a digital signature to send with the message content.
To encrypt, or scramble, the contents of a message, click Seal Message with Encryption. Exchange Client will retrieve the recipient's public key from 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). You click the Send button to transmit the encrypted message key and the encrypted message.
When you receive a digitally encrypted message, the message icon will be an envelope with a small padlock on the first view line for the message. Click the message line. You supply your security password to retrieve your private key from the local disk and decrypt the key and the message. (To avoid entering your password every time, by checking Remember, you can request that the client remember it for the next time you need the private key. The client will recall your password until you terminate that session.)
When you enter the correct security access password, the client retrieves the private key from the local disk and decrypts and displays the original message. At this point, the KM Server is not consulted and therefore the CRL--the disavowed list--is not checked. Every time you view the message, you must re-decrypt it. Of course, if you print or save the message while it is decrypted in the viewer, the printout and saved version are not secure.
When you receive a digitally signed message, the message icon will be an envelope 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 the sender's public key to open the message.
A new toolbar icon, Read Digital Signature, appears in the Read Message window toolbar to show that the message was signed and to let you validate the signature. When you click this button, you must enter your security password (unless you previously requested that Exchange Client remember your password). Then Exchange Client will retrieve the sender's public key from the KM Server, search the CRL, and display the following information:
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, which means that signature's security was compromised. The other items are self-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, keep in 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 Internet mail client through the Internet Mail Connector, the message header and body go through, but the signature is stripped off completely. Although you can convince an Exchange Client to send a secure message to an Internet user, no Internet mail client can unscramble an encrypted message or validate a signed one that you create with Exchange Client because its syntax is proprietary.
Exchange Server offers good support for encryption and digital signatures and has done a good job of hiding the complex details from the user. But these advantages are shadowed by limiting use to within a given enterprise and only to Exchange Client users. Although Microsoft has supported some emerging standards, the proprietary nature of the system makes interoperating with the emerging standards for secure Internet mail (e.g., S/MIME) impossible. What remains to be seen is whether Microsoft's market clout can overcome this serious problem as the industry continues to evolve. For more information about secure Exchange email, see the sidebar, "Additional Reading."
Microsoft Exchange Server 4.0 online manuals and internal help