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

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

Part 6: Roundtable
Pioneers or Guinea Pigs? Three early adopters discuss the pros and cons of PKI deployment.


Sanford Brumley
VP of Business Development, Chase Treasury Solutions, The Chase Manhattan Bank
PKI Vendor: Entrust Technologies Inc.

John Jordan
Leader, IT Security Development Team, Texas Instruments Inc.
PKI Vendor: VeriSign Inc.

Hany Elmanawy
Manager, Electronic Value Added Services, Universal Postal Union (Switzerland)
PKI Vendor: Baltimore Inc.

INFORMATION SECURITY MAGAZINE (ISM): Let’s start with the basics: What are you using PKI for? What goals do you hope to achieve with it?

BRUMLEY: Chase Treasury Solutions is using PKI to secure all forms of financial message traffic from our clients, including payment instructions, changes in negotiable financial instruments and other forms of financial communication. We look upon the PKI as a utility, since we’re principally using it to secure instructions from our customers to move money.

Simply put, a robust PKI is what allowed us to expand operations to the Internet. Six months or a year ago, this might have solicited a ‘so what?’ from people. But now it’s an accepted fact that any business with a future has to have broad distribution across the ’Net. Without a PKI, most of the Internet-related development at Chase would not be possible. So it’s obviously a very important utility for us.

JORDAN: We’re putting in place the PKI that will be utilized by all of Texas Instruments. Our pilot program is mainly focused on authentication and access control for business-to-business transactions with TI suppliers and distributors. For example, somebody from Company A connects to our Web page and accesses one of TI’s extranet business applications. The app pulls information out of the user’s certificate, if one is found, to determine who that person is, what company they’re a part of, etc. Based on that, the app builds a Web page specifically for that company, displaying all of their pertinent data.

This is the pilot setup, and we plan to expand it as time goes on. The big push right now is to get the external b-to-b relationships working. In the future, we plan on expanding the program to include authentication for intranet Web applications, document signing with certs, software authorship signing and digital signatures on e-mail.

ELMANAWY: We’re using PKI technology to secure electronic correspondence between our clients. The technology is used as an infrastructure for existing applications, including secure e-mail, secure document exchange and secure EDI.

We view PKI itself as a utility infrastructure—it provides security and authenticity to valued transactions. The overall goal is to achieve wider applicability of the PKI to as many applications as possible.

ISM: One of the big decisions to be made when looking at a PKI is whether to insource or outsource a certificate authority. I want to explore the pros and cons of both options by asking each of you to explain why you chose one over the other.

BRUMLEY: There was a fair amount of discussion early on about whether to insource or outsource, but in our case it was resolved quickly because of the nature of our business. When you think about what a bank does, we mediate issues of trust

between buyers and sellers. It’s what we’ve always done. We see operating our own CA as a key aspect of the services we offer, and we like to be in close control over it. Also, we expect to find economies of scale within our own operations that would not be available to us if we were to outsource.

The decision to use Entrust came as a result of a fairly traditional analysis of the alternatives. We issued an RFP and got responses from all of the key players. And by setting up a matrix of features of each company, we were able to reach a team

decision on which one was best suited to serve Chase’s needs in the long run.

ELMANAWY: To make this decision, we basically focused on two components: the applications and the trust model. First, which applications require security, and what is the business value derived from securing these applications? Second, who does

the customer trust to manage their digital signatures? PKI provides the technical

security guarantees, but it’s the service provider’s policy that furnishes liability protection over valued transactions.

For us, then, the issue became a trade-off. Deploying a PKI in-house is a costly proposition, but outsourcing a PKI means someone else is managing your customers’ digital signatures. Overall, our business case led us to the choice of insourcing the technology through Baltimore, and managing the infrastructure ourselves.

JORDAN: We have outsourced and use the VeriSign service, but we have our own private label CA. We have automated processes in place to allow individual users to request and obtain their own certs, and we’re a couple weeks away from having an automated process to allow each user to revoke his or her own cert.

Basically, we built our own Web app that actually handles certificate issuing. It’s got the

security built in to authenticate users before they actually go get the cert from VeriSign. And we have a specific process with VeriSign so that what we get back is a TI-rooted cert. With this application, every certificate we issue has an understood level of trust, and the automation of the process reduces the cost to manage and support the infrastructure.

ISM: Walk us through some of the initial steps involved in your pilots and give us a sense of the stumbling blocks you encountered, so that others can be prepared as they move into the pilot stage.

BRUMLEY: We faced two general issues: securing the CA and scalability. Eighty percent of the work we did in installation had to do with securing the perimeter of the CA: what sort of firewalls to have in place, how to control access, how to communicate to customers out of band. That process took us three or four times the amount of time it took us to make the purchase decision on the CA itself.

The other issue was scalability. In some setups, scalability isn’t going to matter,

but in our case it certainly does. At the moment, we’re issuing thousands of certs, but we hope to expand that to hundreds-of-thousands and eventually millions, for multiple lines of business and, ultimately, on behalf of our customers.

ELMANAWY: The major issue for us concerned the security of the whole PKI

environment—not only physical security but also the processes and procedures, which depended on two things: technology performance and people. Our certificate policies had to be fine-tuned to balance these issues. Technically, the main issues were related to gateway interoperability, which was resolved with specific modules. Interoperability between messaging clients remains an open issue with most if not all of the current clients, including Netscape and Microsoft. When we tested a multiclient environment, each client handled it differently. In addition, each client encoded S/MIME messages

differently, which made it impossible for two people using two different clients to recognize each other’s digital signatures.

ISM: What key applications do you give certificate access to, and have you had any problems with making these applications PKI-ready?

BRUMLEY: The one that is most visible is Chase Workspace, a treasury management system that’s delivered via the Web. There’s a client-side piece of software set up to manage the certificate interaction. The reason we have to do that is that the basic functioning within browsers is principally link-level encryption. But for policy reasons we require user authentication and a signature on the transaction itself. In order to make that work we have to issue some client-side software.

Eventually, we’d like to see the client software get a lot more standardized, so that it’s just out there rather than something we have to issue. But for right now it’s a lot easier to issue client-side software in the browser space for what we do with our high-end treasury workstation product, which is a huge Windows application.

ELMANAWY: Currently, EDIFACT messages are certificate-enabled. The messages are used to transfer data related to post services and postal items. It’s a closed PKI implementation of the community of existing services, but because of its security

and authenticity we are able to save a lot on handling costs. There were no major problems except for gateways, as described earlier. However, issues with e-mail client interoperability remain.

ISM: Is PKI-enabling key applications a huge obstacle?

ELMANAWY: If it’s an obstacle today, it won’t be tomorrow. Cryptography-based PKI has been around since the ’70s. The basic technology is stable, especially in closed environments. However, when you deploy an open PKI, there are obstacles of interoperability between different systems. In addition, there is a huge cost driver residing in historical CRLs [Certificate Revocation Lists].

There is also a ‘terminology obstacle’ for consumers: People hear PKI, CA, certs, etc., and they have no associations to help them understand what they mean.

JORDAN: I agree with Hany. I think application integration is harder today than it will be in the future. It’s really due to the infancy of PKI. It’s still that ‘new novelty’ out there. Software developers need to realize that PKI is real, and it’s going to be here for a long time. And they need to understand that their applications need to be enabled to handle it.

ISM: Do you have any experience with these PKI-to-legacy application solutions, which basically "PKI-enable" different kinds of commercial and custom-developed applications?

JORDAN: TI doesn’t. You need to weigh the cost of these products versus the benefit you get on the back-end. There are many applications that aren’t going to be PKI-enabled because it just doesn’t make business sense. On the other hand, the life of some apps is extended if you PKI-enable them. So it’s a case-by-case decision.

BRUMLEY: I agree. At the moment, you have no choice but to handle this on a case-by-case basis. In the long run, I think, there will be a mature PKI architecture in which the majority of major applications are PKI-ready out of the box. The big adventure at the moment involves identifying the key pieces to get to that point.

JORDAN: The way I think it’ll happen is that when companies go to a software vendor or a development team looking for a new application, one of the requirements will be that it’s PKI-enabled. It won’t be an option. It’ll be a requirement for doing business. And when the same requirement is received on a regular basis, software companies will change their thinking on how PKI can benefit their products. Then the necessary resources will be spent to really integrate PKI into their applications.

ELMANAWY: You’re probably right. New PCs may come with unique chips that identify the user. Desktop software already links you to get your certificate from recommended providers. Also, authentication of the sender may become part of the network topology. However, as businesses and consumers realize that PKI technology facilitates the presentation of their online identities in a ‘claimed’ way, trust will be the central issue. The question will be: Am I going to rely on a digital contract signed by a certificate that was issued without any face-to-face authentication? If there’s a breach of authentication, who will I seek compensation from?

Yes, future technology will come with PKI components built in, but from a trust relationship perspective, users should evaluate the policies and procedures of trusted third parties and decide if they should be attributed trust for the type of transaction at hand. What I mean is, the issue is not so much one of technology as it is the decision to rely on an electronic transaction that is based on some level of authentication and security provided by a third party.

ISM: What are some of the other drawbacks to deploying PKI right now?

JORDAN: Well, Hany hit on a central issue here. One of the big challenges facing the industry today is how to build and manage circles of trust. As the use of certificates expands, the issue of how individuals should manage multiple certs to interact with different companies will be a growing concern. Until there’s a broad-based mechanism for establishing circles of trust, there are going to be growing issues with the number of different kinds of certificates they’re going to have. It’s an issue that’s going to get larger as time goes on, unless there’s some kind of industry-wide solution.

TI addresses it by issuing a TI-branded cert to its business partners. This is not a good long-term solution. As other companies require their own branded cert, the user’s cost of managing individual certs becomes expensive.

ELMANAWY: Yes. The issue of interoperability between systems is the major drawback. We can’t assume everyone will use the same CA—or that different CAs will use the same technology. The postal industry has tried to address this problem by establishing a common framework for PKI interoperability across 18 postal administrations in 18 countries. After two years, we have established standard policies and procedures that guarantee trust across borders.

A big drawback to this framework, however, is current product limitations. We may be able to provide a solution for the issue that John brought up—handling many certificates based on trade relationships—but the technology does not support it at this time. The vendor community of PKI providers, clients and middleware providers will hopefully put the effort into implementing the standards in a common way. The drawback is the ‘wait time’ until the vendor community can support full PKI interoperability in an open environment.

ISM: Sandy, how does Chase handle the certificate interoperability problem?

BRUMLEY: Same way TI does. We’re issuing Entrust certificates to secure the transactions, and we don’t accept other types of certificates. At this stage, it’s not a tremendous problem because there aren’t that many PKI-enabled applications. But I think the situation will get worse before it gets better. First, you’ll see the proliferation of certificates, and then you’ll see the forming of the federation that eliminates that need.

But like the postal framework Hany describes, Chase is taking a very active role in establishing a global trust hierarchy among leading financial institutions. We’re part of a group called Identrus, a commercial joint venture among global banks such as Chase, Bank of America, Nations Bank, Citibank, Barclays, Deutch Bank and others. Basically, the objective of Identrus is to create a global trust hierarchy within which, hopefully one day, Fortune 500 firms will participate.

ISM: How will this hierarchy work?

BRUMLEY: Let’s say a customer of Texas Instruments has a relationship with Chase. And let’s assume TI has a relationship with, say, Bank of America. If Texas Instruments is vouched for by Bank of America, and the TI customer is vouched for by Chase, then the customer can come to TI’s Web site, present a cert that’s backed by Chase, and TI will be able to trust that cert because Chase vouches for it. The existence of the hierarchy of trust between Chase and Bank of America makes it all possible.

Ultimately, what is important about PKI isn’t that it exists, but what it enables. We think this will be an important part of what banks do in the future. So as far as initiatives like Identrus go, we feel a particular stake in urging it to happen.

ISM: We’ve talked about a couple of areas that need to improve over the next year or so for PKI to become more mainstream: application integration and establishing wider circles of trust for better certificate interoperability. Can you pinpoint other areas that need improvement for PKI to really take the next step?

ELMANAWY: Managing CRLs and historical CRLs has been a major effort for us, mostly due to cost. There may be alternatives to work around historical CRLs, and it is important that the standardization groups look into various solutions.

JORDAN: One problem we’ve encountered concerns mobility. How do you handle mobile users who don’t carry a laptop everywhere, but go from machine to machine? Since most certs are host-based, that can be a real problem. And then, at the other end of the spectrum, there’s the issue of managing certificates on shared workstations, like in a manufacturing environment. These are two areas we’re grappling with right now.

ISM: Have you thought about using tokens, like storing certificates on smart cards?

JORDAN: Yes, we have, but the cost is prohibitive. Deploying smart card readers across an enterprise and then managing and administering smart cards for thousands of people is not cost-effective at this point.

We’re looking at other alternatives, like storing certs in a centralized data repository and having users and applications access those directly. But that brings up a host of other technology issues: What repository should be implemented? Is there an existing interface into the repository that applications can utilize? What will the industry’s standard repository be? Today, the technology answers aren’t there.

BRUMLEY: Right now we’re basically running a two-front war. We’re planning on some central repository-based approaches, and in the near term that’s the only reasonable approach, because smart card readers are simply not pervasive enough. On the other hand, we’re hearing from some major PC vendors that integrated readers will be a standard feature in a few years, and after that it will no longer be an issue.

ISM: A lot of people are shying away from PKI right now because of its perceived complexity. Just how complicated is it?

BRUMLEY: This is actually the single largest issue we’ve had to face. It’s a very complex and arcane technology. Even though we have a number of internal experts, we had to turn outside to find the appropriate tools. As you get further from the field of banking, the PKI ‘bench strength’ falls off significantly. That’s why I would expect to find PKI baked into end-to-end solutions in the future, much as computer chips are a part of many current applications.

JORDAN: I think a lot of that complexity has to do with the insource vs. outsource debate. With TI, VeriSign basically came in with the CA and all the pieces that

go along with it. When we signed up, they came in, and within a day or two we were issuing certs. It was basically a no-brainer as far as we were concerned. We wrapped an application around the front-end so that we could add some security to authenticate the user before issuing the certificate. But once that application was in place, it was very straightforward.

ELMANAWY: I think the complexity of PKI is relative. To developers, PKI utilizes straightforward methodologies. For implementers, deployment can be a straightforward process, especially if all the requirements are well defined. But it is a lot of work, and it does involve a lot of costs, particularly if the business needs are not identified.

ISM: For everyone out there thinking about making the move to PKI, what piece of advice would you pass along? What do you know now that you wish you knew before you started?

BRUMLEY: I guess the observation I would make is that this has taken us much longer than I thought it would, but that strikes me as the price you pay for being an early adopter. But hopefully our having been through it will make the vendors better equipped, and the folks who follow us will have an easier time of it.

JORDAN: The biggest thing we’ve had to deal with is the rush of people wanting to use PKI and trying to slow it down. There are issues that have to be dealt with, and people who don’t fully understand the technology will not understand why they’re such big issues. So we’re trying to have a slow and methodical deployment of PKI throughout the company to make sure we can handle the load. Once we’ve got all the pieces in place, I’m not worried about the scalability factor, and I’m not worried about the availability factor. What I’m worried about are the mobility and shared workstations issues.

The other thing I would add is that you need to do your homework. Spend all the time you need to fully analyze the available products and vendors—what you get and don’t get from a vendor, what it’s going to take to support it, what it’s going to cost, etc.

You really have to understand what PKI is, how it works and the relationship between a user and a certificate. It’s a totally different paradigm than the old user ID/password scenario. The whole technology is different, and if you go in with the mentality of, ‘Well, it’s similar to shared secret authentication,’ then you’re going to miss on your evaluation.

ELMANAWY: I’d say, don’t focus on the technology. Focus on defining your business requirements and the value that PKI will add to your business. Avoid confusing the implementation of a closed PKI community with an open commercial PKI; the requirements are very different.

Also: Think ahead. Business isn’t linear, so you can’t ask your clients and your clients’ partners to implement a single solution. This is a business of establishing trust relationships, and there is usually no room for a second try.

One last issue: Don’t overlook the legal framework that governs such operations in your jurisdiction. In your pilot, simulate a breach of trust with an actual value and take it to the courts, if you can afford it.

ISM: Quickly, on a scale of one to 10, how far along are you, 10 being full ‘wish list’ deployment, completely done, finished, everything’s running smoothly…

JORDAN: I would say based on what I know is coming, we’re probably somewhere between a three and a four.

BRUMLEY: I would say we’re at a 10 for version one deployment, because we’re doing it in multiple lines of business and it’s down to a process. But we’re at a one in terms of where we ultimately want to end up with respect to our hierarchy of trust. It kind of depends on your point of view. Technically, we’re doing all of this stuff now, and it’s working just fine. But that’s in a world where we’re just issuing certs for our own closed loops.

ELMANAWY: In the context of establishing a global commercial PKI environment, I’d say we are at a nine from our side, while the vendors are at about a three in their ability to enable cross-certification opportunities.

Moderator Andy Briney is editor of Information Security.

"Simply put, a robust PKI is what allowed us to expand operations to the Internet. Six months or a year ago, this might have solicited a ‘so what?’ from people. But now it’s an accepted fact that any business with a future has to have broad distribution across the ’Net."

—Sandy Brumley, Chase Manhattan Bank


"As the use of certificates expands, the issue of how individuals should manage multiple certs to interact with different companies will be a growing concern."

—John Jordan, Texas Instruments





"As businesses and consumers realize that PKI technology facilitates the presentation of their online identities in a ‘claimed’ way, trust will be the central issue."

—Hany Elmanawy, Universal Postal Union


© 1999 Information Security Magazine. Used with permission.
Information Security, the official publication of the ICSA, is dedicated to the needs of all security-conscious IT professionals. Free to qualified readers, Information Security features in-depth articles, product announcements and more analysis of information security issues than any other trade magazine. Subscribe today!

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