Network Perimeter Security: Building Defense In-Depth

7.2 PKI Implementation

As discussed, not every application will have all the requirements of a fully implemented PKI. As an example, let us consider the application of the PKI to the Internet. The most common model used, of a browser client connecting to a remote Web server, only needs to utilize specific portions of the PKI. The required elements include:

• Certificate management. Here, the only essential requirement is that of the certificate authority to sign the public keys of Web servers. More advanced features are not required because either users cannot be expected to take advantage of them (for example, checking for expired or revoked certificates is rarely performed), or they are unnecessary (as in maintaining a revocation server since they are rarely utilized). This limited functionality is because the major need of Web transactions is to authenticate Web servers. Encryption keys are generated between the client and the Web server.

• Confidentiality. This is expected through the use of the Transport Layer Security (SSLv3.0) standard.

• Integrity. This is also addressed in the TLS standard.

• Authentication. Web servers use certificates signed by a CA and checked against the CA public key installed on a Web browser to ensure that the Web server is the party that the user expects it to be.

Note how the functions differ if we were to use the PKI to enable the secure exchange of e-mail between those in our own business:

• Certificate management. Because we will be using certificates that will affect our ability to access data in the future, our certificate management needs to be much more robust and able to effectively manage keys across the entire life cycle of the certificate. This includes acting as a repository for certificates of those we would wish to e-mail, along with a directory service to find those individuals, maintaining certificate revocation lists, and signing services for new certificates.

• Key management. As with certificate management, we need to ensure that our private keys are not lost due to computer theft, job termination, or hardware destruction. To minimize the impact on users, automatic key updates are also helpful to ensure an efficient work environment for users. Furthermore, it is advantageous to maintain a history of public keys to ensure that encrypted documents are always available to authorized users.

• Client software. Client software is normally bundled with the e-mail client that is used to encrypt the e-mail. In some cases, it may be a separate application that is bundled with the e-mail client.

• Confidentiality and integrity. The use of secret keys transported via public key hash algorithms signed by private keys ensures the confidentiality and integrity of transmitted messages.

• Authentication. The confidentiality and integrity functions depend on the authentication that is provided by the actual certificate.

While this list is more extensive, it is still simply a sub-set of the entire PKI capability set. For each instance that we could conceivably wish to implement a PKI, such as for VPN sessions or single sign-on authentication, there is a set of PKI elements that is applicable. The first challenge then is to determine the needs of our environment. For the sake of discussion, let us assume a common network scenario and examine the relevance of a PKI to it.

In our hypothetical business environment, we have a policy that requires us to securely authenticate remote VPN users, support TLS sessions with our Web server, and encrypt sensitive documents, including e-mail correspondence. This is a pretty typical set of what public key cryptography can be expected to support. Once we have defined the needs according to policy, we need to examine what elements of the PKI we require.

7.2.1 Certificate and Key Management Functions

Given keying material, we need to have the ability to sign keys created by our end users. In most cases, we will need to sign and manage multiple keys to reflect the fact that the keys we use to encrypt data are generally different than the keys that we use to sign data. Encryption keys will need to be centrally backed up to ensure accessibility to data. A third party should never back up signing keys, used for non-repudiation purposes, lest their integrity be called into question. Because the user population can be assumed to be somewhat dynamic, we will also need the ability to revoke keys and perhaps escrow keys to ensure access to encrypted information after an employee leaves. The state of all keys should be reflected in up-to-date revocation lists. We also need to ensure that certificate information is easily available and trustworthy, even to employees who communicate with each other but have never met face to face.

We may also have the need to have a higher CA certify our own CA. This is most likely the case of for our Web server certificate. While acting as our own CA for employee mail will be sufficient, remote users of Web services are not necessarily familiar with our company and will require third-party verification of our server before trusting our certificates. We will want our CA function to also manage trust relationships for this application.

7.2.2 Client Software

Client software will be a consideration. Because we are enabling client applications to perform at least three different functions, will there be any interaction on the client platform regarding certificates? Most likely, the Web browser, e-mail client, and VPN client will all use separate client certificate software. This may require the management of even more keys, one for each application per client.

7.2.3 Authentication

Authentication will be provided through the use of certificates in each case. The certificates distributed by the PKI will provide authentication for remote VPN clients and local users performing single sign-on for network resources and ensure that e-mail users are communicating with the desired remote party. Server certificates can also be used to perform two-way authentication to ensure that the services our users are connecting to are legitimate and not spoofed sites.

7.2.4 Confidentiality

The actual encryption of data will occur after the authentication process.

7.2.5 Integrity

The keys that have been signed by the CA will be used to sign cryptographic hashes to ensure the integrity of data both stored and transmitted.

7.2.6 Policy and Privilege Management

To enable our PKI to integrate with network resources, we need to ensure that policy and privilege tokens can be assigned to the user certificates.

With a clear idea of what we need from our PKI, we can then begin the process of deployment. The next step occurs in two parts. First, we must examine the cost and effectiveness of implementing the PKI ourselves versus the cost and effectiveness of having a third party provide a PKI solution for us. In evaluating our own solution and that of a PKI vendor, there are several important questions to consider.

• Support. Do our proposed vendors provide adequate support? Is the support available when needed, and is it helpful? If we are providing the service in house, can our IT staff be expected to provide an adequate level of support given their other responsibilities? How easy is the PKI to administer?

• Standards. To ensure interoperability with business partners as the functions of the PKI expand, we must ensure that our solutions are standards based. Furthermore, even standards-based implementations may not interoperate with the standards-based implementation of other vendors. This must also be evaluated.

• Security. Have any independent third parties examined the security of the solution? Have the products been evaluated and given a Common Criteria rating to provide assurances that the products provide the security that they claim?

• Reputation. Whether using products in house or a third party, what is the reputation of the vendor? Are they well-established and likely to be around months from now? If the vendor were to shut its doors, would your encrypted data, certificates, and keys still be valid?

• Facility requirements. The security of the CA is paramount to the trust that we have in the certificates that it signs. Should the CA and CA private key be compromised, the attacker could issue certificates at will. In short, the validity of the entire PKI comes into question. Can a local solution be adequately logically and physically secured? What security steps will a third party take?

• Personnel requirements. A PKI will require several roles to operate properly. A security officer should be assigned to enforce security policy. A PKI operator will have the responsibilities of installing and maintaining the PKI systems. A PKI administrator will be required to perform daily functions such as user and privilege management.

• Disaster planning. What would happen to encrypted data if keys were lost or compromised? How does your solution handle key backups, restoration, and revocations? Can you secure the backup media as well as the CA itself?

• Control. How willing is your company to lose control over the PKI process? This would mean that both keys and certificates, the heart of a PKI, would be out of your direct control. Is this an acceptable security risk?

• Cost. Once the above criteria for our own in-house or third-party PKI have been examined, how do our solutions compare in cost? A PKI only makes good financial sense if the cost of the PKI is less than the cost of the information it is trying to protect.

Answering these questions based on our PKI needs will help us determine if the PKI is most likely something that our company should implement itself or if it is best left to third-party solutions. There is even the possibility that, based on our current security needs, the cost of implementing a PKI is not justified.

Like all information security systems, a PKI should be implemented only in response to a detailed risk analysis and adoption of a comprehensive security policy. Because a PKI is a modular structure by design, it is imperative that the needs to be fulfilled by the PKI are first defined. Before the purchasing of products begins, the question "How will this PKI achieve the goals of my security policy?" must first be answered.

The price and technical details for implementation must be carefully considered if the PKI is going to be a truly effective countermeasure. Although a PKI is not terribly difficult to implement with proper preparation, many institutions tend to outsource the implementation and perhaps even the management of their PKI in the hopes of leveraging the economies of scale that a dedicated PKI provider can achieve.