Understanding the Public-Key Infrastructure in Windows 2000

[Previous] [Next]

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/Decryption	Electronic Signatures
Sending Messages	Recipient's public key is used to encrypt message contents.	Sender's private signing key is used to apply the signature.
Reading Messages	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. 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

Encryption Type	Description
CAST	A 64-bit symmetric block cipher (which encrypts one block, or set length, of data at a time, rather than a byte) developed by Carlisle Adams and Stafford Tavares. It is similar to DES and supports keys between 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 method 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 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 Type	Description
Administrator	Used for authenticating clients and for Encrypting File System (EFS), secure mail, certificate trust list (CTL) signing, and code signing.
Authenticated Session	Used for authenticating clients.
Basic EFS	Used for EFS operations.
CEP Encryption	Used to enroll Cisco Systems, Inc. routers for IPSec authentication certificates from a Windows 2000 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 that 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 mail users.
Exchange Signature Only (offline request)	Used by Exchange Server for client authentication and secure mail (used for signing only).
Exchange User (offline request)	Used by Exchange Server for client authentication and secure mail (used for both signing and confidentiality of 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 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 mail (used for both signing and confidentiality of mail).
User Signature Only	Used for client authentication and secure mail (used for signing only).
Web Server (offline request)	Used for Web server authentication.

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

Type of Certificate	X.509 Certificate	Key Management Security Database	User's Personal Security Store	Exchange Directory Store
Signing certificate			X
Encryption certificate			X
Private encryption key		X	X
Private signing key			X
Public encryption key	X
Public signing key	X	X
Certificate expiration date	X
CA signature	X