This documentation is archived and is not being maintained.
Security Watch Deploy a Globally Trusted PKI
John Morello graduated Summa Cum Laude from Louisiana State University and spent six years with Microsoft as a Senior Consultant in Microsoft Consulting Services. With MCS, he architected PKIs for strategic clients such as Deloitte, GE, and various Federal organizations. He now serves as the Deputy CISO at LSU.
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
This column includes prerelease information which is subject to change.
A Public Key Infrastructure, or PKI, is a fundamental element in building trust among diverse applications, operating systems, and identity realms. It is built on a hierarchical trust model in which end entities trust a common key at the highest root level, and therefore any other keys signed by that root are implicitly trusted.
Because of this structure, a well-designed PKI can be easily scaled out by adding additional Certificate Authorities (CAs), without introducing changes to the end entities.
PKIs are typically implemented in one of two ways. The most common approach is to purchase certificates as needed from one of the implicitly trusted global root providers, such as Cybertrust or VeriSign. These certificates are often used for securing traffic on Web sites, but they can also be used for encrypting Virtual Private Networks (VPNs), signing e-mail, and similar tasks. Because these global roots are built into every modern Web browser and operating system, this method can easily extend a trust relationship across organizational boundaries. However, since these certificates are purchased on an as-needed basis, this approach can be costly to deploy widely within a large organization.
The internal PKI model has recently become more prevalent. As the name suggests, an internal PKI is only trusted within an organization's own network. This model provides a cheaper way for an organization to provision every user and computing device on its network using certificates. This approach is often used to facilitate technologies like smart card log on, Encrypting File System (EFS), and secure wireless networking. The downside is that since these certificates are not globally trusted, they are not well suited to outward-facing applications. Thus, most organizations that have deployed internal PKIs usually adopt a hybrid approach, purchasing certificates for public applications from one of the globally trusted roots.
But what if you could get the best of both worlds? What if your organization could run its own PKI—with the cost savings you get from issuing internal certificates—and at the same time provision publicly trusted certificates, all from your own local system? Such a solution would offer the benefits of an internal PKI (like Active Directory® integration, autoenrollment, and localized IT support), while delivering the key advantage of a globally trusted root. Louisiana State University (LSU) has just such a system. In this installment of Security Watch, I take a close look at the solution we implemented at LSU, discussing its technical design and highlighting best practices to use when deploying a similar system. It should be noted that the solution that I'm going to describe is one that met our particular needs given our environment, resources, and business requirements. You should evaluate all of these aspects of your business in advance in order to determine the type of solution that will be right for you.
How LSU Does PKI
LSU is a major research university with a student, faculty, and staff population that totals over 40,000. It has many publicly facing Web sites, and many of these require Transport Layer Security—the proper term for secure sockets layer (SSL) certificates. LSU was spending thousands of dollars annually on certificates from the globally trusted root providers.
Meanwhile, LSU had other IT security goals that could greatly benefit from a well-designed internal PKI. Given LSU's goals and requirements, you might expect that we would have chosen a hybrid model. But instead, we decided on what we felt was a more innovative approach.
Figure 1 Cybertrust Global Root Certificate (Click the image for a larger view)
The OmniRoot service is specifically designed for the sort of PKI deployment we implemented at LSU. In the OmniRoot program, organizations pay Cybertrust a set annual fee for participating in the program and then pay a per-certificate fee only for those certificates created for public usage. In other words, LSU can issue as many certificates as it requires for internal usage without worrying about per-certificate fees adding up. Meanwhile, the cost of the publicly facing certificates is now significantly cheaper than what we were paying when the university purchased certificates on an as-needed basis.
To be clear, the internal certificates and the public certificates are identical from a technical standpoint. They are issued from the same CA chain, they have the same cryptographic strength, and they are provisioned through the same registration authority system. The only difference between the two is the licensing terms.
Ultimately, we have been able to expand and enhance the LSU IT security platform at a lower cost. This accomplishment made a great business case for this sort of PKI solution at LSU. Now let's take a look at the more technical details of the deployment.
LSU's PKI hierarchy is built on a two-tier design, with the root tier managed by Cybertrust and an online issuing CA running at LSU (see Figure 2). The root tier forms the anchor for trust in the hierarchy. In other words, the trust relationship of all certificates issued by any CA in the hierarchy falls under the root CA (see Figure 3). Thus, the root CA forms the common bond between all CAs, certificates, and end entities in the hierarchy. Because the Cybertrust global root is already built into Windows® and virtually every other modern computing system, this common bond automatically extends beyond LSU's network.
|Root Tier (Cybertrust)||Issuing Tier (LSU)|
|Managed by Cybertrust||Managed by LSU|
|Located in Cybertrust’s secure datacenter||Located on LSU’s Baton Rouge campus|
|Included in the default root certificate of almost all modern computing systems||Issues certificates to end entities within LSU system organizations|
|Certificates issued by LSU fall under the Cybertrust root and therefore are globally trusted|
Figure 3 Certificate Issued from LSU's Issuing CA (Click the image for a larger view)
Cybertrust manages the root CA in one of its secure hosting facilities. The hosting facility uses strong physical security controls, including man-traps, biometric locks, and a fully copper- jacketed storage vault. Cybertrust issues certificates only to the issuing CAs of organizations that have demonstrated compliance with its security and certificate policies.
LSU's issuing CA is an end-entity-facing system responsible for providing certificates to LSU's user and machine population. Its certificate is signed by the Cybertrust CA above it in the hierarchy and it issues certificates that chain through itself to the Cybertrust root CA (see Figure 3).
The Issuing OS and Hardware
LSU uses Windows Server® 2003 Enterprise Edition with Service Pack 1 for its issuing CA. The Windows Server 2003 Certification Authority service offers many new capabilities, including key archival, delta Certificate Revocation Lists (CRLs), and "version 2" templates. The instance of Windows used as the issuing CA is built according to the standard LSU Windows Server build policy. It's updated with all relevant security updates and is managed using the standard LSU change management practices and software inventory and update tools. In short, while there are some unique aspects to managing the CA service itself, the base server hardware and operating system are easily integrated into the organization's existing IT operations.
In addition to following the standard LSU best practices for server installation, we took advantage of the Security Configuration Wizard (SCW), which is available in Windows Server 2003 Service Pack 1. The SCW uses a database that contains dependency matrices of the various workloads that can be run on Windows Server and what security setting these workloads require. This database includes the two primary roles the CA will provide—the CA service itself and IIS (which provides the PKI self-service Web site).
Using the SCW, we easily created a security template that disabled all services other than those required to run these workloads, as well as hardened the network stack of the server. We then used scwcmd.exe to transform this template into a Group Policy Object (GPO) so that we could apply it to the server at the organizational unit level. This approach simplifies scaling out and disaster recovery since the role-based security configuration for an LSU CA is now stored within Active Directory, rather than being machine-specific.
LSU's issuing CA is built on an IBM xSeries 346 server, with dual 3.2GHz Intel Xeon processors, 4GB of RAM, and five 146GB SCSI hard disks. Given the performance demands of the CA service, and the fact that LSU utilizes a hardware security module, this platform should provide significant longevity and headroom for growth.
We followed standard best practices for separating databases and log files onto separate physical spindles by creating two RAID 1 arrays. The fifth hard disk is kept as a hot spare and is available to either of these arrays. We mounted the first array as our system volume, where we keep the CA database. The second array is used for log files and various other data files, such as the CRLs. The CA database is based on the same Jet technology found in other parts of Windows, like Active Directory, so the same maintenance and disk configuration best practices for other Jet-based storage solutions apply here.
A hardware security module (HSM) is a dedicated hardware device that is managed separately from the operating system. HSMs typically come as PCI adapters but are also available as network-based appliances. These modules provide a secure hardware store for CA keys, as well as a dedicated cryptographic processor to accelerate signing and encrypting operations. Windows utilizes the HSM through the CryptoAPI interfaces—the HSM is seen as a cryptographic service provider (CSP) device. The OmniRoot program requires that each CA use at least a FIPS 140-2 level 3 (level 4 devices are fairly rare) certified HSM for key generation and storage. As a unique and highly secure device, an HSM requires a notable financial investment; list prices for PCI-based HSMs are generally in the $10,000-15,000 range.
In the LSU design, an nCipher nShield 500 TPS (500 Transactions Per Second model) is used as a directly attached HSM. ("Directly attached" means that it is internal to the server and available for use only by that server, as opposed to being a network-based HSM that may be shared by multiple hosts.) The HSM is a FIPS 140-2 level 3 device and provides K of N protection of the keying material. The HSM provides significant protection against the private keys being compromised—an attacker would need to possess both the HSM storage as well as a defined number of access tokens and their PINs to access the key.
It is critical to note that HSMs are designed to prevent their contents from being tampered with by malicious parties. Thus, HSMs strictly enforce a limit on consecutive failed logon attempts. In LSU's design, the storage is irrevocably erased after 10 consecutive failed attempts.
We have a single CA in our setup, so the price premium for a network-based HSM is not justifiable. However, if an organization plans to implement two or more CAs, it can be significantly cheaper to purchase a single network-based HSM and share it among the CAs. This approach also makes token management easier, since all key storage can be protected by the same set of tokens.
Active Directory and Enrollment
One of the primary benefits of a Windows-based PKI solution is that certificate provisioning is accomplished without having to install additional software on entities that participate in the PKI. Rather, through a combination of autoenrollment and Group Policy, most certificate provisioning can be managed autonomously, invisible to the end user. LSU uses this technology to automatically distribute machine certificates to computers that are members of its Active Directory. And we use a customized Web site to provide self-service certificate request capabilities for non-Windows hosts.
As mentioned earlier, the OmniRoot program distinguishes between certificates used publicly and those used internally. Certificates are considered public if they are used by systems and users that are not part of the LSU organization (for instance, when a prospective student submits an admissions application through an SSL-secured Web site). Certificates used within the LSU organization (such as those used to encrypt data on LSU's servers) are considered internal.
Since the cost of the OmniRoot program is based on the number of publicly facing certificates, we need to be able to track how many public certificates are issued and to whom. Thus, for any certificate whose purpose is public, the distinguished name of the template begins with "PublicCertificate" and the display name begins with "Public Certificate". For example, the publicly facing LSU TLS certificate template is based on the default Windows Web Server template and is called Public Certificate LSU Web Server. For Web servers used internally, we have a second template called Internal Certificate LSU Web Server. Technically, the two templates are identical; the naming differences only serve to make accounting easier.
For bulk enrollment needs—such as enrolling entire departments for certificates to be used with IPSec—we rely on autoenrollment. This is a simple, highly efficient tool built into Windows. From a PKI administrator's standpoint, the only action required is to change the access control list on the template, granting any group of users or computers that need certificates the right to autoenroll. These entities will then automatically check Active Directory, enumerate what templates they have autoenroll access to, find the CAs with those templates, and automatically enroll for certificates. Also, the autoenrollment feature will ensure that certificates are replaced if a template is superseded and automatically renewed prior to expiration.
For non-bulk purposes, such as provisioning Web servers with certificates, we use a self-service Web site that lets users request certificates through a Web browser. This site is a customized version of the Web enrollment pages that ship with Windows Server 2003 (the /certsrv virtual directory); our implementation includes LSU's standard Web branding and precompletes the correct default entries on the request page. And we use the default exit module in the Windows CA service to automatically e-mail our PKI administration team when a request sent through this site requires approval.
Each certificate has a validity lifetime. From time to time, LSU needs to invalidate certain certificates prior to the end of their validity period (for example, if an employee is given a certificate with a validity period that expires in May 2007, but that employee leaves LSU in January 2007). This type of revocation is accomplished with CRLs, which are files that contain a list of certificate serial numbers signed by a CA. The serial numbers contained on a CRL refer to certificates whose validity lifetime has not expired, but which LSU no longer considers trustworthy. Clients can then download this CRL and check against it to determine the validity of certificates.
Any x.509 v3 certificate (except the root CA certificate itself) should have a pointer to a valid CRL. This pointer is known as a CRL distribution point, or CDP. The CRL distribution point is included in the certificate itself (see Figure 4) and cannot be modified after a certificate is issued. The CRL is an essential part of providing assurance that certificates from a CA are valid. As such, we make sure the LSU CRLs are physically redundant, highly available, and accessible by external parties.
Figure 4 LSU's CRL Distribution Point (Click the image for a larger view)
A Windows Server-based CA that is integrated with Active Directory (like LSU's) automatically publishes its CRL to Active Directory making it accessible through Lightweight Directory Access Protocol (LDAP). The default publishing location is the CDP container (see Figure 5) within the Public Key Services container in the forest. This publishing location is an excellent option, as it provides automatic replication, fault tolerance, and locality for CDP lookups.
Figure 5 The CDP Container (Click the image for a larger view)
In the LSU design, however, there are many non-Windows and non-Active Directory computers that utilize the PKI. And while LSU is a large organization, the great majority of its users are located on the same campus network, with a 10Gbps backbone, making the advantages of Active Directory-based CDP publishing minimal.
So we publish our CRL only to an HTTP path, making it easier to build a redundant hosting platform (our primary Web site is already mirrored). This also removes the potential complexities associated with enabling client LDAP lookups. We publish our CRL on a daily basis and publish delta CRLs on an hourly basis.
While our current PKI provides a strong security solution for the university community, we plan on enhancing its capabilities. Windows Vista™ and the next version of Windows Server (code-named "Longhorn") will provide numerous new key management capabilities that we plan to investigate. We are particularly interested in the planned Online Certificate Status Protocol (OCSP) client and responder capabilities, support for elliptic curve cryptography and SHA-256 algorithms, and a much improved autoenrollment interface. In addition, Windows XP Service Pack 3 is scheduled to include a feature known as credential roaming, which will provide secure roaming of key pairs without the overhead associated with roaming profiles. Finally, we're investigating the use of Certificate Lifecycle Manager (which is currently available in beta) in order to improve our reporting and management capabilities.
In summary, LSU's PKI provides the university with a foundational security service that is used for many critical IT functions. Using Cybertrust's OmniRoot service, we can run a PKI that is well integrated with LSU's other IT systems, but whose trust extends globally. And, by building the solution on the Windows CA service, we have efficient certificate provisioning and management capabilities and excellent integration with our existing directory and identity management system. In short, the PKI vision of strong security and seamless trust is already becoming a reality at LSU.