Deploy a globally trusted PKI

Deploy a globally trusted PKI

John Morello's column contains prerelease information that may change.

The Public Key Infrastructure (or PKI) is a basic element for building trust between different applications, operating systems, and identity recognition fields. It is built on a hierarchical trust model. In this model, the final entity trusts the highest root level public key, so it implicitly trusts any other key signed by the root.

In view of this structure, it is easy to expand the well-designed PKI by adding an additional Certificate Authority (CA) without introducing changes into the final entity.

There are two methods to implement PKI. The most common method is to purchase a certificate from a globally Trusted Root provider (such as cybertrust or Verisign) as needed. These certificates are usually used to protect communication on the website, but they can also be used for Virtual Private Network (VPN) encryption, email signatures, and similar tasks. Since these global roots have been built into every web browser and operating system today, it is easy to use this method to expand trust relationships across organizational boundaries. However, since these certificates are purchased on demand, this method may be costly for extensive deployment within large organizations.

The internal PKI model has been prevalent recently. As the name suggests, internal PKI is only trusted in the organization's own network. If an organization uses a certificate to store each user and each computing device on its network, this model is cheaper. This method is often used to facilitate technologies such as smart card login, encrypted file system (EFS), and secure wireless networking. The disadvantage is that these certificates are not globally trusted, so they are not very suitable for export-oriented applications. Therefore, most organizations that deploy an internal PKI usually adopt a hybrid method to purchase certificates for public applications from a globally Trusted Root.

But what if you can get a lot from both methods? What if your organization can use the cost saved by issuing internal certificates to run its own PKI and set up a public trust certificate (all certificates come from your local system? This solution not only has internal PKI (such as Active Directory^{Integration, automatic registration, and localization of IT support), but also has the main advantages of global trust Root. The Louisiana State University (LSU) has such a system. In this security observation, I will closely follow our solutions implemented in LSU, discuss their technical design, and highlight the best practices that should be used to deploy similar systems. It should be noted that the solution I will introduce only meets the special needs of our specific environment, resources and business needs. You shall evaluate all these aspects of your business in advance to determine the type of solution that is appropriate for you.}

Lsu pki practices

LSU is a research-oriented university with more than 40,000 students and faculty and staff. It has many public-facing websites, many of which require Transport Layer Security (dedicated terminology for Secure Sockets Layer (SSL) Certificates ). Each year, LSU spends thousands of dollars purchasing certificates from trusted root providers around the world.

At the same time, LSU also has other IT security goals. Therefore, we can leverage the well-designed internal PKI. You may choose a hybrid model based on the objectives and requirements of LSU. But the opposite is true. We decided to adopt a method that we felt was more innovative.

We work with a globally Trusted Root cybertrust to deploy a CA in the LSU campus, which belongs to the cybertrust Root CA (see figure 1 ). Cybertrust provides this service in its omniroot program. In this solution, LSU establishes and operates a local ca running on the LSU's own device. However, unlike the internal model discussed earlier, the lsu ca is not self-Signed and Its Key (and any of its signature keys) almost all operating systems and browsers today are implicitly trusted. Technically speaking, this design is an open logical extension of the X.509 standard. Since PKI is built on these standards, systems created by different vendors can be inserted into the same overall hierarchy. That is to say, what is particularly noticeable in the omniroot solution is the terms of use of the service.

Figure 1 cybertrust global root certificate (click the image to get a smaller view)
Figure 1 cybertrust global root certificate (click the image to get a larger view)

The omniroot service is designed for the PKI deployment we implement in LSU. In the omniroot program, organizations that join the program pay a fixed fee each year to cybertrust, and then pay for each certificate created for public purposes. In other words, LSU can issue any number of certificates as needed for internal use without worrying about the increase in the cost per certificate. At the same time, the cost for public certificates is now much lower than the University's cost for purchasing certificates on demand.

Clearly, internal certificates and public certificates are the same from the technical point of view. They are issued from the same CA chain, have the same password strength, and are set through the same registration authorization system. The only difference between the two is the license terms.

In the end, we have been able to expand and enhance the lsu it security platform at a low cost. This achievement sets up a large business model for this PKI solution of LSU. Now, let's take a look at more technical details of deployment.

PKI hierarchy

The PKI hierarchy of LSU is built on a dual-layer design. The root layer is managed by cybertrust and an online ca running on LSU (see figure 2 ). The root layer constitutes the trust anchor in the hierarchy. In other words, the trust relationships of all certificates issued by any CA in the hierarchy are classified as Ca (see figure 3 ). Therefore, the root Ca forms a joint bond between all Cas, certificates, and final entities in the hierarchy. Because cybertrust global root has been built into windows^{And almost every other computing system today, so this joint bond will automatically extend beyond the network range of LSU.}

Figure 3 certificate issued by LSU Ca (click the image to get a small view)
Figure 3 certificate issued by LSU Ca (click the image to get a larger view)

Cybertrust manages the Root CA in one of its security hosting facilities. Hosting uses powerful physical security controls, including traps, biometric feature locks, and a full copper housing repository. Cybertrust only issues certificates to the issuing CA of an organization that has proven to comply with its security and certificate policies.

The LSU issuing CA is a final entity-oriented system that provides certificates to LSU users and machine groups. The certificate is signed by the cybertrust Ca on which the hierarchy is located, and the certificate issued by it is linked to the cybertrust Root CA through its own (see figure 3 ).

Issue OS and hardware

LSU issues CA to use Windows Server with Service Pack 1^{2003 Enterprise Edition. The Windows Server 2003 Certificate Authority Service provides many new features, including key archiving, incremental Certificate Revocation List (CRL), and Version 2 templates. Windows instances used to issue CAs are built based on the standard LSU Windows Server build policy. It updates all related security during the update process, and manages it using standard LSU change management measures and software lists and update tools. In short, although the management of the CA Service itself has some unique characteristics, the basic server hardware and operating system can be easily integrated into the existing IT operations of the Organization.}

In addition to following the standard LSU Server Installation Best Practices, we also used the Security Configuration Wizard (SCW) provided in Windows Server 2003 Service Pack 1 ). SCW uses a database that contains dependencies between various workloads that can run on Windows server and the security settings required for these workloads. This database includes two main roles that will be provided by the ca-ca service itself and IIS (it provides the PKI self-service website ).

We use SCW to easily create a security template. In addition to the services required to run these workloads and services that enhance the server network stack, this template disables all other services. Then, we use scwcmd.exe to convert this template into a group policy object (GPO) so that it can be applied to servers at the organization level. This method simplifies expansion and disaster recovery because the role-based security configurations of lsu ca are currently stored in Active Directory and are not related to specific machines.

The LSU issuing CA is built on an IBM xseries 346 server with dual 3.2 GHz Intel Xeon processor, 4 gb ram, and five 146 gb scsi hard drives. Based on the CA Service performance requirements and the fact that LSU uses the hardware security module, this platform should have significant vitality and growth space.

Based on standard best practices, we split databases and log files into separate physical spindle by creating two RAID 1 arrays. The fifth hard disk is retained as a hot spare and can be used for both arrays. We install the first array as a system volume, which stores the CA database. The second array is used for log files and other data files, such as CRl. The CA database is based on the same jet technology already exists in other Windows components (such as Active Directory), so the best practices for maintaining and configuring other jet-based storage solutions are also applicable here.

The hardware security module (HSM) is a dedicated hardware device that is managed separately from the operating system. HSM usually appears in the form of a PCI adapter, but can also be provided as a network-based device. These modules not only provide a secure hardware storage zone for the CA key, but also provide a dedicated cryptographic processor to accelerate signature and encryption operations. Windows uses HSM-HSM through the CryptoAPI interface as a CSP device. The omniroot program requires each CA to use at least one HSM certified by FIPS 140-2 level 3 (Level 4 devices are quite rare) for key generation and storage. As a unique and highly secure device, HSM requires a considerable investment in property; pci-based HSM is generally priced between $10,000-$15,000.

In the LSU design, a ncipher nshield 500 TPS ("500 transactions per second" model) is used as a direct connection HSM. (The "Direct Connection" indicates that it belongs to the server and can only be used by the server. In contrast, the network-based HSM can be shared by multiple hosts .) The HSM is a FIPS 140-2 Level 3 device that provides n k-weight protection for key control materials. HSM provides strong protection against private key leakage-Attackers need to possess HSM memory and a specified number of access tokens and their pins to access the key.

Note that HSM is designed to prevent malicious content tampering. Therefore, HSM imposes a strict limit on the number of consecutive failed logon attempts. In the LSU design, after 10 consecutive logon attempts fail, the memory will be erased and irrecoverable.

There is only one ca in our settings, so there is no reason to enjoy the network-based HSM price concessions. However, if the Organization plans to implement two or more cas, it will be able to purchase a single network-based HSM at an affordable price and share it with each CA. This method also makes token management easier, because all key storage can be protected by the same group of tokens.

Active Directory and Registration

One of the main advantages of the Windows-based PKI solution is that you do not need to install additional software on the PKI entity to complete certificate backup. On the contrary, through the combination of Automatic Registration and group policies, most certificates can be managed independently and invisible to end users. LSU uses this technology to automatically distribute machine certificates to computers belonging to their active directory. In addition, we use a custom website to provide the Custom Service Certificate Request function for non-Windows hosts.

As mentioned above, omniroot plans to distinguish between public and internal certificates. Certificates are considered public certificates if they are used by systems and users outside the LSU organization (for example, when an expected student submits an admission application through the SSL security website. Certificates used within an LSU organization (for example, certificates used to encrypt data on an LSU server) are considered as internal certificates.

Because the cost of the omniroot program depends on the number of public certificates, we need to be able to track how many public certificates are issued and to whom. In this way, for any public-purpose certificate, the identifiable name of the template starts with "publiccertificate", and the display name starts with "public certificate. For example, the common lsu tls Certificate template is based on the default Windows Web Server template and is called public certificate LSU web server. For internal Web servers, we also have another template called internal certificate LSU web server. Technically speaking, the two templates are exactly the same. The naming difference is only to simplify the accounting work.

For batch registration requirements (for example, for an IPsec certificate to register the entire department), we rely on automatic registration. This is a simple and efficient tool built in windows. From the PKI administrator's point of view, the only operation required is to change the access control list on the template and grant the permission to automatically register any group of users or computers that require certificates. These entities will then automatically check Active Directory, list the templates with automatic registration and access permissions, find the CAS with these templates, and then automatically register the certificates. In addition, if the template has been replaced and is automatically renewed before expiration, the automatic registration function can also ensure that the certificate is replaced.

For non-bulk purposes, for example, to prepare a certificate for a Web server, we use a self-service website so that users can request a certificate through a web browser. This site is a custom version of the web registration page (/certsrv virtual directory) that is included with Windows Server 2003; our implementation includes adding the LSU standard web tag and filling in the correct default entries on the request page in advance. In addition, we use the default exit module in the Windows CA Service to automatically send emails to our PKI Management Team on time for requests sent through this site.

Revocation Design

Each certificate has a valid lifetime. Sometimes, LSU needs to invalidate some certificates that have not yet reached the validity period (for example, if the certificate sent to an employee expires on January 1, May 2007, and the employee leaves LSU on January 1, January 2007 ). Such revocation is completed through CRL (which contains the certificate serial number list signed by the CA. The serial numbers contained on CRL are those certificates that are not valid for a long time but are no longer considered trustworthy by LSU. The client can then download this CRL and check against it to determine the validity of the certificate.

Any X.509 V3 certificate (except the Root CA certificate itself) should have a pointer to a valid CRl. This pointer is called the CRL distribution point, or CDP for short. The CRL distribution point is included in the certificate itself (see figure 4) and cannot be modified after the certificate is issued. CRL is a basic component used to ensure that certificates from CAs are valid. Similarly, we need to ensure that the lsu crl has physical redundancy and high availability and can be accessed by external parties.

Figure 4 CRL distribution point of LSU (click the image to get a smaller view)
Figure 4 CRL distribution point of LSU (click the image to get a large view)

Windows Server-based ca integrated with Active Directory (such as LSU) will automatically publish its CRL to Active Directory, so that you can use the Lightweight Directory Access Protocol (LDAP) access it. The default release location is the CDP container in the public key service container in the forest (see figure 5 ). This release location is an excellent choice because it provides automatic replication, fault tolerance, and CDP local search.

Figure 5 CDP container (click the image to get a small view)
Figure 5 CDP container (click the image to get a larger view)

However, there are many non-Windows and non-active directory computers that use PKI in the LSU design. Moreover, although LSU is a large organization, most of its users are on the same campus network (with a 10 Gbps trunk line ), this allows the advantages of Active Directory-based CDP release to be minimized.

Therefore, we only release CRL to an HTTP path, making it easier to build a redundant hosting platform (our main website has already created an image site ). This eliminates the potential complexity associated with enabling the client LDAP lookup. We release CRL once a day and perform incremental CRL release every hour.

Outlook

Although our current PKI provides a powerful Security Solution for the university community, we plan to continue to enhance its functionality. Windows Vista and the next version of Windows Server (codenamed "Longhorn") will provide a large number of new key management functions that we plan to study. We are particularly interested in the planned Online Certificate Status Protocol (OCSP) client and responder functions, support for Elliptic Curve Cryptography and SHA-256 algorithms, and a significantly improved automatic registration interface. In addition, Windows XP Service Pack 3 plans to add a credential roaming feature that provides key pair Security roaming without causing system overhead involved in roaming configuration files. Finally, we will study the use of the certificate lifecycle Manager (currently available in Beta versions) to improve our reporting and management capabilities.

In short, the lsu pki provides a basic security service for the university, which is applied in many key IT functions. Using cybertrust's omniroot service, we can run a well-integrated PKI with other IT systems of LSU, but it can be trusted globally. In addition, by building this solution on the Windows CA Service, we have gained Efficient Certificate backup and management capabilities and perfect integration with the existing Directory and identity management system. In short, the powerful Security and seamless trust PKI in the imagination has become a reality in LSU.

John MorelloHe graduated from Louisiana State University with the best academic performance and served as a senior consultant at Microsoft consulting services for six years. He uses MCS to build PKI for strategic customers (such as Deloitte, GE, and various federal organizations. He is currently the Deputy Chief Information Security Officer of LSU.
From December 2006 journal technet magazine.
You are welcome to give your comments. You are welcome to send us feedback.