Understanding the Public-Key Infrastructure in Windows Server 2003

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 Server 2003 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

Encryption and Keys

Basic security starts with encryption, which is the process of scrambling data before sending it over a medium. 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. Encrypted data is much more difficult for an interceptor to read than plain text data. 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 Server 2003 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 the 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 remains 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 Server 2003 and Exchange Server 2003 implement this technology by having the public key perform the encryption while the private key is used for decryption.

In Exchange Server 2003, someone having our public key is not a concern, because that individual can only encrypt data with it. However, the private key must be kept secure, because the private key decrypts the 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 25-1 summarizes the key types and when they are used.

Table 25-1: Private and public key usage

Action	Encryption/Decryption	Electronic Signatures
Sending a message	Recipient’s public key is used to encrypt message contents.	Sender’s private signing key is used to apply the signature.
Reading a message	Recipient’s private key is used to decrypt the message contents.	Sender’s public signing key is used to interpret the applied signature.

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. 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 = 28 keys = 256 keys

56-bit key= 256 keys= 72,057,594,037,927,936 keys

128-bit key= 2128 keys= 3.4 x 1038 keys

Attempting to break a 128-bit encryption and trying one trillion keys per second would take 10,819,926,705,615,920,821 years. Needless to say, 128-bit encryption is very strong. Table 25-2 lists some common encryption schemes.

Table 25-2: Common encryption algorithms

Encryption Type	Description
CAST	A 64-bit symmetric block cipher (which encrypts one block, or set length, of data at a time, rather than one byte) developed by Carlisle Adams and Stafford Tavares. It is similar to DES and supports key strengths of 40 bits and 128 bits.
DES	Data Encryption Standard. Developed by IBM for the government for use by the National Institute of Standards and Technology (NIST). This standard uses 56-bit keys with a 64-bit symmetric block cipher. It is the most commonly used encryption algorithm.
3DES	Triple DES; encrypts the data structure three separate times.
DH	The Diffie-Hellman approach for passing symmetric keys.
KEA	Key Exchange Algorithm. An improved version of Diffie-Hellman.
MD2	Message Digest. An algorithm that creates a 128-bit hash value. It was developed by Ron Rivest of RSA (Rivest, Shamir, and Adleman).
MD4	Another RSA algorithm that creates a 128-bit hash value.
MD5	A better version of MD4.
RC2	Rivest’s Cipher, a 64-bit symmetric block cipher.
RC4	An RSA stream cipher (which encrypts one byte or bit at a time) that can use variable-length keys. Microsoft’s implementation of RC4 uses either a 40-bit or 128-bit key.
RSA	A commonly used public/private key encryption scheme developed at RSA.
SHA	Secure Hash Algorithm, developed at NIST. It produces a 160-bit hash value and is similar to MD5, but more secure and thus slower.

Certificate Services in Windows Server 2003

Public and private keys are not enough to guard your sensitive data. For instance, someone can obtain your public key (by definition it is available to anyone) and then impersonate a server with which you’re communicating. An impersonator can easily do this if he or she is in your organization. In this scenario, you might believe that you’re communicating with Server1 when in fact you’re communicating with a different server. Certificate Services is designed to protect against this type of attack.

Windows Server 2003 certificates form the core of the Windows Server 2003 public-key infrastructure. You can install Windows Server 2003 Certificate Services to create a certificate authority (CA) that issues and manages digital certificates. Active Directory can maintain 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 and 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 the 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 it. 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 Server 2003, external users’ digital certificates can be mapped to one or more Windows Server 2003 user accounts for permissions to network resources. Windows Server 2003 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 Server 2003 and 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.

Although 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

As mentioned earlier, a certificate authority 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 Server 2003

Figure 25-1 illustrates the components of Windows Server 2003 Certificate Services. These components work together, in cooperation with CryptoAPI and the cryptographic service providers, to perform all 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 about how to install this snap-in, see the section “Installing and Configuring Certificate Services” later in this chapter.)

Figure 25-1: Components of Certificate Services.

Entry Module

Certificate requests—such as those a user submits 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 25-3 lists the standard certificate types.

Table 25-3: Certificate types

Certificate Type	Description
Administrator	Used for authenticating clients and for Encrypting File System (EFS), secure e-mail, certificate trust list (CTL) signing, and code signing.
Authenticated Session	Used for authenticating clients.
Basic EFS	Used for EFS (Encrypting File System) operations.
CEP Encryption	Used to enroll Cisco Systems, Inc. routers for Internet Protocol Security (IPSec) authentication certificates from a Windows Server 2003 CA.
Code Signing	Used for code signing operations.
Computer	Used for authenticating clients and servers.
Domain Controller	Used for authenticating domain controllers. When an enterprise CA is installed, this certificate type is installed automatically on domain controllers to support the public-key operations that are required when domain controllers are supporting Certificate Services.
EFS Recovery Agent	Used for EFS encrypted-data recovery operations.
Enrollment Agent	Used for authenticating administrators who request certificates on behalf of smart-card users.
Enrollment Agent (Computer)	Used for authenticating services that request certificates on behalf of other computers.
Exchange Enrollment Agent (offline request)	Used for authenticating Microsoft Exchange Server administrators who request certificates on behalf of secure e-mail users.
Exchange Signature Only (offline request)	Used by Exchange Server for client authentication and secure e-mail (used for signing only).
Exchange User (offline request)	Used by Exchange Server for client authentication and secure e-mail (used for both signing and confidentiality of e-mail).
IPSec	Used for IPSec authentication.
IPSec (offline request)	Used for IPSec authentication.
Root Certification Authority	Used for root CA installation operations. (This certificate template cannot be issued from a CA and is used only when installing root CAs.)
Router (offline request)	Used for authentication of routers.
Smart Card Logon	Used for client authentication and logging on with a smart card.
Smart Card User	Used for client authentication, secure e-mail, and logging on with a smart card.
Subordinate Certification Authority (offline request)	Used to issue certificates for subordinate CAs.
Trust List Signing	Used to sign CTLs.
User	Used for client authentication, EFS, and secure e-mail (used for both signing and confidentiality of e-mail).
User Signature Only	Used for client authentication and secure e-mail (used for signing only).
Web Server (offline request)	Used for Web server authentication.

Online certificate templates are used to issue certificates to requestors that have Windows Server 2003 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 Server 2003 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 Server 2003 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 into a Web form, such as a user name, an e-mail address, and a department.

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 Certification 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.