Security Watch: PKI Enhancements in Windows

Article
08/31/2016

Security WatchPKI Enhancements in Windows

John Morello

This column is based on a prerelease version of Windows Server 2008. All information herein is subject to change.

Windows has included strong, platform-wide support for public key infrastructure (PKI) since the release of Windows 2000. That release included the first native certificate-authority capability, introduced auto-enrollment, and provided support for smart-card authentication. In Windows XP and Windows Server 2003, those

capabilities were expanded to provide more flexible enrollment options with version 2 certificate templates and support for auto-enrollment of user certificates. In Windows Vista® and Windows Server® 2008 (formerly code-named "Longhorn"), the Windows® PKI platform takes the next step with support for advanced algorithms, validity checking, and better manageability. This column discusses the new PKI features in Windows Vista and Windows Server 2008 and how they can be utilized by enterprises to lower costs and increase security.

The PKI improvements in Windows Vista and Windows Server 2008 are focused around four main pillars: cryptography, enrollment, manageability, and revocation. In addition to these feature-specific improvements, the Windows PKI platform also benefits from other operating system advances, such as the Roles Manager, that make it easier to create and deploy new certificate authorities (CAs). Additionally, many other parts of Windows are able to take advantage of improvements in the PKI platform, such as support in Windows Vista for using smart cards for the storage of Encrypting File System (EFS) keys.

Cryptography

The improvements to the cryptography pillar are twofold. First, with the introduction of Cryptography Next Generation (CNG), Windows now provides a pluggable, protocol-agnostic encryption capability that makes individual algorithms easier to develop and access programmatically. Second, CNG brings with it new support for the Suite B algorithms, which were introduced by the National Security Agency (NSA) in 2005.

CNG is a new core cryptography interface for Microsoft and is the recommended API for future Windows-based, crypto-aware applications. CNG provides a host of new developer-focused functionality, including easier discoverability and substitution of algorithms, replaceable random number generators, and a kernel mode cryptographic API. While offering these new capabilities, CNG is also fully backwards compatible with the set of algorithms provided in its predecessor, CryptoAPI 1.0. Currently, CNG is being evaluated for Federal Information Processing Standards (FIPS) 140-2 level 2 certification as well as for Common Criteria on selected platforms.

The CNG Suite B support includes all required algorithms: AES (all key sizes), the SHA-2 family (SHA-256, SHA-384 and SHA-512) of hashing algorithms, Elliptic Curve Diffie-Hellman (ECDH), and Elliptic Curve Digital Signature Algorithm (ECDSA) over the National Institute of Standards and Technology (NIST) standard prime curves P-256, P-384, and P-521. The NSA has stated that certified Suite B implementations will be used to protect information classified as Top Secret, Secret, and private information that, in the past, was described as Sensitive-But-Unclassified. All Suite B algorithms were developed openly and some other governments are also exploring adopting them as national standards.

These low-level improvements to the Windows PKI platform provide developers with more secure methods for protecting data, while creating a subsystem that is easier to maintain and improve over time. Because CNG is a pluggable architecture, new algorithms can be added as needed and CNG abstracts these providers from the application layer. The net result is that Windows Vista and Windows Server 2008 are designed to provide an advanced, evolvable platform for developing PKI-enabled applications and services.

Enrollment

The certificate enrollment experience in Windows has been greatly improved with a new wizard-based enrollment tool, better certificate expiration handling, a new API, "enroll on behalf of" capability, and credential roaming. These enhanced capabilities drive down the total cost of ownership for a PKI by making it easier to deploy certificates across your enterprise in a centrally managed fashion and with minimal user impact.

The most noticeable change from an enrollment standpoint is the new Certificate Enrollment user interface shown in Figures 1 and 2. This user interface replaces the old, limited one that lacked the ability to accept data from users during the enrollment process. The new interface allows users to input data during enrollment (if the administrator configures the certificate template to require it). The interface also provides clear explanations for why a user may not be able to enroll for a given template.

Figure 1 Selecting available certificates

Figure 1** Selecting available certificates **(Click the image for a larger view)

Figure 2 Status of unavailable certificates

Figure 2** Status of unavailable certificates **(Click the image for a larger view)

Another key enrollment interface improvement is in the handling of expiring certificates. The new interface provides end users with clear information about what certificates are expiring when and allows users to easily renew certificates or dismiss the warnings from the same interface. While administrators can automatically refresh certificates through auto-enrollment, this warning capability is important for mobile or disconnected users who may log on to the corporate network infrequently and have certificates near their expiration dates.

For developers who work with certificate enrollment, a new API is available that offers significant improvements over the old ActiveX®-based controls (xenroll.dll and scrdernl.dll). The new Certificate Enrollment API provides a well-defined class hierarchy that is much simpler to understand and to code against. This new API replaces xenroll in both Windows Vista and Windows Server 2008.

This change in API impacts both developers and IT professionals because Windows Vista clients cannot use the Web-based enrollment capabilities provided in Windows Server 2003. This is because those enrollment pages (stored in the /certsrv virtual directory by default) utilize the xenroll control no longer present in Windows Vista. The Knowledge Base article "How to Use Certificate Services Web Enrollment Pages Together with Windows Vista" (support.microsoft.com/kb/922706) provides information about a workaround. Auto-enrollment from Windows Server 2003 to Windows Vista is not affected.

In previous releases of Windows Server, enrollment agents were not limited in whom they could enroll on behalf of. In other words, once a user was given enrollment agent abilities, he was able to enroll on behalf of any other user in the forest. Of course, this meant that user could easily escalate his privilege by enrolling on behalf of an existing user and impersonating the user with the newly created certificate. In an attempt to thwart this threat, enrollment agent abilities were provided to only highly trusted individuals. While such an approach improved security, it also made deployment models less flexible, since only a small number of individuals possessed the ability to enroll on behalf of other users. As a result, large, geographically dispersed organization faced increased complexity when deploying certificates to end users (such as for smart cards).

In Windows Server 2008, enrollment agents can be restricted on a much more granular level. Restrictions can be based on what users can be enrolled on behalf of, or by what templates can be enrolled against, as shown in Figure 3. For example, an organization may now provide a local IT professional with the ability to enroll on behalf of all the users at his branch, but not users in the Human Resources group. This granular approach to enrollment agents allows enterprises to more effectively and securely delegate enrollment capabilities throughout their organizations.

Figure 3 Enrollment agent restrictions

Figure 3** Enrollment agent restrictions **(Click the image for a larger view)

One of the biggest challenges of managing a PKI is managing all the key pairs dispersed across an organization's devices. In even a moderately complex PKI environment, any given user may have several different key pairs (such as for EFS, authentication to a wireless network, and S/MIME) that need to be available regardless of where he has logged on. With the increasing prevalence of mobile computing and Terminal Services, it's more important than ever to replicate these key pairs around the network so that they're available to users wherever they may log on. While user-carried tokens such as smart cards can help solve certain parts of this problem, organizations may still have users that are not given cards or have certificates that are not stored on the cards. Credential Roaming solves these problems by securely storing the key pairs and certificates within Active Directory®, thereby making them available to users regardless of where they log on.

Credential Roaming was first delivered in Windows Server 2003 SP1 and allows certificates and keys to roam securely between machines without the use of roaming user profiles. In Windows Vista and Windows Server 2008, this capability is included by default and is implemented in the Certificate Services Client (CSC) service. Configuration options, such as what certificates can roam and how to arbitrate conflicts, are managed via Group Policy. On Windows Vista and Windows Server 2008, the CSC service can also roam stored user names and passwords. While this capability is included by default in Windows Vista, it should be noted that Credential Roaming is fully supported on Windows XP and when logging on to a Windows Server 2003 domain controller (with the deployment of an update; see support.microsoft.com/kb/907247). This means that you do not need to wait until completing a Windows Vista deployment before taking advantage of this technology.

Manageability

A number of upgrades have been made in Windows Server 2008 to improve the manageability of the Certificate Authority (CA) service by making it easier to set up, monitor, and run in a highly available manner. CA setup is integrated with the Role Manager tool and provides a streamlined method to install the CA service. Defaults are defined for each step in the process and setup can now be performed in an unattended mode. Finally, setup has better diagnostic capabilities to make it easier to troubleshoot any failures or problem conditions that may arise.

Monitoring of the CA service has been greatly enhanced in Windows Server 2008 (as has overall certificate diagnostics in Windows Vista). In addition to the much more flexible eventing infrastructure that spans the entire product, the CA service itself now has a built-in monitoring console and hooks into Systems Center Operations Manager 2007 (formerly known as MOM) to provide enterprise-level alerting. The Enterprise PKI monitoring console is an improvement over its predecessor that was introduced in the Windows Server 2003 AdminPak. The new console is included in the product itself and can now monitor Online Certificate Status Protocol (OCSP) URIs in addition to all the CAs in a given forest.

The Operations Manager management pack provides a passive monitoring capability for an organization's PKI, including built-in threshold-based alerting. For example, the management pack can be used to monitor the freshness of a Certificate Revocation List (CRL) and alert PKI administrators when a CRL reaches a certain number of days or hours prior to its expiration. Finally, a host of new performance counters are available that aid in troubleshooting and monitoring the overall performance of the CA service itself. These counters can be used to capture data such as how many certificates are being issued per second.

A new capability makes its debut in Windows Server 2008: support for hardware-level clustering of the CA service. This cluster support utilizes standard Microsoft Cluster Service (MSCS) technology and supports two-node active/passive configurations. Cluster support allows you to run an issuance infrastructure in a highly available manner and can be used in geographically diverse clustering deployments. If you choose to utilize clustering support, note that simply clustering a CA does not result in availability for the entire PKI. While clustering can help ensure that the CAs themselves are available, a properly functioning PKI will likely have other components not running directly on the CAs. For example, the CRL Distribution Points (CDPs) and OCSP responders must also be run in a highly available manner to ensure that revocation can be performed. Additionally, when Hardware Security Modules (HSMs), particularly network-based HSMs, are utilized, they also represent a potential point of failure in a PKI. Clustering is a strong, new capability for providing high availability for the Certificate Authority itself, but it's not a panacea for the availability of an entire PKI deployment.

Revocation

CRLs have long been used to provide validity checking for certificates. These CRLs include the serial numbers of all certificates whose validity period has not yet expired but that should no longer be trusted. For example, if an employee has a certificate with an expiration date of 12/31/2008 but the employee leaves the organization in 9/1/2007, the serial numbers of their certificates would be placed on the CRL. Then the CRL would be made available at multiple CRL Distribution Points (CDPs), such as HTTP and Lightweight Directory Access Protocol (LDAP) paths.

While still in widespread use, CRLs present a problem for large organizations, CRLs can grow to very large sizes (sometimes over 100MB). Distributing these files across a large, widely dispersed network can be difficult or impossible, particularly in branch office scenarios or other environments with constrained bandwidth. This issued is described in RFC 5019 (https://www.rfc-editor.org/rfc/rfc5019.txt) and addressed starting with Windows Vista and Windows Server 2008. An OCSP client runs on the machine that needs to check the validity of a leaf certificate. The client software then references an OCSP responder and sends a message asking for the validity status of the leaf certificate. The responder checks the validity of the certificate and responds back to the client. This approach prevents the client from having to download and cache a very large CRL.

For the first time, OCSP client functionality is included in Windows Vista (previously, third-party software was required) and is configurable via Group Policy. By default, Windows will attempt to use OCSP but will fall back to standard CRL lookups if the responder is not available.

In Windows Server 2008, an OCSP responder is provided to answer these requests. The responder is installed through Role Manager and can be monitored by the Operations Manager 2007 management pack. Because both the client and responder conform to the OCSP standard, they can be easily integrated into existing OCSP environments that utilize similarly standards-based third-party components. For example, it's fully supported to have a Windows Vista client check certificate status against a third-party responder and for a Windows Server 2008 responder to answer queries from a third-party client application. Additionally, the Windows OCSP responder can answer requests for certificates issued by any standards compliant CA. Windows Server 2008 CAs (and Windows-based CAs in general) are not required.

Wrap-Up

The PKI platform in Windows Vista and Windows Server 2008 includes many enhancements and several new features that make deploying and operating a PKI more secure and less costly. The new CNG API provides developers with an easier programming environment and support for new cryptographic standards. Enrollment improvements allow organizations to more easily mass provision certificates and securely roam keys across the enterprise. Likewise, the new management pack and CA clustering capability make it easier to monitor the status of CAs and ensure high availability. Finally, improvements in revocation checking use a standards-based approach to providing validation of certificates without the bandwidth costs of CRL distribution. As a result, Windows Vista and Windows Server 2008 take the Windows PKI platform to a new level.

PKI Enhancement Resources

John Morello has been with Microsoft since 2000. As a Senior Consultant, he designed security solutions for Fortune 100 enterprises and Federal civilian and defense clients. He's currently a Senior Program Manager in the Windows Server division working on security and anywhere access technologies. You can read his team's blog at blogs.technet.com/WinCAT.

Additional resources