• Sidebar: How Public Key Technologies Work
• Sidebar: Digital Certificates, CAs, and Trust
• Sidebar: The Problem with Passwords
• Illustration: Microsoft PKI Architectural Diagram
• Illustration: CryptoAPI
• Illustration: Cryptographic Operations

Public key cryptography can eliminate many of the security and usability problems associated with password-based logons and can provide capabilities not possible with mere passwords. However, it requires implementing a public key infrastructure (PKI), a set of components and services that allow operating systems and applications to use public-key cryptography, which can be difficult, complex, and expensive. With Windows 2000, Microsoft has eased the task by integrating all of the core software elements needed to implement a PKI, but many organizations have still been reluctant to take advantage of this technology. They shouldn't be: a PKI limited to a single organization allows it to implement stronger and easier logon security, more secure virtual private networking, and encrypted file storage, without encountering most of the cost and complexity of a PKI targeted at Internet-wide use.

Public key cryptography enables users to encrypt or decrypt data with pairs of keys: a non-secret public key published in a digital document that can’t be forged called a certificate, and a corresponding private key that only the owner named in the certificate can access. (Readers unfamiliar with the basics of public key cryptography and digital certificates should see the sidebars "How Public Key Technologies Work" and "Digital Certificates, CAs, and Trust".)

Public Key Benefits

Commercial use of public key cryptography is relatively new. However, Windows 2000 has brought together all of the necessary elements for organizations to begin reaping the some of this technology's benefits. The biggest benefit is a more secure method of authenticating users and machines on a Windows network. In addition, companies gain the ability to guarantee the confidentiality and integrity of a company's transmitted and stored data.

Public key cryptography can also facilitate secure communication and collaboration between an organization and its customers and partners over the Internet. However, Internet use of public key cryptography is still embryonic and raises issues of trust that do not apply when it is used inside a single organization.

Strengthening Windows Authentication

Authentication is the process of proving a user’s or a computer’s identity. Without solid evidence that all involved parties are who they claim to be, authorization—the process of determining what actions each user or computer is permitted to do—is meaningless. Microsoft built authentication and authorization mechanisms into the core of Windows NT and, while the latter worked well, its authentication method needed improvement.

Although Windows 2000 can still authenticate users and machines using the Microsoft-proprietary NTLM protocol, enabling backward compatibility with NT and Windows 9x, it normally uses a much stronger authentication protocol based on industry-standard Kerberos version 5. Unlike NTLM, Kerberos authenticates the server and the user to each other, eliminating the possibility of bogus servers masquerading as legitimate members of the domain, yet produces much less network traffic than NTLM and can scale to support hundreds of domains and millions of Active Directory users and computers.

Although cryptographically sound, basic Kerberos logons depend on user-remembered passwords. Password-based logons are a form of "single-factor authentication" because they are based solely on "something you know," i.e., a password or pass phrase. While this method has been used for thousands of years, it is not secure enough in today’s Internet-based computing world. (See sidebar, "The Problem with Passwords".)

In addition, the Kerberos server must also know its users' passwords. Whenever more than one entity knows a password, there's no way to prove which one was actually responsible for the action. This means that Windows Kerberos has no way to conclusively disprove that only one particular user could have carried out a particular action, such as deleting a file—in other words, this type of system has no way to assure non-repudiation.

Public key cryptography provides organizations with a much stronger way of authenticating users by avoiding reliance on shared-secret passwords. Instead, each user or computer must have sole possession of a private key that is used to identify it. For user logons, this is most commonly accomplished using a PIN-protected smart card containing the private key. Kerberos supports an extension called PKINIT that allows substitution of private keys in lieu of passwords as users’ credentials. Computers authenticate themselves using private keys stored on their hard disks.

In all cases, the private key is never shown to another party. Instead, it is used to sign some other piece of data, such as the current time or an arbitrary block of data called a "challenge" supplied by a server. If the authenticating entity can properly decrypt the signed data using the user’s public key, then the user must be authentic.

Because the private key is never disclosed, public key cryptography provides a much higher degree of non-repudiation than standard Kerberos. Smart card users' activities can be recorded to event logs tagged with their user IDs, and they cannot plausibly deny responsibility by claiming that other people learned or guessed their passwords.

Safer authentication and non-repudiation are particularly valuable when the user is accessing a company's resources remotely from home or from an off-site location. Both of the virtual private network (VPN) protocols—Point-to-Point Tunneling Protocol (PPTP) and Layer 2 Tunneling Protocol (L2TP)—can use public key technologies to authenticate users.

Other Benefits Inside Organizations

Along with providing more secure authentication, implementing public key cryptography within an organization has several other important benefits.

Encryption, integrity, and authentication of network traffic. Although Microsoft has taken great care in its operating systems and applications to ensure that passwords never transit the network in clear text, nearly all other data goes across the wire "in the clear." Someone with a packet capture program could eavesdrop on the communication and steal private information contained in the data. Although the advent of Ethernet switches has made it much more difficult to intercept a communication, this is still a risk, especially if the data stream traverses the Internet or travels over wireless protocols.

VPNs provide protection by encrypting and ensuring the origin and integrity of the transmitted data. Historically, Microsoft’s VPN technology was proprietary and targeted strictly at Windows users connecting to Microsoft-based remote access servers. But organizations that use Windows 2000 public key cryptography can take advantage of Windows 2000's IPSec protocol—a subset of Internet Protocol version 6 (IPv6) that works on today’s IPv4 networks—to ensure data confidentiality and integrity in general computer-to-computer or network-to-network communications, even with heterogeneous systems. With IPSec, each machine uses its own certificates to exchange encryption keys and sign and encrypt outgoing network packets. This enables organizations to set up secure connections between computers, firewalls, or routers over any IP network; provides a more standardized and less expensive way to connect remote offices or partner networks using the Internet rather than private WAN connections or proprietary hardware devices; and helps eliminate many forms of attacks that rely on anonymous network connections by letting organizations filter out unsigned network traffic.

Higher-level communication protocols can also use public key cryptography to provide security for communications between two particular computers. Sometimes, only certain types of traffic need extra security, and the higher overhead of IPSec—which signs and encrypts every IP packet—is not required. For instance, Microsoft Message Queue (MSMQ), Microsoft’s COM+ technology for reliably passing messages between applications, can use public key technology to sign and encrypt its messages when they traverse an unsecured network.

Encrypting File System (EFS). Files stored on disk frequently need to remain confidential, and permissions do not adequately protect against someone who can physically access the hard disk. EFS is an extension to the native Windows 2000 file system (NTFS 5) that lets users mark folders or individual files for encryption. Marked files will be unreadable without the possession of a specific private key to unlock them. EFS uses a PKI to "escrow" encryption keys so that administrators can recover the data of users who lose their keys or leave the company.

Code security. Digital signatures can also provide a means to identify the organization or individual who created a driver, program, or macro. Because many viruses use macros to do their damage, organizations can set up Office XP such that only macros signed with a trusted certificate from their firm will be allowed to execute. Windows 2000 and Internet Explorer can also disallow programs that are not signed by trusted sources.

This article is focused on intra-organizational uses of public key cryptography in Windows 2000, but readers should be aware that Windows 2000 PKI supports many other Microsoft applications and components that can use PKI services, including Authenticode, Internet Information Server (IIS), Internet Explorer (IE), Outlook, Outlook Express, Exchange 2000, Exchange 2000 Conferencing Server, and Internet Security and Acceleration (ISA) Server.

Windows 2000 PKI Components

As its name states, a PKI is an infrastructure, not a single product or server. It involves servers, clients, products, people, procedures, and policies, and is only worthwhile when there are system services or applications that can make use of it. Windows 2000 and its successors come with built-in PKI components that provide a cost-effective way of implementing smart card authentication, IPSec, and EFS. In particular, it provides Certificate Services for issuing and managing certificates, Active Directory extensions for publishing certificates and managing Group Policies that manage client-side certificate settings, and the CryptoAPI for using certificates and private keys.

(For an overview of the components of a Windows 2000 PKI, see the illustration "Microsoft PKI Architectural Diagram".)

Why a Windows 2000 PKI?

To implement a PKI, organizations could use commercial PKI products and services from vendors such as Baltimore, Entrust, or VeriSign, create and implement their own PKI using the components supplied with Windows 2000, or use some hybrid of the two. However, the Windows 2000 PKI is highly integrated with the base operating system, Active Directory (AD) and IIS, and uses the Microsoft Management Console (MMC) interface to manage all of its components. Because of this integration and because there are no incremental software licenses needed to implement the PKI, the Microsoft technology can be the cheapest and simplest solution to implement public key cryptography within a single Windows 2000 organization.

Of course, Microsoft has its own reasons for putting PKI into Windows 2000, rather than leaving it to third parties. Because a PKI is tightly linked with operating system functions like user authentication, reliance on third-party PKIs might have allowed competitors to introduce other products that weaken Microsoft’s foothold with its customers. AD is one of its crown jewels, and Microsoft wants to ensure that customers have little incentive to introduce a directory service from one of its competitors. Furthermore, integration of a complete PKI in Windows helps Microsoft improve its image as a vendor that "gets" security.

Certificate Services and Certificate Authorities

A certificate authority (CA) implemented using the Windows 2000 Certificate Service generates certificates using public keys supplied by the requesters; binds them to some form of identity such as a directory name, e-mail name, or employee ID number; sets the allowable types of use; time stamps them; and signs them with its own certificate. It also maintains lists of any certificates the organization has revoked, called certificate revocation lists, or CRLs. Each Certificate Service publishes its certificates and CRLs to the Windows 2000 AD. All server versions of Windows 2000 contain the software needed to install and manage a certificate server infrastructure.

CA architecture. Depending on the size and needs of the organization, the CA architecture can range from a single-server CA to a complex two- or three-tier CA hierarchy consisting of "root," "intermediate," and "issuing" CAs. In this model, users only interact with issuing CAs; the root and intermediary CAs' sole function is to sign the special certificates of subordinate CAs. Because users and computers interact with certificate servers infrequently, a single certificate server can service large numbers of users and computers.

However, a hierarchical model is a good idea for security reasons, not just capacity reasons. Because the root CA certificate is self-signed and all subordinate members of the PKI must trust it, the root CA’s security must never be compromised or damaged. If this happens, all subordinate CAs and all issued certificates also become invalid and the entire PKI must be rebuilt.

For this reason, Microsoft recommends never using the root CA to issue certificates to users or servers, but only to certify subordinate CAs. Windows 2000 includes a way to set up a standalone root server disconnected from the network and locked in a secure room. In this scenario, administrators use floppy disks to request and then transfer the certificates needed to sign subordinate CAs. Even if the root CA is on the network, it must be physically secure and only accessible to a limited number of administrators, and it should not host any other services, such as AD, IIS, or DNS. Special third-party hardware modules can make CAs, particularly the root CA, even more secure and robust.

Hierarchical PKIs are also beneficial in organizations with decentralized IT departments. Each division can administrate its own CA, allowing administrators to configure the enrollment permissions, available certificate templates, and auto-enrollment policy for the division’s users. These divisional administrators can also revoke certificates issued by their CA, yet they have no rights to administrate the root CA or CAs managed by other divisions.

User and administrative interfaces. Windows 2000 comes with the tools users and administrators need to interact with certificate server and their local certificate stores, including MMC-based snap-ins and Active Server Page (ASP)-based Web applications running on the issuing CAs.

Authorized users and Enrollment Officers (trusted individuals permitted to issue certificates on behalf of a user) primarily use the CA’s Web interface to request and install certificates. Savvy users can also use the "Certificates" MMC snap-in to view and manage their local certificates, manage which CAs they trust, request new certificates, and even renew existing certificates, but in most cases they will just use the Web interface. AD Group Policies can also automatically configure their lists of trusted CAs.

Administrators use the MMC "Certification Authority" snap-in to view certificates, revoke certificates, manage the CA’s own certificate, backup and restore the CA, and configure what types of certificates the CA can issue.

Active Directory Publishes Certificates and Revocations

AD plays an important role in a Windows-based PKI. When a client or server needs to retrieve a certificate or a CRL for another machine or user, it simply sends a query to its current domain controller using the Lightweight Directory Access Protocol (LDAP). This design distributes the workload across domain controllers and makes the system more robust, since administrators can occasionally take the issuing CAs offline for maintenance without affecting the PKI’s ability to use certificates and CRLs.

AD does not store private keys in any form: users’ private keys are encrypted and securely stored in the user’s local profile, on roaming profiles located on a central server, or on smart cards in their possession. Private keys for computer certificates are securely stored in local files accessible only by the computer’s System account.

Although Kerberos is solely an authentication protocol, Microsoft has extended it to carry information needed by its authorization system. By comparing the individual and group security IDs (SIDs) transmitted in the Kerberos tickets with entries in the access control lists (ACLs) associated with all Windows 2000 objects and services, the operating system can grant or deny permission to read or write to those objects.

Even though Windows 2000 Kerberos supports using a private key in lieu of a logon password, every user or computer must have an AD account because all authorization is still based on their SIDs rather than identification information contained in the certificates. For this reason, logon certificates must be mapped to computer and user accounts. Each account in AD has a user principal name, or UPN, which looks like an e-mail address (username@domain) and is unique within the organization. When the Certificate Server generates a certificate, it includes the user or computer UPN as one of the names bound into the certificate. Multiple certificates can be bound to a single AD entry, but a certificate cannot belong to two different accounts. Certificates bound to account names are visible with the "Advanced Features" view in the "AD Users and Computers" MMC snap-in.

AD allows administrators to use Group Policy to manage groups of users and Windows 2000 machines for the following PKI configuration tasks:

Auto-generation of machine certificates. To save the time and trouble of manually installing the machine certificates needed by IPSec, administrators can use Group Policies to cause any or all Windows 2000 machines to auto-enroll themselves with a specified issuing CA.

Designation of trusted root CAs and Certificate Trust Lists (CTLs). Group policy provides an easy means of centrally configuring the names of the CAs that users or machines should trust when evaluating the veracity of certificates.

Designation of EFS Recovery Agents. If a Windows 2000 workstation is using EFS, Group Policy can designate which other user account certificates will be able to decrypt the files should the primary user’s private key be lost or become unusable.

CryptoAPI Hooks PKI Components to Cryptographic Operations

Just as the Windows Printing API allows an application to print without requiring developers to write code for specific printers, and the Telephony API (TAPI) allows applications to access modems without requiring specific code for each type of device, the CryptoAPI provides a standard way for Windows 2000 protocols and applications—such as Winlogon, IPSec, and EFS—to access cryptographic functions without the need for special code. These functions are providing by libraries called Cryptographic Service Providers (CSPs). (See the illustration "CryptoAPI".)

Windows 2000 includes nine software-based CSPs that perform functions such as encryption, signing, hashing, and private key management, and they support virtually all of the commonly used hashing and encryption algorithms, with a variety of key lengths. Some of these CSPs support longer encryption keys and are subject to export restrictions, but the U.S. government substantially eased these restrictions in 2000. (For more information, see "New Rules Ease Export of Encryption" on page 14 of the Feb. 2000 Update.)

In addition to the software-based CSPs, the CryptoAPI supports interfaces to hardware security modules, or HSMs. These offload cryptographic processing and storage to external processors contained in smart cards (typically aimed at individual users) or coprocessor boards from firms like nCipher (meant for use on CAs and on servers that handle high volumes of encrypted communications).

Windows 2000 includes CSPs for Schlumberger and Gemplus smart card readers, plus communications protocols and drivers that allow these CSPs to communicate with smart cards via serial, PCMCIA, or USB readers.

Implementing a PKI

A PKI intended only for intra-organizational security purposes is simpler than an inter-organizational implementation, and issues such as standards compliance are less relevant, but it still requires careful planning. Organizations need to consider operating issues such as administration, availability, and CA server security.

Because AD is the default publisher of certificates and CRLs, public key applications do not normally need to communicate with CAs to perform routine cryptographic functions, such as encryption or signing. This means that CAs have looser uptime requirements than services like AD and Domain Name Service (DNS). However, functions such as issuing, renewing, or revoking certificates require the requested CA to be available. Because user and machine certificates normally are long-lived (the default is one year), these operations happen relatively infrequently and short maintenance outages usually have little operational impact.

However, losing a CA has serious ramifications, and administrators must ensure that they can completely recover lost CAs, especially the root CA. Special provisions in Windows 2000 certificate services enable proper backup of the private keys used by CAs to sign the certificates of end entities and subordinate CAs.

What’s Next for Microsoft’s PKI?

Microsoft’s support of PKI technology will continue to evolve, and Windows XP and Windows .NET Server will incorporate several incremental improvements.

Delta CRLs. Similar to the way AD supports replication of only directory attributes that have changed, rather than requiring the replication of entire objects, the next Windows releases will be able to query AD for only those CRL entries that have changed, reducing network traffic and speeding verification of certificates.

User auto-enrollment and renewal. Similar to the way that Windows 2000 machines can automatically get their own certificates, the next releases of Windows will support Group Policies that can automatically enroll and renew user certificates, even for smart card users.

Editable certificate templates. In the Windows 2000 PKI, administrators can use certificate templates to choose which types of certificates they want to make available to users, but these templates are non-editable. Windows .NET Server will allow administrators to edit these templates so that they could, for example, add a field to a certificate that represents the user’s employee number.

Resources

For numerous white papers on cryptography and PKI, see the "Cryptography" and "PKI and Certificates" sections at www.microsoft.com/technet/treeview/default.asp?url=/technet/security/prodtech/prodtech.asp.

For several good white papers discussing the issues surrounding identification, certificates, and trust, see www.mcg.org.br.