Planning Your Encryption Infrastructure

PKI adoption has been pretty slow for two primary reasons: PKI tools have been expensive and hard to manage, and it’s been difficult to make signed and encrypted mail flow properly between organizations using different tools. Microsoft has been working hard to address the difficulty and expense of deploying PKI; you can build a complete PKI without buying anything other than Windows 2000 Server, Exchange 2000, and Microsoft Outlook 2002. However, deciding what you want to do with your PKI is critical because that decision will influence how many and what kind of CAs you use, how you manage your certificate trust relationships, and who gets certificates for what purposes.

Detailing Your Specific PKI Goals

The first step in planning and executing a successful PKI is to decide what you want to achieve by deploying it. This step of the process generally involves answering some simple questions:

• What do you want to use certificates for: encryption, authentication, or both? Do you want to provide other PKI-based services like smart card logons, or are you only securing e-mail?

• Who administers the PKI, and do you need to delegate management? Can users request certificates themselves?

• Will certificates be used only to secure internal traffic, or do you want to use them when communicating with the outside world?

As with any complex technology, you have to look at the big PKI picture before you get too far into the design phase. In this book, our primary focus is on protecting messaging systems, but digital certificates can be used for many other purposes, including access control for users and Web sites, IP Security (IPsec), and IEEE 802.1x wireless authentication. There might already be projects (or at least efforts) within your organization that use, or will need to use, digital certificates. Accordingly, you should spend some time researching existing PKI deployment, particularly whether you already have any existing CAs or relationships with external CAs.

Choosing Certificate Usage

One important step in the planning process is figuring out what certificate purposes you want to allow. The CA-signed portion of a certificate includes a set of flags that indicate for what purposes the certificate can be used. Windows 2000 and later versions support a broad set of purpose flags, including flags that allow certificates to be used for the following:

• Message and document encryption Secure Multipurpose Internet Mail Extensions (S/MIME) encryption works as described in Chapter 2: the sender’s computer generates a random session key, uses it to encrypt the message with a symmetric algorithm, then encrypts the session key using the recipient’s public key. Some organizations don’t want their users to be able to encrypt mail, hence the existence of this flag.

• Message and document digital signatures S/MIME signatures also work as described in Chapter 2: the sender computes a message hash and encrypts it with his or her private key, so that anyone with his or her certificate (which, as you recall, contains his or her public key) can independently recompute and verify the hash.

• Smart card logon Windows 2000 and Windows XP come with built-in support for smart card authentication. Using PKI, a small credit-card-sized device can be associated with a user’s certificate. The card and associated personal identification number (PIN) code or password can then be used instead of a logon name and password to gain access to the network. A smart card can be inserted into a smart card reader to sign a message, log onto a workstation with a domain account, or even gain access from a remote or wireless device. In general, Exchange and Outlook can use smart cards anywhere they would use a “regular” certificate.

• Software code signing Authenticode is a digital signature process that instructs Microsoft clients to examine the publisher of ActiveX, Java, and other active content before installation. Security settings can (and should) be applied so that only known and trusted publishers can be installed on systems. By signing the active content that your company makes, you can ensure that your active content is installed on desktops without user intervention. Normally you wouldn’t use end-user certificates for this; instead, you’d have a special CA certificate for code signing.

• Internet server and client authentication When establishing a Secure Sockets Layer (SSL) connection with a server, it is important to have a guarantee that the server that responds to your Hypertext Transfer Protocol (HTTP) request is the right server. For example, most online commerce sites use SSL to allow customers to verify that they’re really talking to the company’s server and not to some interloper. In other cases, it might be important for the server to verify the client’s identity before a secured connection is established. In these cases, certificates must be provided by the client machines for inspection.

• Insect As you learned in Chapter 11, “Securing Internet Communications,” IPsec doesn’t require PKI, but it can leverage certificates to make the network more secure. In non-Kerberos environments, the two devices would use a preshared key to encrypt and decrypt the communications. However, a more secure alternative is to use Kerberos authentication with machine certificates for authentication; once authenticated, the two ends can complete an IKE exchange to generate a managed asymmetrical key. This process reduces the chance that the secret key will become compromised, along with providing a better guarantee that each station is authentic.

  Tip

  Microsoft Office XP and later versions include tools for digitally signing and encrypting Microsoft Word, Microsoft PowerPoint, and Microsoft Excel documents, completely independent of whether or not you’re using S/MIME.

Management Requirements

The next thing that you need to do in planning for a PKI is determine your management requirements. These have an impact on the number, type, and location of your CAs. Do you need to delegate CA administration or certificate issuance to other departments or divisions, or will your certificates be managed by a central team? Do you wish to allow users to request their own certificates, or will some other entity handle that? Who will decide which other organizations’ CAs you trust?

Cross-Certification

Probably the most important question you need to ask is whether the certificates will be used for intracompany or intercompany purposes. More specifically, will you need to send encrypted messages, sign code, or publish servers on the Internet to people who do not belong to your company? The answer to this question will likely have the biggest financial impact on your design. If you want to communicate between organizations, you’ll have to enter the exciting (and sometimes challenging) world of cross-certification, the process whereby your PKI is enabled to trust certificates issued by some other CA. The most common way to build cross- certification is to use third-party CA services, which I discuss later in the chapter.

Designing Your CA Infrastructure

PKIs have to be designed; they can’t just be thrown together if you want them to provide good security and usability. Accordingly, you need to carefully design the CA infrastructure to reflect your current and future needs, budget, and security requirements.

The first CA infrastructure decision you must make is whether to outsource the PKI to a third party, build your own internal PKI, or do a little of both. Let’s go over the options.

Outsourcing Your PKI

One solution to the difficulties of PKI design and deployment is to make it someone else’s problem by outsourcing your PKI. Creating and maintaining an internal CA will add administrative overhead and in most cases additional server equipment. Some training will be required to bring the administrators up to speed with maintaining the certificates and the CA servers. Moreover, your internal CA will not automatically be trusted by other companies or Internet users; specific relationships must be established with the CAs from partners, customers, and others. In addition, client settings might need to be tweaked to establish a relationship with those divisions, partners, and companies so that your internal certificates can be used. There are other reasons why you might want to consider outsourcing your PKI environment, including these:

• The outsourced PKI will be managed by people who are trained in PKI. Your administrators will not need to become experts on the design aspect, as testing and implementation will be assisted by the outsourcing vendor.

• The experience and guarantees offered by external CAs should provide a stable, secure, and legal environment. Your company will not need to understand the legal implications of running a PKI, although you should review your chosen CA’s standards and practices very carefully and should always have access to PKI experts.

• An outsourced solution can be implemented on short notice because you don’t have to deploy any hardware or software. You might consider outsourcing while your internal PKI project builds an internal infrastructure.

There are several choices for outsourcing PKI depending on your needs and budget. Baltimore Technologies, Netscape, VeriSign, RSA, Entrust, and Thawte are some of the most popular. These companies offer outsourcing and some support mixed environments that allow you to bring some management and distribution tasks in-house.

Building Your Own PKI with Windows Certificate Services

Although outsourcing seems like an ideal way to get PKI’s benefits without any hassle, there are several drawbacks to outsourcing. First and foremost, it can be extremely expensive. Most PKI vendors charge a setup fee, plus a separate charge for each block of certificates. Because certificates expire, most PKI outsourcing companies sell only multiyear contracts, and many require a maintenance fee on top of everything else. It is not uncommon for a company that needs 1000 certificates to spend more than of $50,000 per year, plus management and setup fees, to outsource its PKI. Many organizations see this cost as prohibitive, and Microsoft is trying to exploit that by bundling its own robust PKI tools with Windows. Self-built PKIs are becoming increasingly popular for a variety of reasons:

• By implementing your own PKI infrastructure, your company can control the security levels you need to use for your environment. You can choose the length of your users’ keys, the validity period of their certificates, the revocation policy, and other security practices that you might not have control of with an outsourced solution.

• To provide smart card logon, you must publish your users’ certificates in Active Directory so that user accounts are tied to specific certificates. The easiest way to do this is to use the Windows 2000 Server or Windows Server 2003 Certificate Services. More generally, internal Windows CAs can be leveraged for all of the purposes described earlier—the CA publishes the certificates in Active Directory so they can be used by other Active Directory–aware services and applications.

• Windows 2000 and Windows Server environments support some types of automated enrollment and management. For example, Windows 2000 workstations can automatically enroll for machine certificates; with Windows XP clients and Windows Server 2003 CAs, you can choose to automatically issue user certificates as well.

• Integrating Active Directory with a PKI gives you some very nice management features: easy use of certificates for messaging, automatic enrollment, automatic or manual certificate approval, full replication of certificate revocation lists (CRLs) and certificate trust lists (CTLs), and management using the familiar Microsoft Management Console (MMC).

The cost advantage is pretty compelling, too. The CA is included with the Windows Server product family; there are no per-user, per-certificate, or time-based fees. Moreover, hardware requirements for Windows Certificate Services are minimal, so existing equipment could be used to host the stores and CA services.

Note

For the remainder of this chapter, I’m going to assume that you’ve chosen to build your own internal PKI environment. If you’re outsourcing, your PKI provider will have its own design process, which you might better understand by reviewing the following material. However, the majority of Exchange sites will probably be better off with their own internally managed PKI, so that’s what I focus on.

Standalone versus Enterprise CAs

Before you can begin installing and configuring Certificate Services, there are a few more decisions to make. One of the first choices you need to make during the installation process is what kind of CA you need to establish. The Windows Certificate Services package can operate in two modes:

• In standalone mode, the CA issues certificates and publishes them itself. All certificate requests must be approved by the CA administrator.

• In enterprise mode, the CA issues certificates and publishes them (along with CRLs and CTLs) in Active Directory.

The quickest, easiest way to put up an internal CA is to create a standalone environment. If you’re not using Active Directory, or you need to assign certificates for users who aren’t in Active Directory, you will most likely need to establish a standalone CA. (Of course, if you’re using Exchange 2000, you’ll be using Active Directory!) With a standalone CA, users must enroll themselves for a certificate; the type of certificate must be identified during the enrollment process. If you want to provide a temporary or pilot PKI environment, a standalone configuration might be best because it doesn’t involve putting any data in Active Directory. Some of the other reasons for choosing a standalone CA are as follows:

• For security purposes, many companies require that an administrator or manager approve requests for certificates. A standalone environment is ideal for this scenario, because standalone CAs don’t support automatic enrollment.

• Multiple standalone CAs can be used within a forest. Because standalone CAs don’t use Active Directory, there is no directory integration between the CAs, so different departments and divisions can create and maintain their own standalone CAs. Each CA environment can be used with complete autonomy from the other systems and directories or as part of a hierarchy.

• A standalone CA can be taken offline by unplugging it from the network or turning off the server completely. By removing it from the network, you can better protect the root CA from compromise. If an intruder were to gain access to the original private key, all subordinate and issued keys from that CA would be considered compromised as well. The only secure recourse in this situation is to create a brand new CA and replace every issued certificate.

If you want to integrate your PKI with Active Directory, you’ll need to use the enterprise CA. This directory integration is itself extremely valuable; however, the enterprise mode offers some additional benefits:

• Most of the advanced PKI management features such as auto-enrollment, automatic request approval, and policy enforcement require the enterprise CA.

• In enterprise mode, you can use Active Directory group policies to control some kinds of PKI behavior. For example, you can assign certificate templates to computers based on Group Policy; the ability to manage many management functions can be granted based on security groups or placement in the Active Directory. You can also assign key usage policies and CTLs using Group Policy.

• With an enterprise CA, your CRL is published in Active Directory. This is important because clients need access to the CRL to determine if a particular certificate has been revoked. The redundancy and reliability built into Active Directory makes it much easier for clients to get the current CRL on demand.

• Smart card use requires that user certificates be in Active Directory; the easiest way to get them there is to use an enterprise CA.

Designing a Hierarchy

If you already understand the way Active Directory separates items into hierarchies (the forest contains one or more trees; each tree contains one or more domains, and so forth), the relationships used by PKIs will seem very natural. Objects within Active Directory are identified by their containers; the X.509 PKI standard, which Windows 2000 and Exchange 2000 implement, uses a similar scheme for naming objects using a hierarchy of components.

The certificate hierarchy begins with a root CA. Like every other CA, the root is responsible for issuing certificates to subordinate entities; however, the root CA normally issues certificates only to other subordinate CAs. The subordinate CAs issue certificates to end users and computers. When an application needs to verify a certificate’s authenticity, it can verify the signature on the certificate, then on the issuing CA, then on that CA’s parent CA, and so forth, up to the root, as shown in Figure 12-1.

Figure 12-1: A hierarchy is possible with just two entries. Your hierarchy begins when you bring up the first CA, which becomes the root for your hierarchy.

When you create the first CA in your organization, it might or might not have a root. If you’re building a hybrid PKI using an outside root, then your root’s certificate request will go to the third party, which will issue your CA’s certificate. If you’re building a purely internal PKI, your CA will have to sign its own certificate— there’s no parent CA to do so. This self-signed certificate contains the identity of your company, the name of the CA server, its unique public key, and some additional attributes. As you add subordinate CAs, each one generates its own key pair and uses it to request a certificate from your root CA. When a subordinate CA issues certificates, the entire line or hierarchy is published within the certificate.

When the root CA issues certificates to child CAs, this process establishes a trust relationship between the CAs, similar to that within an Active Directory forest. If this subordinate CA is used to issue certificates to end entities, it is usually referred to as an issuing CA. However if the subordinate CA is used to parent additional child CAs, it is referred to as an intermediate CA. This distinction is important because you will need to manually apply settings to individual child CAs to control whether they act as issuing or intermediate CAs.

Protecting the Root CA

The root CA is the linchpin of your entire PKI. If its private key is compromised or lost, your entire PKI becomes essentially worthless because the private key’s new owner can issue or revoke certificates or change trust relationships at will; you’ll have to create a new CA and reissue certificates to all the intermediate and issuing CAs, then reissue end user and computer certificates. For this reason, recommended practice is to keep your root CA offline except when you’re actually using it. However, this introduces an extra twist: only standalone CAs can be kept offline without errors. The best way to accomplish this is to create a standalone root CA on a Windows server in a workgroup, then lock it in a secure area. Keep this server disconnected from the network unless specifically needed. Use the root to issue certificates for one or more enterprise subordinate CAs, which can either be intermediate or issuing CAs. Putting the server in a workgroup eliminates any problem with domain account synchronization, and prevents a domain compromise from allowing an attacker access to the root.

If possible, keep your intermediate CAs disconnected from the network as well. However, these servers will be domain members. Because Active Directory periodically changes the machine account password, you’ll have to bring these offline servers back online periodically. Moreover, to process any pending requests for subordinate CAs and to generate CRLs from the root, the root CA must be online. For these reasons, in addition to disaster recovery planning and awareness, it is good practice to create a procedure where the root servers are brought online at regular intervals for maintenance and normal change control procedures.

How Many CAs Should You Have?

Depending on who you ask about hierarchy design, you’ll hear a wide range of answers to this question. In keeping with the “keep it simple, stupid” mantra that all administrators learn early on, let’s begin with the simplest possible configuration: a single CA that acts as root and issuer. Why might you want to add more subordinate issuing or intermediate CAs? Here are some of the reasons:

• You want to be able to take the root CA offline. The root can generate CRLs only when it’s online. Likewise, an offline root can’t receive certificate requests. If you only have one root or issuing CA, you have to leave it online all the time, which is a bad security plan. Adding a subordinate issuing CA beneath your root allows you to leave the root off and have the subordinate issuing CA sign the CRL.

• You need to provide fault tolerance for your PKI environment. Depending on your network connections, number of potential requests, and overall redundancy requirements, one CA might not be enough. Exchange is smart enough to handle multiple KMS servers in an organization, and Windows doesn’t impose any restriction on how many CAs can be in a hierarchy (or an Active Directory forest, for that matter).

• Your administrative model requires segregated administration. Perhaps you have different divisions that require specific certificates to be issued. It could be your administrative teams are located in either a different divisions or they might be outsourced. In these cases, you’ll need multiple CAs to adequately delegate the administrative responsibilities of your PKI. This is especially true if you plan to have CA servers provide specific CAs; for example some companies configure one CA for external certificates and a separate server for internal certificates.

  If you need to have different standards, algorithms, hardware types, key lengths, or directories, you’ll be forced to add extra CAs. Once you install a root CA, you’re stuck with the key length and algorithms you’ve chosen for its certificate; these settings apply to all the keys issued to that particular CA. If you need two different types or maximum lengths of keys for application or vendor compatibility, you need more than one CA.

Some More Exotic Hierarchies There’s no single “correct” PKI hierarchy. Fortunately, though, there are a few basic designs that can be adapted to meet the needs of most organizations:

• Offline root with multiple issuing CAs Assuming that you plan to provide certificates for external users (partners, vendors, customers) and internal users, it’s common to use three CAs: a standalone root that is taken offline with two subordinate issuing CAs. One of the issuing CAs issues certificates for internal users; the other issues certificates for external users.

• Offline root with a trusted hierarchy This design is similar to the three- server approach just mentioned, but the subordinate CAs don’t issue certificates to the users. Instead, they become intermediate CAs, with another layer of issuing CAs beneath. This might seem like an unnecessary complication, but separating the intermediate and issuing CAs in this manner allows you to distribute certificate issuance across business units, divisions, or geographical regions. The root and intermediate CAs can be controlled by the IT or security organization, with certificate issuance pushed out to a lower level. Because this design is both scalable and flexible, it works well in most environments. It easily accommodates geographical (network) and policy (administrative) boundaries, while maintaining a single company-wide CA structure. Moreover, because trust relationships with external CAs happen at the root level, this design works well during an acquisition, merger, partnership, or cross-certification; the root can make a single trust for the entire company.

• Cross-certification hierarchy Depending on the administrative and political model in your organization, it might be difficult to establish a single root CA. Perhaps you recently merged with other companies that have existing PKIs, where collapsing one environment into the other would not be a simple weekend task, or perhaps you need to communicate with outside organizations with whom you have a common root. In the cross-certification hierarchy model, your root CA establishes a cross-certificate to one or more external CAs. This root trust establishes a full or one-way hierarchy similar to that of the root–subordinate relationship. If each organization issues a cross- certificate to the other, then the trust becomes bidirectional and the two are considered peers. Although this design is very flexible, it is not as scalable as the trusted hierarchy model: each outside root has to have its own cross-certificate trust, and managing these trusts can become complicated.

Working with Trusts and Cross-Certification

Within a certificate hierarchy, each new CA added to the environment trusts the root and the subordinates superior to it. All trusts are automatic and built in to the hierarchy and certificate path. In a network hierarchy or cross-certification model, external trusts are established. These trusts are used to establish organizational relationships between CAs with different roots, and the trusts are not necessarily reflected in the certificate paths of issued certificates.

Just as the name implies, a CTL identifies other trusted CAs and certificates that are external to your root CA. Each client has the ability to establish its own trust list. In fact, if you open Internet Explorer and select Tools | Internet Options from the menu, then click the Content tab, you will find the Certificates button. Clicking Certificates displays the existing trusts contained in your local CTL. To add a trust to the CTL, you must add an entry to this list. This is normally done by clicking Yes in a warning screen when presented a certificate that is not trusted.

Now, because certificates are not validated unless the hierarchy is known, the user also needs to install a copy of the root CA certificate, then explicitly trust it. By having this certificate (or a way to get it), the trust can be consummated and certificates from that authority can be used. The result of these efforts is a new entry in the user’s CTL. This manual procedure sounds easy enough if you are running a small network with just a few machines, but if you are in charge of a larger environment, or if you don’t want users making their own, perhaps ill- informed, choices about whom to trust, you need a way to make these changes company-wide or department-wide. Using Group Policy, the administrator can create a CTL that contains a signed list of root certification authority certificates. This CTL can automatically be applied to clients, which cannot override the CTL by adding or removing external roots.

Diving in to Digital Certificates

Once you’ve designed a hierarchy that makes sense for your security and trust requirements, it’s time to select the type, number, and capability of certificates that you want to issue. There are several issues to consider.

Key Length and Complexity

The Windows CryptoAPI supports key lengths ranging from a mere 384 bits to a whopping 16,384 bits. However, the cryptographic service provider (CSP) you use to actually generate the key is what determines how long a key you actually get. For example, the Microsoft base CSP that comes with Windows supports RSA key lengths of 384 to 16,384 bits, but the Digital Signature Algorithm (DSA) provider in the same CSP only supports 512- and 1024-bit keys. For most uses, 1024-bit keys are adequate; however, within the same algorithm (remember the work factor), longer keys are more secure because they are harder to break.

Lengthening the key can give your certificates a longer lifetime because certificate lifetime is tied to growth in computing power. Processing power becomes less expensive over time, and as years pass, it will take less time for a certificate of a given length to be broken using brute-force methods. A shorter key might be sufficiently difficult to break using today’s computing power, but will not meet your organization’s security requirements when matched against a malicious attacker’s computer 10 years from now.

Longer keys have other implications, too; they affect the size of the key store and performance (for the server, during key generation; for the client, during encryption and decryption). You should document a standard for issuing certificates and identify any requirements for key length. It is perfectly acceptable and expected that you will choose a different key length depending on the type of certificate required. Longer keys should be used for certificates that need a longer lifetime and more security. For example, because the root CA certificate is very valuable, and because having to rekey it frequently would be a hassle, root CA certificates are often 4096 bits long. Subordinate CAs, which are proportionally less valuable, are then configured to use 2048-bit keys, with user and machine certificates having 1024-bit keys. These lengths are fine for the foreseeable future, but if your company has identified more stringent security requirements, you might elect to use much longer keys. Figure 12-2 summarizes these issues.

Figure 12-2: Longer keys are used when additional security is needed. These longer certificates can also have a longer lifetime or validity period because the keys are harder to break.

Choosing a Certificate Lifetime

Certificates are not designed to be eternal. In fact, they are designed to expire after a certain interval, known as the validity period, has passed. To facilitate this, PKIs are designed with specific renewal procedures and limits that are set by the CA. Although possessing a digital certificate might allow for the encryption and signing of messages, the certificate is only as secure as the policies that control its access and use. For example, if someone has been terminated from your company and revocation procedures are lax, that person could continue to sign messages as if he or she still belongs to the company. Worse still, if the certificate never gets revoked, the person can continue to pose as an employee until the certificate expires at the end of its validity period. In addition, given enough time, every key can be broken. By renewing certificates with new key pairs on a scheduled basis, you can mitigate the risk of compromise for your certificates. Accordingly, you should keep the validity period of your certificates fairly short, and when renewing certificates you’ll need to periodically regenerate new keys (a process known as rekeying) instead of automatic renewal of old key pairs.

To determine the appropriate validity periods for your certificates, you must first determine your particular security requirements; specifically, how much do you trust your environment? Let’s say that your company uses a large number of temporary employees. Because turnover in these positions is high, you should probably assign certificates with shorter life spans issued to those employees. A shorter lifetime means that the certificates expire more frequently; because the renewal process requires administrative or policy approval, this gives you more control over the active certificates in your environments. There are a couple of other factors to consider in determining the appropriate lifetime for your certificate key pairs. For example, a longer key takes longer to break and thus can “live” longer than shorter keys. Also, keys that are kept on hardware tokens or smart cards can “live” longer, as these keys are much more difficult to access.

The advantage of a longer lifetime is obvious: less administration is required. The less often an administrator needs to renew or reassign key pairs to the user community, the less time it takes to manage the PKI environment. A lifetime that is too short can add tremendous burden to the support infrastructure and a lifetime that is too long can compromise security.

Just as there are general guidelines for key lengths, there are general practices for certificate life spans. Most organizations choose a 1- to 2-year life span for end user certificates, with a 5- to 10-year lifetime for their issuing and root CAs.

Rekeying versus Renewal

When the lifetime expires on a certificate, it must be renewed to remain authentic. The renewal process follows the same procedures as your enrollment; you can utilize auto-enrollment features or a user-initialized process. In either event, it is up to the administrator to determine whether the certificate should be rekeyed or renewed. The difference is subtle: when a certificate is rekeyed, the requester has to generate a new key pair, and the new public key is incorporated in the certificate. When the certificate is reissued, the validity period and attributes are updated before the new certificate is signed, but the existing key pair is used instead.

For server keys, a new key pair should be created at the same frequency as the lifetime for the certificate. In other words, a 5-year root CA certificate should be issued a new key pair at least once every 5 years. The reasons for this are clear when you consider the importance of the CA certificates and the risk associated with a break of these very important keys. On the other hand, user certificates are often rekeyed at twice the frequency of their lifetimes, so a user certificate that is good for 2 years could be renewed once using the same keys, then 2 years later the certificate could be rekeyed when it’s renewed.

Protecting the Private Key

If you lose control of your private key, either because you lose access to it or because someone guesses, steals, or ferrets out the password that protects it, you’re in trouble: that person can impersonate you with impunity. As bad as this is for you, it’s much worse if the private key in question belongs to one of your CAs. The attacker can then generate legitimate certificates for anyone he or she wants to. This pretty much negates the whole point behind using PKIs in the first place, so you want to prevent this from happening wherever possible.

By default, storage of certificates is handled by the certificate server and the client machine. Lax server or workstation protection mechanisms can put the integrity of your security plan at risk. In addition, mobility can create problems for PKI environments because users might need to gain access to their private certificates from other workstations or devices. Although increasing the complexity and length of keys can help mitigate some of the risks associated with key security, it does not address key mobility or access.

Windows supports several software CSPs by default, but it also supports a number of hardware CSPs. A hardware CSP can provide any number of advanced security options that cannot be realized with software keys. Hardware random number generation, hardware-assisted key generation, key archive and recovery, acceleration of cryptographic operations, and hardware-secured key storage are some of the possibilities when hardware solutions are added to your PKI design.

There are many options available for hardware-assisted PKIs. These options range from software keys stored on tokens or smart cards to hardware CSPs that help offload cryptography processes and, not incidentally, provide hardware-secured storage for the private key. These solutions come in several varieties:

• Smart cards allow you to store one or more certificates (along with their associated private keys) in a small, secure device that users can carry from place to place. Because smart cards are mobile, they can be used for multiple applications. For example, Microsoft has deployed smart cards to employees, and they can be used for secure e-mail, remote access, and buying meals in the corporate cafeterias. You might consider the use of smart cards for the entire population, or just for security-sensitive users such as administrators and executives. Using Group Policy, you can require that certain accounts use a smart card for authentication.

• nCipher offers a range of hardware devices, including some that are validated to Federal Information Processing Standard (FIPS) 140-1 Level 2 or Level 3 specifications. Their units generate keys based on hardware random- number generation, and they support multiple sets of smart card–based hardware tokens and additional scalability and administrative tools. These devices are really only useful for CAs, not individual workstations. Microsoft has documented their use at http://www.microsoft.com/technet/security/prodtech/windows/windows2000/ncipher.asp.

• Rainbow Technologies’ line of iKey 2000 products allow smart card–like capabilities in small universal serial bus (USB) tokens that don’t require a separate smart card reader.

Understanding Enrollment

Before you can sign your first message, you must first obtain a certificate. That raises the question of how you obtain the certificate in the first place. The term enrollment covers the process, from the initial creation of a certificate request through installation of the issued certificate. Your enrollment options depend largely on the type of certificate services you’re using. For example, had your company chosen an external CA, you’d be stuck with whatever methods they require. There are several ways a client, server, or workstation can become enrolled into the PKI environment, as follows:

• By default, Certificate Services installs with Web enrollment support. This process requires that a user connect with a browser to the Certsrv virtual directory on the CA to request a specific type of certificate. The request must then be accepted by the CA, optionally approved by the administrator, and processed after approval. This process is available on standalone and enterprise CAs.

• Group Policy auto-enrollment is available with enterprise CAs. There are two separate policies that allow auto-enrollment: the Enrollment Agent (Computer) policy allows the automatic enrollment of servers and workstations in a domain, and the Exchange Enrollment Agent (Offline Request) policy allows for KMS support of auto-enrollment for e-mail certificates.

• The Certificate Request Wizard and Certificate Renewal Wizard are both found in the Certificates MMC snap-in. Windows 2000, Windows XP, and Windows Server 2003 users can use this snap-in to request new certificates.

• A smart card enrollment station (the exact makeup of which varies among vendors) is used to enroll smart card devices into the environment. An administrator uses this terminal to associate cards with private keys and publish the resulting certificates; these stations are normally used to allow enrollment on behalf of users. Because the smart card protects the key material, there is little risk of compromise.

Understanding the Exchange KMS

The need to secure messaging is not new. In fact, the original X.509 specification, ISO/IEC/ITU 9594-8, was first published in 1988. This original specification is often referred to as X.509 version 1 (or just X.509v1) and was supported in the very first version of Microsoft Exchange Server. Since then, the X.509 standards have evolved; currently, X.509v3 is the standard definition for certificate functionality. Exchange’s KMS has evolved in parallel. With Exchange 4 and 5, the operating system didn’t include a CA. Accordingly, the Exchange KMS had to handle enrollment, management, storage, and revocation—essentially every aspect of PKI for Exchange.

The Exchange 2000 KMS still performs some of those functions, but it is reliant on Windows 2000 Certificate Services for most of its functionality. The biggest fundamental change to the Exchange 2000 KMS compared to previous versions is that it now leverages an existing PKI environment instead of providing one.

Whether you have a legacy Exchange KMS in place with X.509v1 certificates or a new Windows 2000 Certificate Services environment established, KMS augments the environment and provides additional management and support. Because KMS uses Active Directory, you must have an enterprise CA configured with the Enrollment Agent (Computer), Exchange Signature Only, and Exchange User certificate templates before KMS can be installed. The installation process inspects Active Directory during KMS installation to verify the configuration of the CA. After the installation, the Exchange management tools reflect the existence of the KMS. Within Exchange System Manager, a new node named Advanced Security appears under the administrative group; this is the tool that must be used to start KMS should the service stop because of a reboot or other unplanned event.

The primary purpose of KMS is to augment the existing enrollment and management functions with additional, Exchange-specific tools and services. When KMS is installed and configured, administrators will be able to take advantage of additional enrollment options. For example, once the KMS is present, you can use the E-Mail Security item in the Exchange Features tab of the user properties dialog box in Active Directory Users And Computers, shown in Figure 12-3.

Figure 12-3: The KMS administrator can edit the properties of this entry to enroll, recover, and revoke the e-mail certificate of the selected user.

Not only are the enrollment procedures enhanced, but additional features such as Key Recovery are enabled. This feature allows lost keys to be recovered and it also permits the use of older keys in addition to new ones for when a user moves companies or if the entire organization recently went through a rekeying process. In addition, Exchange users are able to renew their certificates over e-mail as well. This option, as well as the new enrollment options, are well suited for distributed networks or in cases where the user population consists primarily of remote users. Management of user certificates is distributed between the KMS administrator and the end users.

Understanding Revocation

At some point, you might need to terminate or revoke a valid certificate. If an employee has left the company, or you learn that a valid key has been compromised, you should revoke those keys and mark them as invalid. The X.509 standard specifies a process for this: the CA can generate a signed list of revoked certificates, known as a CRL. Each entry on the CRL contains the serial number of a certificate issued by that CA, along with a time stamp and a reason for revocation.

An enterprise CA stores the CRL in Active Directory; all types of CA allow the CRL to be retrieved over File Transfer Protocol (FTP), HTTP, or through a file share. There’s a specific X.509 certificate attribute that the CA populates to specify where that CA’s CRL can be downloaded. To set the locations of your CRL, open the Certificate Authority snap-in, view the CA server’s Properties dialog box, then click the Policy Module tab. Click Configuration, then click the X.509 Extensions tab in the Properties dialog box.

Revocation List Policies Before you can decide if the default settings are appropriate, you need to make some business decisions about handling revoked certificates. For one, you need to determine and document the reasons why your company would revoke a certificate. Next, you need to decide the frequency for updating the CRL. In other words, if you revoke a certificate right now, how many hours or days should it take for the CRL to reflect the revoked certificate company- wide? Be careful when making this decision; the more often you issue CRL updates, the more frequently the CA has to be online, and the more replication traffic the CRL generates. Finally, we need to decide for how long each CRL should be valid. If the lifetime of the CRL is, say, three weeks, then it could take at least that long for a client to know that a given certificate has been revoked because clients do not collect a new CRL if the lifetime of a cached list is still valid.

Tip

The Troubleshooting Certificate Status and Revocation white paper (see http://www.microsoft.com/technet/prodtechnol/WinXPPro/support/tshtcrl.asp) also contains a terrific explanation of CRLs and revocation policy.

Integrating Smart Cards

Although smart cards seem to have little to do with encrypting or signing messages, they’re a powerful technology that can add security while simplifying your PKI administration. A smart card is an ISO 7816-standard circuit card (with or without small metal contacts) that can be used to store information. Some smart cards have fairly sophisticated processing power, whereas others are merely data storage units with some hardware tamper-resistance built in.

In a PKI environment, smart cards provide a way to create, distribute, and protect private keys in a tamper-resistant storage medium. Windows 2000, Windows XP, and Windows Server 2003 support smart cards through vendor- specific CSPs that link specific types of smart cards to CryptoAPI (along with drivers for USB, serial-port, or keyboard-port smart card readers).

For less than $50 (how much less depends on volume) you can purchase a card and reader that can be used for logon, network access, e-mail, and virtually any other instance where a user certificate needs to be presented for encryption or authentication purposes. When you install a compatible reader in Windows 2000 or later versions, it can immediately be used for logon; there are several Group Policy settings that allow you to control what happens when the smart card is inserted or removed (a favorite is to lock the workstation automatically any time the card is withdrawn).

To use smart cards productively, you’ll need Active Directory and an enterprise CA. Configuring a smart card requires the administrator to use an enrollment station that is equipped with a smart card writer and the necessary software components to generate new credentials for new users by interoperating with the Certificate Server Web pages. Microsoft has published a smart card deployment cookbook (http://www.microsoft.com/technet/security/prodtech/smrtcard/smrtcdcb/) that describes in detail how to set up smart cards, including specific information required to configure a CA environment to support the devices.

However, there’s one twist to using smart cards: the Exchange 2000 KMS does not support them directly, because Exchange 2000 is hard-coded to use the Exchange CSP. Instead of enrolling your users through KMS, you’ll enroll them at the smart card enrollment station (being sure to specify that the smart card certificate can be used for S/MIME encryption and signing). When the user receives his or her smart card, he or she can just plug it in and use it with Outlook and Windows without any special enrollment.

Server Performance Guidelines

If you think about how a certificate service functions, you will soon realize that the CA doesn’t have all that much to do at any point in time—its workload is quite low. Enrollment typically happens in small batches, and revocation lists are usually published once a day or once a week. Unless you are performing bulk import and revocation processes, you can run Microsoft Certificate Services on relatively small servers.

A standalone Windows 2000 certificate server can support literally millions of certificates per physical CA. A fairly minimal dual-processor computer can issue more than a million certificates a day, which should suffice for most uses. To determine what size of CA server you need, you’ll have to understand the disk space requirements for certificates of differing key lengths. Microsoft uses the familiar Jet database engine for the certificate stores, meaning that (just like Exchange) the CA will have an EDB file, transaction log files, and a database checkpoint file. Be sure to site these on separate physical disks, more for recoverability than for performance.

For planning purposes, we can assume that each certificate occupies about 32 KB of disk space on the certificate server (remember, the server has to keep copies of the issued certificates and requests). If you were planning on issuing a million certificates, then you would need roughly 32 GB of space to hold the certificate files, plus extra space for transaction logs and the checkpoints. You would certainly want to protect the data against loss by using a Redundant Array of Independent Disks (RAID) configuration. This configuration will also increase the performance of your system.

Administration and networking requirements will probably dictate the need for multiple issuing CAs in several locations. In short, your performance requirements are likely to be low because multiple CAs are usually the best idea in most environments. Although older equipment will generally work quite well for your CAs, bear in mind that these are still production servers with important data, so they need to be as fault tolerant as your requirements and budget allow.