Planning a Windows Server 2003 Certificate-Based PKI

EXAM 70-293 OBJECTIVE 6, 6.2

Computer networks have evolved in recent years to enable an unprecedented sharing of information between individuals, corporations, and even national governments. The need to protect this information has also evolved, and network security has consequently become an essential concern of most system administrators. Even in smaller organizations, the basic goal of preventing unauthorized access while still enabling legitimate information to flow smoothly requires the use of more and more advanced technology.

In the mid-1990s, Microsoft began developing what was to become a comprehensive security system of authentication protocols and technology based on already developed cryptography standards known as Public Key Infrastructure (PKI). With the release of Windows 2000 Server, Microsoft used various existing standards to create the first

Windows-proprietary PKI – one that could be implemented completely without using third-party companies. Windows Server 2003 expands and improves on that original design in several significant ways, which we’ll discuss later in this chapter.

Understanding Public Key Infrastructure

To understand how a PKI works, you first need to understand what it is supposed to do. The goals of your infrastructure should include the following:

• Proper authentication

• Trust

• Confidentiality

• Integrity

• Non-repudiation

By using the core PKI elements of public key cryptography, digital signatures, and certificates, all of these equally important goals can be met successfully. The good news is that the majority of the work involved in implementing these elements under Windows Server 2003 is taken care of automatically by the operating system and is done behind the scenes.

The first goal, proper authentication, means that you can be highly certain that an entity such as a user or a computer is indeed the entity that he, she, or it is claiming to be. Think of a bank. If you wanted to cash a large check, the teller will more than likely ask for some identification. If you present the teller with a driver’s license and the picture on it matches your face, the teller can be highly certain that you are that person – that is, if the teller trusts the validity of the license itself. Because the driver’s license is issued by a government agency – a trusted third party – the teller is more likely to accept it as valid proof of your identity than if you presented an employee ID card issued by a small company that the teller has never heard of. As you can see, trust and authentication work hand in hand.

When transferring data across a network, confidentiality ensures that the data cannot be viewed and understood by any third party. The data might be anything from an e-mail message to a database of social security numbers. In the past twenty years, more effort has been spent trying to achieve the goal of data confidentiality than perhaps all the others combined. In fact, the entire scientific field of cryptology is devoted to ensuring confidentiality (as well as all the other PKI goals). Cryptology has even claimed a place in Hollywood – the movie Sneakers is just one example.

Note

Cryptography refers to the process of encrypting data; cryptanalysis is the process of decrypting, or “cracking,” cryptographic code. Together, the two make up the science of cryptology.

As important as confidentiality is, however, the importance of network data integrity should not be underestimated. Consider the extreme implications of a patient’s medical records being intercepted during transmission and then maliciously or accidentally altered before being sent on to their destination. Integrity gives confidence to a recipient that data has arrived in its original form and hasn’t been changed or edited.

Finally, we come to non-repudiation. A bit more obscure than the other goals, non-repudiation enables you to prove that a particular entity sent a particular piece of data. It is impossible for the entity to deny having sent it. It becomes extremely difficult for an attacker to masquerade as a legitimate user and then send malevolent data across the network. Non-repudiation is related to, but separate from, authentication.

Public Key Cryptography

The history of general cryptography almost certainly dates back to almost 2000 B.C. when Roman and Greek statesmen used simple alphabet-shifting algorithms to keep government communication private. Although complexity increased, not much changed until the 1970s, when the National Security Agency (NSA) worked with Dr. Horst Feistel to establish the Data Encryption Standard (DES) and Whitfield Diffie and Martin Hellman introduced the first Public Key Cryptography Standard (PKCS). Windows Server 2003 still uses Diffie-Hellman (DH) algorithms for Secure Sockets Layer (SSL), Transport Layer Security (TLS), and IP Security (IPSec).

DH algorithms are known collectively as shared secret key cryptographies, also known as symmetric key encryption. Say you have two users, Greg and Matt, who want to communicate privately. With DH, Greg and Matt each generate a random number. Each of these numbers is known only to the person who generated it. Part one of the DH function changes each secret number into a non-secret, or public, number. Greg and Matt now exchange the public numbers and then enter them into part two of the DH function. This results in a private key – one that is identical to both users. Using advanced mathematics, this shared secret key can be decrypted only by someone with access to one of the original random numbers. As long as Greg and Matt keep the original numbers hidden, the shared secret key cannot be reversed.

Another major force in modern cryptography came about in the late 1970s. RSA Labs, founded by Ronald Rivest, Adi Shamir, and Leonard Adleman, furthered the concept of key cryptography by developing a technology of key pairs, where plaintext that is encrypted by one key can only be decrypted by the other matching key. Windows Server 2003 uses RSA technology in its various forms extensively for such things as Kerberos authentication and S/MIME. The theory goes something like this: Two users, Dave and Dixine, wish to communicate privately. Dave and Dixine each own a key pair consisting of a public key and a private key. If Dave wants Dixine to send him an encrypted message, he first transmits his public key to Dixine. She then uses Dave’s public key to encrypt the message. Fundamentally, since Dave’s public key was used to encrypt, only Dave’s private key can be used to decrypt. When he receives the message, only he is able to read it. Security is maintained because only public keys are transmitted – the private keys are kept secret and are known only to their owners. Figure 12.1 illustrates the process.

Figure 12.1: Public/Private Key Data Exchange

Exam Warning

In a Windows Server 2003 PKI, a user’s public and private keys are stored under the user’s profile. For the administrator, the public keys would be under Documents and Settings\Administrator\System Certificates\My\Certificates and the private keys would be under Documents and Settings\Administrator\Crypto\RSA (where they are double encrypted by Microsoft’s Data Protection API, or DPAPI). Although a copy of the public keys is kept in the registry, and can even be kept in Active Directory, the private keys are vulnerable to deletion. If you delete a user profile, the private keys will be lost!

RSA can also be used to create “digital signatures” (see Figure 12.2 below). In the communication described above, a public key was used to encrypt a message and the corresponding private key was used to decrypt. If you invert the process, a private key can be used to encrypt and the matching public key to decrypt. This is useful, for example, if you want people to know that a document you wrote is really yours. If you encrypt the document using your private key, then only your public key can decrypt it. If people use your public key to read the document and they are successful, they can be certain that it was “signed” by your private key and is therefore authentic.

Figure 12.2: Digital Signatures

Head of the Class...
Modern Cryptography 101

Thanks to two mathematical concepts, prime number theory and modulo algebra, most of today’s cryptography encryption standards are considered intractable – that is, they are unbreakable with current technology in a reasonable amount of time. For example, it might take 300 linked computers more than 1000 years to decrypt a message. Of course, quantum computing is expected to someday change all that, making calculations exponentially faster and rendering all current cryptographic algorithms useless – but don’t worry about that for now.

First, an explanation of the modulo operator. Think about elementary school where you first learned to do division. You learned that 19/5 equals 3 with a remainder of 4. You also probably concentrated on the 3 as the important number. Now, however, you get to look at the remainder. When you take the modulus of two numbers, the result is the remainder; therefore, 19 mod 5 equals 4. Similarly, 24 mod 5 also equals 4 (can you see why?). Finally, you can conclude that 19 and 24 are congruent in modulo 4. So how does this relate to cryptography and prime numbers?

The idea is to take a message and represent it by using a sequence of numbers. Call the sequence x_i. What you need to do is find three numbers that make the following modulo equation possible: (x^e)^d mod y = x

The first two numbers, e and d, are a pair and are completely interchangeable. The third number, y, is a product of two very large prime numbers (the larger the primes, the more secure the encryption). Prime number theory is too complex for an in-depth discussion here, but in a nutshell, remember that a prime number is only divisible by the number 1 and itself. This gives each prime number “uniqueness.”

After you have found these numbers (although we won’t go into how because this is the really deep mathematical part), the encryption key becomes the pair “e, y” and the decryption key becomes the pair “d, y.” Now it doesn’t matter which key you decide to make public and which key you make private, because they’re interchangeable. It’s a good thing that Windows Server 2003 does all the difficult work for us!

The Function of the PKI

The primary function of the PKI is to address the need for privacy throughout a network. For the administrator, there are many areas that need to be secured. Internal and external authentication, encryption of stored and transmitted files, and e-mail privacy are just a few examples. The infrastructure that Windows Server 2003 provides links many different public key technologies to give the IT administrator the power necessary to maintain a secure network.

Most of the functionality of a Windows Server 2003-based PKI comes from a few crucial components, which are described below. Although there are several third-party vendors, such as VeriSign (www.verisign.com) that offer similar technologies and components, using Windows Server 2003 can be a less-costly and easier-to-implement option – especially for small- and medium-sized companies.

Components of the PKI

Properly planning for and deploying a PKI requires familiarity with a number of components, including but not limited to the following:

• Digital Certificates

• Certification Authorities

• Certificate Enrollment

• Certificate Revocation

• Encryption/Cryptography Services

In the following sections, we will discuss each of these in more detail.

New & Noteworthy...
PKI Enhancements in Windows Server 2003

Windows Server 2003 introduces many new enhancements that allow for a more easily implemented PKI solution. The following list items include the major highlights:

• Auto-enrollment for Users Windows 2000 first introduced the concept of auto-enrollment for a PKI, but it was limited in scope to machine certificates. Windows Server 2003 now enables the automatic requesting and issuing of user certificates as well.

• Key Archival and Recovery Exchange Server 2000 was the first Microsoft product to employ the capability to recover lost keys, but Windows Server 2003 now enables the retrieval of encryption private keys. This eliminates the need to completely reconstruct a user’s key pairs.

• Delta Certificate Revocation Lists (Delta CRLs) Delta lists enable new additions to a CRL to be published without the need to publish the entire CRL again. Much like an incremental backup in theory, this advancement helps optimize network speed and simplifies the distribution of CRLs.

• Triple DES and Advanced Encryption Standard (AES) Support With Windows Server 2003, Microsoft has adopted more components of the standard PKI endorsed by many organizations. The acceptance of 3-DES, or triple DES, in particular has been greatly anticipated by many cryptography experts. AES is still a relatively new standard, but possibly represents the future of encryption.

• Qualified Subordination When linking an outside organization’s certification authority (CA) structure with your own, trust issues are paramount. New advancements enable the limiting of trust chains and enable the restriction of certificate types acceptable when issued by an external authority.

• Version 2 Certificate Templates Windows Server 2003 Enterprise Edition and Windows Server 2003 Datacenter Edition provide many enhancements to the certificate templates found in Windows Server 2003 Standard Edition. Delta CRLs, user certificate auto-enrollment, and key archival/recovery are just some of the important enhancements that version 2 templates have.

Understanding Digital Certificates

In our previous discussion of public and private key pairs, two users wanted to exchange confidential information and did so by having one user encrypt the data with the other user’s public key. We then discussed digital signatures, where the sending user “signs” the data by using his or her private key. Did you notice the security vulnerability in these methods?

In this type of scenario, there is nothing to prevent an attacker from intercepting the data mid-stream and replacing the original signature with his or her own using of course his or her own private key. The attacker would then forward the replacement public key to the unsuspecting party. In other words, even though the data is signed, how can you be sure of who signed it? The answer in the Windows PKI is the certificate.

Think of a certificate as a small and portable combination safe. The primary purpose of the safe is to hold a public key (although quite a bit of other information is also held there). Someone you trust must hold the combination to the safe – that trust is the basis for the entire PKI system. If I am a user and want to send you my public key so that you can encrypt some data to send back to me, I can just sign the data myself, but I am then vulnerable to the attack mentioned above. However, if I allow a trusted third-party entity to take my public key (which I don’t mind because they’re trustworthy), lock it away in the safe, and then send the safe to you, you can ask the trusted party for the combination. When you open the safe, you can be certain that the public key and all other information inside really belongs to me, because the safe came from a trustworthy source. The “safe” is really nothing more than a digital signature, except that the signature comes from a universally trusted third party and not from me. The main purpose of certificates, then, is to facilitate the secure transfer of keys across an insecure network. Figure 12.3 shows the properties of a Windows certificate. Notice that the highlighted public key is only part of the certificate.

Figure 12.3: A Windows Server 2003 Certificate

Test Day Tip

Certificates are at the very core of the Windows PKI. Make certain that you understand what certificates are, and why they are needed when using public keys. Also, be familiar with the types of certificates listed in this section and the differences between them.

User Certificates

Of the three general types of certificates found in a Windows PKI, the user certificate is perhaps the most common. User certificates are certificates that enable the user to do something that would not otherwise be allowed. The Enrollment Agent certificate is one example. Without it, even an administrator is not able to enroll smart cards and configure them properly at an enrollment station. Under Windows Server 2003, required user certificates can be requested automatically by the client and subsequently issued by a certification authority (discussed below) with no user intervention necessary.

Machine Certificates

Also known as computer certificates, machine certificates (as the name implies) give the system – instead of the user – the capability to do something out of the ordinary. The main purpose for machine certificates is authentication, both client-side and server-side. As stated earlier, certificates are the main vehicle by which public keys are exchanged in a PKI. Machine certificates are mainly involved with these behind-the-scenes exchanges and are normally overseen by the operating system. Machine certificates have been able to take advantage of Windows’ auto-enrollment feature since Windows 2000 Server was introduced. We will discuss auto-enrollment later in this chapter.

Application Certificates

The term application certificate refers to any certificate that is used with a specific PKI-enabled application. Examples include IPSec and S/MIME encryption for e-mail. Applications that need certificates are generally configured to automatically request them and are then placed in a waiting status until the required certificate arrives. Depending upon the application, the network administrator or even the user might have the capability to change or even delete certificate requests issued by the application.

Understanding Certification Authorities

EXAM 70-293 OBJECTIVE 6.2.1

Certificates are a way to transfer keys securely across an insecure network. If any arbitrary user were allowed to issue certificates, it would be no different from that user simply signing the data. For a certificate to be of any use, it must be issued by a trusted entity – an entity that both the sender and receiver trust. Such a trusted entity is known as a certification authority (CA). Third-party CAs such as VeriSign or Entrust can be trusted because they are highly visible and their public keys are well known to the IT community. When you are confident that you hold a true public key for a CA, and that public key properly decrypts a certificate, you are then certain that the certificate was digitally signed by the CA and no one else. Only then can you be positive that the public key contained inside the certificate is valid and safe.

In a third-party, or external PKI, it is up to the third-party CA to positively verify the identity of anyone requesting a certificate from it. Beginning with Windows 2000, Microsoft has allowed the creation of a trusted internal CA – possibly eliminating the need for an external third party. With a Windows Server 2003 CA, the CA verifies the identity of the user requesting a certificate by checking that user’s authentication credentials (using Kerberos or NTLM). If the credentials of the requesting user check out, a certificate is issued to the user. When the user needs to transmit his or her public key to another user or application, the certificate is used to prove to the receiver that the public key inside can be used safely.

In the analogy we used earlier, the state driver’s licensing agency is trusted because it is known that the agency requires proof of identity before issuing a driver’s license. In the same way, users can trust the certification authority because they know it verifies the authentication credentials before issuing a certificate.

CA Hierarchy

EXAM 70-293 OBJECTIVE 6.2.1

For a very small organization, it might be possible under Windows Server 2003 for you to use only one CA for all PKI functions. However, for larger groups, Microsoft outlines a three-tier hierarchical structure starting at the top with a root CA, moving downward to a mid-level CA, and finally an issuing-level CA. Both the mid-level CA and issuing-level CA are known as subordinate CAs.

Exam Warning

Although there are certain advantages to using both external and internal CAs when planning an organization’s PKI, you should know that it is possible for a Windows Server 2003 root CA to trust an external root CA, but it is nearly impossible to get the external root CA to trust yours.

The reason is that external CAs are established and highly visible, and therefore easily verifiable to the outside world. Your internal CA is most definitely not. To prove your identity to the external authority, you must jump through a most rigorous set of hoops, and you must also justify the business need for such a relationship. If you go to Microsoft’s home Web site at www.microsoft.com and search for the words CA cross trust, you will find a white paper entitled Public Key Interoperability. This is a good place to start learning more about this complex topic.

Root CAs

When you first set up an internal PKI, no CA exists. The first CA created is known as the root CA, and it can be used to issue certificates to users or to other CAs. As mentioned earlier, in a large organization there usually is a hierarchy where the root CA is not the only certification authority. In this case, the sole purpose of the root CA is to issue certificates to other CAs to establish their authority.

The question then becomes: who issues the root CA a certificate? The answer is that a root CA issues its own certificate (this is called a self-signed certificate). Security is not compromised for two reasons. First, you will only implement one root CA in your organization and second, configuring a root CA requires administrative rights on the server. The root CA should be kept highly secured because it has so much authority.

Subordinate CAs

Any certification authority that is established after the root CA is a subordinate CA. Subordinate CAs gain their authority by requesting a certificate from either the root CA or a higher-level subordinate CA. After the subordinate CA receives the certificate, it can control CA policies and/or issue certificates itself, depending on your PKI structure and policies.

Test Day Tip

Remember that if a root or subordinate CA becomes compromised (e.g., the server’s hard drive is damaged), all CAs subordinate to it will lose their trust relationship and therefore their authority. Always keep current backups of your CAs.

Worse still is the scenario in which a CA’s private key is obtained by an attacker. If the CA in question is your root CA, your entire PKI will be compromised.

How Microsoft Certificate Services Works

The Windows Server 2003 PKI does many things behind the scenes. Thanks in part to auto enrollment (discussed later in this chapter) and certificate stores (places where certificates are kept after their creation), some PKI-enabled features such as EFS work with no user intervention at all. Others, such as IPSec, require significantly less work than would be required without an advanced operating system.

Even though a majority of the PKI is handled by Windows Server 2003, it is still instructive to have an overview of how certificate services work.

1. First, a system or user generates a public/private key pair and then a certificate request.

2. The certificate request, which contains the public key and other identifying information such as user name, is forwarded to a CA.

3. The CA verifies the validity of the public key. If it is verified, the CA issues the certificate.

4. After it is issued, the certificate is ready for use and is kept in the certificate store, which can reside in Active Directory. Applications that require a certificate use this central repository when necessary.

In practice, it isn’t terribly difficult to implement certificate services, as the following exercise shows. Configuring the CA requires a bit more effort, as does planning the structure and hierarchy of the PKI – especially if you are designing an enterprise-wide solution. We’ll cover these topics later in this chapter.

Exercise 12.01: Installing Certificate Services

1. After logging on with administrative privileges, click Start | Control Panel, and then click Add/Remove Programs.

2. Click Add/Remove Windows Components, and then check Certificate Services. This selects both sub-components of certificate services, which are Certificate Services CA and Certificate Services Web Enrollment Support. If Web enrollment support is not checked, you will not be able to complete Exercise 12.03.

3. A warning dialog box appear telling you that after certificate services have been installed you will not be able to change the machine’s domain membership or change its computer name. Click Yes to continue.

4. You now must choose the type of CA to establish, as seen in Figure 12.4. You have two decisions to make – that of root vs. subordinate and enterprise vs. standalone (discussed later in this chapter). For this exercise, click Enterprise root CA and click Next. If you checked the Use custom settings to generate the key pair and CA certificate, you would be prompted to choose a custom cryptographic service provider (CSP), a hash algorithm, and a key length. You could also elect to use an existing key or to use an imported one.

   
   Figure 12.4: Choosing the CA Type

5. The next dialog box presented is the CA Identifying Information box. See Figure 12.5. Enter a common name for the CA. For this exercise, type My Root CA. The distinguished name suffix is provided by the operating system and is used along with the common name you just typed in to form the distinguished name. Note that you can also change the default five-year validity period of the CA. You can set the validity period as a number of days, weeks, months, or years. Click Next to continue.

   
   Figure 12.5: Naming the CA

6. After the key pair is generated, the Certificate Database Settings dialog box appears. As in Figure 12.6, you will notice that both the certificate database and certificate database log textboxes are already filled with default values. You may elect to Store configuration information in a shared folder, but do not check it for purposes of this exercise. Click Next to complete the installation. After Windows Server 2003 has completed its work (you might be notified during this process that the Internet Information Service (IIS) will stop if you have IIS running on this machine), click Finish. During the configuration process, you might be prompted to insert your Windows Server 2003 installation CD or enter the path to the installation files on the hard disk or on a network share. You will also be notified that Active Server Pages (ASP) must be enabled in IIS to provide Web enrollment services. Click Yes to enable ASP.

   
   Figure 12.6: Selecting the Certificate Database Location

Exam Warning

Pay special attention to the warning given in step 3 in the above exercise. Because the distinguished name of the CA is a part of the certificates it issues, renaming the server or removing it from the domain is not allowed. Windows Server 2003 uses the X.500 standard for distinguished names.