PKI: The Myth, the Magic and the Reality - Page 4

 By Charles Breed
Page 4 of 6   |  Back to Page 1
Print Article

Part 4: You Can't Buy PKI

By William Murray

Have you heard the one about how to build a 777 airliner? First you build a Boeing. In the presence of a Boeing, building a 777 is merely difficult; in its absence, it is impossible. Okay, so how do you build a Boeing? Well, first you build a network. But how do you build a network? You get the idea.

You can buy an airplane, but not the runways, hangers, terminals, refineries, fuel depots and navigation aids. You can buy an automobile, but not roads, bridges, tunnels and service stations. You can buy nodes and links, but not a network. Here’s the point: You can buy instruments, and these instruments can be very useful in helping you do what you need to do. But you can’t buy infrastructure, which is cooperative, collaborative and public, and which evolves on a generational time scale. You can throw money at it, but, by definition, you can’t buy it.

Back in the olden days, IBM sold access-control programs for its mainframe systems. Given how much customers had been clamoring for this software, it was surprisingly difficult to sell. First, customers had not designated anyone to buy it. Second, they had not designated anyone to operate it, either. There was product, but no supporting infrastructure to make it useful. A generation later, that infrastructure is so well established that it’s hard to believe it hasn’t always been there. While we may build the public-key infrastructure in less time, we still must build it. We can’t buy it.

Public-key cryptography uses two different, but mathematically related, numbers to encrypt and decrypt. Because the ability to encrypt with the public number does not include the ability to decrypt, you can send a confidential message with a minimum of pre-arrangement. Because the ability to decrypt with the public number does not include the ability to encrypt with the secret number, you can demonstrate that the owner of the key pair created the cryptogram. It is this marvelous property that enables digital signatures. All we have to do is to demonstrate who owns the key.

PKI is that collection of ideas, understandings, conventions, agreements, contracts, laws, regulations, institutions, people and, yes, trust and confidence that will enable us to use public-key envelopes and digital signatures to do those things we have historically done with handmade marks in ink on paper. Certificates are analogous to drivers’ licenses, credit cards and point-of-sale network and bank signature card files.

Enterprise PKI is the collection of policies, roles, responsibilities, decisions, services and controls for using public-key cryptography within an enterprise, across applications. Enterprise PKI takes over the functions of enrolling users to applications one-by-one. From a confidentiality perspective, PKI is all about ensuring that you use Alice’s public key when you get ready to send her a confidential message. If, by mistake or ruse, you use Eve’s key, then Eve will be able to read it and Alice won’t. From an integrity point of view, PKI is about knowing that if you can decrypt with a key that you believe belongs to Bob, that Bob in fact sent the message.

The Cost of Infrastructure

Okay, so if you can’t buy PKI, then what’s all the hype about? People are buying and selling something, right? Yes, but it’s not PKI. It’s directory service and certificate service software and hardware, which are analogous to the cameras that take photos for ID badges, or the filing cabinets in which signature cards are stored, or the boxes where extra copies of keys are secured. While all these are necessary to the infrastructure, they are not the infrastructure. They are, at best, components of the enterprise portion of that infrastructure.

Many applications—for example, Lotus Notes—have directory and certificate services built in. The issue of infrastructure arises when one wishes to share directories, key-pairs and certificates across applications. The efficiency of these services increases as the number of applications grows. In general, prefer certificates to shared secrets and trusted servers; in the long run, they will be more efficient.

The cost of the infrastructure is in the initial authentication process, not in how you record the results. That is, it costs far more to establish someone’s identity than to issue him a credential. Once the change in infrastructure is made, it is as cheap to issue a certificate as it is to establish a shared secret in a trusted database. However, if the infrastructure is shared across all applications, then so also can the cost be shared across all applications.

If you can’t buy PKI, and if it may take a generation to build it, then what’s the hurry? The urgency stems from its potential benefits. Few things on the agenda have the promise of enterprise PKI, whose advantages include: (1) a single administrative interface across all applications; (2) credentials, privileges and capabilities that can be relied upon without regard to where they are stored; and (3) strong authentication with efficiency of user logon.

In a world in which our systems are falling over left and right to automated attacks on static passwords, strong authentication is agenda item #1. In a world in which millions of computer users are spending tens-of-minutes per day logging on and logging off, even small improvements in the efficiency of logon are valuable. In a world in which the biggest single chore of administrators is remedying lost and forgotten passwords, these advantages are significant.

Well, if you must build it instead, where do you start, and how do you proceed? As with all difficult issues in the world of information technology, proceed one application at a time. Design your infrastructure from the top down using functional decomposition, and implement it from the bottom up. When selecting products, pay particular attention to their scalability; infrastructure often lasts longer and grows larger than expected. For this same reason, prefer products that interoperate well with others, and that support such open standards as LDAP and X.509. Finally, all other things equal, prefer offerings from those vendors that have technology and market leadership—and that are likely to be around for a while.

William Murray, an executive consultant for Information Protection at Deloitte & Touche, is a 25-year veteran of the information security industry.


This article was originally published on Sep 7, 1999
Get the Latest Scoop with Networking Update Newsletter