Imagine a technology that authenticates virtually any transaction, enables e-commerce applications and is available to any user, anywhere.
Now imagine a technology that can lead to fraud, is expensive to implement and requires serious retooling of enterprise hardware and software to be effective. Which one would you pick?
Actually, both descriptions apply equally well to the same technology: public-key infrastructure (PKI). PKI can help anywhere strong authentication is needed -- in business-to-business transactions, in bank exchanges, in communications involving human resources data. These types of transactions are usually encrypted using digital keys, and PKI comprises the policies and equipment to manage those keys.
In recent history, PKI has taken its place alongside firewalls and VPNs as a security must-have for a growing number of enterprise networks. But PKI design remains something of a black art, forcing network professionals to wade through a thicket of acronyms and algorithms. It's little wonder many companies opt to outsource the entire process. Others, mistrustful of delegating too much security, muddle through rolling out their own.
For network managers opting to build their own PKI, the biggest risk is compromised certificates resulting from network, physical or personnel security that isn't up to a specification. Outsourcers are usually strong in these areas, but any company going with a commercial certificate authority provider still needs to be vigilant that the provider keeps the corporation's data private.
Deciding whether to build or buy is probably the most important step in any PKI implementation. Neither route is easy, and both pose serious security risks if poorly implemented.
For build and buy decisions, network executives will need to understand the various PKI components, the elements of PKI design and the ways in which PKI interacts with existing applications and network infrastructure.
By mixing and matching the basic building blocks, network designers can put together PKI for a department, a company, many companies or many individuals. The design phase is where PKI gets tricky.
In the most basic case, all users request certificates from one certificate authority. This design is simple, but also unrealistic in most company settings because it may not scale to encompass multiple offices or large numbers of users.
A more common type of PKI design involves a hierarchy of certificate authorities with a "root" certificate authority at the top of a tree. A hierarchical design is relatively simple, but on the downside, it doesn't provide for direct any-to-any connectivity among certificate authorities.
Using this model, any PKI-enabled application must first verify the authenticity of a certificate before using it. This involves the certificate application walking the tree of certificate authorities and thereby establishing a so-called certification path. In a hierarchical design like this, all certification paths must begin at the root certificate authority as a design restriction -- in this case the root certificate authority is the one vouching for all the certificate authorities below it. The deeper the hierarchy, the more complex the certification paths become.
An alternate design employs a mesh topology, with all or most certificate authorities directly connected to each other. Here, certification paths may begin at any point. Accordingly, the certification paths are more varied than in the hierarchical model, but they may actually be simpler for the certificate user. The benefits of a shorter certification path are that authentication may happen more quickly and management traffic is reduced.
Unfortunately, most certificates don't offer clues as to whether they belong in a hierarchy or mesh, or at which point along the certification path they should begin to make a query to the originating certificate authority. For security, it probably won't be apparent to end users exactly who is doing the certifying. For performance, longer look-up paths take more time to traverse. Some implementations build a "certificate cache" in PKI-enabled applications -- a store of all previously used certificate paths -- to speed future attempts at certificate path construction.
It's important to note that these are design and not product issues. Any commercial certificate authority product will work in either design.
The PKI market includes software and equipment vendors and outsourced service bureaus. Software and equipment vendors offer tools such as certificate authorities, smart cards and encryption algorithms. Major vendors in this area include Baltimore Technologies, Entrust Technologies, RSA Security and VeriSign.
Service bureaus such as Electronic Data Systems, IBM, the Big 5 consulting firms and numerous ISPs offer the same tools as equipment vendors, along with value-adds such as integration.
From the buy side
Service bureaus will integrate PKI into just about anything -- be it an enterprise application, a router, a set of VPN gateways or a wireless infrastructure. Service bureaus also manage the certificate authority and handle the issues surrounding certificate management, such as obtaining a certificate (called "enrollment" in PKI-speak) and keeping certificate revocation lists current. Outsourcing also moves the responsibility for securing the certificate authority away from the company.
Many companies find it more convenient to hand over these tasks than to manage their own certificate authorities.
"It's still hard to do enrollment and revocation, partially because the protocols are hard and partly because they're not implemented in a neat, tidy way," says Rodney Thayer, a security consultant and author of several PKI and IP Security standards.
Another plus for service bureaus is they set up and manage public certificate authorities, an important consideration for e-commerce applications. Public certificate authorities give customers a ready means of mutual authentication without the need to expose a company's internal network.
One last consideration in favor of service bureaus is that PKI standards are still a moving target. Going with a service bureau could relieve a company of having to keep current with the alphabet soup of PKI protocols and the politics that surround them.
Consider the two competing proposals for "certificate lifecycle" issues -- enrollment, revocation and expiration. Entrust and Baltimore Technologies back a specification called certificate management protocol, while VeriSign, Cisco Systems and Microsoft support a competing specification called certificate management protocol using cryptographic message syntax. The two protocols differ in the extensions and cryptography standards they support. Companies without an abiding interest in these topics may find it more worthwhile to pay someone else to sort it out.
The biggest downside for buying a managed PKI service is the farming out of trust. Some companies won't outsource any security function because they're not comfortable delegating security to outsiders.
That doesn't mean outsourcing is automatically the best choice. Arguments for rolling out your own PKI include project scope and a desire to control all aspects of key management.
A project involving one certificate authority, a small set of users and a simple security policy, may not justify bringing in a service bureau. For more complex situations, the buy/build decision may be a question of deciding whose time is more valuable -- the internal staff or the outsourcer. Thayer favours internal certificate authorities, regardless of project size.
"People always say internal [certificate authorities] are hard to do, but they're really not any harder than outsourcing," Thayer says. "When you look at all the procedures you end up going through [with service bureaus], it ends up about the same."
Thayer cites one case where a client decided to outsource its PKI and had to sign nine contracts, including different pacts for requesting and issuing certificates. "Some of the contracts were just silly, like those barring us from fraudulent behavior that was already illegal," Thayer says.
Thayer also rejects the notion that outsourcing enables cross-certification of multiple organizations' certificate authorities. "Cross-certification is a trust leakage mechanism," he says.
While building one's own PKI has its advantages, the learning curve is definitely steeper. Network executives will need to learn PKI protocols and design issues that can make even the most complex lower-layer network design look like child's play.
Certified, but safe?
Regardless of which way you go with the buy/build decision, there are serious issues of trust management that need to be addressed in any PKI design.
These issues include the security of the certificates and certificate authorities; the authority of the certificate authority; the uniqueness of certificates; and the degree to which integration of other systems into PKI may compromise the system.
Certificates are assumed to be secure because they're issued by an authority and signed with a user's private key. But the vast majority of users store certificates on conventional computers or smart cards, both of which are prone to attack. As in any system design, security is only as strong as the weakest component. If the storage medium is vulnerable to viruses, other malicious code, or even physical attacks, the certificate is vulnerable, too.
In some states, the holder of a key certified by an approved certificate authority is responsible for whatever that key does, says Bruce Schneier, a leading cryptographer and CTO of Counterpane Internet Security Inc., a security monitoring service. The problem with this, he says, is that it doesn't matter who was at the keyboard or what virus may have done the signing.
PKI vendors generally consider nonrepudiation -- the inability of a certificate holder to deny a transaction took place -- to be a benefit. Schneier doesn't think nonrepudiation is a valid practice in all cases. He cites the example of credit cards, where users can repudiate unauthorized charges. There isn't yet a similar mechanism in most PKI designs.
Of course, securing the certificate authority is also a major issue in the case of buying or building. A compromise of the certificate authority's private key would be a disaster in security terms because it means the attacker could issue bogus certificates.
But attackers can compromise the certificate authority's authority even without compromising the certificate authority. In an alarmingly high-profile case earlier this year, attackers posing as Microsoft employees successfully extracted bogus certificates from a certificate authority run by VeriSign. Microsoft was forced to issue a security bulletin stating that the vulnerability could affect "all customers using Microsoft products." VeriSign determined the breach occurred because humans did insufficient checking on the validity of the attacker's request.
Although the bogus certificates apparently were never used, they could have been used for anything -- and that raises the issue of certificate legitimacy. For example, your assistant could pose as you and say to your bank "withdraw all my money" or to your doctor "send all my medical records to XYZ address."
Microsoft asks users to decide whether they trust Microsoft content when they download bug fixes. Few users actually inspect the digital signature to verify its content, making it just as easy to accept forged certificates as legitimate certificates.
Counterpane's Schneier points to an even more pervasive example -- the Secure Sockets Layer encryption used to secure Web transactions. He says there are Web pages whose certificate is for the Web hosting company, not for the company whose logo is on the pages. In such situations, Schneier says it's not clear with whom the end user is having a "secure" conversation. Worse, he says, most end users can't or won't be bothered to find out.
Yet another generic problem with certificates is that they may not be unique. Schneier gives the example of a certificate for someone named John Robinson. Even if a user knows only one person named John Robinson, the certificate authority may know dozens, Schneier says. The X.509 format allows the use of many other attributes besides the "Common Name" for identifying a certificate holder, but this practice assumes the certificate user also knows to use those other means when looking for the correct John Robinson.
A final issue is that of integrating PKI with existing applications, especially authentication schemes. Consider single sign-on (SSO) authentication mechanisms. It is possible to integrate a certificate-issuing smart card into an SSO system so that a user only has to authenticate once a day to reach all the computing resources in the company. While it sounds convenient, Schneier cautions that it also defeats the PKI's intent of validating every transaction at the time of the transaction. For an office clerk, it may not be a big deal if someone "borrows" the computer while he is at lunch; in the boiler room of a brokerage-trading floor, the stakes could be different.
Properly implemented, PKI can deliver a powerful means of making any transaction so secure it's virtually immune from attack. It can also pose some of the thorniest security challenges network designers have ever faced. Getting it done right is difficult and requires taking the time to understand and implement the various pieces of the PKI infrastructure in a truly secure way.
Newman is president of Network Test, an independent benchmarking and network design consultancy in Westlake Village, Calif. He can be reached at firstname.lastname@example.org