Lesson 1: Public Key Infrastructure Fundamentals

 < Day Day Up > 



Computer networks are no longer closed systems in which a user's mere presence on the network can serve as proof of identity. In this age of information interconnection, an organization's network might consist of intranets, Internet sites, and extranets-all of which are potentially susceptible to access by unauthorized individuals who intend to maliciously view or alter the organization's digital information assets.

There are many potential opportunities for unauthorized access to information stored on networks. A person can attempt to monitor or alter information as it crosses the network, including e-mail messages, electronic commerce transactions, and file transfers. A thief who steals a laptop computer can attempt to access confidential documents stored on the computer. An attacker might attempt to impersonate a legitimate user to gain access to information that would not otherwise be authorized.

A well-planned PKI can reduce the likelihood of each of these common attacks. As a security administrator, you must understand the fundamentals of a PKI, and be able to deploy a Windows Server 2003 Certificate Services infrastructure.

After this lesson, you will be able to

  • Describe the significance of public key encryption.

  • Explain why a PKI is necessary to enable public key encryption to be used on a large scale.

  • List the components of PKIs and the significance of each.

  • Deploy Certificate Services on multiple servers.

  • Back up and restore important CA data.

  • Audit access to CA services.

Estimated lesson time: 50 minutes

Cryptography and Encryption

Cryptography is essential for the secure exchange of information across intranets, extranets, and the Internet. From a technical point of view, cryptography is the science of protecting data by mathematically transforming it into an unreadable format, otherwise known as encryption. To a business, cryptography is a means to reduce the likelihood of a costly security compromise by providing authentication, confidentiality, and data integrity.

Network encryption comes in two main varieties: shared key encryption and public key encryption. Shared key encryption requires both the sender and the recipient of an encrypted message to have a shared secret-a password that can be used to encrypt and decrypt the message. Shared key encryption is easy to understand, but it is difficult to implement on a large scale. After all, to allow secure communication between 1,000 employees at a company would require about 1 million passwords to be exchanged, because any two users who wanted to communicate would need to exchange a unique password.

For example, if Sam wants to send an encrypted electronic message to Toby, Sam first walks over to Toby and whispers a password in his ear. Then, when Toby receives the electronic message, Toby decrypts it with the password. As long as nobody else knows the password, Sam can be sure that the contents of the message are private.

The second common network encryption mechanism is public key encryption, also known as asymmetric key encryption. Public key encryption uses one key to encrypt a message, and a second, related key to decrypt the message. These two keys form a key pair. One of these keys is kept private, and the other key can be shared publicly (hence the name, public key encryption).

For example, if Sam wants to send an encrypted message to Toby, Sam uses Toby's public key to encrypt the message. When Toby receives the message, Toby uses his private key to decrypt it. Only Toby's private key can be used to decrypt a message encrypted with his public key, so Sam can be sure that nobody else was able to view the contents of the message.

There's another interesting way to use public key encryption: digital signatures. If Sam wants to prove to Toby that Sam, and not somebody else, sent the message, Sam can use Sam's own private key to encrypt the message. After Toby receives it, Toby needs to use Sam's public key to decrypt the message. If it decrypts properly, Toby can be certain that Sam's private key was used to encrypt it and that the message hadn't changed since Sam sent it. Of course, encryption takes a great deal of processing power, so Sam would probably choose to encrypt a short hash of the message instead of the entire message, and append the hash onto the end of the message. That would be sufficient to prove that Sam sent the message and that it hadn't been modified in transit.

Public Key Infrastructure

Public key encryption wouldn't be any easier than shared key encryption if everyone had to manually exchange public keys. That's why we use a PKI-to make the process of managing and exchanging public keys simpler. A PKI is a set of policies, standards, and software that manages certificates and public and private keys. A PKI consists of a set of digital certificates, certification authorities (CAs), and tools that can be used to authenticate users and computers and to verify transactions. In order to place the PKI implementation provided by Windows Server 2003 in the proper context, this section provides a general overview of the components that make up a PKI.

See Also 

The data formats and network communications used by a PKI are (mostly) standardized. For detailed, but dry, information about PKI standards, refer to RFC 2459.

Certificates

A public key certificate, referred to in this chapter as simply a certificate, is a tool for using public key encryption for authentication and encryption. Certificates are issued and signed by a CA, and any user or application that examines the certificate can safely assume that the CA did indeed issue the certificate. If you trust the CA to do a good job of authenticating users before handing out certificates, and you believe that the CA protects the privacy of its certificates and keys, you can trust that a certificate holder is who he or she claims to be.

Certificates can be issued for a variety of functions, including Web user authentication, Web server authentication, secure e-mail, encryption of network communications, and code signing. CAs even use certificates to identify themselves, create other certificates, and establish a certification hierarchy between other CAs. If the Windows Server 2003 enterprise CA is used in an organization, clients can use certificates to log on to the domain.

Certificates contain some or all of the following information, depending on the purpose of the certificate:

  • The user's principal name.

  • The user's e-mail address.

  • The computer's host name.

  • The dates between which the certificate is valid.

  • The certificate's serial number, which is guaranteed by the CA to be unique.

  • The name of the CA that issued the certificate and the key that was used to sign the certificate.

  • A description of the policy that the CA followed to originally authenticate the subject.

  • A list of ways the certificate can be used.

  • The location of the certificate revocation list (CRL), a document maintained and published by a CA that lists certificates that have been revoked. A CRL is signed with the private key of the CA to ensure its integrity.

Certification authorities

A CA is an entity trusted to issue certificates to an individual, a computer, or a service. A CA accepts a certificate request, verifies the requester's information according to the policies of the CA and the type of certificate being requested, generates a certificate, and then uses its private key to digitally sign the certificate. A CA can be a public third party, such as VeriSign, or it can be internal to an organization. For example, you might choose to use Windows Server 2003 Certificate Services to generate certificates for users and computers in your Active Directory directory service domain. Each CA can have distinct proof-of-identity requirements for certificate requesters, such as a domain account, an employee badge, a driver's license, a notarized request, or a physical address.

Registration is the process by which subjects make themselves known to a CA. Registration can be accomplished automatically during the certificate enrollment process, or it can be accomplished by a trusted entity such as a smart card enrollment station. Certificate enrollment is the procedure that a user follows to request a certificate from a CA. The certificate request provides identity information to the CA, and the information the user provides becomes part of the issued certificate.

Certificate life cycle

Certificates cannot be used forever; that would give an attacker too much time to identify the corresponding private key. Certificates have a predefined life cycle and expire at the end of this life cycle. You, as the security administrator, maintain control over the certificate. You can extend the lifetime of a certificate by renewing it, or end the usefulness of a certificate before the expiration date by revoking it.

A number of factors influence the length you will choose for a certificate lifetime, such as the type of certificate, the security requirements of your organization, the standard practices in your industry, and government regulations. In general, longer keys support longer certificate lifetimes and key lifetimes. Longer lifetimes reduce administrative labor, which reduces costs.

When establishing certificate and key lifetimes, you must consider how vulnerable your keys are to compromise and what the potential consequences of compromise are. The following factors influence the lifetimes that you choose for certificates and keys:

  • The length of private keys for certificates.Because longer keys are more difficult to break, they justify longer safe key lifetimes.

  • The security of the CAs and their private keys.In general, the more secure the CA and its private key, the longer the safe certificate lifetime. CAs that are operated offline and stored in locked vaults or data centers are the most secure.

  • The strength of the technology used for cryptographic operations.In general, stronger cryptographic technology supports longer key lifetimes. You can extend key lifetimes if you enhance private key storage by using smart cards and other hardware cryptographic service providers. Some cryptographic technologies provide stronger security, in addition to support for stronger cryptographic algorithms. For example, you might use smart cards for user logon or FIPS 140-1 Crypto Cards for secure mail and secure Web browsers.

  • The vulnerability of the CA certification chain.In general, the more vulnerable your CA hierarchy is to attack, the longer the CA private keys and the shorter the key lifetimes required.

  • The users of your certificates.Organizations typically trust their own employees more than they trust employees of other organizations. If you issue certificates to external users, you might want to shorten the lifetimes of those certificates to reduce the time window during which a compromised private key can be abused.

  • The number of certificates that have been signed by a dedicated CA.The more public the CA public key that is used to sign an issued certificate, the more vulnerable it becomes to attempts to break its key.

An expiration date is defined for each certificate when it is issued. An enterprise CA issues certificates with lifetimes that are based on the certificate template for the requested certificate type.

CA validity periods

Every certificate issued by a CA has a validity period that ends with the certificate's expiration date. Because a CA is really just another entity that has been issued a certificate-either issued by itself (in the case of a root CA) or issued by a parent (in the case of a subordinate CA)-every CA has a built-in expiration date. The expiration date of a CA's certificate is more important than that of other certificates, however.

Although a CA's certificate can be renewed just as easily as any other certificate, a CA cannot issue a certificate with an expiration date valid beyond the expiration date of its own certificate. Therefore, when a CA's certificate reaches the end of its validity period, all certificates it has issued will also expire. Because of this, if you purposely do not renew a CA, you can be assured that all the certificates that the now-expired CA has issued can no longer be used. In other words, there will be no 'orphaned' certificates that are still within their validity period but that have been issued by a CA that is no longer valid.

Because a CA that is approaching the end of its own validity period issues certificates valid for shorter and shorter periods of time, you need to have a plan in place to renew the CA well before it expires in order to avoid issuing certificates of a very short validity period. For example, in the case of Windows Server 2003, the root CA's certificate defaults to a validity period of five years. You should renew it every four years, however, to prevent new certificates from being published with lifetimes shorter than a year.

You can reduce the time required to administer a PKI by increasing the validity period of the root CA. As with any certificate, you should choose a validity period shorter than the time required for an attacker to break the root CA key's cryptography. Given the current state of computer technology, one estimate is that a 4096-bit private key would take about 15 to 20 years to crack. While a determined attacker could eventually crack a private key by using the corresponding certificate, the end result would be useless if the certificate had expired by the time the attack completed.

Certificate revocation

A certificate has a specified lifetime, but CAs can reduce this lifetime by the process known as certificate revocation. The CA publishes a certificate revocation list (CRL) that lists serial numbers of certificates that it regards as no longer valid. The specified lifetime of CRLs is typically much shorter than that of a certificate. The CA might also include in the CRL the reason the certificate has been revoked. A revocation might occur because a private key has been compromised, because a certificate has been superseded, or because an employee has left the company. The CRL also includes the date the certificate was revoked.

During signature verification, applications can check the CRL to determine whether a given certificate and key pair are still trustworthy. Applications can also determine whether the reason or date of the revocation affects the use of the certificate in question. If the certificate is being used to verify a signature, and the date on the signature precedes the date of the revocation of the certificate by the CA, the signature can still be considered valid.

Off the Record 

Most applications do not analyze the reason code. If a certificate is revoked, it's revoked. The reason code just isn't that important.

To reduce the number of requests sent to the CA, the CRL is generally cached by the client, which can use it until it expires. If a CA publishes a new CRL, applications that have a valid CRL do not usually use the new CRL until the one they have expires.

Windows Server 2003 Certificate Services

A PKI can be used to dramatically increase the security of an organization's network. To make the task of implementing a PKI simpler, Windows Server 2003 includes Certificate Services to help your organization implement PKI. You can use Certificate Services to create a single CA or an entire hierarchy of CAs. Windows Server 2003 also includes several tools for managing CAs, certificates, and certificate templates. These tools will be discussed in detail in the other lessons in this chapter.

Although you can implement a PKI by using other software, there are distinct advantages to using Windows Server 2003: no additional cost, and tight integration with Active Directory. You can use Group Policy objects to control which users and computers have the rights to issue and manage certificates. You can use standard authorization lists to control the rights of users and computers to request certificates. You can even use certificates issued by your PKI to authenticate users, computers, and domain controllers when they access resources in Active Directory.

See Also 

This book does not provide information about designing a PKI infrastructure based on Windows Server 2003 because the exam is focused on the tactical installation, configuration, and management tasks. For design information, refer to the Windows Server 2003 Deployment Kit.

Root CAs

The first step in deploying a PKI is to install a CA, and the first CA you install in your organization must be a root CA. You can create two types of root CAs: enterprise and standalone. In a nutshell, enterprise CAs require Active Directory. Because enterprise CAs rely on Active Directory to store and replicate data, all enterprise CAs must also be domain controllers. Enterprise CAs are only capable of issuing certificates to computers and users in the Active Directory forest. Standalone CAs can be used in an Active Directory environment, but they do not require it.

Though there are several requirements and restrictions imposed upon enterprise CAs, they offer some important advantages. You can use autoenrollment with an enterprise CA to dramatically reduce the labor associated with managing certificates. Users performing certificate enrollment with a standalone CA must use Web enrollment, although enterprise CAs provide several other options. Throughout this chapter, differences between enterprise and standalone CAs will be pointed out.

CA hierarchies

CAs can be hierarchical, just as Active Directory forests can be designed in a hierarchy. In a hierarchical CA structure, two or more CAs are organized in a structure with a single root CA and one or more subordinate CAs. The root CA provides a certificate to the subordinate CAs, which in turn can generate certificates for additional subordinate CAs or end users. In Active Directory, trusts are automatically created between domains in a hierarchy. In a CA hierarchy, trust chaining enables certificates issued by subordinate CAs to be trusted by clients who trust the root CA.

Within an organization's certificate hierarchy, some subordinate CAs might be intermediate CAs. In other words, they do not issue certificates to end users or computers; they only issue certificates to other subordinate CAs that are below them in the certification hierarchy. Intermediate CAs are not required. However, using an intermediate CA allows you to take your root CA offline, which greatly increases the security of the root CA. After all, if the root CA is unplugged, it is invulnerable to network attacks.

Subordinate CAs that do issue certificates to end users are known as issuing CAs. Of course, root and intermediate CAs are also capable of issuing certificates to end users. Figure 7.1 shows the relationships between root, intermediate, and issuing CAs and the users and computers who use certificates.

click to expand
Figure 7.1: A CA hierarchy

You add a subordinate CA to a CA hierarchy by using the same process you use to create a root CA. However, you will need to specify that the computer is an enterprise or standalone subordinate CA, as shown in Figure 7.2. Then you will have to specify the parent CA and provide credentials on the root CA. If you are creating an enterprise subordinate CA, you must provide the user name and password of an account in the Domain Admins group. The entire process of adding a subordinate CA can be accomplished in just a few minutes.

click to expand
Figure 7.2: Creating a subordinate CA

You will need to spend a few additional minutes if you are using an offline CA, because you must perform an offline certificate request. On the CA Certificate Request page of the subordinate CA installation process, select Save The Request To File instead of Send The Request Directory To A CA. After you complete the installation of the subordinate CA, you will need to transfer the certificate request to the parent CA. On the parent CA, use Web enrollment to perform an advanced certificate request, and select the Submit A Certificate Request By Using A Base-64-Encoded CMC Or PKCS #10 File, Or Submit A Renewal Request By Using A Base-64-Encoded PKCS #7 File option. You will then need to use the Certification Authority console to issue the certificate before transferring it back to the subordinate CA to be installed. Exercise 2 in this lesson will guide you through this process.

You can use qualified subordination to exhibit a great deal of control over what subordinate CAs are allowed to do. For example, you can configure a subordinate CA so that it only issues certificates for a specific namespace, such as partners.cohowinery.com. You can also restrict a subordinate CA to issuing specific types of certificates. This would allow you to create a subordinate CA that issued only smart card certificates. Configuring these options is complex, however, and outside the scope of this book.

See Also 

For more information about qualified subordination, read the white paper titled 'Planning and Implementing Cross-Certification and Qualified Subordination Using Windows Server 2003' at http://www.microsoft.com/technet/prodtechnol/windowsserver2003/plan/ws03qswp.asp.

Disaster recovery

Like any other critical service, Certificate Services must be backed up so that they can be restored if a hardware failure or other adverse event occurs. You can back up Certificate Services by using the Certification Authority snap-in, the Backup Utility, or other software.

To manually back up Certificate Services, open the Certification Authority console, right-click the name of your computer, click All Tasks, and then click Back Up CA. The Certification Authority Backup Wizard appears to guide you through the backup process. As shown in Figure 7.3, you can choose to back up the private key and CA certificate, the certificate database, or both. You will be prompted to provide a password that will be used to encrypt the backup file. You will need to have this password to recover the backup.

click to expand
Figure 7.3: Backing up a CA

To restore Certificate Services, open the Certification Authority console, right-click the name of your computer, click All Tasks, and then click Restore CA. You will be prompted to stop Certificate Services. Then the Certification Authority Restore Wizard will appear to guide you through the backup process. During the restore process, you will be prompted for the password you used when creating the backup. After successfully restoring the CA, you will be prompted to restart Certificate Services.

When you use the Backup Utility, Certificate Services is automatically backed up with the system state. If you are using non-Microsoft backup software, and you almost certainly are if your organization has more than one computer, contact the software vendor to make sure that it backs up Certificate Services. Even better, perform a test backup and restore of the server.

Auditing

As with most components of Windows Server 2003, you can and should audit Certificate Services events that might be useful in identifying attacks. To audit Certificate Services events, first enable the Audit Object Access Group Policy setting for the CA. Then open the Certification Authority console, right-click the CA, and click Properties. Click the Auditing tab, and then select the events you want to audit. You can choose from the following self-explanatory events:

  • Back up and restore the CA database

  • Change CA configuration

  • Change CA security settings

  • Issue and manage certificate requests

  • Revoke certificates and publish CRLs

  • Store and retrieve archived keys

  • Start and stop Certificate Services

Practice: Configuring a CA Hierarchy

In this practice, you will configure Computer1 as a root CA and Computer2 as a subordinate CA. To complete these exercises, Computer1 and Computer2 must both be domain controllers in the same domain, as described in the 'Before You Begin' section of this chapter.

Exercise 1: Creating a Root CA

In this exercise, you will install Certificate Services on Computer1 and configure Computer1 as an enterprise root CA.

  1. Log on to the cohowinery.com domain on Computer1 using the Administrator account.

  2. Open Add Or Remove Programs in Control Panel.

  3. Click Add/Remove Windows Components.

  4. In the Windows Components Wizard, select the Certificate Services check box. When prompted, click Yes.

  5. Click Next.

  6. At the CA Type dialog box, click Enterprise Root CA, and then click Next.

  7. In the Common Name For This CA box, type computer1. Click Next.

    Note that the default validity period is 5 years, as shown in Figure 7.4.

    click to expand
    Figure 7.4: Specifying the common name for a CA

  8. On the Certificate Database Settings page, accept the defaults by clicking Next. If prompted to stop Internet Information Services (IIS), click Yes.

  9. After Certificate Services is installed, click Finish. Close all open windows.

Exercise 2: Creating a Subordinate CA

In this exercise, you will install Certificate Services on Computer2 and configure Computer2 as a subordinate CA to the enterprise root CA, Computer1.

  1. Log on to the cohowinery.com domain on Computer2 using the Administrator account.

  2. Open Add Or Remove Programs in Control Panel.

  3. Click Add/Remove Windows Components.

  4. In the Windows Components Wizard, select the Certificate Services check box. When prompted, click Yes.

  5. Click Next.

  6. In the CA Type dialog box, click Enterprise Root CA, and then click Next.

  7. In the Common Name For This CA box, type computer2. Click Next.

  8. On the Certificate Database Settings page, accept the defaults by clicking Next.

  9. On the CA Certificate Request page, click Save The Request To A File. Click Next.

    Note that the default location for the certificate request is C:\computer2.cohowinery.com_computer2.req.

  10. If prompted to stop IIS, click Yes.

  11. When notified that the Certificate Services installation is incomplete, click OK.

  12. After Certificate Services is installed, click Finish. Close all open windows.

    At this point, you have installed Certificate Services on Computer2, but it does not yet have a certificate CA. In the following procedure, you will submit the certificate request to Computer1, which will generate a subordinate CA certificate that you will install on Computer2.

  13. Start Microsoft Internet Explorer.

    This exercise demonstrates how to perform an offline certificate request. To simplify the exercise, you will submit the request to Computer1 across the network. This would not be possible if Computer1 were offline. In a production environment, you would need to save the certificate request file to some form of removable media and transfer it to the root CA, and then submit the request from the root CA itself.

  14. In the address bar of Internet Explorer, type http://computer1/certsrv. Click Go.

  15. If you are not automatically authenticated, provide your user name and password when prompted, and then click OK. If you are notified that content from the Web site will be blocked, add Computer1 to the list of trusted computers.

  16. Click Request A Certificate.

  17. Click Advanced Certificate Request.

  18. Click Submit A Certificate Request By Using A Base-64-Encoded CMC Or PKCS #10 File, Or Submit A Renewal Request By Using A Base-64-Encoded PKCS #7 File.

  19. Open the certificate request you created in step 9 by clicking Start, clicking Run, typing Notepad C:\computer2.cohowinery.com_computer2.req, and then clicking OK.

  20. Press Ctrl + A to select the entire contents of the file, and then press Ctrl + C to copy the contents to the clipboard.

  21. Return to Internet Explorer. Click the Saved Request field, and then press Ctrl + V to paste the certificate request into the form, as shown in Figure 7.5.

    click to expand
    Figure 7.5: Requesting a subordinate CA certificate

  22. Click the Certificate Template field, and then click Subordinate Certification Authority. Finally, click Submit.

  23. On the Certificate Issued page, click Download Certificate. When prompted, click Save, and save the file on the desktop. Click Close.

    You have submitted the certificate request and it has been approved. The final step is to install the subordinate CA certificate.

  24. Start the Certification Authority console.

    Notice that Certificate Services is not started because the subordinate CA certificate has not been installed.

  25. Right-click Computer2, click All Tasks, and then click Install CA Certificate. Browse to the desktop. In the Files Of Type box, select X.509 Certificate. Click the new certificate, and then click Open.

  26. Right-click Computer2, click All Tasks, and then click Start Service.

    Computer2 will start successfully. This exercise demonstrated the process of configuring a subordinate CA to an offline root CA. If the root CA were online, you could have configured the subordinate CA entirely from the Windows Components Wizard.

Lesson Review

The following questions are intended to reinforce key information presented in this lesson. If you are unable to answer a question, review the lesson materials and try the question again. You can find answers to the questions in the 'Questions and Answers' section at the end of this chapter.

  1. Which of the following scenarios would use public key encryption to keep a message sent from User A to User B private?

    1. User A encrypts a message with User B's public key.

    2. User A encrypts a message with User A's public key.

    3. User B encrypts a message with User B's private key.

    4. User B encrypts a message with User A's public key.

  2. Which of the following is a feature unique to enterprise CAs?

    1. Web enrollment.

    2. Certificate autoenrollment.

    3. Certificates can be revoked.

    4. Certificates can be renewed prior to their expiration date.

Lesson Summary

  • Public key encryption uses two keys to encrypt and decrypt messages. A message encrypted with one key can be decrypted only with the second key in the key pair, and vice-versa.

  • To send a private message by using public key encryption, encrypt the message with the recipient's public key. Only the private key can be used to decrypt the message.

  • Public key encryption can be used to digitally sign messages, which proves that the message was sent by the holder of the private key, and that the message was not modified.

  • A PKI is used to manage keys and to distribute keys to a large number of users. A PKI consists of many components, including CAs, certificates, and CRLs.

  • A CA issues certificates to end users. A certificate is only as trustworthy as the CA that signed it.

  • Certificates expire at a time specified when the certificate is generated. CRLs are used to revoke certificates before that specified expiration date.

  • Root CAs cannot issue certificates that are valid beyond the CA's certificate's expiration date. Specifying a long lifetime for the root CA reduces labor, but this might increase your vulnerability to brute force attacks.



 < Day Day Up > 



MCSA(s)MCSE Self-Paced Training Kit Exam 70-299 (c) Implementing and Administering Security in a M[.  .. ]twork
MCSA/MCSE Self-Paced Training Kit (Exam 70-299): Implementing and Administering Security in a MicrosoftВ® Windows Server(TM) 2003 Network (Pro-Certification)
ISBN: 073562061X
EAN: 2147483647
Year: 2004
Pages: 217

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net