Security

The major components of the Windows 2000 public key infrastructure include the following:

• Windows 2000 Certificate Services

• Microsoft CryptoAPI and cryptographic service providers (CSPs)

• Certificate stores

• Certificates console

• Certification authority trust model

• Certificate enrollment and renewal methods

• Public key Group Policy

• Certificate revocation lists

• Preinstalled trusted root certificates

• Smart card support

Windows 2000 Certificate Services

You can deploy Windows 2000 Server and Certificate Services to issue and manage certificates for your organization. You can also obtain Certificate Services from a variety of third-party vendors.

Windows 2000 Certificate Services support two types of Certification Authorities (CAs): enterprise CAs and stand-alone CAs. Enterprise CAs are integrated with Active Directory and use certificate templates to specify the types of certificates that are issued by the CA. Stand-alone CAs do not require Active Directory and do not use certificate templates. For more information about Certificate Services, see Windows 2000 Certificate Services and Public Key Infrastructure in the Microsoft Windows 2000 Server Resource Kit Distributed Systems Guide .

Microsoft CryptoAPI and Cryptographic Service Providers

Microsoft CryptoAPI provides a secure interface for the cryptographic functionality that is supplied by the installable cryptographic service provider (CSP) modules. CSPs perform all cryptographic operations and manage private keys. CSPs can be implemented in software as well as in hardware. Windows 2000 Certificate Services uses CryptoAPI and CSPs to perform all cryptographic and private key management operations. CryptoAPI and CSP services are available to all services and applications that require cryptographic services.

CSPs can be software-based, hardware-based, or a combination of both. Hardware-based cryptography and key management is more secure than software-based cryptography and key management because cryptographic operations and private keys are isolated from the operating system. However, hardware-based CSPs (such as smart card CSPs) often store only a limited number of private keys and can take a long time to generate keys.

Software CSPs usually provide more flexibility than hardware CSPs, but are somewhat less secure. Nevertheless, software-based CSPs provide ample security to meet a wide range of needs. You usually use hardware-based CSPs only for special security applications, such as for logging on with smart cards or for secure Web communications with smart cards.

Vendors can develop hardware or software CSPs that support a wide range of cryptographic operations and technologies. However, Microsoft must certify and digitally sign all CSPs. CSPs do not work in Windows 2000 unless they have been digitally signed by Microsoft.

How Private Keys Are Stored

Private keys for the Microsoft RSA-based CSPs, including the Base CSP and the Enhanced CSP, reside in the user profile under RootDirectory \Documents and Settings\< username >\Application Data\Microsoft\Crypto\RSA. In the case of a roaming user profile, the private key resides in the RSA folder on the domain controller and is downloaded to the users computer until the user logs off or the computer is restarted.

Unlike their corresponding public keys, private keys must be protected. Therefore, all files in the RSA folder are automatically encrypted with a random, symmetric key called the users master key . The users master key is generated by the RC4 algorithm in the Base or Enhanced CSP. RC4 generates a 128-bit key for computers with the Enhanced CSP (subject to cryptography export restrictions) and a 56-bit key for computers with only the Base CSP (available for all Windows 2000 computers). The master key is generated automatically and is renewed periodically. It encrypts each file in the RSA folder automatically as the file is created.

The RSA folder must never be renamed or moved because this is the only place the CSPs look for private keys. Therefore, it is advisable to provide additional security. The administrator can provide additional file system security for users computers or use roaming profiles.

You should protect private keys for recovery, which is critical for backup, by exporting the certificate and private key to a floppy disk or other medium, storing the floppy disk or other medium securely, and then deleting the private key from the computer. This preserves the file from a system crash and makes it unavailable for cracking. To decrypt a data file, the recovery agent administrator inserts the floppy disk or other medium and imports the certificate and private key to the recovery agent account. For more information about how to secure recovery keys, see Windows 2000 Server Help.

Protect Folder

The users master key is encrypted automatically by the Protected Storage service and stored in the user profile under RootDirectory \Documents and Settings\< username >\Application Data\Microsoft\Protect. For a domain user who has a roaming profile, the master key resides on the domain controller and is downloaded to the users profile on the local computer until the computer is restarted.

The users master key is encrypted twice, and each instance of encryption is stored in one of two parts of the Protect file. The first part, the password encryption key, is produced by the Hash-Based Message Authentication Code (HMAC) and SHA1 message digest function and is a hash of:

• A symmetric encryption of the users master key produced by 160-bit RC4.

• The users security identifier (SID).

• The users logon password.

The second part is to create a backup form of the master key. This is needed if the users password changes on one computer but the keys are in the user profile on another computer, or if the administrator resets the users password. In either case, the Protected Storage service, which cannot detect password changes, uses the backup/restore form of the master key to regenerate the password encryption key.

To create the backup form of the master key, the users encrypted master key is sent to the Protected Storage service on the domain controller. That service uses HMAC and SHA1 again to make a hash of the master key and the domain controllers own backup master key, and sends that back to the users computer to store in the Protect file. These transmissions are authenticated (signed and encrypted) by remote procedure calls so that the users master key is never sent over the network as plaintext.

The domain controllers backup master key is stored on the system as a global Local Security Authority (LSA ) secret in the HKEY_LOCAL_MACHINE/SAM key in the registry and is replicated over the network using Active Directory. (Global LSA secrets are objects provided by the LSA to enable system services to store private data securely.)

The System Certificates, RSA, and Protect folders have their system attributes set. This prevents the files in them from being encrypted by EFS, which would make them inaccessible.

System Key

You can provide another level of protection for master keys and various other secrets through use of the system key. The system key protects the following sensitive information:

• Master keys that are used to protect private keys.

• Protection keys for user account passwords stored in Active Directory.

• Protection keys for passwords stored in the registry in the local Security Accounts Manager (SAM) registry key.

• Protection keys for LSA secrets.

• The protection key for the administrator account password that is used for system recovery startup in safe mode.

For all computers in a domain, the secret key is enabled by default and all master keys and protection keys stored on a computer are encrypted with the unique 128-bit symmetric random system key. The system key must be stored in volatile memory on the operating system during system startup to unlock the password protection key. There are three ways to configure the system key for computers:

• Use a computer-generated random key as the system key and store it on the local system by using a complex obfuscation algorithm that scatters the system key throughout the registry. This option allows you to restart the computer without having to enter the system key. This is the default configuration for the system key.

• Use a computer-generated random key, but store it on a floppy disk. The system key is not stored anywhere on the local computer, and the floppy disk must be inserted for the system to start. It is inserted when prompted after Windows 2000 begins the startup sequence, but before it is available for users to log on to the system.

• Use a password to derive the system key. The password is created by the system administrator and is not stored anywhere on the computer. Windows 2000 prompts the administrator for the password when the system is in the initial startup sequence, but before the system is available for users to log on.

The system key configuration options are available from the system key dialog boxes that appear when you run syskey . For computers in a domain, you must be a member of the Domain Admin group to run syskey . For stand-alone computers, you must be logged on as the local Administrator to run syskey . You can configure the system key differently for each computer in the domain.

System key protection is enabled by default in each Windows 2000 domain, but you might want to change the default system key option for various computers in a domain. You also might need to enable system key protection for stand-alone computers.

Certificate Stores

The Windows 2000 certificate stores include physical stores and logical stores .

Physical certificate stores are where public key objects such as certificates, certificate revocation lists (CRLs), and certification trust lists (CTLs) are physically stored either locally in the system registry or remotely in Active Directory. Many of the public key objects in the physical stores are shared among users, services, and computers through the use of logical certificate stores.

Logical certificate stores group certificates together in logical, functional categories for users, computers, and services. Logical certificate stores contain pointers to the physical certificate stores. Use the Certificates console (an MMC snap-in) to manage certificates in certificate stores. Changes to the logical certificate stores are made to the appropriate physical stores that are located in either the system registry or Active Directory. Because you use only the logical certificate store for a user, service, or computer, you neither have to keep track of where the certificates are actually stored, nor do you have to edit the system registry to manage the certificate stores.

The use of logical certificate stores eliminates the necessity of storing duplicates of common public key objects, such as trusted root certificates, CTLs, and CRLs for users, computers, and services. Users and services share many public key policy objects in common with the local computer. The common public key objects are stored in sections of the registry of the local computer. However, some certificates, CTLs, or CRLs, are issued for use only by an individual service, user, or local computer. Therefore, users, computers, and services also have individual stores that provide a place to store certificates, CTLs, or CRLs that are not shared in common. For example, a user can request and obtain a certificate or a CRL, which appears in the individuals logical store and is physically stored in the users unique certificate store in the registry. Such individual user certificates and CRLs are not shared with local computers or with services.

In addition, some public key objects, such as trusted root certificates and CTLs, can be distributed through Public Key Group Policy. Public key objects that are distributed through Group Policy are stored in special areas of the system registry and appear in the logical stores for users, computers, and services. When you use Group Policy, separate CTLs can be created for users and computers. The CTLs for users are not shared with services or the computer. However, the CTLs for computers are shared with users and services.

The logical certificate stores include the following categories for users, computers, and services:

• Personal*:* Contains individual certificates for the user, service, or computer. For example, when an enterprise CA issues you a User certificate, the certificate is installed in the Personal store for your user account. User certificates reside in Documents and Settings\< username >\ApplicationData\Microsoft\SystemCertificates\My\Certificates for each user profile. These certificates in the user profile are written to the users personal store in the system registry each time the user logs on to the computer. For roaming profiles, the users certificates are located on the domain controller so the certificates follow users when they log on to different computers in the domain.

• Trusted Root Certification Authorities : Contains certificates for root CAs. Certificates with a certification path to a root CA certificate are trusted by the computer for all valid purposes of the certificate.

• Enterprise Trust : Contains CTLs. Certificates with a certification path to a CTL are trusted by the computer for purposes specified in the CTL.

• Intermediate Certification Authorities : Contains certificates for CAs that are not trusted root certificates (for example, certificates of subordinate CAs), but that are required to validate certification paths. This store also contains CRLs for use by the user, service, or computer.

• Active Directory User Object : Contains certificates that are published in Active Directory for the user. This store appears in the Certificates console for users only, not for computers or services.

• Request : Contains pending or rejected certificate requests. This store appears only in the Certificates console after a certificate request has been made for the user, computer, or service.

• SPC : Contains certificates for software publishers that are trusted by the computer. Software that has been digitally signed by publishers with certificates in this store is downloaded without prompting the user. By default, this store is empty. When Microsoft Internet Explorer downloads for the first time software that has been signed by a software publisher, users are prompted to choose whether they want to trust all software that is signed by this publisher. If a user chooses to trust all software signed by the publisher, the publishers software publisher certificate (SPC) is added to the SPC store. This store appears in the Certificates console for the local computer only, not for users or services.

Certificates Console

The Certificates console is an MMC snap-in, which you can use to manage the certificate stores for users, computers, and services.

You can use the Certificates console to perform the following tasks:

• View information about certificates, such as certificate contents and the certification path.

• Import certificates into a certificate store.

• Move certificates between certificate stores.

• Export certificates and, optionally, export private keys (if key export is enabled).

• Delete certificates from certificate stores.

• Request certificates from an enterprise CA for the Personal certificate store.

For more information about how to use the Certificates console, see Certificate Manager Help.

Certification Authority Trust Model

The Windows 2000 public key infrastructure supports a hierarchical CA trust model and CTLs. To control the certificates that are trusted in the enterprise, you can deploy Windows 2000 Certificate Services to create CA trust hierarchies and you can create CTLs.

Certification Authority Hierarchies

The Windows 2000 public key infrastructure supports a hierarchical CA trust model, called the certification hierarchy , to provide scalability, ease of administration, and compatibility with a growing number of commercial third-party CA services and public key-aware products. In its simplest form, a certification hierarchy consists of a single CA. However, the hierarchy usually contains multiple CAs that have clearly defined parent-child relationships. Figure 13.1 shows some possible CA hierarchies.

Figure 13.1 Certification Hierarchies

The CA at the top of the hierarchy is called a root CA. Root CAs are self-certified by using a self-signed CA certificate. Root CAs are the most trusted CAs in the organization, and it is recommended that they have the highest security of all. There is no requirement that all CAs in an enterprise share a common top-level CA parent or root. Although trust for CAs depends on each domains CA trust policy, each CA in the hierarchy can be in a different domain.

Child CAs are called subordinate CAs. Subordinate CAs are certified by the parent CAs. A parent CA certifies the subordinate CA by issuing and signing the subordinate CA certificate. A subordinate CA can be either an intermediate or an issuing CA. An intermediate CA issues certificates only to subordinate CAs. An issuing CA issues certificates to users, computers, or services.

There is no restriction with regard to how deep the certification hierarchy can be. However, for many organizations, a three-level certification hierarchy (root CA, intermediate CA, and issuing CA) meets most needs.

Certification Path

A certification hierarchy forms a trust chain, called the certification path , from the certificate back to the root CA. Figure 13.2 illustrates a certification path for a four-level path that corresponds to the three-level CA hierarchy in Figure 13.1.

Figure 13.2 Trusted Certification Path

In the example, an EFS Recovery Agent certificate that was issued by Issuing CA-D has a certification path to Root CA 2 at the top of the path. The EFS Recovery Agent certificate is trusted because the certificate for Root CA 2 is contained in the Trusted Root Certification Authorities store.

The certification path links each certificate in the chain back to the root CA. Certificates that have a valid certification path to a root certificate that is in the Trusted Root Certification Authorities store are trusted for all purposes listed in the certificate. If the root CAs certificate for a certification path is not in the Trusted Root Certification Authorities store, the certification path is not trusted until the certificate of the root CA is added to the Trusted Root Certification Authorities store.

Before it trusts a certificate, Microsoft CryptoAPI validates the certification path from the certificate to the certificate of the root CA by checking each certificate in the path. Each certificate contains information about the parent CA that issued the certificate. CryptoAPI retrieves the certificate of each parent CA in the path from either the Intermediate Certification Authorities store or the Trusted Root Certification Authorities stores (if the certificates are present in the stores), or from an online location (such as an HTTP or LDAP address) that is specified in the certificate. If CryptoAPI discovers a problem with one of the certificates in the path, or if it cannot find a certificate, it does not trust the certification path.

When CryptoAPI retrieves a subordinate CA certificate for certificate path validation and the certificate is not located in the Intermediate Certification Authorities store, the API stores the certificate in the Intermediate Certification Authorities store for future reference. However, for computers that operate offline, such as portable computers that are used by mobile users, you might have to import subordinate CA certificates into the Intermediate Certification Authorities store to ensure that nonroot CA certificates are available to validate certification paths.

Figure 13.3 shows an example of a nontrusted certification path where the root certificate is not in the Trusted Root Certification Authorities store.

Figure 13.3 Nontrusted Certification Path

By default, certificates that are issued by trusted CAs are trusted for all of the intended purposes that are listed in the certificate. You can use the Certificate Details dialog box to restrict the purposes for which local certificates can be used. You can also use CTLs to establish trust for certificates and restrict the purposes for which certificates are trusted.

Certificate Trust Lists

You can use the Certificate Trust List wizard that is available from the Public Key Policy section of the Group Policy console (an MMC snap-in) to create CTLs. By using CTLs, you can choose to trust certificates that have certification paths to root CAs that are listed in the CTL. You can create CTLs for computers and users. CTLs for computers apply to all computers, users, and services within the scope of the Group Policy. However, CTLs for users apply only to users within the scope of the Group Policy. Figure 13.4 shows an example of a certification path with a CTL.

Figure 13.4 Trusted Certification Path with a CTL

In the example, the certification path from EFS Recovery Agent to Root CA 2 is identical to the certification path shown in Figure 10.3, but the certificate for Root CA 2 is not in the Trusted Root Certification Authorities store. The certification path also includes the CTL, the trust list signing certificate (CTL Signing in the example), and the root CA certificate that issued the signing certificate (Root Issuing CA in the example). The EFS Recovery Agent certificate is trusted because the certificate for Root Issuing CA (which issued the CTL Signing certificate) is contained in the Trusted Root Certification Authorities store.

A CTL must be signed by an administrator who has a valid certificate for trust list signing, such as the Administrator and Trust List Signing certificates that can be issued by enterprise CAs. By default, CTLs are valid until the trust list signing certificate expires and the CTL becomes invalid. However, to limit the time that certificates are trusted, you have the option of specifying a shorter lifetime for the CTL.

By default, members of the Domain Admins and Enterprise Admins security groups are granted permissions to enroll for Administrator and Trust List Signing certificates. To change the default certificate enrollment settings, modify the ACLs for the Administrator and Trust List Signing certificate templates.

For the CTL to be valid, the trust list signing certificate must have a certification path to a root CA in the Trusted Root Certification Authorities store. Figure 13.5 shows an example of a CTL that is invalid because the trust list signing certificate is invalid. This might be the situation because either the certification path for the trust list signing certificate does not validate to a trusted root certificate or the trust list signing certificate has expired.

Figure 13.5 Invalid CTL

CTLs are stored in the Enterprise Trust store and you can use the Certificates console to view them.

In addition, you can use CTLs to restrict the purposes for which certificates can be used. For example, even though a certificate permits the purposes of software code signing, secure mail, and client authentication, you can use a CTL to restrict certificate use to client authentication only. CTLs are frequently used to restrict trust for certificates that are issued and managed by other organizations. For example, you might configure a CTL to trust a business partners CA for only code signing and client authentication on an extranet that you manage.

Certificate Validation Process

Before it trusts certificates, Windows 2000 performs a validation check to ensure that certificates are valid and that they have a valid certification path. Figure 13.6 shows the basic certificate validation process.

Figure 13.6 Basic Certificate Validation Process

Certificates can be invalid or are not trusted for a variety of reasons, including the following:

• The start and expiration dates are improper or expired.

• The certificate format is improper (does not conform to the X.509 version 3 standard for digital certificates).

• The information in certificate fields is improper or incomplete.

• The certificates digital thumbprint and signature fail the integrity check, indicating that the certificate has been tampered with or corrupted.

• The certificate is listed as revoked in a published certificate revocation list.

• The issuing CA is not in either a trusted certification hierarchy or a CTL.

• The root CA for the certification path is not in the Trusted Root Certification Authorities store.

• The certificate is not permitted for the intended use as specified in a CTL.

Certificate Enrollment and Renewal Methods

Windows 2000 Certificate Services supports the following certificate enrollment and renewal methods:

• Manual certificate requests that use the Certificate Request wizard (only for Windows 2000 users, computers, and services).

• Automatic certificate requests, which use the Automatic Certificate Request Setup wizard (only for Windows 2000 computer certificates).

• Manual certificate requests that use the Web Enrollment Support pages (for Web browser users).

• Smart card enrollment, which uses the Smart Card Enrollment Station available in the Web Enrollment Support pages.

The enrollment methods and types of certificates that are supported by third-party Certificate Services depend on the features and functions of each third-party product. For more information, contact the vendor for the certificate service.

Manual Certificate Requests for Windows 2000–based Clients

You can request or renew certificates for Windows 2000 users, computers, and services by using the Certificate Request wizard that is available in the Certificates console. The Certificate Request wizard does not function unless an enterprise CA is online to process and issue certificate requests. The ACLs for the certificate templates determine which user accounts or computer accounts can enroll for the various types of certificates.

You can also use the Certificate Renewal wizard that is available in the Certificates console to renew certificates either before or after they expire. The Certificate Renewal wizard does not function unless an enterprise CA is online to process and issue certificate requests. You have the option of renewing certificates with the same private key and public key set. You must not renew certificates with the same private and public key sets if the maximum safe key lifetime would be exceeded.

Automatic Computer Certificate Enrollment and Renewal

You can use the Automatic Certificate Request Setup wizard (available from the Public Key section of the Group Policy console) to configure auto-enrollment for computer certificates. Auto-enrollment is not available for user certificates and does not function unless an enterprise CA is online to process certificate requests. You can configure auto-enrollment for Computer, Domain Controller, and IPSec certificates.

When auto-enrollment is configured, the specified certificate types are issued automatically to all computers that are within the scope of the Public Key Group Policy and to all computers that have Enroll permissions for that certificate type. Auto-enrollment certificates are issued the next time the computer logs on to the network.

For example, if you configure auto-enrollment for Computer certificates, the certificates are issued to all computers in the Domain Computers security group that are within the scope of the Public Key Group Policy. By default, all Windows 2000 computers are members of the Domain Computers security group, except for domain controllers, Routing and Remote Access servers, and Internet Authentication Service (IAS) servers. You can control which computers receive the Computer certificates by modifying the ACLs for the Computer certificate templates, for example, to grant Enroll permissions to a special security group composed of computers that you designate. Computers within the scope of the Public Key Group Policy that are members of the special security group are then issued Computer certificates the next time they log on to the network.

In addition, you also can use organizational units (OUs) and Public Key Group Policy for those OUs to restrict auto-enrollment to certain groups of computers. For example, you might create an IPSec Authentication OU that contains the Windows 2000 clients that you designate for IPSec authentication with certificates. To limit the scope of auto-enrollment for IPSec certificates, configure Public Key Group Policy and auto-enrollment for the IPSec Authentication OU.

When auto-enrollment is configured, the Computer certificates that are issued by auto-enrollment also are automatically renewed from the enterprise-issuing CA. You can also renew Computer certificates manually with the Certificate Renewal wizard or through the Certificate Services Web Enrollment Support pages.

Web Enrollment Support Pages

The Windows 2000 Certificate Services Web Enrollment Support pages are composed of Active Server Pages and ActiveX controls that provide a Web-based user interface to a CA. By default, the Web Enrollment Support pages are automatically installed on the computer where the CA is installed, but you also have the option of installing the Web Enrollment Support pages on another Windows 2000 Server computer.

You can use the Web Enrollment Support pages to perform the following tasks:

• Request and obtain a basic user certificate.

• Request and obtain other types of certificates by using advanced options.

• Request a certificate by using a certificate request file.

• Renew certificates by using a certificate renewal request file.

• Save a certificate request to a file.

• Save the issued certificate to a file.

• Check on pending certificate requests.

• Retrieve the CAs certificate.

• Retrieve the latest certificate revocation list from the CA.

• Enroll for smart card certificates on behalf of other users (for use by trusted administrators).

The Web Enrollment Support pages that are installed for stand-alone CAs are similar to the pages that are installed for enterprise CAs, but they differ in the respect that stand-alone CAs do not use certificate templates. For stand-alone CAs, all information about the certificate, including information about the requestor, must be specified in the certificate request. The Web Enrollment Support pages for stand-alone CAs support a number of types of certificates that have much of the same functionality as certificate types that are based on templates. You can deploy stand-alone CAs and Web Enrollment Support pages to issue most of the types of certificates that enterprise CAs can issue. However, certificates for logging on by using smart cards logon and for auto-enrollment require an enterprise CA to issue and renew the certificates.

The Web Enrollment Support pages work with Microsoft Internet Explorer 4 and Microsoft Internet Explorer 5. Use of the Microsoft Enhanced Cryptographic Provider requires Internet Explorer browsers with nonexportable cryptography. Internet Explorer browsers with exportable cryptography work only with the Microsoft Base Cryptographic Provider.

Netscape Navigator version 4. x and Netscape Communicator version 4. x work with most of the Web Enrollment Support pages. Netscape browsers do not work with the Advanced Certificate Requests form and the Smart Card Enrollment Station page because these pages use ActiveX controls. In addition, Netscape browsers use their own cryptographic security modules rather than CSPs and might not support all of the features that are available for the Microsoft CSPs.

Public Key Group Policy

Public Key settings are a subset of Group Policy. You can configure Public Key Group Policy to specify automatic enrollment for computer certificates, trusted root certificates, CTLs for computers and users, and EFS recovery agents and apply the Group Policy to sites, domains, or organizational units.

The Group Policy console is an MMC snap-in. You can use MMC to manage Public Key Group Policy for multiple sites, domains, and organizational units. You can configure Public Key Group Policy separately for users and for computers. You can use the Group Policy console to configure the following Public Key Group Policy settings for computers:

• Specify the certificates in Trusted Root Certification Authorities stores.

• Create CTLs to trust CAs and restrict the uses of certificates issued by the CAs.

• Specify automatic enrollment and renewal for computer certificates.

• Specify alternative Encrypted Data Recovery Agents for EFS.

Public Key Group Policy settings apply for computers within the scope of the Group Policy. For example, you can create an organizational unit and configure Public Key settings that apply only to the computers in that organizational unit.

You also can use the Group Policy console to configure CTLs that apply only to users within the scope of the Group Policy. For example, you can create an organizational unit and configure CTLs that apply only to the users in that organizational unit. For more information about Group Policy, see Windows 2000 Professional Help and Windows 2000 Server Help.

Certificate Revocation Lists

Windows 2000 supports industry standard X.509 version 2 CRLs. Each CA maintains a CRL for the certificates it issues and publishes the CRL-to-CRL distribution points. CRL distribution points can include Web pages, network shares, or Active Directory. An X.509 version 3 certificate usually contains the CRL distribution point for its issuing CA.

Certificate revocation checking is supported by Internet Explorer 5, Internet Information Services, and Active Directory mapping services. When revocation checking is enabled, CRLs are automatically cached on local computers to enhance revocation checking performance. If a certificate lists the CRL distribution point, the revocation checking process checks the local cache to determine whether the CRL is in the cache. If not, the revocation checking process then checks the network for the CRL. If a certificate does not list the CRL distribution point, revocation checking checks the issuing CA for a CRL, if one is available. You also can use the Web Enrollment Support pages to request the latest CRL from a CA.

When revoked certificates expire, they are removed from the next published CRL. For some large organizations with high certificate revocation rates, CRLs might become so large that it places a significant load on the network and computers during CRL publication. However, you can prevent large CRLs by deploying multiple issuing CAs to distribute the certificate load among your users and by issuing certificates with reasonably short lifetimes.

Preinstalled Trusted Root Certificates

The root CA certificates that are contained in the Trusted Root Certification Authorities store are trusted for all Windows applications that use public key certificates for security functions. Windows 2000–based computers include many preinstalled certificates in the Trusted Root Certification Authorities stores. The preinstalled trusted root certificates include root certificates from a variety of commercial CAs and Microsoft. Certificates that are issued by these trusted CAs are trusted on local computers for valid purposes. However, you might not want to trust the preinstalled root certificates, or you might want to add other certificates as trusted root certificates.

You can use the Certificates console to delete or add certificates manually for Trusted Root Certification Authorities stores on each local computer. You also can add trusted root certificates for groups of computers by using Public Key Group Policy.

In addition, you can use the Internet Explorer Administration Kit (IEAK) to create and deploy custom builds of Internet Explorer that have only the root certificates that you want for your enterprise. For example, you can create custom builds that include only a few trusted root certificates and then deploy those custom builds to groups of computers. The computers where the custom builds of Internet Explorer are installed have only the trusted root certificates that you specified. You can create different custom builds to meet the requirements of different groups in your organizations. For more information about using the IEAK, see the Microsoft Windows 2000 Server Resource Kit Internet Explorer Resource Guide .

Smart Card Support

Smart cards are credit card–sized and contain integrated circuit cards (ICCs). They can be used to store certificates and private keys and to perform public key cryptography operations, such as authentication, digital signing, and key exchange. Smart cards offer the following security enhancements and benefits:

• They provide tamper-resistant storage for protecting private keys and other forms of personal information.

• They isolate security-critical computations involving authentication, digital signatures, and key exchange from other parts of the system that do not have a specific purpose for this data.

• They enable the portability of credentials and other private information between work, home, and remote computers.

In addition, smart cards use Personal Identification Numbers (PINs) rather than passwords. The smart card is protected from misuse by the PIN, which is known only to the owner of the smart card. To use the smart card, a user inserts the card in a smart card reader that is attached to a computer and, when prompted, enters the PIN. The smart card can be used only by someone who possesses the smart card and knows the PIN.

PINs offer more protection than standard network passwords. Passwords (or derivations such as hashes ) are sent over the network and are vulnerable to attacks. The strength of the password depends on its length, how well it is protected, and how difficult it is to guess. In contrast, PINs never travel on the network, so they cannot be stolen.

Windows 2000 supports industry standard Personal Computer/Smart Card (PC/SC)–compliant Plug and Play smart cards and smart card readers that conform to specifications that have been developed by the PC/SC Workgroup. To work with Windows 2000, a smart card must conform physically and electrically to the International Organization for Standardization (ISO) 7816-1, 7816-2, and 7816-3 standards.

Smart card readers attach to standard personal computer peripheral interfaces such as RS–232, PS/2, PCMCIA, and Universal Serial Bus (USB). Readers are considered standard Windows 2000 devices, and they carry a security descriptor and a Plug and Play identifier. Smart card readers are controlled through standard Windows device drivers and are installed and removed by using the Hardware wizard.

Windows 2000 includes drivers for various commercially available Plug and Play smart card readers that are certified to display the Windows-compatible logo. Some manufacturers might provide drivers for noncertified smart card readers that currently work with Windows 2000. Nevertheless, to ensure continued support by Microsoft, it is recommended that you purchase only those smart card readers that display the Windows-compatible logo.

The Windows 2000 CSPs includes smart card CSPs from Gemplus SCA and Schlumberger Limited. These CSPs support smart cards from the respective vendors and work with all smart card readers that display the Windows-compatible logo. The smart card CSPs store the issued certificate and the private key on the smart card.

Each smart card vendor provides software that you must install and use to initialize and configure smart cards before they can be deployed. You can use the vendors software to configure PINs and to configure the number of PIN attempts that are allowed to occur before the smart card locks. You also can use the vendors software to return locked smart cards to service.

For more information about smart cards, see Choosing Security Solutions That Use Public Key Technology in the Microsoft Windows 2000 Server Resource Kit Distributed Systems Guide .