Microsoft Exchange 2000 Server Adminstrator's Companion

A PKI deployment involves several basic components. A solid understanding of how these components work is essential to setting up good, basic network security. You can think of the PKI as a collection of resources that work together to provide a secure messaging authentication system. The major components of the Windows 2000 PKI are as follows:

• Certificate Services
• Digital certificates
• Policies to manage the certificates
• Microsoft CryptoAPI and cryptographic service providers (CSPs)
• Certificate stores for storing certificates

This section discusses these components and how they work together to ensure solid Exchange 2000 messaging security. It starts by looking at encryption and public key/private key technology, followed by a description of encryption schemes. Finally, it discusses Certificate Services and the use of certificates.

Encryption and Keys

Basic security starts with encryption. Encryption is the process of scrambling data before sending it over a medium. Encrypting data before sending it to another person makes it much more difficult for a would-be interceptor to read the data than if it was in plain text. Hence, the sender will then scramble, or encrypt, the data with a structure called a key. Encryption technology uses two types of keys: symmetric keys and asymmetric keys.

Symmetric keys, also known as shared keys, are identical: both the sender and the recipient use the same key to encrypt and decrypt the data. Asymmetric keys are not identical: one key is used to encrypt the data and a different key is used to decrypt it. With asymmetric keys, one key is known as the public key and the other is known as the private key. Exchange 2000 Server uses this type of encryption technology.

The public key is often made public by being published in some central place, such as a public folder or Active Directory directory service. The private key must be secured so that no one but the owner of that key has access to it. A pair of public and private asymmetric keys is generally referred to in cryptography as a key pair.

With key pairs, either key can encrypt or decrypt the data, but the corresponding key is required to perform the opposite function, whether that is encrypting or decrypting. If the key that decrypts the data is not available, the encrypted data will remain encrypted and is, essentially, useless unless the key can be found and employed. Although in theory, either key can perform either function (for example, a private key can be used to encrypt and the public key used to decrypt), Windows 2000 and Exchange 2000 Server implement this technology by having the public key perform the encryption while the private key is used for decryption.

Hence, in Exchange 2000 Server, we are not concerned if someone has our public key, because they can only encrypt data with it. However, the private key must be kept secure, because it is the private key that can decrypt data. The best way to keep a private key secure is to never send it over a medium where a would-be hacker could capture it and use it.

The use of one key to encrypt (the public key) and a different key to decrypt (the private key) forms the foundation of Certificate Services. Table 21-1 summarizes the key types and when they are used.

Table 21-1. Private and public key usage

Encryption Schemes

Encryption allows a message to be sent via an insecure channel, such as the Internet, safely. The entire message, including attachments, is encrypted. How is data encrypted? A mathematical function called a key is applied to the data, changing it into an unreadable form. Hence, plain text becomes encrypted, or cipher, text. The strength of an encryption describes how difficult the encryption is to break, or decrypt. The length of the key determines the encryption strength. Here are some numbers to consider:

8-bit key      = 2⁸ keys       =256 keys

56-bit key    = 2⁵⁶ keys     =72,057,594,037,927,936 keys

128-bit key   = 2¹²⁸ keys    =3.4 x 10 ³⁸ keys

A brute force attack attempting to break a 128-bit encryption and trying one trillion keys per second would take 10,819,926,705,615,920,821 years to break the key. Needless to say, 128-bit encryption is very strong. Table 21-2 lists some common encryption schemes.

Table 21-2. Common encryption algorithms

Certificate Services in Windows 2000

Public and private keys are not enough to guard your sensitive data. For instance, it is possible for someone to obtain your public key—and, by definition, it is available to anyone—and then impersonate a server with which you're communicating. This is easily done if the impersonator is a person internal to your organization. In this scenario, you might believe that you're communicating with Server1 when in fact you're communicating with someone else. Certificate Services is designed to protect against this type of attack.

Windows 2000 certificates form the core of the Windows 2000 public-key infrastructure. You can install Windows 2000 Certificate Services to create a certificate authority (CA) that issues and manages digital certificates. Active Directory maintains information that a CA needs, such as user account names, group memberships, and certificate templates, as well as information about each CA installed in the domain. Active Directory also maintains certificate mappings to user accounts for authenticating clients and controlling access to network resources.

Digital Certificates and the X.509 Standard

Digital certificates verify a user's identity. They are issued by the CA (discussed later in the section "Certificate Authority"). We can trust digital certificates because we trust the source of the certificate, the CA. In addition to issuing the certificate itself, the CA by default creates any public key/private key pair, which is the basis of security in any digital certificate.

Digital certificates generally follow the X.509 standard, which means that they meet the standard criteria for electronic certificates outlined in the X.509 standard. Typically, an X.509 certificate incorporates the following fields:

• Version number
• Serial number of the certificate
• Signature algorithm ID
• Name of the person to whom the certificate was issued
• Expiration date of the certificate
• Subject user name
• Subject public-key information
• Issuer unique ID
• Subject unique ID
• Extensions
• Digital signature of the authority that issued the certificate

SSL/TLS also conforms to the X.509 standard. In Windows 2000, external users' digital certificates can be mapped to one or more Windows 2000 user accounts for permissions to network resources. Windows 2000 then uses the Subject field (the subject user name in the list of fields just given) to identify the user associated with the certificate. In this way, Windows 2000 and Microsoft Certificate Services can map an external user to a user account stored in Active Directory.

The X.509 Standard

The X.509 standard describes two levels of authentication: simple authentication, using a password as the only verification of a claimed identity, and strong authentication, using credentials generated by cryptographic technologies. The standard recommends that only strong authentication be used as a basis for providing secure services.

The strong authentication method specified in the X.509 standard is based upon public-key technologies. The one huge advantage of this standard, and the reason why it is so popular today, is that user certificates can be held within Active Directory as attributes and can be communicated within the directory systems like any other attribute of a user account.

While the X.509 standard does not require the use of a particular algorithm to produce the certificates, it notes that for two users to communicate, they must use the same algorithms during authentication.

Certificate Authority

A certificate authority (CA) issues certificates and enables parties to trust each other. The CA's private key is used to sign the certificate, and the certificate is needed to verify the signatures. Because certificates originate from a verified authority, the receiving party can explicitly trust them. For example, a client application can import a certificate to be trusted by a user who is reading data from the application.

Clients and CAs can maintain a list of explicitly trusted certificates. Certificates can also be placed on a certificate revocation list (CRL), which lists certificates that are explicitly distrusted. In addition, they can be set to expire after a predetermined amount of time.

Certificate Services Architecture in Windows 2000

Figure 21-1 illustrates the components of Windows 2000 Certificate Services. These components work together, in cooperation with Microsoft CryptoAPI and the cryptographic service providers, to perform all of the tasks necessary to generate, store, and apply certificates in the enterprise. You can manipulate these objects and modules in the Certification Authority snap-in. For information on how to install this snap-in, see the section "Installing and Configuring Certificate Services" later in this chapter.

Figure 21-1. Components of Certificate Services.

Entry Module

Certificate requests—such as when a user submits a certificate request via the Web enrollment support page—enter the Entry module of Certificate Services, either through remote procedure calls (RPCs) or HTTP. The requests are placed in a pending queue until they are approved or rejected by the Policy module.

Policy Module

The Policy module determines whether a certificate request should be approved, denied, or left pending for an administrator to review. Once the certificate is approved, the Policy module can verify information in the request against various sources, such as Active Directory or an external database. Additional attributes or extensions can be inserted into the Policy module if a customized client application requires them. For example, a signing limit can be inserted into certificates and used by an online purchasing form to determine whether the user can sign for the amount requested.

Certificate Templates

Certificate templates define the attributes for certificate types. You can configure enterprise CAs to issue specific types of certificates to authorized users and computers. When the CA issues a certificate, a certificate template is used to specify its attributes, such as the authorized uses for the certificate, the cryptographic algorithms that are to be used with it, the public-key length, and its lifetime. Certificate templates are stored in Active Directory. Table 21-3 lists the standard certificate types.

Online certificate templates are used to issue certificates to requestors that have Windows 2000 accounts and that support obtaining certificates directly from an enterprise CA. Offline templates are used to issue certificates to requestors that don't have Windows 2000 accounts or that don't support obtaining a certificate from an enterprise CA.

When a CA issues an online certificate, it obtains information about the requestor from the requestor's Windows 2000 account for inclusion in the certificate. When it issues an offline certificate, it includes in the certificate the information that the requestor entered as part of the request, such as a user name, e-mail address, department, and so forth that the requestor entered into a Web form.

Table 21-3. Certificate types

Certificate Database

The certificate database records all certificate transactions, such as certificate requests. It records whether requests were granted or denied, and it also holds information about the certificate, such as its serial number and expiration date. Revoked certificates are flagged and tracked in this database as well. You'll use the Certificate Authority snap-in to manage the audit trail.

Exit Modules

Exit modules send the certificate to the location specified in the request. Acceptable destinations include LDAP directory services, file systems, and URLs. You can create customized exit modules so that new certificates are sent in e-mail messages or to a public folder on the network. There can be many or few exit modules, depending on your needs. Modules can be written in the Component Object Model (COM) interface to allow any entity or directory to be notified when a certificate is issued. In fact, you could write an exit module to notify a database of a new certificate, for billing purposes.

Brief Summary of Security Objects

At this point, you might be a bit confused as to what we've covered and where a given certificate, key, or file is located. Table 21-4 summarizes this information.

Table 21-4. Location of security objects