Pandora's Box or Panacea?

PKI's promise is to help make e-commerce transactions truly secure. But because it's built on a fragile underlying Web of trust, be careful when implementing it in your enterprise.

Greek mythology says the first woman, Pandora, was endowed by the gods with all the graces and given a box full of all the world's bad things. Despite instructions, Pandora opened the box and set evil loose on the world.

Conversely, Panacea was the Greek goddess of healing, and her name has come to mean the answer to all problems and difficulties.

So which one is PKI?

PKI Basics

I assume in this article that you have some knowledge of how PKI works, but to review briefly: PKI is based on key pairs, one kept private and one made available via a certificate in some public domain. Only the private key can decrypt what has been encrypted by its associated public key, and vice versa. The best implementations rely on the issuance and management of these key pairs by the presence of a certificate authority, whether public or private. The very words "certificate authority" have come to mean the organization that manages the infrastructure as well as the physical device which stores the policy and issues the certificates.

—R.B.

I suspect that most of you have been subject to some promotional efforts that offer Public Key Infrastructure, or PKI, as the solution to all your security issues. In the world of the future, it's said, you'll use PKI to log on to systems, encrypt your e-mail, digitally sign e-documents and access your medical records over the Internet.

Chances are that you're already using some form of PKI somewhere today. Perhaps you have a token, smart card or biometric device that relies on or is integrated with the use of private and public key pairs, certificates and such. Perhaps you've purchased a certificate from Verisign or some other public Certification Authority to use for e-mail or to create a secure server for your e-commerce site.

On first examination, PKI-issued certificates do seem to be a security proponent's dream. These electronic data structures remove authentication from the bane of passwords and instead use tokens, cards and devices. Slick cryptographic wizardry seems to support hack-proof structures. But does it?

The supporting infrastructures of PKI are built on something so ultimately fragile that it proves once more that technology will never be the final answer to security issues. PKI, you see, is built on trust. You trust that the lynchpin, the Certificate Authority (CA), that nebulous device that actually issues and signs the certificates, can't be compromised. You trust that the humans managing the CA can't and won't accidentally issue certificates to imposters. You trust that users can't and don't share private keys with others. And unless you choose to operate an internal PKI in a vacuum, you trust that other PKIs outside your enterprise are worthy of your trust.

So just how fragile is this system of trust, and does it mean we shouldn't embrace this solution? What other PKI-specific vulnerabilities or issues should cause you to pause?

I'm not going to lecture here on the technological gyrations that make up the components of PKI [see the "PKI Basics" sidebar]. Nor will I pick at any perceived weaknesses in its algorithms. Instead, I'm going to make you aware of the human and peripheral issues produced by implementing a PKI infrastructure. My intent is to make you think a bit before jumping on the PKI bandwagon. If your company is already firmly on the bandwagon, I want to inspire you to review what your teams have implemented and where weak spots might crop up.

Six Possible Cracks in PKI

Unless you're very careful, implementing PKI can expose your enterprise in ways you might not have considered. Here are six places where PKI can fall short if implemented incorrectly or carelessly:

Invalid certificates. When a certificate request is authenticated, it's possible for an imposter to step in and issue an invalid certificate. A security episode with Microsoft Corp. and Verisign Inc. last year illustrated this problem.

Bad "krills." If a certificate is revoked for some reason, the Certificate Revocation List may not show that-or a user's browser may not be set to check the CRL list during a purchase. CRLs, or "krills," aren't yet what they should be-up-to-date lists of invalid certificates.

Self-sign certificates. Some software, like Microsoft's Encrypting File System (EFS), lets users encrypt their own files in Windows 2000. This can create problems, though, since your administrators lose control and files can be lost. In a well-designed system, centralized control monitors all encryption.

Protecting the CA. The Certificate of Authority is central to a PKI, and thus its weaknesses can become the PKI's weaknesses. If you're keeping a database of private keys, that's a potential vulnerability. Likewise, make sure the company issuing CAs is worthy of your trust.

Deciding whom to trust. There are three models for PKIs, each based on a different trust model. This can create problems. For example, you may have difficulty using certificates issued by a CA using one trust mode in an architecture that depends on another trust model.

Who controls the private keys? Like CAs, private keys are integral to PKI and must be guarded appropriately. Think about protecting private keys on a hardware device, establishing key escrows and blocking the use of hijacked keys.

—R.B.

Crack 1: Certificate Requests
Certificates are central to PKI in that they can be used to authenticate access to systems-but how is the request for a certificate validated? How can the CA discover if the requestor is who he says he is? After all, imposters have already succeeded, and at least in one instance has been made public. In early 2001, Verisign Inc. announced that it had erroneously issued two code-signing certificates. (Code-signing certificates verify that applications, scripts and other executables were produced by a trusted company.) However it happened, someone was able to obtain two certificates from Verisign that carried Microsoft identification-but the requestor was not from Microsoft Corp. Although there's no publicly available record of the certificates being used for an illicit purpose, the point was made. If a certificate is supposed to prove identity, and someone obtains it falsely, the system has been breached. Although it didn't happen, users could easily have been tricked into downloading and running malicious code.

Crack 2: Bad Krills
Along with the challenge of authentication, here's the other big PKI issue: How do you determine if a formerly valid certificate has been revoked?

Certificates, like credit cards, expire. Since credit cards can be stolen, the banks that issue them have created a method for manually invalidating them. Because card validity is automatically and electronically checked at time of purchase, we often forget that not too many years ago merchants had to look through little booklets of invalid card numbers at the checkout stand, and later had to manually dial for approval-that or take a chance that your card was still good.

Well, I've got some bad news for you. Establishing that an electronic certificate is valid today is harder than it was to establish the valid credit card transaction of yesterday. Oh, there are Certificate Revocation Lists, or CRLs (pronounced krills). CA vendors are supposed to regularly add their revoked certificates to CRLs. Problem is, even if CAs are vigilant, your PKI-enabled application (a browser, for example) must be able to use the CRLs. Modern browsers and PKI-enabled applications can be directed to automatically check revocation lists before approving transactions, but to do this, they have to be able to find the revocation list quickly, and they must be able to work with it. Browsers, by default, aren't set to do either. In the Microsoft/Verisign case I described, Verisign did revoke the improperly issued certificates as soon as it realized it had issued them. However, Verisign apparently doesn't include the address of its CRL in its certificates. So even if a browser was configured to check the Verisign CRL, how could it have done so without a CRL address to go to?

The answer, of course, is that it couldn't. In this case, Microsoft prepared a patch for its browser that hard-coded the serial numbers of the two illegal certificates. It wasn't a good solution, but it was a necessary quick fix to repair a problem created by another vendor.

In the long run, public CAs, PKI-enabled application vendors and users of these products-that's you-must demand and meet strict requirements for CRL publication standards.

Cross Certification Trust Model

Vendors are starting to work together to issue trust models. The Cross Certification trust model allows mutual certification of consenting companies' CAs. Because each partner's CA trusts the others, certificates issued by the other's CA can also be trusted. Each company retains the ability to determine for what purpose certificates are trusted. Here are some examples:

—R.B.

Crack 3: Self-Signed Certificates
A PKI consists of multiple components that work together. The CA is the seat of policy for the PKI. It issues certificates, maintains a database of information on certificates issued, requested and revoked, prepares and publishes the CRL, and contains security policies and encryption modules. Certificates are composed of data structures that enumerate information about the owner and the issuer, as well as a copy of the public key half of the key pair. Cryptographic algorithms, in many cases executed on the client, produce the key pair. Additional components-a key escrow, recovery agents and hardware, like smart cards and biometric devices-complete the infrastructure.

Much of the strength of the PKI concept is based on the ability of the many components to augment and enforce the actions of the others. In a well-thought-out and implemented design, there's built-in protection. Control is centralized and can be appropriately and more easily administered.

A full-blown PKI isn't necessary, however, to take advantage of the strength of public key/private key algorithms. A number of applications exist that take advantage of this; one example is Microsoft's Encrypting File System (EFS). This built-in enabled-by-default mechanism allows Windows 2000 users to encrypt personal files on the desktop. EFS uses self-signed keys (meaning there's no CA present to issue the certificate-it's signed by the user instead).

The concept sounds good: You trust yourself, and the files are your files. That's true, but because the files are self-signed, there's no central way to manage keys. That leaves users responsible for their own key archive-and we all know what happens when we leave those sorts of responsibilities to end users. Also, because recovery key agent keys are difficult to manage, the ability to decrypt encrypted files can be lost. The solution in this case is to disable EFS until you can implement a PKI to support its use centrally.

Crack 4: Who's Guarding the CA?
As I said, a central element of PKI is the Certificate of Authority. A CA's weaknesses can become PKI weaknesses.

In the password/user ID security model, access control is only as good as the strength of the password and the end user's security savvy. That means users shouldn't write down passwords and stick them to desktops, or share them with others. Replacing passwords with certificates on smart cards counteracts some of these issues, but doesn't remove them all.

Like passwords, certificates rely on your ability to protect the security database. If an attacker can access the password file, he can take it offline and use tools to crack passwords, then return later to masquerade as a valid user. In a strong PKI, the private key is held only by the owner of the key; there's no central database of private keys. The public keys are made public so that they can be used to establish secure transactions with the owners of the matching private key. An attacker gains little by compromising the public key store, since it gets him little more than what you've approved access to anyway. And knowledge of the public key doesn't easily lead to discovery of the private key.

There is, however, a component that must be protected from attack-the CA itself. If the CA can be compromised, the attacker might issue himself or herself certificates that allow unrestricted access to your systems and resources.

If you place your trust in a public CA, you need to be assured that the public CA is keeping the CA absolutely safe. If your company manages its own CA, is it offline and installed inside a vault with James Bond-style security? How can automatic enrollment of users and computers exist if the CA isn't connected to the network? If each certificate must be obtained offline and somehow placed online, is there an opportunity for theft during that event? Think carefully about how you can manage this efficiently and still protect the CA.

Crack 5: Deciding Who to Trust
Finding the address of CRLs, which I discussed earlier, isn't the only area in which compatibility issues arise. In fact, it's one of three major differences in PKI implementation today that may cause you problems. While you might avoid these issues to some extent by adopting a single vendor's solution, that's not acceptable in an Internet/global economy. While proposed standards exist [see the "PKI Resources" sidebar.—Ed.], they're merely recommendations; standards don't define implementation. Vendors usually follow standards in response to customer demands for integration. PKI is moving in this direction, but beware of vendor-issued compatibility statements.

One of the major differences in PKI is the way in which trust is established. There are three basic models for PKIs, each based on a different trust model. A properly issued and standard certificate from one vendor's CA may not be recognized by another vendor if the validity of the certificate can't be determined. To establish trust, an application must be able to determine if it has established trust with the issuer of the certificate. This is the "anyone-who-is-a-friend-of-yours-is-a-friend-of-mine" approach, and it works well if I can figure out who your friends are.

In the hierarchical trust model, a top-level or root CA can issue certificates for subordinate CAs, which may issue certificates to other subordinate CAs. Eventually, one or more CAs issue certificates to users. To determine if a presented certificate is trusted, the system traces its origin back to the root CA. It isn't necessary to store trusted certificates, just a copy of each trusted root. Microsoft PKI implements this style of trust, as do certificates issued for server authentication using SSL. If the Web browser stores a copy of the root certificate for Verisign, all server certificates signed by Verisign can be extended trust. This is a model used by Amazon.com. In addition to the encryption of your credit card data when you make a purchase there, your browser has verified that the Amazon server owns a certificate that has been issued by one of the trusted root certificates it has in its certificate store.

In the network model, trust is established directly between two certificate holders. Your application must obtain and store certificates from all of the parties you want to trust, and they must have a copy of mine. This rather unwieldy trust is used by PGP, the popular e-mail encryption and digital signature signing certificate. It works because we can share certificates with those few we want to trust. Imagine, however, if this process was used in the e-commerce world. You'd literally have to obtain certificates from every merchant you dealt with, an enormous waste of resources as well as an impossible task. How could you ever determine that the certificates were to be trusted? In other words, how do you know they are from the company they claim to be from?

Imagine the difficulties in attempting to use certificates issued by a CA using one trust mode in an architecture that depends on another trust model.

Cryptographic algorithms and key lengths raise another question. Not every CA uses the same cryptographic algorithms, nor are available key lengths always the same. While most CAs offer choices, the integrator must take care not only that both support the same algorithms and key lengths, but that those used to produce certificates by one fall with the ranges available on the other. I'll address this issue in a future column.

Crack 6: Who Controls the Private Keys?
We've talked about the need to secure the CA, but what about securing the private keys? They're also an important part of PKI, and as with CAs, their weaknesses can translate over to the PKI. In your organization, are private keys ensconced in some hardware device (that's good), obscured and protected on the client machines' hard drive (that could be good) or traveling from machine to machine (that one is harder to protect). Is there a "key escrow" or some other way to retrieve good copies of damaged keys? What are the consequences of this? Can users control what happens to their private keys? If private keys can be hijacked, what prevents them from being used by unauthorized personnel? Various strategies abound, from self-destructing smart cards to biometric affirmation that the owner of the key is indeed using it. What's best and how much more does it cost? There's not necessarily a best practice for everyone here; it's more important that you ask and answer these questions in order to ensure that private keys aren't a weak spot in your enterprise.

PKI Resources

Here are some helpful sources for further research into PKI.

Understanding Public-Key Infrastructure, by Carlisle Adams and Stevel Lloyd, Macmillan Technical Publishing, ISBN 1-57870-166

A good PKI primer is at www.webtools.com/story/security/_TLS20010222S0001

You can examine RFCs at www.rfc-editor.org/cgi-bin/rfcsearch.pl using the RFC search engine. While you are there, you may want to read these PKI-related RFCs:

  • RFC 2585 details the proposed standard for the use of FTP and HTTP in obtaining certificates and CRLs.
  • RFC 2527 presents a framework for writers of certificate policies or certificate practice statements.
  • RFC 2587 describes a schema to support PKIX in an LDAPv2 environment.
  • RFC 2560 discusses the Online Certificate Status Protocol, a methodology for checking certificate status without using CRLs.
  • RFC 2510 specifies the Internet x.509 Public Key Infrastructure Certificate Management Protocols.

—R.B.

Epilogue
Despite all these potential problems, I believe that PKI will persevere. I don't think using PKI equates to opening Pandora's box, but it must be done properly. Used correctly, PKI presents a relatively strong, robust technology that can be used successfully to thwart attack. I'm betting that we'll all find many reasons for deploying it in our enterprises. Ultimately, the issue comes down to this: Can you properly and securely implement PKI for the use it's intended for? Is your trust in third-party CAs, products and partners well-founded? Can you audit your use of PKI? Are you willing to take responsibility and ensure its appropriate use and protection?

While doing all of this can provide a secure PKI, the bottom line is: Whom do you trust to design, implement and maintain PKI? We no longer entirely trust employees, so we attempt to use technology to move the need for trust elsewhere. In doing so, we need to remember that no technological system is foolproof. We can't eliminate the necessity for training employees in how to use security systems, and in creating an atmosphere in which all people work toward the common good. PKI reminds us to avoid misplacing our trust in technology alone.