Public Key Infrastructure in Windows 2000

Implement powerful and flexible security

The explosive growth of the Internet, e-commerce, and data communications challenges fundamental network security technologies. When companies don't have an adequate security infrastructure, intruders can enter corporate networks and steal or tamper with sensitive business information. To protect your business, you must apply cryptographic technologies in your network. Public key cryptography, digital certificates, Certificate Authorities (CAs), and security policies pertaining to public keys are known collectively as public key infrastructure (PKI). Microsoft has built a comprehensive PKI into Windows NT 4.0 and Windows 2000 (Win2K­formerly NT 5.0) that can compete withthird-party solutions in the Windows environment. In particular, PKI in Win2K lets you establish and customize a comprehensive PKI for your enterprise. In this article, I'll take you on a tour of most of the components that make up Microsoft's PKI. Although I will point out PKI components in NT 4.0, I'll focus my discussion on PKI in NT 5.0.

PKI Basics
Public key cryptography uses two keys--­a public key to encryptinformation and a private key to decrypt information--­to provide a high level of security in private intranets and the public Internet. Users keep their private key private--­for example, by storing it in their local computer. Users publish their public key to the public--­for example, by listing their public key in their company's directory. You use a person's public key to encrypt a message to that person or to verify that person's digital signature. You use your private key to decrypt messages others send to you via your public key. CAs certify public keys with digital certificates, and they manage complicated key and certificate transactions (e.g., provide key backup and recovery; certificate storage; and key publishing, retrieval, renewal, and revocation). To learn more about CAs, the services they provide, and digital certificates, see "You Can Be a Web Certification Authority," October 1997.

Although digital certificates provide the means to validate public keys, companies still need to define policies governing how to use certificates and public keys. For example, if a company uses public key encryption to exchange secure email messages with its business partners, the company needs to define whether its users must encrypt messages, digitally sign messages, or do both. The company also needs to define how to establishtrust relationships between its CA and its partners' CAs. Microsoft's PKI gives your company the means to define and implement effective certificate and public key policy, and it lets you establish a variety of trust relationships between CAs.

Microsoft PKI Components
The foundation of Microsoft's PKI is its cryptographic API--­CryptoAPI 2.0. This API provides a cryptographic service and a certificate management service for public key security. CryptoAPI's cryptographic service performs functions such as key generation, message hashing, digital signature, and encryption. The certificate management service provides X.509v3 digital certificate management and storage. PKI in Win2K comprises various components: Cryptographic Service Providers (CSPs), Certificate Server, smartcard service, a secure channel, Authenticode, Encrypting File System (EFS), Microsoft Exchange Server Key Management (KM) Server, and PKI applications. Figure 1 shows the components and architecture of Win2K's PKI.

Win2K has a modular PKI architecture, which lets administrators easilyupgrade, integrate, extend, and develop their enterprise's PKI without changing underlying OS kernels. For example, Exchange Server 5.5 uses only its KM server to issue and manage Exchange Server client certificates. With Service Pack 1 (SP1) in Exchange Server 5.5, Exchange Server uses Certificate Server, rather than Exchange Server KM Server, to issue and manage Exchange Server client certificates. (To learn more about Exchange Server KM Server, see Tony Redmond, "Maintaining Secure Exchange Servers," October 1997.)

Developers can build PKI-enabled applications based on Microsoft-provided PKI components and CryptoAPI. For example, you can employ CryptoAPI and digital certificates to encrypt and authenticate messages in Microsoft Message Queue Server (MSMQ) applications. You can also selectively use Microsoft PKIcomponents according to your business needs. For example, if your companyrequires a secure Web site, you can use Certificate Server and the securechannel function built into Internet Information Server (IIS) and InternetExplorer (IE).

Let's take a closer look now at some of Win2K's PKI components. I'lldescribe CSPs; Certificate Server, its Certificate Manager and CertificateServer Manager tools, and the certificate policies it generates; smartcardservice; the secure channel function; Authenticode; and EFS.

Cryptographic Service Providers
CSPs implement specific security algorithms and key strength based onsecurity requirements (e.g., 1024-bit RSA public key generation, 128-bit RC2 and RC4 encryption, 56-bit Data Encryption Standard--­DES). You can configure one application with different CSPs according to your business' needs and export restrictions. For example, you might use Microsoft Enhanced Cryptographic Provider (which supports 1024-or-greater-bit RSA public key, 128-bit RC2/RC4, DES, and 3DES) in North America, and Microsoft Base Cryptographic Provider (which supports 512-bit RSA public key and 40-bit RC2/RC4) outside North America to comply with export laws. When you need to specify a CSP in an application, simply choose the CSP you want from NT's installed CSPs. Screen 1 shows how you can easily choose a CSP by using Certificate Server's Certificate Template Wizard.

In addition to the base and enhanced CSPs that Microsoft includes in NT4.0, Win2K includes more CSPs to meet your security needs--­for example, RSA, Digital Signature Standard (DSS), Diffie-Hellman, and various base smartcard CSPs. Third-party developers can write proprietary CSPs that you can install after Microsoft ap-proves the CSPs' use in NT. For example, Datakey, a company providing smartcard products, shipped a Microsoft-approved CSP called SignaSURE Cryptographic Provider, which fulfills all major cryptographic functions in smartcards.

Physically, a CSP is a .dll file. Most CSPs are software-based, but you can implement a CSP on hardware. For example, a vendor might implement itsproprietary smartcard CSP in its smartcard reader adapter to heightenperformance and efficiency.

Certificate Server
Microsoft delivered Certificate Server 1.0 in IIS 4.0 for NT 4.0 and isbuilding a new version of Certificate Server in Win2K. Both versions let you request, issue, and manage keys and X.509v3 certificates. Certificate Server 1.0 provides a simple Web interface for certificate request and management, which Screen 2 shows. A user can retrieve a CA certificate and request client certificates via the Certificate Enrollment Tools hotlink after connecting an IE or Netscape browser to the certificate server. Administrators can issue and revoke certificates via the Certificate Administration Queue Utility hotlink. Certificate Server 1.0 also supplies several command lines for advanced operations, such as Web server certificate issuance and key and certificate database backup and restoration. You can use Certificate Server 1.0 to issue Web certificates in your intranet. Unfortunately, Certificate Server 1.0 lacks a comprehensive administrative GUI to customize certificate types and policysettings. You must use the Certificate Server software development kit (SDK) for customization.

Compared with Certificate Server 1.0, Certificate Server in Win2K takes a big leap forward in functionality. In addition to Web interface support, Win2K's Certificate Server provides two user-friendly GUI tools for certificate and key management, Certificate Manager and Certificate Server Manager. Both tools are Microsoft Management Console (MMC) snap-ins. Certificate Manager is a client tool for requesting and managing CA and client certificates in a client computer. Certificate Server Manager is an administrative tool for issuing, revoking, and managing certificates in the certificate database and executing other administrative tasks, such as key and certificate database backup and restoration. Certificate Server in Win2K takes full advantage of Win2K's policy features and Active Directory (AD), using AD to store and publish certificates. Certificate Server in Win2K uses Group Policy Editor, an MMC snap-in, to set upcertificate policies in AD. Figure 2 shows the basic components and functions of Certificate Server in Win2K.

Certificate Manager. Certificate Manager manages client and CA certificates a client computer keeps in five certificate stores: personal, trusted-root CA, intermediate CA, enterprise-trusted CA, and AD user object. From within the personal store, you can request a client certificate from a CA by using the certificate request wizard. When the CA grants your request andissues the certificate, you can either immediately install the certificate intothe personal store or install it into the personal store later by searching forthe certificate in AD and retrieving it into the personal store. A certificatein the personal store can reside in the local machine's Registry or in asmartcard. In addition, you can renew expired certificates and restore current valid certificates that you have lost in your local machine from within the personal store.

Certificate Server in Win2K can issue three kinds of client certificates: user, computer, and NT service. However, each type of client certificate requires a separate Certificate Manager snap-in in MMC.

Certificate Manager preinstalls several public CA certificates (e.g., AT&T's,GTE's, and VeriSign's) in the trusted-root CA store. If your company's CA inWin2K is a root CA (i.e., a CA that issues and signs its CA certificate), youplace that CA's certificate in the trusted-root CA store.

Certificate Server in Win2K supports CA hierarchy, also called certificatehierarchy. In a CA hierarchy, you can have a public root CA issue your company'sCA certificate. If you do so, your Win2K CA becomes a subordinate CA of thepublic root CA. You store the subordinate CA certificate in the intermediate CAstore. Using the CA hierarchy, you can easily establish CA trust relationshipswith other companies and your business partners. For example, if Company X is asubordinate CA of the public-root CA of which your company is also asubordinate, your company's CA and Company X's CA automatically trust eachother. You save your trusted CA certificates in the enterprise-trusted CA store.In addition to the personal, trusted-root CA, intermediate CA, andenterprise-trusted CA stores, which physically keep client and CA certificates,Certificate Manager provides an AD user object store. The AD user object storedoesn't physically contain certificates but rather supplies pointers that pointto a particular user's certificates published in AD. The AD user object storelets users easily identify all of their certificates, including those they havenot retrieved into their personal store.

Certificate Server Manager. Certificate Server Manager inCertificate Server manages four lists: issued certificate, failed request,pending request, and revoked certificate. Certificate Server Manager alsoperforms other administrative functions, such as backup and restoration of keysand certificates and configuration of policy and exit modules.

Certificate Server stores issued certificates in the issued certificatelist and publishes them in AD. The server's policy module compares the requestinformation against the server's defined policies to determine whether theserver should grant, deny, or suspend a certificate request. If the policymodule finds that the request matches a policy, the module composes certificateproperties such as a subject name, public key, email address, organization name,and key usage and certificate path and generates an X.509v3 certificate. Theserver's exit module sends the issued certificate to the client and publishes itin AD. Certificate Server rejects a certificate request if the policy modulefinds unmatched criteria in a policy. For example, if the client requests asales certificate but doesn't belong to the sales group in the sales certificatetemplate's access control list (ACL), Certificate Server rejects the request.The server places rejected requests in the failed request queue. If the policymodule can't find a policy to match against a request, the server will save therequest in the pending request list for a manual process a CA administrator orsecurity systems administrator must perform.

Using Certificate Server, you can revoke client certificates if userscompromise their private key or leave the company. Certificate Server storesrevoked certificates in the revoked certificate list and publishes the list inAD, so applications that use certificates can verify a certificate's status fromthe revoked certificate list. Certificate Server can automatically update therevoked certificate list at intervals you define, such as once a day. You canalso manually update the revoked certificate list immediately after certificaterevocation.

Certificate Server is an open platform on which you can develop your ownpolicy and exit modules with the SDK if the defaults don't meet yourrequirements. For example, if you want to publish certificates in a separatedirectory from AD, you can write a new exit module to replace the default exitmodule in Certificate Server. Using Certificate Server Manager, you can alsoeasily back up CA private keys and certificates and all issued and revokedcertificates to files so that you can restore them in case of disaster.

Certificate policies. Certificate Server in Win2Kautomatically installs a set of default certificate templates in a group policyobject (GPO) in AD. A certificate template consists of a list of definablepolicies governing how to generate and use the certificate. For example,you can use a certificate for secure mail, client authentication, and EFS, andyou can use the certificate's public key for digital signature and dataencryption. The certificate template includes an ACL in which you can specifywhich users and groups in AD can request the certificate. The GPO is a securitypolicy store in which you can define security policies for users and machines.The default public key security policies in the GPO contain several usercertificate templates, such as User and Administrator, and machine certificatetemplates, such as Web Server and Computer. Certificate Server preinstalls thesedefault templates to its policy settings. Screen 3, page 100, shows CertificateServer's policy settings in the right-hand pane of the MMC management window.

If the default templates don't meet all your needs, you can create customcertificate templates in the GPO. For example, I added a Sales certificatetemplate to the policy settings, as Screen 3 shows. When you create a customcertificate template, you need to use the Group Policy Editor to manipulate theGPO of the certificate server. (I named my GPO "CA" Policy, as you seein the left pane of Screen 3.) The GPO contains two certificate templatefolders--­ User Settings and Computer Settings. User Settings holdsthe user certificate templates, and Computer Settings holds the machinecertificate templates. To create a new template, use the template creationwizard in one of the template folders. Then, add the newly created template tothe policy settings in Certificate Server Manager.

You can also configure the automatic certificate request settings in UserSettings and Computer Settings to let a user's computer automatically receive aparticular certificate the next time the user logs on to AD. For example, if youadd the Sales certificate template to the automatic certificate requestsettings, everyone in the Sales group will receive the certificate the next timethey log on to AD.

Smartcard Service
Smartcard service is an important component in Microsoft's PKI in Win2K. Asmartcard is a password-protected, credit card-sized device that consists of an embedded 8-bit microprocessor, cryptographic coprocessor, and local storage. The card runs a special purpose card-operating system that resides in a 6KB to 24KB ROM chip. A 1KB to 16KB erasable programmable ROM (EPROM) chip can store limiteduser data, such as certificates and private keys. EPROM chips have only 128bytes to 512 bytes of RAM for run-time data.

You can store a Certificate Server-issued certificate in a smartcard. Then,if you have a smartcard reader attached to your computer--­whether in theoffice, at home, or on the road--­you can access the certificate. Thesmartcard's portability lets you use a certificate on any computer with asmartcard reader. To ensure compatibility and interoperability betweensmartcards and smartcard readers, the International Organization forStandardization (ISO) developed the ISO 7860 standard for smartcard hardware.ISO 7860, however, doesn't address interoperability between smartcards and PCs.Microsoft and other vendors formed a Personal Computer/Smart Card (PC/SC)workgroup and developed a PC/SC specification based on ISO 7860 to standardizesmartcards and smartcard readers that interface with PCs. Microsoft alsodelivered a device-independent smartcard SDK for developers to use to writesmartcard-enabled applications in the Windows environment. Win2K includes aMicrosoft-based smartcard cryptographic service provider to support PC/SC- andISO 7860-compliant smartcards and smartcard readers.

An important use of smartcards in Win2K is for public key logon. You can use the certificate in your smartcard to log on to a Win2K domain instead of going through the regular NT logon process. Figure 3 depicts the smartcard logon process. When you insert your smartcard into the smartcard reader on yourcomputer, Win2K prompts you to enter your personal identification number (PIN)in a smartcard logon window. If NT authenticates you as the owner of the card,the Local Security Authority (LSA) in your computer retrieves the certificatefrom the smartcard and sends it to the Kerberos Key Distribution Center (KDC),which is a Win2K domain controller. After the KDC verifies your certificate'svalidation and issuer (i.e., CA), the KDC uses the subject name in thecertificate as a reference to look up your user object in AD. When the KDC findsthe object, it builds a Kerberos ticket-granting ticket (TGT), which containsyour user account and access control information. The KDC encrypts the TGT witha session key, which your public key then encrypts, and returns the TGT to yourcomputer. Your smartcard decrypts the session key with your private key, whichthe smartcard contains, and uses the session key to decrypt the TGT. Finally,the KDC lets the LSA log you on to the Win2K domain. (To learn more aboutKerberos user authentication in Win2K, see Michael E. Chacon, "Kerberos Ison Guard in Windows NT 5.0," October 1997.)

In addition to smartcard logon, you can use Win2K's smartcard service forother PKI operations, such as client and server authentication in Secure SocketsLayer (SSL). To fully leverage your smartcard, you can integrate other securityfunctions, such as your company ID information and bank automatic teller cardauthorization, into the smartcard containing your digital certificate.

Secure Channel
Win2K incorporates a secure channel that supports SSL protocol, which manycompanies use to secure Web communications over the Internet. The InternetEngineering Task Force (IETF) has ratified SSL as an Internet standard andrenamed it Transport Layer Security (TLS). Microsoft's secure channel alsoincludes Server Gated Cryptography (SGC), an extension to SSL 3.0 using 128-bit encryption to secure online banking sessions. IE 3.0 and earlier, and IIS 3.0 support SSL/TLS; IE 4.0, IIS 4.0 and later, and Money 98 support SGC.

Compared with SGC, SSL/TLS is a general-purpose protocol. You can use SSL/TLS for any kind of Web site. Because of US export limitations on powerful cryptography, SSL/TLS implements two versions of IE: One version has 128-bit encryption for North America, and the other version has 40-bit encryption for international use. However, banks and financial institutions require powerful cryptography to protect customers using online access over the Web. The US government lets international financial organizations use SGC between the United States and almost every other country. Microsoft has built SGC into 40-bit and 128-bit IE 4.0 and 5.0 browsers. Only when the Web server that the browser communicates with is equipped with an SGC server certificate can the browser use the SGC function for 128-bit encryption.

Let's look at how SSL/TLS and SGC use certificates and public keys toestablish a secure channel between a client and a server. In SSL/TLS, the clientfirst sends a hello message to the server, and the server greets the client bysending its server certificate to the client. The client authenticates theserver by using the CA's public key, which the client extracts from the CAcertificate stored in the client, to check the CA's signature in the server'scertificate. The server can optionally authenticate the client by asking for andchecking the client's certificate (in IIS 3.0 and later versions, administratorscan choose the option of having the server authenticate the client). After theclient authenticates the server, the client generates a 40-bit or 128-bitsession key, according to security restrictions. The client then encrypts thesession key with the server's public key (extracted from the server'scertificate) and sends the encrypted session key to the server. The serverdecrypts the received session key using its private key. Now the server andclient can exchange data encrypted with this session key.

You can use certificates Win2K's Certificate Server or other CAs issue forSSL/TLS. To use SGC, however, you must request an SGC server certificate from an authorized CA, such as VeriSign, that will examine your eligibility. SGC uses a handshake sequence similar to the sequence that SSL/TLS uses to set up a secure session, but SGC differs from SSL/TLS in two ways. First, in SGC, the client resets and restarts the handshake sequence when it determines that the server certificate is an SGC certificate after the first hello exchange. Second, in SGC, the client always generates a 128-bit session key after resetting the handshake sequence and server authentication.

Authenticode
Microsoft's PKI offers a code-signing technology called Authenticode thatensures the integrity and origin of commercial and free software distributedover the Internet. Authenticode, based on digital signature technology, adds adigital signature, a code-signing certificate, and a time stamp into suchsoftware codes as Java applets, ActiveX controls, .dll files, executable files,cabinet files, and catalog files. Authenticode also verifies downloaded codebefore you run it on your system. To sign and verify code, Authenticode uses twotechniques: code signing and code verification.

Before you can sign code to guarantee its integrity and origin, you mustobtain a code-signing or software-publishing certificate from a CA. You can thenuse the Authenticode signing functions the ActiveX SDK provides to sign thecode. You pass the code you want to authenticate through a hashing algorithm anduse your private key to sign the hash, which results in a digital signature. Youthen build a signature block, which contains the digital signature and thecode-signing certificate. Authenticode lets you time stamp the signature blockbased on the current date and time that a time stamping service provider, suchas VeriSign, provides. Finally, you bind the time stamped signature block to theoriginal software. Now you can publish the signed software on your Web site fordownload.

The ActiveX SDK also supplies a code-verification function to verifydownloaded software before you execute it. Microsoft has incorporated thisfunction in IE 3.0 and later versions. Before IE runs signed code, it will callup the code-verification function to check the signature, publisher'scertificate, and time stamp. After verification, the code-verification functionwill display the name of the code, the name of the organization or person whopublished the code, when the publisher authenticated the code, and the name ofthe CA that issued the code-signing certificate. The user decides whether totrust the publisher. Screen 4, page 102, shows a sample code-verification display. The display confirms that the verified code is an ActiveX control to capture the product ID in the local computer, that Microsoft signed the code at 9:42 a.m. on July 16, 1998, and that VeriSign issued the code-signing certificate. When you click Yes in a code-verification display, your browser will install and run the verified code.

In IE, you can set up a security policy for Authenticode with four securitylevels: high, medium, low, and custom. The high level doesn't execute damagedcode; the medium level warns you before running potentially damaged code; thelow level always executes any code; and the custom level lets you choosesecurity settings, such as to enable ActiveX or to disable Java applets. You canalso define different levels for different security zones, such as the Internet,intranets, trusted sites, and restricted sites in IE.

Encrypting File System
Win2K introduces EFS, a new security feature, in NTFS. EFS lets you encryptfiles and directories in a local or remote computer. Figure 4 shows how EFS usespublic keys for data encryption, decryption, and recovery.

Before you can use EFS, you need to create a data recovery agent. You useGroup Policy Editor in the Win2K domain in which you want to use EFS. The datarecovery agent contains a pair of public keys. A domain's data recovery agentcan recover encrypted data in any Win2K computers in the domain if an original file's owner loses a private key. You can create a local data recovery agent in a local computer if the computer doesn't belong to a domain.

When you encrypt a file, EFS randomly generates a file encryption key (FEK) and uses this FEK to encrypt the file. To encrypt the FEK, EFS uses your public key, which EFS retrieves from your certificate, and saves the encrypted FEK to the Data Decryption Field (DDF) along with the file.

If you don't have a certificate, EFS simply generates a pair of keys--­one public key and one private key--­for you. If multiple users share the file, EFS will use a user's public key to encrypt the FEK for that user and save each encrypted FEK to the DDF. EFS encrypts the FEK a second time using the data recovery agent's public key and inserts the encrypted FEK into the Data Recovery Field (DRF) of the file. The EFS process is transparent; you simply enable the file encryption attribute in the advanced attribute list of a file's properties in Windows Explorer.

When you access an encrypted file, EFS automatically decrypts and opens the file for you if you are on the DDF list. If you are not on the DDF list, EFS denies access. When EFS decrypts a file, it locates your private key, uses this key to decrypt the FEK in your DDF, and decrypts the file using the FEK. EFS uses the same method to recover data with the data recovery agent's private key.

Building Security on PKI
I've given you a brief outline of Microsoft's rich set of PKI solutions. Using these tools, your company can establish a comprehensive PKI that ispowerful, flexible, and customizable. When Win2K arrives, I think you'll be pleased with the power you'll have to satisfy your business security needs and to build your network security on PKI in Win2K.