ANALYZING A COMPUTER IN THIS PROCEDURE, YOU USE THE SECURITY CONFIGURA...

2. For each of the following messaging scenarios, specify which key you should use

to encrypt the message: the sender’s public key, the sender’s private key, the

recipient’s public key, or the recipient’s private key.

a. To send a message that can’t be read by anyone but the recipient

b. To assure the recipient that the message you are sending actually came from you

Lesson Summary

■

Public key encryption uses two keys, a public key and a private key.

■

Data encrypted with the public key can only be decrypted using the private key, and

data encrypted using the private key can only be decrypted with the public key.

■

A PKI is a collection of software components and operational policies that govern

the distribution and use of public and private keys.

■

Private keys must never be transmitted over a network. Public keys are distributed

in digital certificates.

■

Certificates are issued by a certification authority (CA). You can run your own CA

using Windows Server 2003, or you can obtain your certificates from a third-party

commercial CA.

Lesson 2: Designing a Public Key Infrastructure

As with most elements of a network, implementing a public key infrastructure requires

careful planning before you begin deployment. Planning a PKI typically consists of the

following basic steps:

■

Defining certificate requirements

■

Creating a certification authority infrastructure

■

Configuring certificates

After this lesson, you will be able to ■

List the types of certificates a Windows Server 2003 CA can issue

■

Describe the structure of a CA hierarchy

■

List the differences between enterprise and stand-alone CAs

■

Configure certificate parameters

Estimated lesson time: 30 minutes

Defining Certificate Requirements

As in most phases of designing a network, the first step of the planning phase is to

determine the requirements of the users. In the case of a PKI design, you must deter-

mine what your client’s security needs are, how certificates can help provide that secu­

rity, which users, computers, services, and applications will use certificates, and what

kinds of certificates your clients need. In many cases, you will have already answered

some or all of these questions as you developed an overall security strategy.

A PKI using computers running Windows Server 2003 can create certificates that sup-

port any or all of the following applications:

■

Digital signatures Used to confirm that the person sending a message, file, or

other data is actually who he or she purports to be. Digital signatures do not pro­

tect the data itself from compromise; they only verify the identity of the sender.

■

Encrypting File System user and recovery certificates The Windows

Server 2003 Encrypting File System (EFS) enables users to store data on disk in

encrypted form, to prevent other users from accessing it. To prevent loss of data

resulting from users leaving the organization or losing their encryption keys, EFS

allows designated recovery agents to create public keys that can decode the

encrypted information. As with IPSec, EFS does not have to use the PKI for its

encryption keys, but the use of a PKI simplifies managing EFS.

■

Internet authentication You can use the PKI to authenticate clients and serv­

ers as they establish connections over the Internet, so that servers can identify the

clients connecting to them and clients can confirm that they are connecting to the

correct servers.

■

IP Security The IP Security extensions (IPSec) enable you to encrypt and digi­

tally sign communications, to prevent them from being compromised as they are

transmitted over a network. The Windows Server 2003 IPSec implementation does

not have to use a PKI to obtain its encryption keys, but you can use the PKI for

this purpose.

■

Secure e-mail Internet e-mail protocols transmit mail messages in plain text,

making it relatively easy to intercept them and read their contents. With the PKI,

you can secure e-mail communications by encrypting the actual message text

using the recipient’s public key, and you can digitally sign the messages using

your private key.

■

Smart card logon A smart card is a credit card-size device that contains mem­

ory and possibly an integrated circuit. Windows Server 2003 can use a smart card

as an authentication device that verifies the identity of a user during logon. The

smart card contains the user’s certificate and private key, enabling the user to log

on to any workstation in the enterprise with full security.

■

Software code signing Microsoft’s Authenticode technology uses certificates to

confirm that the software users download and install actually comes from the pub­

lisher and has not been modified.

■

Wireless network authentication The increasing popularity of wireless local

area networking (LAN) technologies, such as those based on the 802.11 standard,

raises an important security issue. When you install a wireless LAN, you must

make sure that only authorized users can connect to the network and that no one

can eavesdrop on the wireless communications. You can use the Windows

Server 2003 PKI to protect a wireless network by identifying and authenticating

users before they are granted access to the network.

Once you have decided what applications you want to secure with certificates, you can

create a plan indicating the level of security for each user. For example, you might

decide that you want everyone on your network to use secured e-mail, while only the

Research and Development and Accounting departments need IPSec for all their net-

work communications. Users’ locations can also be significant. You might want to use

software code signing and Internet authentication for clients who connect to your net-

work over the Internet, but omit these requirements for internal users.

When defining the certificate security requirements for your network, the best practice

is to create a small set of security definitions and apply them to your users and com­

puters as needed. For example, Table 11-1 shows a certificate plan for an organization

that includes four levels of security: basic, medium, high, and external. The basic security

level, applied to most of the users in the organization, uses certificates to provide

encrypted e-mail and EFS services. Medium-level security, which is used for general

users in more sensitive departments, adds IPSec to secure their LAN communications.

Top-level executives and people working with highly sensitive information use high

security and must use a smart card to log on to the network. Because the organization

runs a Web site where registered customers can download software products, a special

classification for external users calls for certificates that provide software code signing

and Internet authentication.

Table 11-1

Sample Certificate Plan

Basic Security Medium Security High Security External Security

Secure e-mail Secure e-mail Secure e-mail Software code signing

EFS EFS EFS Internet authentication

IPSec IPSec

Smart card logon

Creating a CA Infrastructure

Once you have decided what you are going to use certificates for and who is going to

need them, you can plan the infrastructure of certificate authorities that will provide the

certificates you need. Certificate authorities function using a hierarchy in which each

CA is validated by a CA at a higher level until you reach the root CA, the ultimate

authority for the organization. CAs issue certificates not only to applications and users,

but also to other CAs. If you trust a particular root CA, you should also trust any lower-

level CAs that are authenticated and validated by that root CA. Trusts between CAs flow

downward through the hierarchy, just as file system permissions do (see Figure 11-1).

Trust Root CA Trust Trust Intermediate CA Issuing CA Issuing CA Figure 11-1

Certification authority trusts flow downward