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 (Win2Kformerly NT 5.0) that can compete with third-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 encrypt
information 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 establish trust 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 easily upgrade, 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 PKI components according to your business needs. For example, if your company requires a secure Web site, you can use Certificate Server and the secure channel function built into Internet Information Server (IIS) and Internet Explorer (IE).
Let's take a closer look now at some of Win2K's PKI components. I'll describe CSPs; Certificate Server, its Certificate Manager and Certificate Server Manager tools, and the certificate policies it generates; smartcard service; the secure channel function; Authenticode; and EFS.
Cryptographic Service Providers
CSPs implement specific security algorithms and key strength based on
security 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 NT 4.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 its proprietary smartcard CSP in its smartcard reader adapter to heighten performance and efficiency.
Certificate Server
Microsoft delivered Certificate Server 1.0 in IIS 4.0 for NT 4.0 and is
building 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 policy
settings. 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 up certificate 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 and issues the certificate, you can either immediately install the certificate into the personal store or install it into the personal store later by searching for the certificate in AD and retrieving it into the personal store. A certificate in the personal store can reside in the local machine's Registry or in a smartcard. 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 in Win2K is a root CA (i.e., a CA that issues and signs its CA certificate), you place that CA's certificate in the trusted-root CA store.
Certificate Server in Win2K supports CA hierarchy, also called certificate hierarchy. In a CA hierarchy, you can have a public root CA issue your company's CA certificate. If you do so, your Win2K CA becomes a subordinate CA of the public root CA. You store the subordinate CA certificate in the intermediate CA store. Using the CA hierarchy, you can easily establish CA trust relationships with other companies and your business partners. For example, if Company X is a subordinate CA of the public-root CA of which your company is also a subordinate, your company's CA and Company X's CA automatically trust each other. You save your trusted CA certificates in the enterprise-trusted CA store. In addition to the personal, trusted-root CA, intermediate CA, and enterprise-trusted CA stores, which physically keep client and CA certificates, Certificate Manager provides an AD user object store. The AD user object store doesn't physically contain certificates but rather supplies pointers that point to a particular user's certificates published in AD. The AD user object store lets users easily identify all of their certificates, including those they have not retrieved into their personal store.
Certificate Server Manager. Certificate Server Manager in Certificate Server manages four lists: issued certificate, failed request, pending request, and revoked certificate. Certificate Server Manager also performs other administrative functions, such as backup and restoration of keys and certificates and configuration of policy and exit modules.
Certificate Server stores issued certificates in the issued certificate list and publishes them in AD. The server's policy module compares the request information against the server's defined policies to determine whether the server should grant, deny, or suspend a certificate request. If the policy module finds that the request matches a policy, the module composes certificate properties such as a subject name, public key, email address, organization name, and key usage and certificate path and generates an X.509v3 certificate. The server's exit module sends the issued certificate to the client and publishes it in AD. Certificate Server rejects a certificate request if the policy module finds unmatched criteria in a policy. For example, if the client requests a sales certificate but doesn't belong to the sales group in the sales certificate template's access control list (ACL), Certificate Server rejects the request. The server places rejected requests in the failed request queue. If the policy module can't find a policy to match against a request, the server will save the request in the pending request list for a manual process a CA administrator or security systems administrator must perform.
Using Certificate Server, you can revoke client certificates if users compromise their private key or leave the company. Certificate Server stores revoked certificates in the revoked certificate list and publishes the list in AD, so applications that use certificates can verify a certificate's status from the revoked certificate list. Certificate Server can automatically update the revoked certificate list at intervals you define, such as once a day. You can also manually update the revoked certificate list immediately after certificate revocation.
Certificate Server is an open platform on which you can develop your own policy and exit modules with the SDK if the defaults don't meet your requirements. For example, if you want to publish certificates in a separate directory from AD, you can write a new exit module to replace the default exit module in Certificate Server. Using Certificate Server Manager, you can also easily back up CA private keys and certificates and all issued and revoked certificates to files so that you can restore them in case of disaster.
Certificate policies. Certificate Server in Win2K automatically installs a set of default certificate templates in a group policy object (GPO) in AD. A certificate template consists of a list of definable policies governing how to generate and use the certificate. For example, you can use a certificate for secure mail, client authentication, and EFS, and you can use the certificate's public key for digital signature and data encryption. The certificate template includes an ACL in which you can specify which users and groups in AD can request the certificate. The GPO is a security policy store in which you can define security policies for users and machines. The default public key security policies in the GPO contain several user certificate templates, such as User and Administrator, and machine certificate templates, such as Web Server and Computer. Certificate Server preinstalls these default templates to its policy settings. Screen 3, page 100, shows Certificate Server'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 custom certificate templates in the GPO. For example, I added a Sales certificate template to the policy settings, as Screen 3 shows. When you create a custom certificate template, you need to use the Group Policy Editor to manipulate the GPO of the certificate server. (I named my GPO "CA" Policy, as you see in the left pane of Screen 3.) The GPO contains two certificate template folders-- User Settings and Computer Settings. User Settings holds the user certificate templates, and Computer Settings holds the machine certificate templates. To create a new template, use the template creation wizard in one of the template folders. Then, add the newly created template to the policy settings in Certificate Server Manager.
You can also configure the automatic certificate request settings in User Settings and Computer Settings to let a user's computer automatically receive a particular certificate the next time the user logs on to AD. For example, if you add the Sales certificate template to the automatic certificate request settings, everyone in the Sales group will receive the certificate the next time they log on to AD.
Smartcard Service
Smartcard service is an important component in Microsoft's PKI in Win2K. A
smartcard 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 limited
user data, such as certificates and private keys. EPROM chips have only 128
bytes 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 the office, at home, or on the road--you can access the certificate. The smartcard's portability lets you use a certificate on any computer with a smartcard reader. To ensure compatibility and interoperability between smartcards and smartcard readers, the International Organization for Standardization (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 standardize smartcards and smartcard readers that interface with PCs. Microsoft also delivered a device-independent smartcard SDK for developers to use to write smartcard-enabled applications in the Windows environment. Win2K includes a Microsoft-based smartcard cryptographic service provider to support PC/SC- and ISO 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 your computer, 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 certificate from the smartcard and sends it to the Kerberos Key Distribution Center (KDC), which is a Win2K domain controller. After the KDC verifies your certificate's validation and issuer (i.e., CA), the KDC uses the subject name in the certificate as a reference to look up your user object in AD. When the KDC finds the object, it builds a Kerberos ticket-granting ticket (TGT), which contains your user account and access control information. The KDC encrypts the TGT with a session key, which your public key then encrypts, and returns the TGT to your computer. Your smartcard decrypts the session key with your private key, which the 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 about Kerberos user authentication in Win2K, see Michael E. Chacon, "Kerberos Is on Guard in Windows NT 5.0," October 1997.)
In addition to smartcard logon, you can use Win2K's smartcard service for other PKI operations, such as client and server authentication in Secure Sockets Layer (SSL). To fully leverage your smartcard, you can integrate other security functions, such as your company ID information and bank automatic teller card authorization, into the smartcard containing your digital certificate.
Secure Channel
Win2K incorporates a secure channel that supports SSL protocol, which many
companies use to secure Web communications over the Internet. The Internet
Engineering Task Force (IETF) has ratified SSL as an Internet standard and
renamed it Transport Layer Security (TLS). Microsoft's secure channel also
includes 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 to establish a secure channel between a client and a server. In SSL/TLS, the client first sends a hello message to the server, and the server greets the client by sending its server certificate to the client. The client authenticates the server by using the CA's public key, which the client extracts from the CA certificate stored in the client, to check the CA's signature in the server's certificate. The server can optionally authenticate the client by asking for and checking the client's certificate (in IIS 3.0 and later versions, administrators can choose the option of having the server authenticate the client). After the client authenticates the server, the client generates a 40-bit or 128-bit session key, according to security restrictions. The client then encrypts the session key with the server's public key (extracted from the server's certificate) and sends the encrypted session key to the server. The server decrypts the received session key using its private key. Now the server and client can exchange data encrypted with this session key.
You can use certificates Win2K's Certificate Server or other CAs issue for SSL/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 that
ensures the integrity and origin of commercial and free software distributed
over the Internet. Authenticode, based on digital signature technology, adds a
digital signature, a code-signing certificate, and a time stamp into such
software codes as Java applets, ActiveX controls, .dll files, executable files,
cabinet files, and catalog files. Authenticode also verifies downloaded code
before you run it on your system. To sign and verify code, Authenticode uses two
techniques: code signing and code verification.
Before you can sign code to guarantee its integrity and origin, you must obtain a code-signing or software-publishing certificate from a CA. You can then use the Authenticode signing functions the ActiveX SDK provides to sign the code. You pass the code you want to authenticate through a hashing algorithm and use your private key to sign the hash, which results in a digital signature. You then build a signature block, which contains the digital signature and the code-signing certificate. Authenticode lets you time stamp the signature block based on the current date and time that a time stamping service provider, such as VeriSign, provides. Finally, you bind the time stamped signature block to the original software. Now you can publish the signed software on your Web site for download.
The ActiveX SDK also supplies a code-verification function to verify downloaded software before you execute it. Microsoft has incorporated this function in IE 3.0 and later versions. Before IE runs signed code, it will call up the code-verification function to check the signature, publisher's certificate, and time stamp. After verification, the code-verification function will display the name of the code, the name of the organization or person who published the code, when the publisher authenticated the code, and the name of the CA that issued the code-signing certificate. The user decides whether to trust 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 security levels: high, medium, low, and custom. The high level doesn't execute damaged code; the medium level warns you before running potentially damaged code; the low level always executes any code; and the custom level lets you choose security settings, such as to enable ActiveX or to disable Java applets. You can also 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 encrypt
files and directories in a local or remote computer. Figure 4 shows how EFS uses
public keys for data encryption, decryption, and recovery.
Before you can use EFS, you need to create a data recovery agent. You use Group Policy Editor in the Win2K domain in which you want to use EFS. The data recovery agent contains a pair of public keys. A domain's data recovery agent can 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 is
powerful, 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.
