Putting the infrastructure back in PKI

Share it on Twitter  
Share it on Facebook  
Share it on Google+
Share it on Linked in  

Depending on who's talking - and what they stand to gain - you hear the full range of opinions regarding the readiness, ease of deployment, and most importantly, cost, of public key infrastructure (PKI) technology. Back in early 2000, a research firm was predicting the PKI market would be taking in multiple billions of dollars by the early to middle part of this decade. Everyone wanted a piece of the action, since capturing even 0.5% of that pie meant a lot of annual revenue. And with Y2K concerns out of the way, what else was there for IT managers to spend money on?

The reality is that pretty much everything you've heard about PKI, good or bad, is true. PKI is a great technology for enabling other services to do things easier and more securely. And yes, it can be expensive and time consuming to deploy - if you shoot for the sky. But do you need to?

When it comes to PKI, the important thing to remember is that the "I" stands for infrastructure. When rolling out a PKI, you really aren't rolling out secure email, certificate-based virtual private network (VPN) access, or digitally signed workflow. What you are doing is creating the infrastructure that will enable these services - through another project. The point is, you've got to distinguish between deploying a PKI and deploying PKI-enabled services.

PKI-enabled services make use of the underlying enabling technology to enhance functionality of applications. Do you need to invest in a large PKI to achieve these enhancements? Not necessarily. To put it simply, PKI is really a way to manage encryption key pairs on behalf of users, with a lot of trust and usage guidelines thrown in for good measure.

In its simplest form, a PKI consists of a "trusted" source of certificates and the policy that dictates their use and management. The trusted source can be a designated person who uses OpenSSL on a laptop kept in a safe to put certificates on floppies and give them to users. So long as a policy is in place that validates the usage and security required for that enterprise, then for all intents and purposes, this will work.

There are essentially two ways you can implement a PKI: build it in-house or outsource. The in-house model is where you own the infrastructure components and run the infrastructure with your own personnel. The outsourced model is where somebody else does it for you. Lately, some hybrid versions have appeared as well. No matter which route you take, designing and deploying the infrastructure requires you to conduct a needs assessment and interoperability tests, develop policies, perform integration and train personnel. And all of this is just to set up the infrastructure; you're not yet getting any PKI-enabled services for your money.

So how much PKI is required to deploy some of these "enabled" services? Let's take a look at the more popular examples.

Keeping it simple with SSL

Secure Sockets Layer (SSL) is the easiest PKI-enabled service to deploy. SSL can be very powerful as it can implement all sorts of granular access controls, but that requires a lot more configuration and potentially design work, with respect to the certificate profile. But basic SSL capabilities require only an SSL-capable Web server and a certificate for it. SSL server certificates can be obtained from a number of PKI service providers for a few hundred dollars. To take advantage of optional SSL client authentication security capabilities, end user certificates will be required. End users connecting to your server can be customers or partners as well as employees. Depending on the number of end user certificates required, using a commercial certificate authority to issue the certificates is again a fast and inexpensive solution. All modern browsers trust most commercial CAs.

Following the simple case scenario where SSL is only being used to enable private (encrypted) access to a server (such as to view private human resources data), and assuming the server is not accessed by customers, then the only requirement is a server certificate that is trusted by parties accessing the server. If the certificate is generated in-house, then the root certificate needs to be pushed out to the clients and configured as trusted. It will take only minimal training to enable support personnel to manage this process and the rest of the server's SSL functionality. But remember, this is for the simplest case. Design, testing, integration, training, support and maintenance grow as you add more features to the SSL functionality.

Secure email

A logical step beyond SSL may be to provide secure email. PKI-enabled secure email is accomplished through the Secure/Multipurpose Internet Mail Extensions (S/MIME) standard for encrypted email. You'll need an S/MIME-capable client such as Microsoft's Outlook98, Outlook Express 5.0 or above, or Netscape Messenger 4.x (sorry, Netscape 6 hasn't yet integrated this functionality into its mail client). You'll also need an X.509 digital certificate for each participating user. And that's it. Other things would make life easier - such as a directory in which to store certificates, or an online certificate status protocol (OCSP) server to validate certificates - but again, the bare minimum is having the correct client and users with certificates.

A trusted third-party CA service can be contracted to issue certificates to your users en masse or on a per-user basis. You would only need to develop a short in-house policy defining usage and certificate lifecycle issues, such as what to do if you lose your certificate. This is a great way to try out PKI-enabled services and get buy-in from management for further services, perhaps leading to a larger in-house PKI.

Last, but not least, you'll need to develop a simple training manual on how to use the mail client to send and receive secure email. The service will never take off if it isn't simple and transparent to end users. Granted, the more "bare bones" the implementation, the more steps will be required of end users and the more documentation to accompany it.

The biggest headache for users can be matching up recipients with their certificates. Depending on the client, its address book features and the availability of a directory, this seemingly simple task can be challenging. Therefore, it pays to do a little interoperability and usage testing to allow for adequate, user-friendly documentation and support. Your IT personnel will also need to be trained because no matter how easy a system is, the end-user community will always require some level of support.

PKI-enabled VPNs

Virtual private networks are another possible application for PKI technology, as an alternative to giving remote users cryptic usernames and passwords and risk having them poorly manage that information (such as writing passwords on sticky notes attached to their monitors). With PKI, users are instead issued a key pair and certificate that is used by the VPN client and gateway for identification and authorization. In Windows systems, the key can be used with no user intervention or, for added security, the user may be required to enter a password before the key is employed.

Most, if not all VPN software provides support for certificates. Again, the minimum requirement is getting certificates to the end users and VPN gateway, establishing a policy and developing the training for end users and administration/support personnel. As with secure email, most commercial CAs can issue the appropriate certificates. It may also be possible to use the same certificate for both secure email and VPN access, depending on what information is in the certificate.

Deployment takes a little longer because you'll need to understand how the VPN integrates with the PKI. Management is also a bit more involved because of update requirements. The idea is that the gateway will authorize a user's access based on the certificate's validity. How the gateway determines the validity varies from vendor to vendor. It may be as simple as providing a list of valid or invalid certificates for the gateway to access locally, or it may require connection to a PKI component such as a CA, OCSP server or a certificate repository (directory). This means that every time a user's certificate is added or removed from the list of valid certificates, somebody (a trusted somebody) will need to update this information in a manner consistent with the selected implementation.

These steps are just the tip of the iceberg. But as you can see, understanding what services are available and to what degree they rely on an infrastructure can get you a lot farther than spending an arm and a leg to build an infrastructure with fully unrealized potential. Ideally, you will one day find that PKI disappears into the computing background noise and is just there when you need it, like so many other computing protocols and mechanisms.

Mark Schertler spent more than a decade as a network information security specialist with the U.S. government's National Security Agency (NSA), where he helped develop the Internet Key Management Protocol. He is now director of Network Security Services for the IT consultancy Primitive Logic, based in Sausalito, Calif. He can be reached at mark.schertler@primitivelogic.com.

Submit a Comment

Loading Comments...