Microsoft Exchange Server has always provided the Advanced Security subsystem to let users secure their mail messages. Advanced Security guarantees confidentiality and message content integrity and verifies the sender’s authenticity. Advanced Security provides end-to-end message security from the moment the sender signs and encrypts the message until the receiver reads it. The message stays encrypted even in Exchange Server’s Information Store (IS) or in a user’s personal folders. Microsoft builds Advanced Security around the optional Key Management Service (KMS). For now, I want to discuss Microsoft Exchange 2000 Server’s KMS version and review the key differences between the new KMS and its Exchange Server 5.5 predecessor. In part 2 of this series, I’ll provide more information about Microsoft Outlook 2000’s and Outlook Express 5.0’s Secure MIME (S/MIME) features.
KMS Basics and Interoperability
From the beginning, Advanced Security has included a unique key recovery feature that lets you recover copies of users’ lost or deleted encryption keys. Don’t confuse key recovery with key escrow: Key escrow deals with government access to encrypted user data, whereas key recovery deals with users’ access to their encrypted data.
In Advanced Security, key recovery is server-oriented. The KMS database contains copies of each Advanced Security-enabled user’s current and previous private encryption keys. This method of key storage explains the use of a dual-key-pair system, in which users have one key pair for encryption and another pair for signing. Advanced Security couldn’t guarantee trustworthy digital signature services if it used only one key pair and stored the pair’s private key in the KMS database for key recovery purposes. Digital signatures require that users can access only their private signing keys (otherwise, anyone could impersonate a particular user). Therefore, Exchange Server stores the signing pair’s private key only on the client side. The server-oriented approach requires more administrative overhead. Administrators must enroll users in Advanced Security, put a regular KMS database backup scheme in place, and recover users’ encryption keys when necessary.
The Exchange Server KMS has evolved to deliver practical secure messaging. Originally, the KMS generated X.509 Version 1 certificates. An important change occurred in Exchange Server 5.5 Service Pack 1 (SP1). Beginning with SP1, you can outsource certificate generation to Microsoft Certificate Server (which generates X.509 Version 3 certificates). In this scenario, the KMS becomes a Registration Authority. In public key infrastructure (PKI) terminology, a Registration Authority performs all certificate administration tasks, with the exception of generating and revoking certificates. (A Certificate Authority—CA—is responsible for certificate generation and revocation.) A Registration Authority identifies users and generates certificate requests. The KMS’s evolution is the first step toward Advanced Security’s complete integration into an enterprise PKI.
Open standards support is extremely important for interoperability. Advanced Security uses X.509 certificates (an International Telecommunications Union Telecommunication Standardization Sector—ITU-T—standard that defines a certificate format) and S/MIME (an Internet standard for secure messaging). S/MIME is an excellent example of a hybrid cryptographic solution: It bundles the powers of asymmetric and symmetric ciphers and hashing. In June 1999, the Internet Engineering Task Force (IETF) standardized S/MIME 3.0 in Requests for Comments (RFCs) 2632 through 2634. An important interoperability topic is Advanced Security’s support for dual key pairs: Remember that not all vendors’ S/MIME products support the dual-key-pair system. I’ll provide more information about secure messaging standards in part 2.
KMS Architecture
The basic Exchange 2000 KMS architecture is identical to that of its predecessor. The new KMS still uses a private JET database (kmsdir.edb) to store the KMS administrator accounts and passwords as well as users’ private-encryption-key, signing, and encryption-certificate histories. The Exchange 2000 KMS still derives a key from the KMS database startup password and uses the key to encrypt and decrypt the JET database. You must manually enter the password as a startup parameter at every KMS startup, or you can put the password on disk to partially automate the startup. The Exchange 2000 KMS offers a new option that lets you change the database startup password; this feature offers enhanced security. To change the password, right-click the Key Manager object and select All Tasks, Change Startup Password.
To enable strong 128-bit KMS database encryption, the new KMS still uses the Exchange-specific Cryptographic Service Provider (CSP). The Exchange 2000 System Attendant (SA) still functions as a buffer that stores KMS-related user requests in case the KMS goes offline. For example, when the KMS is offline while a user enrolls in Advanced Security, the SA buffers the user’s request for a signing certificate until the KMS comes back online.
Thanks to the directory integration between Exchange 2000 and Windows 2000 (Win2K), Active Directory (AD) now stores certificates, certificate revocation lists (CRLs), and encryption preferences. (I address CRL storage and publication in more detail in "Active Directory Integration.")
To enable the Exchange 2000 KMS to use X.509 Version 3 certificates, you can link the KMS with Certificate Server. You no longer need to install the special CA policy module (expolicy.dll) on Certificate Server—the policy module included with Win2K Certificate Server already understands Exchange 2000. For compatibility with S/MIME clients of Outlook 97 and earlier, the new KMS still supports X.509 Version 1 certificates. To enable the KMS to generate X.509 Version 1 certificates, double-click the Key Manager object, enter the KMS administrator password, go to the Enrollment tab, and select the I have Outlook 97 or older clients in my organization. Issue Version 1 and Version 3 certificates check box, as Screen 1 shows. At user enrollment, the KMS automatically detects the client’s capabilities. Then, the KMS either generates an X.509 version 1 certificate (for Outlook 97 clients) or generates an X.509 Version 1 certificate and passes a request to Certificate Server for an X.509 Version 3 certificate (for Outlook 98 or later clients).
Advanced Security Server-Side Installation
You need to install Win2K, Exchange 2000, AD, and an operational Win2K CA before you can install Exchange 2000 Advanced Security. The latter requirement represents a major difference between the Exchange 2000 KMS and earlier versions. You must integrate the CA with AD (Microsoft calls this integration an Enterprise CA) and load the Machine Enrollment Agent, Exchange User, and Exchange User Signature certificate templates. (I refer to a CA loaded with these templates as a KMS-CA.) Win2K certificate templates provide a flexible way to determine which certificate types a CA can issue. The Machine Enrollment Agent certificate type lets machines request certificates on behalf of other entities—exactly what the Exchange 2000 KMS needs because one of its primary functions as Registration Authority is to request S/MIME certificates on behalf of Exchange 2000 users. The Machine Enrollment Agent, Exchange User, and Exchange User Signature certificate templates have been available out-of-the-box since Win2K Release Candidate 2 (RC2).
Exchange 2000 comes with a new installation wizard. To install the KMS from the installation wizard, expand Microsoft Exchange 2000 in the Component Selection dialog box, expand Microsoft Exchange Messaging and Collaboration, select Microsoft Exchange Key Management Services, and click Install in the left column, as Screen 2 shows. As in earlier versions of Exchange Server, you can choose between 3.5" disk and manual KMS-startup mode during KMS setup. The installation process creates a new Win2K global group called Exchange KMServers and issues a Machine Enrollment Agent certificate to your Key Management (KM) Server. The installation process also changes AD’s Configuration Naming Context to reflect organizational changes related to Exchange 2000 Administrative Groups.
The Exchange KMServers group facilitates the management of some KMS-CA-related access control settings. The Exchange KMServers group contains the machine account of each server that runs the KMS. In Exchange 2000, every service uses the Local System Account, which in turn uses the machine credentials (i.e., the machine account and password). In short, the new KMS uses the machine credentials to authenticate the KMS to other services when accessing resources—a fundamental change from Exchange Server 5.5. Exchange 2000’s machine account feature avoids the inconveniences associated with using an administrator’s user account as a service account, such as a password expiring after an administrator leaves the company. The machine account feature also offers better password-quality and password-change-interval security.
An Exchange 2000 Administrative Group is a logical grouping of Exchange 2000 objects; you use the Administrative Group to delegate administration. When you install the KMS on an Exchange 2000 machine, you’ll notice that the KMS extends your AD schema and adds the Advanced Security container to each Administrative Group in your Exchange Server organization. Unlike Exchange Server 5.5 (in which each site can contain one KM Server), the Exchange 2000 KMS now links to an Administrative Group, and each Administrative Group can contain one KM Server. To enable Advanced Security (i.e., S/MIME) capabilities for all the mailboxes in your Exchange Server organization, you need to install the KMS on at least one of your Exchange 2000 servers. In a multinational Exchange Server organization that contains multiple sites, one KM Server might suffice. However, you might decide to install multiple KM Servers to speed up administration or for political reasons (e.g., a subsidiary doesn’t like the idea of the organization administering the S/MIME settings from a central location abroad). Following Microsoft scalability shouldn’t be a concern, unless you plan to enroll more than 100,000 users in Advanced Security.
The Advanced Security container that Screen 3 shows can include two objects: the Encryption Configuration object and the Key Manager object. The latter object is available only in Administrative Groups containing a KM Server. The Encryption Configuration object is available in every Administrative Group; the administrator can set different encryption preferences for each group.
Like the Exchange Server 5.5 KMS, the new KMS differentiates between Exchange Server 5.0 or 4.0 and S/MIME (or post-Exchange Server 5.0) secure messaging settings in the Encryption Configuration settings. At first glance, the Exchange Server and S/MIME categories refer to Exchange Server-related secure mail operations, but in truth they refer to client-side secure mail operations (all secure-mail-related cryptographic operations on messages happen on the client side). The difference between the two settings is the client-side support for the encryption algorithms used in the S/MIME protocol or in the Exchange Server 5.0 or Exchange Server 4.0 secure messaging protocol (which is a proprietary protocol that Entrust Technologies developed). The encryption algorithm that the client software chooses for the encryption of a mail message depends on the client-side software version and the preferred encryption algorithm.
The client-side software version. As of this writing, Outlook comes in a North American and an international version. Microsoft provides stronger encryption algorithms for the North American version than for the international version because US export laws prohibit the exportation of encryption software that uses key lengths longer than 56 bits. You can use Server Gated Cryptography (SGC) to export 128-bit encryption outside of North America only for e-commerce and for the applications listed in the US Cryptography Law Exception List—not for the encryption of regular email messages. Recent changes to US export laws might soon result in changes to international encryption standards. (For more information about the US encryption export policy, see the US Department of Commerce, Bureau of Export Administration’s Web site at http://www.bxa.doc.gov/encryption/qanda.htm.)
The preferred encryption algorithm. The Exchange Server administrator can set the preferred encryption algorithm in each Administrative Group’s Encryption Configuration object. When multiple algorithms are available on both the sender side and the receiver side, the client software chooses the preferred encryption algorithm set in the Administrative Group to which the client’s mailbox belongs. Because stronger algorithms require more processing power on the client side, choose the least-processor-intensive encryption algorithm (e.g., Data Encryption Standard—DES—is less processor-intensive than Triple DES—3DES) for environments in which encryption strength isn’t crucial.
Before sending an S/MIME message, each Advanced Security-enabled client queries the AD for each recipient’s encryption capabilities. To secure the message, Advanced Security uses an encryption algorithm and a key length that every recipient supports. Remember that an Advanced Security-enabled client can always send a signed message, but to send an encrypted message the client must first receive a signed message (which comes with the recipient’s encryption certificate and public key) from the intended recipient.
After you install the KMS, you need to give the Exchange KMServers group permission to read and manage the CA object. You can grant these permissions from the CA container’s security properties in the Microsoft Management Console (MMC) Certificate Authority snap-in. The KMS service account needs these permissions to revoke certificates on behalf of the KMS administrator.
The certificate templates are regular AD objects linked to an ACL. To enable the KMS to enroll for Exchange 2000 certificates, you must add the Exchange KMServers with Enroll permission on every template. Open the MMC Sites and Services snap-in, and select the Show Services Node from the View menu. Double-click the Services container and the Public Key Services container, then select the Certificate Templates container. Right-click the appropriate certificate template from the right pane, select the Security tab, and change the permissions as necessary.
Certificate Server Integration
I already mentioned that you must load an Enterprise Certificate Server to use the KMS in your corporate Exchange 2000 environment. Look at the properties of your CA object (in the MMC Certificate Authority snap-in), or run the command-line Certsrv tool with the -z switch to confirm that an Enterprise Certificate Server is installed. Screen 4 shows the output of the Certsrv tool. Notice that the CA issues two certificates for every user enrolled in Advanced Security. A fundamental difference exists between the Win2K Enterprise policy module and the policy module that Exchange Server 5.5 uses to link the KMS to the CA: The Exchange 2000 KMS-CA can issue more than just Exchange 2000 certificates. In Exchange Server 5.5, you can’t issue any other certificate type after you install the Exchange Server policy module.
Win2K publishes Enterprise CAs in AD. Any client that can browse AD can access the location information of your corporate AD-integrated Enterprise CA servers. For the Exchange 2000 KMS, pointing the KMS to one fixed-certificate server (the way you do in Exchange Server 5.5) is unnecessary. If the KMS-CA goes down, the KMS automatically queries AD to find another CA—an important fault-tolerant, flexible feature that also removes the need for complicated KMS-CA rollover procedures.
The Win2K Certificate Server implementation includes other important enhancements over its Windows NT predecessor. (For more information about PKI in Win2K, see Tao Zhou, "Public Key Infrastructure in Windows 2000," January 1999.) Perhaps the most interesting enhancement is the ability to build multilevel CA hierarchies (Microsoft claims to support more than 40 levels). You can link one CA server to multiple KM Servers. Win2K also provides enhanced integration with other CA hierarchies: Your Win2K CA can be subordinate to a commercial (i.e., non-Microsoft) CA, although the KMS-CA must run Microsoft CA software. Such enhancements improve interoperability.
Active Directory Integration
A core change in Exchange 2000 is the integration of its directory and AD. Microsoft unifies Exchange 2000 directory objects and Win2K directory objects: A mailbox is now a mailbox-enabled user object, a custom recipient is a mail-enabled contact object, and a distribution list (DL) is a mail-enabled distribution group. The administration benefits are clear: You can set users’ security- and mail-related properties through one interface. Open the MMC Users and Computers snap-in, and double-click any user object to view its properties (including the Exchange Features settings), as Screen 5 shows. The new interface lets you enroll a user in Advanced Security, revoke a user’s certificate, and recover a user’s private encryption key.
Since Exchange Server 5.5 SP1, Advanced Security supports the definition of certificate trust lists. CTLs let you set up certificate-based security interoperability without the need for a hierarchical relationship between two CAs. Win2K implements CTLs through the Trusted Root Certification Authorities and Enterprise Trust Group Policy Object (GPO) entries. GPOs are new Win2K features that facilitate centralized computer administration. The Trusted Root Certification Authorities GPO entry contains certificates of CAs in your Win2K forest (Advanced Security automatically adds internal CAs to your internal clients’ root CA store). The Enterprise Trust GPO entry can contain certificates of trusted external CAs. A Win2K administrator must manually add these certificates. Through the transparent and automatic application of GPO settings, certificates of trusted CAs automatically download to a Win2K machine’s certificate store. Outlook 2000 still gets its CTL from the AD. The KMS creates this CTL from the corresponding GPO-CTL entries on the KM Server and publishes the CTL to the AD. Microsoft plans to fully support GPO-CTL settings in a future version of Outlook.
What about CRLs? The new KMS still maintains its CRL in the KMS database (kmsdir.edb) and publishes the CRL to the AD. The KMS needs this CRL to publish revoked X.509 Version 1 certificates and to let mail clients with Outlook 98 or earlier get a CRL. By default, the Win2K KMS-CA publishes its CRL to the AD and to the CA’s Web directory. The Exchange Server Advanced Security X.509 Version 3 certificates that the Win2K Enterprise Certificate Server issues also incorporate Win2K’s changes to automated CRL checking. Each certificate now includes pointers to CRL distribution points. CDPs have a key advantage: When the client software validates a certificate, the software can use the certificate’s CDPs to locate the appropriate CRL. By default, each certificate contains an LDAP pointer to the CRL in AD and an HTTP pointer to the CRL in the CA’s Web directory. To take advantage of CDPs, you need a mail client such as Outlook Express 5.0 distributed with Internet Explorer (IE) 5.0 or Outlook 2000. To enable CDP support in Outlook 2000, you must create the HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Cryptography\\{7801ebd0-cf4b-11d0-851f-0060979387ea\} Registry key, add the PolicyFlags Registry value, and set that value to 0x00010000. Another useful Win2K CA feature lets you set the CRL-publication interval from the Revoked Certificates container’s properties in the MMC Certificate Authority snap-in.
In Exchange Server 5.5, a distinguished name (DN) identifies each object. Because the DN contains the alias of a user’s mailbox, you can recover a user’s encryption keys, even when the directory no longer includes an entry for the user’s mailbox. If the SA creates a new mailbox with a similar name, the associated account inherits the old user’s key history. In Win2K, a globally unique ID (GUID) identifies every directory object within a Win2K forest. In Exchange 2000, a mailbox-enabled user object is bound to a GUID. Deleting a user also deletes the GUID, and you can’t reuse GUIDs. As a consequence, you can’t retrieve a deleted user object’s key and certificate history.
KMS Administration
To administer the KMS, you can use the MMC Exchange System Manager snap-in or you can start up Advanced Security as a standalone snap-in. Remember that you can enroll a single user from the MMC Users and Computers snap-in console.
In Exchange 2000, Microsoft removes the password memory feature in the Advanced Security administration interface. The password memory feature temporarily caches the administrator password in system memory so that you don’t need to enter the password every time you open a new dialog box in the KMS administration interface. This technique is risky: Intruders can recover in-memory passwords. Instead, Exchange 2000 includes a set of administrative tasks that you can perform in bulk (and for which you need to enter the administrator password only once): enrollment, revocation, recovery, bulk export, and bulk import. Exchange Server 5.5 supports only bulk enrollment. Microsoft also adds buttons at the top of the MMC Exchange System Manager snap-in to speed up administrative tasks.
You can perform bulk operations at three different levels: administrative group, server, or individual user, as Screen 6 shows. Exchange Server 5.5 provides bulk enrollment capabilities only at the container level. Exchange 2000 also remedies the performance problems that occur in large Exchange Server 5.5 bulk operations, such as slow system performance during bulk enrollment of more than 2000 mailboxes.
The ability to export and import user accounts and their key and certificate histories from one KMS database (kmsdir.edb) to another (i.e., from one administrative group to another) is an important Exchange 2000 enhancement that provides organizational flexibility. In Exchange Server 5.5, moving a user easily between sites is almost impossible: You must use the Microsoft BackOffice Resource Kit’s Sectool utility to bulk decrypt all the user’s mail, move the user's mailbox to the other site, reenroll the user, and use Sectool to bulk reencrypt the mail. Or you can use a more complex method: While connected to the old mailbox, export the user's keys and certificates (i.e., the KMS database entries for the user) to an .epf file. Then connect to the new mailbox and import the .epf file into Outlook. To facilitate the new export-import process, Exchange 2000 provides the Exchange KMS Key Export Wizard, which Screen 7 shows. The wizard uses the CA’s certificate to secure the export-import process, and you can run the import wizard only once (i.e., against one administrative group). The wizard logs the results of the export and import processes into the filename.explog and filename.implog files. An important technical detail: The wizard not only exports the user's record but also deletes it from the KMS database.
The Exchange 2000 KMS still supports the use of a missile-silo (or multiple-password) policy for important KMS operations, which means that the KMS requires the presence of more than one administrator’s credentials to perform a particular administrative task. In Exchange 2000, you can set multiple-password policies to add and delete administrator accounts, recover and revoke user keys, change the support for X.509 Version 1 or Version 3 certificates, and import and export user accounts. Don’t forget that the administrator accounts you use on the KMS level differ from regular Win2K accounts: Exchange 2000 stores the KMS accounts together with the associated password in the KMS database (the default password is password).
Microsoft has also enhanced the KMS backup. The KMS database is now part of the Win2K backup's Exchange Container, which allows online backups. You must back up the KMS and the KMS-CA at the same time to synchronize them at the certificate-revocation level.
The primary source of KMS troubleshooting information is the NT Event Viewer’s application folder. Exchange 2000 extends the number of logging entries and logs events such as updating CRLs or CTLs and enabling Advanced Security for user accounts.
Extended S/MIME Capabilities
In Exchange 2000, Microsoft has extended its S/MIME capabilities through the tight integration of AD and the Win2K Certificate Server, as well as through numerous KMS administrative ameliorations. How interoperable is Exchange 2000’s S/MIME implementation with other vendors’ implementations? We’ll find out in the months to come. Exchange 2000’s support for open standards is an ideal starting point.
