The basis of infosecurity is understanding the value of your electronic assets—and who’s out to get them or disturb their operation. It really boils down to risk: What are your high-value assets? What are the risks to these assets? Which of these risks is unacceptable? And how do you reduce risk without slowing down progress or breaking the bank?
The rapid evolution of electronic commerce and e-business raises the stakes even higher. In a world increasingly dominated by online transactions and remote access to back-office applications, the pace of change requires strong yet flexible tools for controlling access and managing risk. In essence, that’s what public-key infrastructure (PKI) is all about: managing how users and network devices are identified and given access to online information and services.
In the physical world, "hierarchies of trust" determine who has access to what. For instance, while a bank manager may have access to the main safe, the bank tellers themselves may not, and the customers definitely won’t. In essence, PKI provides the technology for managing these types of relationships in the cyberworld. It defines and establishes identity, authentication and authorization—and distributes, exchanges,
accounts for and revokes this information within the enterprise and online world. By providing a way in which trust can be interpreted equally among all parties, PKI allows organization to use e-commerce applications while maintaining a firm grip on the security required for online transactions.
Now for the $64,000 question: Is it time for your organization to deploy a PKI? As you’ll see, there are multiple factors that must be considered before making this decision. However, if your company employs more than 1,000 people, and is increasing its dependence on electronic applications for correspondence (e-mail) and transactions between offices, departments, suppliers and customers (VPN and remote access), then the answer is probably yes. Indeed, for a medium- to large-size company to remain competitive in the e-commerce arena, adopting a PKI-based approach to authentication and access control may well be the most important technological investment it makes over the next two years.
The growth of the PKI market has been nothing short of astounding. UBS Securities, for instance, estimates that by 2003, PKI products and services will account for approximately $1.1 billion in revenue, up from $100 million in 1998. The downside to such a burgeoning market is that it’s accompanied with an inevitable amountof hype and hoopla. Considering the importance of this technology to future enterprise e-commerce, it’s important to distinguish between the myth, the magic and the reality of PKI:
The Myth: PKI is the next killer app. It automatically reduces costs and allows us to securely interact with other online organizations.
The Magic: A properly implemented enterprise PKI, tied to an accurate company directory, can make e-mail, VPNs and Web apps extremely powerful while reducing dependency on expensive private leased lines.
The Reality: PKI isn’t a killer app, but rather a critical IT infrastructure for enabling applications with a high level of security. As is true with most emerging technology, there are advantages and disadvantages to being an early adopter. Implementing an effective PKI is a not trivial matter, and there’s no way to avoid the pains of early deployment. Estimating sufficient resources and setting a realistic and measurable ROI is the key to success.
Before addressing the issues involved in PKI deployment, you should have a clear understanding of exactly what it will and will not do. This begins with recognizing all of the elements in this infrastructure and how they fit together. In essence, a PKI is an interoperating set of software and hardware elements that…
- Reviews certificate requests via registration authorities (RAs);
- Issues and revocates digital certificates (through a certificate authority [CA]);
- Stores and retrieves certificates (in a directory);
- Manages encryption key and certificate lifecycles;
- Handles key backup and recovery;
- Time-stamps services;
- Provides cross-certification between organizations with separate CAs; and
- Facilitates authenticated access to "PKI-enabled" client/server applications.
PKI technology solves the problem of authenticating people and devices that need to do business with you. It serves up digital certificates that carry public-key material, including a wide variety of attributes, such as name, account number and even security policy. The keys within certificates are used to encrypt confidential data, ensure data integrity, authenticate the owner and provide a means for non-repudiation.
Will a PKI Provide a Measurable ROI?
Despite the growing pains many early PKI adopters have experienced, benefits such as reduced cost, streamlined processes and better customer service offer tangible returns on a PKI investment.
Calculating the ROI on your PKI investment is an inexact process, but it can be done. It’s more of an art than a science. You need to have a good understanding of your company, how it will benefit from PKI-enabled applications, and what risks will be mitigated through a PKI. The following actions can help you to determine what benefit you can expect:
1. Estimate the total cost of your PKI by number of employees over some specific time period (see discussion in # 5, below).
2. Estimate the probability of attack and its financial harm over the same period.
3. Estimate the amount of new business and revenue your organization will get due to PKI-enabled applications.
4. Determine the cost savings vs. using an Internet-based VPN, EDI or secure e-mail, and without the use of private leased lines.
5. Do the math: Total benefit from new applications, reduced risk and cost savings minus the PKI cost equals ROI.
Top 10 Deployment Issues
Before deciding to move forward with a PKI for your organization, you should have a solid understanding of the following deployment issues. Not surprisingly, these are the same issues that are usually downplayed by vendors selling PKI products and services.
1. How Client and Server Applications Handle Digital Certificates
This is ranked as the #1 issue because if your applications don’t interpret or understand how to deal with digital certificates, then what’s the point? Unless you can deploy a single PKI for several applications, then PKI may not be the best option right now. There are many different levels of certificate interoperability within software applications. Research your applications to determine if they’re PKI-ready.
2. User Acceptance
One of the great values in a PKI is that the same type of certificate can be used to authenticate both people and devices, such as desktop PCs, routers, Web servers and firewalls. However, clients will have to install PKI-ready applications or new software on these devices in order to play, and any utility that introduces more "steps" for the end-user to perform is asking for trouble.
To "unlock" private key(s) and open an encrypted message, users typically type in a static password or phrase. In the long run, however, this will not be enough. A stronger, two-factor authentication scheme between a real person and his or her digital certificate will be required. Many vendors are working on this with biometrics and smart card technologies. But once again, two-factor authentication puts an extra step into the process and involves additional cost and administration.
3. Initial Deployment, Planning, Design and Certificate Issuance
This initial setup phase of your deployment will be greatly influenced by your
organization’s expectations and level of expertise. Uncertainty about how the PKI will be used, combined with a lack of PKI-enabled applications, will increase your deployment efforts two-fold. Additional delays may result from pre-existing infrastructure obstacles, such as lack of network bandwidth or directories, or firewalls placed between external or internal groups. Plan on a minimum of between six weeks and five months for initial deployment.
4. Lack of Personnel With PKI Expertise
Not much explanation needed here. No matter what region of the world you’re in, finding knowledgeable people on PKI/CA deployment and administration is verydifficult, unless you throw a ton of money their way.
What is the cost of (1) tying a PKI into corporate directory services, and (2) managing it on a day-to-day basis? Part of the difficulty with these questions is that the answers will depend on your enterprise setup and your requirements for a PKI. The cost model will also fluctuate from one vendor to the next, depending on the type of service you require.
For discussion purposes, let’s assume your enterprise has multiple sites, and wants to issue certificates to authenticate access to e-mail and Web applications for half of them. For a 5,000-user enterprise, the estimated total cost of ownership (TCO) over a three-year period would be $90,000-$160,000 for the initial PKI investment, with an additional $300K– $400K for support and maintenance. For a 25,000-user enterprise, the estimated TCO would be $200K-$400K for initial investment, with $540K-$840K for support and maintenance.
Scalability should be high on your list of concerns if you work in a large organization with more than 50,000 users. For most initial deployments, pilot projects cover a few hundred users. ISPs, banks, reservation systems and government agencies, however, need a PKI that can grow to the millions in Internet speed, which means by 2001. The PKI vendors assure us that scalability is being addressed, but you can expect the large customers to push the envelope on performance, revocation and certificate management tools for the next few years.
7. Emerging Standards
The wonderful thing about standards is that there are so many to choose from, including those from the multiple working groups in the IETF and recent vendor modifications of PKCS. However, this may also increase the confusion factor. The IETF’s PKIX working group has been instrumental in defining the different technical aspects of an X.509-based public-key infrastructure. Multiple interpretations of the same draft documents are responsible for some of the confusion, but time will help iron these conflicts out.
Interoperability between different standards bodies and special interest groups will be the next challenge: Where does one specification leave off and another begin? These standards organizations now depend on each other, something they never had to deal with in the past.
8. Multivendor CA Interoperability and Cross Certification
Also important is the co-existence of certificates from multiple vendors. Choosing a vendor that makes a conscious effort to interoperate with its competitors is important. Given the relative youth of this market segment, don’t expect any one vendor to dominate the entire PKI market. However, over the next year, you can expect about five key players to emerge as market leaders, which means five types of certificates, all requiring a high degree of interoperability.
You can blame this dilemma on the standards, but certainly not on the lack of competing standards. It’s more an issue of how the standards drafts are interpreted by the implementers. This is not a showstopper, because these issues will be worked out over time (at the expense of early adopters), but don’t expect a multivendor cross-certified CA deployment to be easy (or even possible) for quite some time.
9. Certificate Revocation
PKI has been widely criticized for the lack of a predictable revocation scheme— and rightfully so. Revocation parameters greatly depend upon the application and transaction tolerances. An internal corporate PKI with a single CA is not a problem. But an e-commerce scenario with heterogeneous CAs that require real-time revocation is virtually impossible today.
10. X.509 Technical Limitations
Last but not least, if the IETF draft standard PKIX is to be the PKI standard, the X.509 certificate structure is something we’ll have to live with.
A certificate has three elements: the client’s public key, certificate owner attributes and one or more issuers/signatories binding these elements into the certificate. Unfortunately, the strict, non-flexible structure of an X.509 certificate could become a major problem over time (see sidebar below). X.509 has a single issuer or signature binding the attributes to the key or principal element. Meanwhile, one of the "pretty good" things about Pretty Good Privacy (PGP) is that each individual attribute of a certificate can have any number of authorization signatures (exportable or not). This is useful and greatly reduces certificate management. Having a single issuer means you’ll end up with lots of different certificates per user as attributes change. This will cause management problems over time. Also, the X.509 v. 3 extension fields and flags are interpreted differently between most vendors, which reduces their usefulness.
These 10 factors are critical to knowing whether PKI deployment will actually provide lasting benefit to your organization by reducing security risks. For example, if deployment will be limited to simple protection of private keys by unmanaged passwords, then PKI-based authentication might not be significantly stronger than an existing password synchronization scheme. Likewise, if you’re unable to determine what kind of certificate revocation requirements and timelines you need (or, if your applications don’t support them), then you may not be able to determine if a PKI-enabled application is really stronger under attack than your existing system.
That’s why it’s so important to be clear on what you expect from a PKI. Be sure you understand the benefits (and limitations) of your plans for PKI deployment, and whether it will translate into a meaningful reduction in risk.
Half-Full, or Half-Empty?
In the past, IT security projects have not been completely successful in preventing the corporation from harm. This is because the majority of breaches come from insiders, from simple human error or from social engineering attacks that circumvent even the best security controls. Having a high degree of trust or assurance of one’s identity or authorization will greatly—but not entirely—reduce risk. The "human factor" always screws up the wonderfully predictable nature of cryptography.
Despite what some vendors might have you believe, PKI does not eliminate the possibility that bad things will happen to your corporate assets. If you’re in IT, you’re in an application-driven industry. Information security, however, is not an application, but an enabler of applications. Similarly, PKI is an enabling technology for e-commerce, a means and not an end to securing online and back-office applications.
The reality is that PKI has huge potential, especially given the world’s growing reliance on e-commerce. In coming years, PKI won’t be a matter of if, but when. The challenge is determining when the time is right for your organization.
E-Commerce and Digital Signature Legislation
OnWatch Service utilizes the Entrust/PKI to store, distribute and manage encryption and authentication keys via the ’Net.
Bull Worldwide Information Systems
Compatible with other vendors’ CAs, PKIs perform certificate registration and CA functions.
Celo Communications Inc.
Solutions combine user authentication and digital signing over SSL, PKI-enable legacy and client/server intranet applications and add digital signature capability to browsers.
Provides secure root CA services.
Choreo Systems Inc.
Provides PKI consulting and technical and implementation services.
Solutions offload cryptographic processing from CAs in a PKI.
Provides outsourced CA and issues certificates for authentication and access control.
CygnaCom Solutions Inc.
Offers integration and consulting services with PKI products from Baltimore, Entrust, GTE CyberTrust and VeriSign.
Builds PKIs and provides security components for PKIs.
Digital Signature Trust Co.
PKI solutions include digital certificate life-cycle management, CA services, repository and business process reengineering services.
Passport Certificate Server offers full life-cycle functionality for digital certificate management, providing PKI-based security for wireless, smart card and cable environments.
E-Lock Technologies Inc.
Offers free PKI security software that can issue an unlimited number of digital certificates with unlimited life.
Entrust Technologies Inc.
Entrust/PKI, now in its fourth version, is in-house-managed PKI software for secure electronic transactions, desktop and developer applications, access control devices and Internet commerce.
Provides outsourced PKI products and services that allow organizations to issue and manage digital certificates for network-based applications.
Provides CA and key services, as well as PKI reference code implementation, which can be used to build in-house PKIs.
Solutions combine PKI and smart cards.
Products PKI-enable applications and allow an organization to implement PKI technology to operate their own CA.
Offers a CD-ROM package that acts as a guide to implementing a PKI in an organization.
Provides 32-bit PKI smart cards, and solutions that combine PKI and smart card technology into enterprise-wide solutions.
PKI-to-legacy integration technology provides digital certificate-based user authentication and secure data transfer between browsers and back-end legacy systems.
Provides services for creating, deploying and managing PKI-based applications.
Network Associates Inc.
Net Tools PKI is a solution for issuing and managing X.509 certificates for Network Associates’ products.
Offers nFast cryptographic accelerators.
Phaos Technology Corp.
The Centuris PKI Platform is a Java-based solution for building PKI applications.
Rainbow Technologies Inc.
Provides PKI protocol engines and a USB-based cryptographic personal authentication token for Web-based access control, securing e-mail and VPNs.
Security Dynamics Technologies Inc.
www.securitydynamics.com Keon, a family of PKI products based on RSA’s public-key technology, provides PKI solutions and enables customers to build their own PKI solutions.
Shym Technology Inc.
PKEnable integrates packaged or legacy applications with multiple PKI services.
Offers software and solutions that help organizations create and deploy PKI solutions.
Validation authority (VA) products and services ascertain digital certificate trust by adding validation to PKI applications.
Offers outsourced PKI software and processing services through its OnSite PKI platform, now in its fourth version.
Xcert Int’l. Inc.
Offers solutions that PKI-enable Web servers and integrate products with a CA and PKI.
Part 6: Roundtable
Pioneers or Guinea Pigs? Three early adopters discuss the pros and cons of PKI deployment.
MODERATED BY ANDY BRINEY
VP of Business Development, Chase Treasury Solutions, The Chase Manhattan Bank
PKI Vendor: Entrust Technologies Inc.
Leader, IT Security Development Team, Texas Instruments Inc.
PKI Vendor: VeriSign Inc.
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!