Secure Mail

Standard Internet mail is sent as plaintext over open networks with no security. In today's increasingly interconnected network environments, the open nature of Internet mail poses many problems for mail security. Intruders can monitor your mail servers and network traffic to obtain proprietary or sensitive information. You also risk exposure of proprietary and confidential business information when you send mail over the Internet from within your organization. Messages sent over the Internet can be intercepted and read by eavesdroppers who are monitoring Internet traffic or even by legitimate administrators of the mail servers and connectors that process and route the messages.

Even in organizations with security policies that prohibit the exposure of proprietary business information on the Internet, employees sometimes forward their office mail over the public Internet to their personal mail accounts. Employees can also inadvertently send proprietary mail to the wrong mail alias or to a mail alias that includes the addresses of people who do not have a need to know the information in the message.

Another form of intrusion is impersonation. On IP networks, anyone can impersonate mail senders by using readily available tools to counterfeit the originating IP address and mail headers. When you use standard Internet mail, you can never be sure who really sent a message or whether the contents of the message are valid. Moreover, malicious attackers can use mail to cause harm to the recipient computers and networks (for example, by sending attachments that contain viruses).

For these reasons, many organizations have placed a high priority on implementing secure mail services that provide confidential communication, data integrity, and nonrepudiation. However, until recently, many of these secure mail systems have been proprietary or have not been scalable for global communication.

In Windows 2000, you can use secure mail to ensure the integrity of messages and to enable confidential mail communication within your organization.

Standards-based Mail Clients

The S/MIME Secure Mail working group of the IETF developed the open S/MIME standard to extend the original Multipurpose Internet Mail Extensions (MIME) standard. The S/MIME standard enables the digital signing and encryption of confidential mail. Secure mail can be exchanged between S/MIME clients that run on any platform or operating system. Secure mail clients can send S/MIME messages over the Internet without regard to the types of mail servers that handle the messages between the origin of the message and the final destination because all cryptographic functions are performed on the clients, not on the servers. Mail servers treat S/MIME messages as standard MIME. The only function of Internet mail servers is to route MIME messages; they do not alter the contents of messages in transit.

Microsoft supports S/MIME in the Microsoft® Outlook® 98 messaging and collaboration client as well as in Microsoft® Outlook Express version 4 and Outlook Express version 5. Microsoft is also working with the S/MIME Mail Security working group of the IETF, as well as with other vendors, to ensure maximum interoperability of Outlook 98 and Outlook Express with other S/MIME applications. Many of the other leading mail clients from third-party vendors also support S/MIME.

Secure mail with S/MIME uses the industry-standard X.509 version 3 certificates and public key technology. To provide message authentication data integrity, and nonrepudiation, secure mail clients can sign messages with the sender's private key before sending the messages. The recipients then use the sender's public key to verify the message by checking the digital signature. Clients require a valid secure mail certificate before they can send signed mail. Recipients must have a copy of the originator's secure mail certificate (which contains the public key) before they can verify the originator's signature.

In addition, secure mail clients can send and receive confidential mail. Clients generate random secret bulk (symmetric) encryption keys and use the secret key to encrypt messages for confidentiality. Then they protect the secret bulk encryption key by encrypting it with the public key of each recipient and sending the encrypted key along with the encrypted message to each recipient. Message originators must have a copy of the recipient's secure mail certificate (which contains the public key) before they can send confidential mail. Recipients use their private keys to decrypt the secret bulk encryption key; then they use the secret key to decrypt the message.

For more information about symmetric key encryption, public key encryption, and digital signatures, see "Cryptography for Network and Information Security" in this book.

Secure Mail Clients

By using secure mail, senders are assured that the integrity of their messages is preserved and that only the intended recipients can read the encrypted mail. Recipients are assured that the message is genuine and originated from the sender. For secure mail to work, each mail client must have a valid certificate for secure mail and each client must trust the root CA in the certification path of the other client's secure mail certificates. Certificates can be published in Lightweight Directory Authentication Protocol (LDAP) directories, public folders, and Web pages to facilitate the distribution of certificates and public keys. In Windows 2000, secure mail certificates are published to Active Directory for the user account that is issued a certificate. You also have the option of configuring Certificate Services to publish certificates to public folders, Web pages, or other LDAP-compliant directory services. Users with mail clients that support LDAP, such as Outlook 98 or Outlook Express, can browse directory services to locate and obtain the published certificates of others.

Secure mail clients must trust the certificates from other correspondents. You can configure secure mail for your organization to trust secure mail certificates that are issued by CAs in your organization or to trust secure mail certificates that are issued by third-party CAs. If you trust only the secure mail root CAs in your organization, secure mail communications are limited to transactions between employees. However, you can enable secure mail transactions with third parties by trusting their secure mail root CAs.

The strength of the encryption cryptography that is available for secure mail clients depends on the current export or import restrictions for cryptography that are required by many governments. The actual cryptographic strength that is available to your mail clients depends on the cryptography restrictions that apply for the locality where the mail clients are deployed and for the locality where the mail clients are installed. In general, mail clients with exportable technology provide much weaker security than mail clients with nonexportable cryptography.

You can deploy Certificate Services so that it issues secure mail certificates that work with S/MIME-compliant secure mail clients such as Outlook 98 or Outlook Express. You can deploy Web enrollment pages to enroll users and issue secure mail certificates.

In addition, you can use a mail service, such as the Microsoft® Exchange Server version 5.5 client/server messaging and groupware, to provide management services for secure mail. You can deploy Exchange Server and use the Key Management server (KM server) to manage secure mail certificate enrollment for Certificate Services. You can also use KM server to provide key recovery services as described in the following section.

For more information about trust for CAs and the certification path, see "Windows 2000 Certificate Services and Public Key Infrastructure" in this book.

Key Management and Key Recovery Services

Because the S/MIME secure mail standard is client-based, it does not specify key management or key recovery requirements. However, you can use a key management service, such as KM server, to provide secure mail recovery services for keys that are not used to sign messages. Key recovery services maintain copies of nonsigning private keys in a central, protected database, where only authorized security administrators can obtain copies of the keys and restore them to their owners when necessary. Keys are maintained and transmitted in a password-protected, encrypted format to ensure their confidentiality.

Important

When a copy exists of a private key that is used for digital signing, the integrity and the nonrepudiation provided by the signing key are compromised. If anyone else can gain access to and use the private key, they can impersonate the owner of the key. Then he or she could, for example, forge the digital signature and send counterfeit messages. Therefore, private keys that are used for digital signing should never be copied (exported) or stored in a key recovery system.

Without key recovery, an encrypted message that is sent to a user cannot be decrypted if the private key has somehow been corrupted or destroyed. For example, if a user's hard disk crashes and cannot be restored and the user has secure mail, other people can still send encrypted messages to the user. But if the private key cannot be restored, the user cannot read the encrypted messages. Therefore, the nonsigning private keys that are used for key recovery systems should be maintained in a protected database for at least the lifetime of the corresponding secure mail certificates. When the certificate expires, the public key cannot be used any longer to send secure mail.

The private keys for secure mail are used for encrypting secret bulk encryption keys for confidential mail and for the digital signing of messages. If you do not use a key recovery system, you can use one certificate for both confidential mail and signing mail. However, if you provide key recovery services, you must issue two certificates to users — one that is used only for confidential mail and the other that is used only for signing messages. The private key that is used for confidential mail can be exported and stored for key recovery. The private key that is used for signing mail cannot be exported and is not stored by the key recovery service.

Although the Windows 2000 public key infrastructure does not provide key recovery or dedicated certificate enrollment services for secure mail, Exchange Server 5.5 provides the KM server for managing certificate mail enrollment and for recovering private keys. The KM server maintains a protected key recovery database that contains all private keys for certificates that have been issued for secure mail. It stores private keys until the certificate expires or is revoked and the public key is no longer used. Administrators can use the KM server to recover private keys and securely restore the keys to their owners — for example, if the private key has been damaged on the owner's computer. Starting with Exchange Server version 5.5 Service Pack 1, the KM server uses Certificate Services to issue the secure mail certificates. Earlier versions of Exchange did not use Certificate Services; instead, the KM server issued the now obsolete X.509 version 1 certificates. To use Certificate Services with Exchange, install a CA, and then install the Exchange Policy module. The CA uses the Exchange Policy module to issue secure mail certificates upon receipt of valid requests for certificates from the KM server.

For more information about the Exchange Policy module and how to use Certificate Services with Exchange Server, see Certificate Services Help and Exchange Server Help.