Export (0) Print
Expand All

Microsoft Windows 2000 Public Key Infrastructure

 

Microsoft Corporation

Updated April 1999

Summary: Microsoft Windows 2000 introduces a comprehensive public-key infrastructure (PKI) to the Windows platform. This infrastructure extends the Windows-based public-key (PK) cryptographic services introduced over the past few years, providing an integrated set of services and administrative tools for creating, deploying, and managing PK-based applications. This allows application developers to take advantage of the shared-secret security mechanisms or PK-based security mechanism in Windows, as appropriate. Enterprises also gain the advantage of being able to manage the environment and applications with consistent tools and policies.

Contents

Introduction
Concepts
Windows 2000 PKI Components
Certificate Authorities
Enabling Domain Clients
PK Security Policy in Windows 2000
Applications Overview
Interoperability
Preparing for Windows 2000 PKI
For More Information

Introduction

The Microsoft Windows 2000 operating system introduces a comprehensive public-key infrastructure (PKI) to the Windows platform. This infrastructure extends the Windows-based public-key (PK) cryptographic services that were introduced over the past few years, providing an integrated set of services and administrative tools for creating, deploying, and managing PK-based applications. This allows application developers to take advantage of the shared-secret security mechanisms or PK-based security mechanism, as appropriate. Enterprises also gain the advantage of being able to manage the environment and applications with consistent tools and policies.

The remainder of this article provides an overview of the PKI in Windows 2000.

Concepts

Public-Key Cryptography

Cryptography is the science of protecting data. Cryptographic algorithms mathematically combine input plaintext data and an encryption key to generate encrypted data (ciphertext). With a good cryptographic algorithm, it is computationally not feasible to reverse the encryption process and derive the plaintext data, starting with only the ciphertext; some additional data, a decryption key, is needed to perform the transformation.

In traditional, secret (or symmetric) key cryptography, the encryption and decryption keys are identical and thus share sensitive data. Parties wishing to communicate with secret-key cryptography must securely exchange their encryption/decryption keys before they can exchange encrypted data.

In contrast, the fundamental property of public-key (PK) cryptography is that the encryption and decryption keys are different. Encryption with a public-key encryption key is a one-way function; plaintext turns into ciphertext, but the encryption key is irrelevant to the decryption process. A different decryption key (related, but not identical, to the encryption key) is needed to turn the ciphertext back into plaintext. Thus, for PK cryptography, every user has a pair of keys, consisting of a public key and a private key. By making the public key available, it is possible to enable others to send you encrypted data that can only be decrypted by using your private key. Similarly, you can transform data by using your private key in such a way that others can verify that it originated with you. This latter capability is the basis for digital signatures, discussed below.

Public-Key Functionality

The separation between public and private keys in PK cryptography has allowed the creation of a number of new technologies. The most important of these are digital signatures, distributed authentication, secret-key agreement by using public key, and bulk data encryption without prior shared secrets.

There are a number of well-known PK cryptographic algorithms. Some, such as Rivest-Shamir-Adleman (RSA) and Elliptic Curve Cryptography (ECC), are general-purpose; they can support all of the above operations. Others support only a subset of these capabilities. Some examples include the Digital Signature Algorithm (DSA), which is part of the U.S. government's Digital Signature Standard, FIPS 186, which is useful only for digital signatures, and Diffie-Hellman (D-H), which is used for secret key agreement.

The following sections briefly describe the principal uses of PK cryptography. These operations are described in terms of two users, Bob and Alice. It is assumed that Bob and Alice can exchange information but do not have any pre-arranged, shared secrets between them.

Digital Signatures

Perhaps the most exciting aspect of public-key cryptography is creating and validating digital signatures, which is based on a mathematical transform that combines the private key with the data to be signed so that:

  • Only someone possessing the private key could have created the digital signature.
  • Anyone with access to the corresponding public key can verify the digital signature.
  • Any modification of the signed data (even changing only a single bit in a large file) invalidates the digital signature.

Digital signatures are themselves just data, so they can be transported along with the signed data that they protect. For example, Bob can create a signed e-mail message to Alice and send the signature together with the message text, providing Alice the information that is required to verify the message origin. In addition, digital signatures provide a way to verify that data has not been tampered with (either accidentally or intentionally) while in transit from the source to the destination. Therefore, they can be exploited to provide a very secure data-integrity mechanism.

Authentication

PK cryptography provides robust distributed authentication services. Entity authentication guarantees that the sender of data is the entity that the receiver thinks it is. If Alice receives data from Bob, and then sends him a challenge encrypted with Bob's public key, Bob then decodes this challenge and sends it back to Alice, proving that he has access to the private key associated with the public key that Alice used to issue the challenge. Alice can also send a plaintext challenge to Bob. Bob then combines the challenge with other information, which is digitally signed. Alice then uses Bob's public key to verify the signature and prove that Bob has the associated private key. The challenge makes this message unique and prevents replay attacks by a hostile third party. In either case, this is known as a proof-of-possession protocol because the sender proves that he has access to a particular private key.

Secret Key Agreement by Using a Public Key

Another feature of PK cryptography is that it permits two parties to agree on a shared secret, using public, and nonsecure, communication networks. Basically, Bob and Alice each generate a random number that forms half of the shared secret key. Bob then sends his half of the secret, encrypted, to Alice, using her public key. Alice sends her half, encrypted, to Bob with his public key. Each side can then decrypt the message received from the other party, extract the half of the shared secret that was generated by the other, and combine the two halves to create the shared secret. After the protocol is completed, the shared secret can be used for securing other communications.

Bulk Data Encryption Without Prior Shared Secrets

The fourth major technology enabled by PK cryptography is the ability to encrypt bulk data without the establishment of prior shared secrets. Existing PK algorithms are computationally intensive relative to secret-key algorithms. This makes them ill suited for encrypting large amounts of data. To get the advantages of PK cryptography along with efficient bulk encryption, PK and secret-key technologies are typically combined.

This is accomplished by first selecting a secret-key encryption algorithm and generating a random session key to use for data encryption. If Bob is sending the message, he first encrypts this session key, using Alice's public key. The resulting ciphertext key is then sent to Alice along with the encrypted data. Alice can recover the session key, using her private key, and then use the session key to decrypt the data.

Protecting and Trusting Cryptographic Keys

In secret-key cryptography, Alice and Bob trust their shared-secret key because they mutually agreed on it or exchanged it in a secure manner, and each has agreed to keep it stored securely to prevent access by a malicious third party. In contrast, using PK cryptography, Alice need only protect her private key and Bob, his private key. The only information they need to share is their public keys. They need to be able to identify the other's public key positively, but they need not keep it secret. This ability to trust the association of a public key with a known entity is critical to the use of PK cryptography.

Alice might trust Bob's public key because Bob handed it to Alice directly in a secure manner, but this presupposes that Alice and Bob have had some form of prior secure communication. More likely, Alice has obtained Bob's public key through a nonsecure mechanism (for example, from a public directory), so some other mechanism is needed to give Alice confidence that the public key that she holds claiming to be from Bob really is Bob's public key. One such mechanism is based on certificates issued by a certification authority (CA).

Certificates

Certificates provide a mechanism for gaining confidence in the relationship between a public key and the entity that owns the corresponding private key. A certificate is a digitally signed statement that deals with a particular subject public key, and the certificate is signed by its issuer (holding another pair of private and public keys). Typically, certificates also contain other information related to the subject public key, such as identity information about the entity that has access to the corresponding private key. Thus, when issuing a certificate, the issuer is attesting to the validity of the binding between the subject public key and the subject identity information.

The most common form of certificates in use today is based on the ITU-T X.509 standard. This is a fundamental technology used in the Windows 2000 PKI. It is, however, not the only form of certificates. Pretty Good Privacy (PGP) secure e-mail, for example, relies on a form of certificates unique to PGP.

Certification Authorities

A certification authority (CA) is an entity or service that issues certificates. A CA acts as a guarantor of the binding between the subject public key and the subject identity information that is contained in the certificates it issues. Different CAs may choose to verify that binding through different means, so it is important to understand the authority's policies and procedures before choosing to trust that authority to vouch for public keys.

Trust and Validation

The fundamental question facing Alice when she receives a signed message is whether she should trust that the signature is valid and was made by whomever claimed to make it. Alice can confirm that the signature is mathematically valid; that is, she can verify the integrity of the signature, using a known public key. However, Alice must still determine whether the public key used to verify the signature does, in fact, belong to the entity claiming to have made the signature in the first place. If Alice does not implicitly trust the public key to be Bob's, she needs to acquire strong evidence that the key belongs to Bob.

If Alice can locate a certificate, which was issued by a CA that Alice implicitly trusts, for Bob's public key, Alice can trust that Bob's public key really belongs to Bob. That is, Alice is likely to trust that she really has Bob's public key if she finds a certificate that:

  • Has a cryptographically valid signature from its issuer.
  • Attests to a binding between the name Bob and Bob's public key.
  • Was issued by an issuer that Alice trusts.

Assuming that Alice finds such a certificate for Bob's public key, she can verify its authenticity, using the public key of the issuing CA, Maira. However, Alice is now faced with the same dilemma. How does she know that the public key actually belongs to Maira? Alice now needs to find a certificate that attests to the identity of Maira and the binding between Maira and Maira's public key.

Ultimately, Alice ends up constructing a chain of certificates leading from Bob and Bob's public key through a series of CAs and terminating in a certificate issued to someone that Alice implicitly trusts. Such a certificate is called a trusted root certificate because it forms the root (top node) of a hierarchy of public keys/identity bindings that Alice accepts as authentic (for more information, see the section titled Certificate Hierarchies, later in this article). When Alice chooses to explicitly trust a particular trusted root certificate, she is implicitly trusting all the certificates issued by that trusted root, as well as all certificates issued by any subordinate CA certified by the trusted root.

The set of trusted root certificates that Alice explicitly trusts is the only information that Alice must acquire in a secure manner. That set of certificates secures Alice's trust system and her belief in the public-key infrastructure.

Windows 2000 PKI Components

Figure 1 presents a top-level view of the components that make up the Windows 2000 PKI. This is a logical view and does not imply physical requirements for separate servers; in fact, many functions may be combined on a single-server system. A key element in the PKI is Microsoft Certificate Services. This allows you to deploy one or more enterprise CAs. These CAs support certificate issuance and revocation. They are integrated with Active Directory, which provides CA location information and CA policy, and allows certificates and revocation information to be published.

The PKI does not replace the existing Windows domain trust-and-authorization mechanisms based on the domain controller (DC) and Kerberos Key Distribution Center (KDC). Rather, the PKI works with these services and provides enhancements that allow applications to readily scale to address extranet and Internet requirements. In particular, PKI addresses the need for scalable and distributed identification and authentication, integrity, and confidentiality.

ms995346.pki1(en-us,MSDN.10).gif

Figure 1. Windows 2000 public-key infrastructure components

Support for creating, deploying, and managing PK-based applications is provided uniformly on workstations and servers running Windows 2000. Figure 2 provides an overview of these services. Microsoft CryptoAPI is the cornerstone for these services. It provides a standard interface to cryptographic functionality supplied by installable cryptographic service providers (CSPs). These CSPs may be software-based or take advantage of cryptographic hardware devices and can support a variety of algorithms and key strengths. As indicated in the figure, one possible hardware-based CSP supports smart cards. Some CSPs that ship with Windows 2000 take advantage of the Microsoft PC/SC-compliant smart card infrastructure (see www.microsoft.com/smartcard and http://www.pcscworkgroup.com/).

Layered on the cryptographic services is a set of certificate management services. These support X.509 version 3 standard certificates, providing persistent storage, enumeration services, and decoding support. Finally, there are services for dealing with industry-standard message formats. Primarily, these support the PKCS standards and evolving Internet Engineering Task Force (IETF) Public Key Infrastructure, X.509 (PKIX) draft standards.

Other services take advantage of CryptoAPI to provide additional functionality for application developers. Secure Channel (schannel) supports network authentication and encryption by using the industry standard TLS and SSL protocols. These can be accessed by using the Microsoft WinInet interface for use with the HTTP protocol (HTTPS) and with other protocols through the SSPI interface. Authenticode supports object signing and verification. This is used principally for determining origin and integrity of components downloaded over the Internet, though it may be used in other environments. Finally, general-purpose smart-card interfaces are supported. These are used to integrate cryptographic smart cards in an application-independent manner and are the basis for the smart-card logon support that is integrated with Windows 2000.

ms995346.pki2(en-us,MSDN.10).gif

Figure 2. Public-key application services

Certificate Authorities

Microsoft Certificate Services, included with Windows 2000, provides a means for an enterprise to easily establish CAs to support its business requirements. Certificate Services includes a default policy module that is suitable for issuing certificates to enterprise entities (users, computers, or services). This includes identification of the requesting entity and validation that the certificate requested is allowed under the domain PK security policy. This may be easily modified or enhanced to address other policy considerations or to extend CA support for various extranet or Internet scenarios. Because Certificate Services is standards-based, it provides broad support for PK-enabled applications in heterogeneous environments.

Within the PKI, you can easily support both enterprise CAs and external CAs, such as those associated with other organizations or commercial service providers. This allows an enterprise to tailor its environment in response to business requirements.

Certificate Hierarchies

The Windows 2000 PKI assumes a hierarchical CA model. This was chosen for its scalability, ease of administration, and consistency with a growing number of commercial and third-party CA products. In its simplest form, a CA hierarchy consists of a single CA, though in general, a hierarchy contains multiple CAs with clearly defined parent-child relationships, as shown in Figure 3. As shown, there may be multiple unconnected hierarchies of interest. There is no requirement that all CAs share a common top-level CA parent (or root).

In this model, children are certified by parent CA–issued certificates, which bind a CA's public key to its identity and other policy-driven attributes. The CA at the top of a hierarchy is generally referred to as a root CA. The subordinate CAs are often referred to as intermediate or issuing CAs. In this article, a CA that issues end-entity certificates is called an issuing CA. Intermediate CA refers to a CA that is not a root CA, but that only certifies other CAs.

ms995346.pki3(en-us,MSDN.10).gif

Figure 3. Certificate authority hierarchies

The fundamental advantage of this model is that verification of certificates requires trust in only a relatively small number of root CAs. At the same time, it provides flexibility in the number of issuing CAs. There are several practical reasons for supporting multiple issuing CAs. These include:

  • Usage—Certificates may be issued for a number of purposes (for example, secure email, network authentication, and so on). The issuing policy for these uses may be distinct, and separation provides a basis for administering these polices.
  • Organizational divisions—There may be different policies for issuing certificates, depending upon an entity's role in the organization. Again, you can create issuing CAs to separate and administer these policies.
  • Geographic divisions—Organizations may have entities at multiple physical sites. Network connectivity between these sites may dictate a requirement for multiple issuing CAs to meet usability requirements.

Such a CA hierarchy also provides administrative benefits, including:

  • Flexible configuration of CA security environment (key strength, physical protection, protection against network attacks, and so on) to tailor the balance between security and usability. For example, you may choose to employ special-purpose cryptographic hardware on a root CA, operate it in a physically secure area, or operate it offline. These may be unacceptable for issuing CAs, due to cost or usability considerations.
  • Use of fairly frequent updates for issuing CA keys and certificates, which are the most exposed to compromise, without requiring a change to established trust relationships.
  • The ability to turn off a specific portion of the CA hierarchy without affecting the established trust relationships. For example, you can easily shut down and revoke an issuing CA certificate associated with a specific geographic site without affecting other parts of the organization.

In general, CA hierarchies tend to be static, though this is not a requirement. You can add or delete issuing CAs under a given root CA fairly easily. You can also merge existing CA hierarchies by issuing a certificate from one of the root CAs certifying the other root as an intermediate CA. However, before doing this, you should carefully consider policy inconsistencies that this could introduce and the impact of depth constraints that may be encoded into existing certificates.

Deploying an Enterprise CA

Deploying Microsoft Certificate Services is a fairly straightforward operation. It is recommended that you establish the domain prior to creating a CA. Then establish an enterprise root CA, or CAs. The Certificate Services installation process walks the administrator through this process. Key elements in this process include:

  • Selecting the host server—The root CA can run on any Windows 2000 Server platform, including a domain controller. Factors such as physical security requirements, expected loading, connectivity requirements, and so on, should be considered in making this decision.
  • Naming—CA names are bound into their certificates and hence cannot change. You should consider factors such as organizational naming conventions and future requirements to distinguish among issuing CAs.
  • Key generation—The CA's public-key pair is generated during the installation process and is unique to this CA.
  • CA certificate—For a root CA, the installation process automatically generates a self-signed CA certificate, using the CA's public/private-key pair. For a child CA, a certificate request can be generated that may be submitted to an intermediate or root CA.
  • Active Directory integration—Information concerning the CA is written into a CA object in the Active Directory during installation. This provides information to domain clients about available CAs and the types of certificates that they issue.
  • Issuing policy—The enterprise CA setup automatically installs and configures the Microsoft-supplied Enterprise Policy Module for the CA. An authorized administrator can modify the policy, although in most cases this is not necessary.

After a root CA has been established, it is possible to install intermediate or issuing CAs subordinate to this root CA. The only significant difference in the installation policy is that a certificate request is generated for submission to a root or intermediate CA. This request may be routed automatically to online CAs located through the Active Directory, or routed manually in an offline scenario. In either case, the resultant certificate must be installed at the CA before it can begin operation.

There is an obvious relationship between the enterprise CAs and the Windows 2000 domain trust model, but, this does not imply a direct mapping between CA trust relationships and domain trust relationships. Nothing prevents a single CA from servicing entities in multiple domains, or even entities outside the domain boundary. Similarly, a domain may have multiple enterprise CAs.

CAs are high-value resources, and it is often desirable to provide them with a high degree of protection, as discussed above. Specific actions that should be considered include:

  • Physical protection—Because CAs represent highly trusted entities within an enterprise, protect them from tampering. This requirement is dependent upon the inherent value of the certification made by the CA. Physical isolation of the CA server, in a facility accessible only to security administrators, can dramatically reduce the possibility of such attacks.
  • Key management—The CA keys are its most valuable asset because the private key provides the basis for trust in the certification process. Cryptographic hardware modules (accessible to Certificate Services through a CryptoAPI CSP) can provide tamper-resistant key storage and isolate the cryptographic operations from other software that is running on the server. This significantly reduces the likelihood that a CA key will be compromised.
  • Restoration—Loss of a CA due to hardware failure, for example, can create a number of administrative and operational problems, as well as prevent revocation of existing certificates. Certificate Services supports backup of a CA instance so that it can be restored at a later time. This is an important part of the overall CA management process.

Trust in Multiple CA Hierarchies

Based on the preceding discussion, it is evident that the Windows 2000 PKI must deal with trust relationships across multiple CA hierarchies. This could involve only CA hierarchies within a single enterprise, but may involve hierarchies within multiple enterprises, as well as commercial CAs (such as VeriSign, Thawte, and others).

Within the PKI, you can administratively establish and enforce CA-based trust relationships based on the Windows 2000 domain policy objects. For each trusted root CA, the system provides a means to apply usage restrictions on certificates that are issued by the CA. For example, you could choose to validate only certificates that are issued by a CA for server authentication, even if the CA issues certificates for several purposes.

In addition, individual users can add CA trust relationships that apply only to themselves. This is done by using client functionality and does not involve administrative action.

An alternative to explicitly including all trusted root CAs in a policy object is to use cross certificates. These have been used by at least one vendor's PKI product and provide a means to create a chain of trust from a single, trusted, root CA to multiple other CAs. Windows 2000 PKI is capable of processing such cross certificates and using them in making trust decisions, but they are unnecessary in this model. Microsoft chose this approach because of the issues that cross certificates raise, notably:

  • Uncertain interpretation of cross certification across organization boundaries when the CAs implement disparate policies.
  • Interpretation of cross certification in the absence of existing business agreements covering their use.
  • Additional administrative burden of generating and maintaining cross certificates.

Enabling Domain Clients

Windows 2000 provides a comprehensive set of core services that support the development and deployment of interoperable PK-based applications. The most significant new feature of the Windows 2000 implementation is integration with the domain administration and policy model, which simplifies application management within the enterprise.

The remainder of this section discusses the core application services that are provided by the PKI.

Generating Keys

Use of PK technology is dependent upon the ability to generate and manage keys for one or more PK algorithms. the Microsoft CryptoAPI supports installable CSPs that support key generation and management for a variety of cryptographic algorithms. The CryptoAPI defines standard interfaces for generating and managing keys that are the same for all CSPs.

Mechanisms for storing key material are dependent on the selected CSP. The Microsoft-provided software CSPs (or base CSPs) store key material in an encrypted form on a per-user or per-computer basis. They also support control over public-key pair exportability (CRYPT_EXPORTABLE flag) and usage control (CRYPT_USER_PROTECT flag). The former controls private-key export from the CSP; the latter determines user-notification behavior when an application attempts to use the private key. Other CSPs may implement different mechanisms. For example, smart card CSPs store the public-key pair in the smart card tamper-resistant hardware and generally require entry of a PIN to access operations involving the private key. These protection mechanisms are transparent to an application, which references all key pairs through a key-set name that is unique in the context of a CSP.

Key Recovery

The CryptoAPI architecture is compatible with, but does not mandate, key recovery. In this context, key recovery implies persistent storage of an entity's private key, allowing access by authorized individuals without knowledge or consent of the owning entity. Typically, this is necessary to ensure access to critical business correspondence or to meet law-enforcement requirements.

Key recovery is useful only when applied to keys that are used in the encryption of persistent data. For PK-based applications, this usually implies an entity's key-exchange keys. There is questionable value, and considerable danger, in archiving identification or digital-signature private keys because their only practical use would be for impersonation of the private key owner.

Microsoft Exchange currently provides support for recovery of key-exchange keys so that encrypted email can be read. In addition, third-party CSPs are available that provide general support for key recovery. Microsoft may include additional key-recovery functionality in the future, depending upon customer demand.

Certificate Enrollment

As mentioned, practical use of PK-based technology generally relies on certificates to bind public keys to known entities. The Windows 2000 PKI supports certificate enrollment to the Microsoft enterprise CA or third-party CAs. Enrollment support is implemented in a transport-independent manner and is based on use of industry-standard PKCS #10 certificate request messages and PKCS #7 responses that contain the resulting certificate or certificate chain. At this time, certificates that support RSA keys and signatures, Digital Signature Algorithm (DSA) keys and signatures, and Diffie-Hellman keys are supported.

Support for PKCS #10 and PKCS #7 messages is provided by a Microsoft-supplied enrollment control (Xenroll.dll), which can be scripted for web based enrollment or called programmatically to support other transport mechanisms, such as RPC, DCOM, and email. This control allows the calling application to specify the attributes included in the PKCS #10 message and allows use of an existing key pair or generation of a new key pair. The enrollment process is assumed to be asynchronous, and the enrollment control provides state management to match issued certificates against pending requests. This provides a means of creating an internal binding between the certificate, the CSP that generated the key pair, and the key-pair container name.

The PKI supports multiple enrollment methods, including web-based enrollment, an enrollment wizard, and policy-driven auto-enrollment, which occurs as part of a user's logon processing.

Renewal

Certificate renewal is conceptually similar to enrollment, but takes advantage of the trust relationship inherent in an existing certificate. Renewal assumes that the requesting entity wants a new certificate with the same attributes as an existing, valid certificate, but with extended validity dates. A renewal may use the existing public key or a new public key.

Renewal is of advantage primarily to the CA. A renewal request can presumably be processed more efficiently because the existing certificate attributes need not be reverified. Renewal is currently supported in the Windows 2000 PKI for automatically enrolled certificates. For other mechanisms, a renewal is treated as a new enrollment request.

Using Keys and Certificates

Within the Microsoft PKI, cryptographic keys and associated certificates are stored and managed by the CryptoAPI subsystem. As noted, keys are managed by CSPs, and certificates are managed by the CryptoAPI certificate stores.

The certificate stores are repositories for certificates and their associated properties. By convention, the PKI defines five standard certificate stores:

  • MY—This store is used to hold a user's or computer's certificates for which the associated private key is available.
  • CA—This store is used to hold issuing or intermediate CA certificates to use in building certificate-verification chains.
  • TRUST—This store is used to hold Certificate Trust Lists (CTLs). These are an alternate mechanism that allows an administrator to specify a collection of trusted CAs. An advantage is that they may be transmitted over nonsecure links, because they are digitally signed.
  • ROOT—This store holds only self-signed CA certificates for trusted root CAs.
  • UserDS—This store provides a logical view of a certificate repository that is stored in the Active Directory (for example, in the userCertificate property of the User object). Its purpose is to simplify access to these external repositories.

These are logical stores that can present a consistent, system-wide view of the available certificates that may reside on multiple physical stores (hard disk, smart cards, and so on). By using these services, applications can share certificates and are assured of consistent operation under administrative policy. The certificate management functions support decoding of X.509 v3 certificates and provide enumeration functions to assist in locating a specific certificate.

To simplify application development, the MY store maintains certificate properties that indicate the CSP and key-set name for the associated private key. After an application has selected a certificate to use, it can use this information to obtain a CSP context for the correct private key.

Recovery

Public key pairs and certificates tend to have high value. If they are lost due to system failure, their replacement may be time consuming and expensive. Therefore, the Windows 2000 PKI supports the ability to back up and restore both certificates and associated key pairs through the certificate-management administrative tools.

When exporting a certificate, using the certificate manager, the user must specify whether to also export the associated key pair. If this option is selected, the information is exported as an encrypted (based on a user-supplied password) PKCS #12 message. This may later be imported to the system, or another system, to restore the certificate and keys.

This operation assumes that the key pair is exportable by the CSP. This is true for the Microsoft base CSPs if the exportable flag was set at key generation. Third-party CSPs may or may not support private key export. For example, smart card CSPs do not generally support this operation. For software CSPs with nonexportable keys, the alternative is to maintain a complete system-image backup, including all registry information.

Roaming

Roaming in the context of this article means the ability to use the same PK-based applications on different computers within the enterprise Windows environment. The principal requirement is to make a user's cryptographic keys and certificates available wherever he or she logs on.

The Windows 2000 PKI supports this in two ways. First, if the Microsoft base CSPs are used, roaming of keys and certificates is supported by the roaming profile mechanism. This is transparent to the user after roaming profiles are enabled. It is unlikely that this functionality will be supported by third-party CSPs because they generally use a different method of preserving key data, often on hardware devices. Second, hardware token devices, such as smart cards, support roaming, provided that they incorporate a physical certificate store. The smart card CSPs that ship with the Windows 2000 platform support this functionality. The user carries the hardware token to the new location.

Revocation

Certificates tend to be long-lived credentials, and there are a number of reasons why these credentials may become untrustworthy prior to their expiration. Examples include:

  • Compromise, or suspected compromise, of an entity's private key.
  • Fraud in obtaining the certificate.
  • Change in status.

PK-based functionality assumes distributed verification in which there is no need for direct communication with a central trusted entity that vouches for these credentials. This creates a need for revocation information that can be distributed to individuals attempting to verify certificates.

The need for revocation information, and its timeliness, is dependent upon the application. To support a variety of operational factors, the Windows 2000 PKI incorporates support of industry-standard Certificate Revocation Lists (CRLs). Enterprise CAs support certificate revocation and CRL publication to the Active Directory under administrative control. Domain clients can obtain this information and cache it locally to use when verifying certificates. This same mechanism supports CRLs published by commercial CAs or third-party certificate server products, provided that the published CRLs are accessible to clients over the network.

Trust

The principal client trust concern when using PK-based functionality is the trust associated with certificate verification. This is generally based on the trust associated with the CA that issued the certificate. As discussed, the PKI assumes a rooted CA hierarchy in which the control of trust is based on decisions concerning root CAs. If a specified end-entity certificate can be shown to chain to a known trusted root CA, and if the intended certificate usage is consistent with the application context, it is considered valid. If either of these conditions is not present, it is considered not valid.

Within the PKI, users may make trust decisions that affect only themselves. They do this by installing or deleting trusted root CAs and configuring associated usage restrictions with the certificate-management administrative tools. This should be the exception, rather than the rule. These trust relationships should be established as part of the enterprise policy. For more information, see the following section, PK Security Policy in Windows 2000. Trust relationships established by policy are automatically propagated to Windows 2000–based client computers.

PK Security Policy in Windows 2000

Security policies can be applied to sites, domains, or organizational units (OUs), and affect the associated security groups of users and computers. PK security policy is only one aspect of the overall Windows security policy and is integrated into this structure. It provides a mechanism to centrally define and manage policy, while enforcing it globally. The most significant aspects of PK security policy are discussed below.

Trusted CA Roots

Trust in root CAs may be set by policy to establish trust relationships used by domain clients in verifying PK certificates. The set of trusted CAs is configured using the Group Policy Editor. It can be configured on a per-computer basis and apply globally to all users of that computer.

In addition to establishing a root CA as trusted, the administrator can set usage properties that are associated with the CA. If specified, these restrict the purposes for which the CA-issued certificates are valid. Restrictions are specified based on object identifiers (OIDs) as defined for ExtendedKeyUsage extensions in the IETF PKIX Part 1 draft. Currently, these provide a means of restricting use to any combination of the following:

  • Server authentication
  • Client authentication
  • Code signing
  • Email
  • IP Security (IPsec) end system
  • IPsec tunnel
  • IPsec user
  • Time stamping
  • Microsoft Encrypted File System

Certificate Enrollment and Renewal

As part of the overall PKI integration with Windows 2000, policy mechanisms have been defined to support an automated certificate enrollment process. This is controlled by two key elements: certificate types and auto-enrollment objects. These are integrated with the Group Policy Object and may be defined on a site, domain, OU, computer, or user basis.

Certificate types provide a template for a certificate and associate it with a common name, for ease of administration. The template defines elements such as naming requirements, validity period, allowable CSPs for private key generation, algorithms, and extensions that should be incorporated into the certificate. The certificate types are logically separated into computer and user types and applied to the policy objects accordingly. After they are defined, these certificate types are available for use with the auto-enrollment objects and certificate-enrollment wizard.

This mechanism is not a replacement for the enterprise CA issuing policy, but is integrated with it. The CA service receives a set of certificate types as part of its policy object. These are used by the Enterprise Policy Module to define the types of certificates that the CA is allowed to issue. The CA rejects requests for certificates that fail to match these criteria.

The auto-enrollment object defines policy for certificates that an entity in the domain should have. This can be applied on a computer and user basis. The types of certificates are incorporated by reference to the certificate type objects and may be any defined type. The auto-enrollment object provides sufficient information to determine whether an entity has the required certificates and to enroll for those certificates with an enterprise CA, if they are missing. The auto-enrollment objects also define policy on certificate renewal. This can be set by an administrator to occur before certificate expiration, supporting long-term operation without direct user action. The auto-enrollment objects are processed and any required actions taken whenever policy is refreshed (logon time, GPO refresh, and so on).

Smart-Card Logon

Smart-card logon (also see the section on smart-card logon in the Applications Overview section below) is controlled by policy associated with the user object in a manner analogous to password policy. Policy may be set either to enable smart-card logon, in which case password-based logon may still be used, or to enforce smart-card logon. In the latter case, protection against unauthorized access to the account is significantly stronger. It does mean however, that users are unable to log on if they forget their smart card or attempt to use a computer lacking a smart-card reader.

Applications Overview

This section provides an overview of significant applications that currently take advantage of PK-based functionality. It is intended to serve as an introduction to the ways you can use PKI to solve real-world business needs.

Web Security

The web has rapidly become a key element in creating and deploying solutions for the effective exchange of information on a worldwide basis. In particular, growth in its use for business purposes has been dramatic. For many uses, security is a key consideration. Notably:

  • Server authentication—To enable clients to verify the server they are communicating with.
  • Client authentication—To allow servers to verify the client's identity and use this as a basis for access-control decisions.
  • Confidentiality—Encryption of data between clients and servers to prevent its exposure over public Internet links.

The Secure Sockets Layer (SSL) and the IETF standard Transport Layer Security (TLS) protocols play an important role in addressing these needs. SSL and TLS are flexible security protocols that can be layered on top of other transport protocols. They rely on PK-based authentication technology and use PK-based key negotiation to generate a unique encryption key for each client/server session. They are most commonly associated with web-based applications and the HTTP protocol (referred to as HTTPS).

SSL and TLS are supported on the Windows platform by the secure channel (Schannel) SSPI provider. Microsoft Internet Explorer and Internet Information Services both use Schannel for this functionality. Because Schannel is integrated with Microsoft's SSPI architecture, it is available for use with multiple protocols to support authenticated and encrypted communications.

Taking full advantage of the SSL and TLS protocols requires both clients and servers to have identification certificates issued by mutually trusted CAs, allowing the parties to authenticate each other. In this mode, certificates are exchanged along with data that proves possession of the corresponding private key. Each side can then validate the certificate and verify possession of the private key by using the certificate's public key. The identifying information included in the certificate can then be used to make supplemental access-control decisions. For example, the client can determine whether the server meets its criteria for conducting business, and the server can determine what data the client can access.

Windows 2000 PKI integrates support for this behavior as a standard feature of Windows 2000 Server. User certificates can be mapped on a one-to-one or many-to-one basis against security principals (User objects) in the Active Directory. Schannel can use this information to automatically synthesize a security token for the client so that the Windows ACL mechanisms are used to enforce access control to resources. This is advantageous for services because they can use the identical access-control mechanism independent of the client-authentication mechanism used (PK or Kerberos).

After the client and server have authenticated each other, they can negotiate a session key and begin communicating securely. SSL and TLS are also often employed in a mode that does not require client authentication. Use of mutual authentication is recommended in the enterprise environment, however, because it allows you to make use of the Windows-based access control mechanisms. Also, the PKI significantly simplifies certificate enrollment and management, reducing the burden on the client.

Secure Email

PK-based secure email products, including Microsoft Exchange, have been available for a number of years and are widely deployed. These systems rely on PK technology for:

  • Digital signatures, to prove origin and authenticity of an e-mail message.
  • Bulk encryption without prior shared secrets, for confidentiality between correspondents.

The distributed nature of email, and the reliance on store-and-forward transport to multiple recipients, have been decisive factors in the use of PK technology. Alternate approaches, based on shared-secret cryptography, impose administrative and physical security requirements that make them difficult to use.

A limitation of some early implementations was the lack of cross-vendor interoperability. In the absence of suitable standards, vendors implemented systems that relied on proprietary protocols, message encodings, and trust assumptions that effectively defined non-interoperable PKIs. (PGP, though in fairly wide use, is in this category because its messaging formats never became a basis for interoperable secure email applications within the industry at large.)

In operation, these systems use a user's private key to digitally sign outgoing email. The user's certificate is then sent along with the email so that the recipient can verify the signature. S/MIME defines a profile for these certificates to ensure interoperability and assumes a hierarchical CA model to provide scalable trust management. To encrypt email, the user obtains the encryption certificate of the recipient, either from prior email or a directory service. After this certificate is verified, the user can use the contained public key to encrypt the secret key used to encrypt the email.

Digitally Signed Content

The growing use of the Internet has driven reliance on downloaded active content, such as Windows-based applications, ActiveX controls, and Java applets. The result has been a heightened concern for the safety of such downloads because they often occur as a side effect of web scripts without any specific user notification. In response to these concerns, Microsoft introduced Authenticode digital signature technology in 1996 and introduced significant enhancements in 1997.

Authenticode technology allows software publishers to digitally sign any form of active content, including multiple-file archives. These signatures may be used to verify both the publishers of the content and the content integrity at download time. This verification infrastructure scales to the worldwide base of users of Windows by relying on a hierarchical CA structure in which a small number of commercial CAs issue software-publishing certificates. For enterprise needs, the Windows 2000 PKI allows you to issue Authenticode certificates to internal developers or contractors and allows any employee to verify the origin and integrity of downloaded applications.

Encrypting File System

The Windows 2000 Encrypting File System (EFS) supports transparent encryption and decryption of files stored on a disk in the Windows NT file system (NTFS). The user can designate individual files to encrypt or folders whose contents are to be maintained in encrypted form. Applications have access to a user's encrypted files in the same manner as unencrypted files. However, they cannot decrypt any other user's encrypted files.

EFS makes extensive use of PK-based technology to provide mechanisms for encrypting files to multiple users as well as supporting file recovery. To do this, it uses the ability of PK to support bulk encryption without prior shared secrets. In operation, each EFS user generates a public-key pair and obtains an EFS certificate. The certificate is issued by an enterprise CA in the Windows 2000 domain, although EFS generates a self-signed certificate for stand-alone operation where data sharing is not an issue. In addition, Windows 2000 supports an EFS recovery policy in which trusted recovery agents can be designated. These agents generate an EFS recovery public-key pair and are issued an EFS recovery certificate by the enterprise CA. The certificates of the EFS recovery agents are published to domain clients with the Group Policy object.

In operation, for each file to be encrypted, EFS creates a random key that is used to encrypt the file. The user's EFS public key is then used to encrypt this secret key and associate it with the file. In addition, a copy of the secret key, encrypted with each recovery agent's EFS public key, is associated with the file. No plaintext copy of the secret key is stored in the system.

When retrieving the file, EFS transparently unwraps the copy of the secret key encrypted with the user's public key, using the user's private key. This is then used to decrypt the file in real time during file read and write operations. Similarly, a recovery agent may decrypt the file by using the private key to access the secret key.

Smart-Card Logon

Windows 2000 introduces PK-based smart-card logon as an alternative to passwords for domain authentication. This relies on a PC/SC Workgroup-compliant smart-card infrastructure, first introduced for Windows NT and Windows 95 in December 1997, and RSA-capable smart cards with supporting CryptoAPI CSPs. The authentication process makes use of the PKINIT protocol, proposed by the IETF Kerberos working group, to integrate PK-based authentication with the Windows 2000 Kerberos access-control system.

In operation, the system recognizes a smart-card insertion event as an alternative to the standard CTRL + ALT + DEL secure attention sequence to initiate a logon. The user is then prompted for the smart-card PIN code, which controls access to operations with the private key stored on the smart card. In this system, the smart card also contains a copy of the user's certificate (issued by an enterprise CA). This allows the user to roam within the domain.

IP Security (IPsec)

IPsec defines protocols for network encryption at the IP protocol layer. IPsec does not require PK-based technology and can use shared-secret keys that are communicated securely through an out-of-band mechanism at the network end-points for encryption. The IETF IPsec working group recognized, however, that PK-based technology offers a practical solution to create a scalable distributed trust architecture, in particular, one in which IPsec devices can mutually authenticate each other and agree upon encryption keys without reliance on prearranged shared secrets.

The IPsec community, including Microsoft, is actively working on standards for interoperable certificates and certificate enrollment and management protocols. Although a level of interoperability has been demonstrated, there is still work required to ensure broad interoperability across IPsec devices and PKI implementations. Microsoft is committed to developing its Windows 2000 PKI in conjunction with these evolving standards.

Interoperability

Criteria

In an ideal world, a PKI would be exactly that: an infrastructure. CAs would issue a suite of completely interoperable certificates based on a standard certificate-request protocol. Applications would then evaluate them in a consistent manner (including whether they have been revoked), and there would be no ambiguity in either the syntactic or semantic interpretation anywhere in the process.

The industry has yet to achieve this level of interoperability. As more applications take advantage of PK-based technology, relatively seamless interoperability is achievable. Today, SSL/TLS and S/MIME work well across multiple vendor products. Newer applications, such as code signing and digitally signed forms are not yet reliable. More troublesome is the fact that there is no current technical mechanism to compare names in two different language encodings. Unicode, for example, allows accented characters to be encoded in multiple equivalent forms.

In the future, at least two major forces will drive interoperability:

  • Initial trials, followed by a growing dependence on PK-based systems.
  • Greater emphasis on standards.

Microsoft is actively involved in the development of PK-relevant standards and is committed to building a product based on accepted current standards to maximize interoperability.

Internet Standards

Internet standards do not ensure interoperability, although they help. The historic problem with standards is that commercial product deployment outpaces the collaborative process. This has been especially true in PK technology, where the IETF currently has multiple working groups actively developing proposed standards for PK-based technology. Many of the applications that are potential beneficiaries of these standards are already shipping products. Moreover, no standard can anticipate every application requirement and dependency. Even the most comprehensive standards must be adapted in implementation. Interoperability, then, is the result of standards tempered by market realities.

The IETF working group charged with defining the basis for an interoperable PKI is PKIX (X.509). After almost three full years of work, the basic architecture is in place. The specification, RFC 2459, Internet Public Key Infrastructure X.509 Certificate and CRL Profile, Part 1 is available at ftp://ftp.isi.edu/in-notes/rfc2459.txt. Microsoft is heavily involved in work on this standard within the IETF and is committed to assuring that its PKI products are compliant with it. Once ratified, this will become an important factor in defining a robust PKI that ensures certificates that can be requested, interpreted, and revoked in some standard way.

There are also a number of other efforts within the IETF that may have significant impact on PKI interoperability. These are being driven by the needs of PK-based applications, notably TLS, S/MIME, and IPSec. In each case, these applications made it necessary to define a PKIX subset that meets their needs; often they supersede PKIX-defined functionality. Although this could appear to fragment the process, it does create a close-in feedback loop for the PKI designers.

It is not surprising, then, that the most aggressive set of application-dependent standards are products of the IETF S/MIME working group (http://www.ietf.org/ids.by.wg/smime.html). Of these, the (S/MIME) Cryptographic Message Syntax, S/MIME Version 3 Message Specification, S/MIME Version 3 Certificate Handling, and Certificate Request Syntax are the most important. The S/MIME community, like TLS before it, has the advantage of starting with a de facto standard. PKIX also started with a standard (X.509), but this has proven inadequate as a basis for interoperable PK-based systems. This means that PKIX Part 1, the base IETF standard, is gaining experience from the applications that are trying to use it. A recent example of the feedback process is certificate chain verification.

PKIX Part 1 suggests, but does not specify, a certificate-chain validation algorithm. One possible interpretation of the current Internet draft is that name-chaining (that is, matching the certificate issuer name against a CA name in the subject field of the parent certificate) must always be enforced, even if information such as AuthorityKeyIdentifier (issuer of a public key) is present. An inherent problem with this approach, however, is that it does not accommodate two significant public-key environments: one where there is no directory available to locate CA certificate by name, and complex ones where there is a complex web of cross-certified CAs. The PKIX working group did not encounter this class of problem until applications tried to generalize their chain validation algorithms and found that they could not. The positive effect of this is that the feedback loop is working, and the new mechanism is now reflected in the standard.

There is also an important forcing function on the horizon for PKI interoperability. The National Institute of Standards (NIST) has established an interoperability work group, consisting of AT&T, CertCo, Certicom, Cylink, Digital Signature Trust, Dynacorp, Entrust, Frontier Technologies, GTE, ID Certify, MasterCard, Microsoft, Motorola, Spyrus, VeriSign, and Visa. The goal of this project is to ensure minimum interoperability between the members' implementations of PKIX Part 1. NIST is optimistic that this forum will resolve any ambiguities and/or errors in the new PKIX standard.

Another factor in defining PKI standards lies entirely outside the IETF. There is a set of de facto cryptographic message standards (PKCS) developed and maintained by RSA Laboratories (http://www.rsa.com/rsalabs/html/standards.html) that is already broadly deployed in products. The PKCS standards, first published in 1990, include syntax for cryptographic messages. The standards that are most relevant to PKI are PKCS #7, Cryptographic Message Syntax Standard, and PKCS #10, Certification Request Syntax Standard. The significance of the RSA standards is that they provide a basic, but well-understood framework for interoperability. In fact, when the PKIX working group proposed another standard for certificate management, the S/MIME working group created its own proposal based on PKCS. This response is typical of IETF practices and reflects market awareness. De facto standards are often the best kind, and Microsoft has taken advantage of these standards in its current PKI implementation to maximize interoperability.

It is fair to expect the standards process to lay the groundwork, but it is ultimately some subset of its standards that multiple vendors incorporate in their products to create interoperable solutions. A good example of the role that market forces play in the determination of PK interoperability is how trust models work.

The term infrastructure implies that PKIs themselves can be linked together. If, for example, a department within a company chooses Vendor A's PKI model for its application and the company later chooses Vendor B for its mail system, it makes sense that there should be some natural overlap. It gets slightly more complicated when Company A and Company B want to selectively join their PKIs in a business-specific extranet. The technical complexity comes from having to map the trust relationships (who trusts whom for what) between the entities and keep track of them over time. There are currently three competing models for how trust relationships should work:

  • Rooted hierarchies (for example, VeriSign, Microsoft, and Netscape)
  • Networks (for example, Entrust)
  • Webs (for example, PGP)

Each of these three trust models assumes something different about how trust relationships are established and maintained, whether they are created directly or through an intermediary. Different trust models probably will not interoperate seamlessly. At best, sufficient flexibility can be built into a PKI, along with supporting administrative tools, to allow users to integrate separate trust models in a way that makes sense for specific business reasons.

Preparing for Windows 2000 PKI

S/MIME-based Email Using Exchange Server

Public Key Infrastructure–based security is relatively new, and there are very few case studies of actual PKI deployment. To deploy PKI on a wide scale, a corporation must educate its users, understand the key/certificate management issues, and understand the risks and liabilities associated with PKI. A number of companies can provide assistance on these issues. A list is available at the Security Advisor site at www.microsoft.com/security/, where you will find a section on "Partners."

One of the most common areas that can benefit from the use of PKI security is email. Using S/MIME, which is based on PKI, customers can send digitally signed and encrypted email. Through the use of S/MIME-based email, corporations can start deploying PKI and build up experience and expertise.

Microsoft recommends that customers who want to deploy PKI start with Microsoft Exchange Server 5.5 (SP1) and the Microsoft Outlook 98 messaging and collaboration client, which offers S/MIME based email. The key pieces of a PKI are included in Microsoft Exchange and Microsoft Outlook and are illustrated in Figure 4:

  • Key Management server with built-in key recovery features
  • X.509 version 3 Certificate Services
  • LDAP-based Exchange directory service
  • S/MIME clients (Outlook) using CryptoAPI

ms995346.pki4(en-us,MSDN.10).gif

Figure 4. Key pieces of a PKI

--------------------------------------------

The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.

This article is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS DOCUMENT.

Microsoft, ActiveX, Authenticode, Outlook, The BackOffice logo, Windows, and Windows NT are registered trademarks of Microsoft Corporation.

Other product or company names mentioned herein may be the trademarks of their respective owners.

Microsoft Corporation · One Microsoft Way · Redmond, WA 98052 · USA

Show:
© 2014 Microsoft