Public Key Infrastructure

The term public key infrastructure (PKI) is often loosely thrown around, but is not often thoroughly explained. PKI, in a nutshell, is the collection of digital certificates, registration authorities, and certificate authorities that verify the validity of each participant in an encrypted network. Effectively, a PKI itself is simply a concept that defines the mechanisms that ensure that the user who is communicating with another user or computer on a network is who he says he is. PKI implementations are widespread and are becoming a critical component of modern network implementations. Windows Server 2003 fully supports the deployment of multiple PKI configurations, as defined in the following sections.

PKI deployments can range from simple to complex, with some PKI implementations utilizing an array of smartcards and certificates to verify the identity of all users with a great degree of certainty. Understanding the capabilities of PKI and choosing the proper deployment for an organization are subsequently a must.

Private Key Versus Public Key Encryption

Encryption techniques can primarily be classified as either symmetrical or asymmetrical. Symmetrical encryption requires that each party in an encryption scheme hold a copy of a private key, which is used to encrypt and decrypt information sent between the two parties. The problem with private key encryption is that the private key must somehow be transmitted to the other party without it being intercepted and used to decrypt the information.

Public key, or asymmetrical, encryption uses a combination of two keys, which are mathematically related to each other. The first key, the private key, is kept closely guarded and is used to encrypt the information. The second key, the public key, can be used to decrypt the information. The integrity of the public key is ensured through certificates, which will be explained in depth in following sections of this chapter. The asymmetric approach to encryption ensures that the private key does not fall into the wrong hands and only the intended recipient will be able to decrypt the data.

Certificates

A certificate is essentially a digital document that is issued by a trusted central authority and is used by the authority to validate a user's identity. Central, trusted authorities such as VeriSign are widely used on the Internet to ensure that software from Microsoft, for example, is really from Microsoft, and not a virus in disguise.

Certificates are used for multiple functions, such as the following:

• Secure email

• Web-based authentication

• IP Security (IPSec)

• Code signing

• Certification hierarchies

Certificates are signed using information from the subject's public key, along with identifier information such as name, email address, and so on, and a digital signature of the certificate issuer, known as the Certificate Authority (CA).

Certificate Services in Windows Server 2003

Windows Server 2003 includes a built-in Certificate Authority (CA) known as Certificate Services. Certificate Services can be used to create certificates and subsequently manage them; it is responsible for ensuring their validity. Certificate Services is often used in Windows Server 2003 if there is no particular need to have a third-party verify an organization's certificates. It is common practice to set up a standalone CA for network encryption that requires certificates only for internal parties. Third-party certificate authorities such as VeriSign are also extensively used but require an investment in individual certificates.

Certificate Services for Windows Server 2003 can be installed as one of the following CA types:

• Enterprise Root Certification Authority The enterprise root CA is the most trusted CA in an organization and should be installed before any other CA. All other CAs are subordinate to an enterprise root CA.

• Enterprise Subordinate Certification Authority An enterprise subordinate CA must get a CA certificate from an enterprise root CA but can then issue certificates to all users and computers in the enterprise. These types of CAs are often used for load balancing of an enterprise root CA.

• Standalone Root Certification Authority A standalone root CA is the root of a hierarchy that is not related to the enterprise domain information. Multiple standalone CAs can be established for particular purposes.

• Standalone Subordinate Certification Authority A standalone subordinate CA receives its certificate from a standalone root CA and can then be used to distribute certificates to users and computers associated with that standalone CA.

To install Certificate Services on Windows Server 2003, follow these steps:

1.	Choose Start, Control Panel, Add or Remove Programs.
2.	Click Add/Remove Windows Components.
3.	Check the Certificate Services box.
4.	A warning dialog box will be displayed, as illustrated in Figure 13.4, indicating that the computer name or domain name cannot be changed after you install Certificate Services. Click Yes to proceed with the installation. Figure 13.4. Certificate Services warning.
5.	Click Next to continue.
6.	The following screen, shown in Figure 13.5, allows you to create the type of CA required. Refer to the preceding list for more information about the different types of CAs that you can install. In this example, choose Enterprise Root CA and click Next to continue. Figure 13.5. Selecting the type of CA server to install.
7.	Enter a common name for the CAfor example, CompanyABC Enterprise Root CA.
8.	Enter the validity period for the Certificate Authority and click Next to continue. The cryptographic key will then be created.
9.	Enter a location for the certificate database and then database logs. The location you choose should be secure, to prevent unauthorized tampering with the CA. Click Next to continue. Setup will then install the CA components.
10.	If IIS is not installed, a prompt will be displayed, as shown in Figure 13.6, indicating that Web Enrollment will be disabled until you install IIS. If this box is displayed, click OK to continue. Figure 13.6. IIS warning in the CA installation procedure.
11.	Click Finish after installation to complete the process.

Using Smartcards in a PKI Infrastructure

A robust solution for a public key infrastructure network can be found in the introduction of smartcard authentication for users. Smartcards are plastic cards that have a microchip embedded in them; this chip allows them to store unique information in each card. User login information, as well as certificates installed from a CA server, can be placed on a smartcard. When a user needs to log in to a system, she places the smartcard in a smartcard reader or simply swipes it across the reader itself. The certificate is read, and the user is prompted only for a PIN, which is uniquely assigned to each user. After the PIN and the certificate are verified, the user can log in to the domain.

Smartcards have obvious advantages over standard forms of authentication. It is no longer possible to simply steal or guess someone's username and password in this scenario as the username can be entered only via the unique smartcard. If stolen or lost, the smartcard can be immediately deactivated and the certificate revoked. Even if a functioning smartcard were to fall into the wrong hands, the PIN would still need to be used to properly access the system. Smartcards are fast becoming a more accepted way to integrate the security of certificates and PKI into organizations.

Encrypting File System

Just as transport information can be encrypted via certificates and public key infrastructure, so too can the NT File System (NTFS) on Windows Server 2003 be encrypted to prevent unauthorized access. The Encrypting File System (EFS) option in Windows Server 2003 allows for this type of functionality and improves on the Windows 2000 EFS model by allowing offline folders to maintain encryption sets on the server. EFS is advantageous, particularly for laptop users who tote around sensitive information. If the laptop or hard drive is stolen, the file information is worthless because it is scrambled and can be unscrambled only with the proper key. EFS is proving to be an important part in PKI implementations.

Integrating PKI with Non-Microsoft Kerberos Realms

Windows Server 2003's Active Directory component can use the PKI infrastructure, which utilizes trusts between foreign non-Microsoft Kerberos realms and Active Directory. The PKI infrastructure serves as the authentication mechanism for security requests across the cross-realm trusts that can be created in Active Directory.