PKI: The Myth, the Magic and the Reality

By Charles Breed | Sep 7, 1999 | Print this Page
http://www.enterprisenetworkingplanet.com/netsecur/article.php/615851/PKI-The-Myth-the-Magic-and-the-Reality.htm


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.

Magic Debunked

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.

5. Cost

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.

6. Scalability

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.

 

FYI

E-Commerce and Digital Signature Legislation

www.mbc.com/ecommerce.html

Reviews all recent state and federal legislation regarding EC and digital signatures.

IETF PKIX Working Group

www.ietf.org/html.charters/pkix-charter.html

Contains draft documents on the PKI x.509 charter.

Meta Certificate Group

www.mcg.org.br/cert.htm

Provides an overview of certification systems.

PKI Information Bank

www.magnet.state.ma.us/itd/legal/pki.htm

The Sans Institute/Risk Management

www.sans.org/geer98.txt

Links to "Risk Management Is Where the Money Is!" by Daniel E. Geer Jr.

 




Part 2: Snapping in PKI


A major obstacle blocks PKI’s path to mainstream acceptance: How do enterprise apps integrate with the various certificate formats and alternatives?

While PKI vendors offer developer toolkits that enable applications to work with their certificates, application vendors have been slow to do so, particularly in the absence of mass-market demand. Instead, they’ve had to choose between either supporting all of the PKI vendors or one exclusively, neither of which seems like a good business decision.

Moreover, enterprise customers wanting to take advantage of PKI have been handcuffed by a lack of certificate interoperability. Standards have been slow in developing, and many of today’s PKI deployments are forced to accept certificates from only one PKI vendor. This, in turn, places limitations on scalability and the enterprise’s ability to expand their hierarchical "circle of trust."

A number of security vendors are working on solutions to this dilemma. LockStar Inc., for example, offers a PKI-to-legacy integration technology, providing end-to-end digital certificate-based user authentication and data security. A similar solution comes from SHYM Technology, a Boston-based start-up that has rolled out a product appropriately named PKEnable. A PKI-neutral solution, PKEnable links applications to different brands of PKI products through an infrastructure that sits between the two.

"PKEnable software allows enterprises to integrate packaged and legacy applications with PKI services from a variety of vendors, allowing them to use digital certificates," says Burton Group president and analyst Jamie Lewis. "There is no question that this kind of application will help further the adoption of PKI."

SHYM’s PKEnable infrastructure consists of a number of major components (see Figure). First and foremost are the "Shyms," which link prepackaged enterprise applications and leading security standards such as the GSS API to the rest of the infrastructure. The Shyms also support in-house, custom applications through the Shym toolkit, as well as network communications via PKEnable’s AutoShym capability.

Through a management facility called the Shym Integration Layer (SIL), all security-related requests are channeled from the various applications into a common area. Here the SIL interacts with the Shym server to determine which PKI that application is tied to, and if the user’s certificate is valid for that application. Once the server provides the SIL with that information, the request is then channeled into the Shym Provider Interface (SPI) for the appropriate PKI. The PKI does the processing and responds through the infrastructure back to the application.

SHYM currently supports digital certificates from VeriSign and Entrust Technologies, with support for GTE CyberTrust and Baltimore in the works. Shyms have been developed for commercial applications such as Lotus Notes, PeopleSoft, SAP and Documentum. In the future, the company plans to develop Shyms for enterprise resource management apps from the likes of J.D. Edwards, Oracle, Baan and Mapics; supply chain management apps from i2 Technologies, Manugistics and Logility; customer resource management and sales force automation solutions from Siebel, Vantive and Clarify; and database products from Oracle, Sybase and Informix.

Despite PKEnable’s potential, Burton Group’s Lewis says that the technology has a downside that could slow market acceptance: It requires installation of client software. "Customers don’t mind installing a server for a function, but when they have to go out and touch every client, that increases the complexity and cost," he says. "But there is really no way to get around that. The ability for customers to map existing applications to PKI is important and necessary to move towards PKI. It remains to be seen to some degree how well they implement it."

SHYM’s application integration model

—Margot Suydam

 



Part 3: X.509 vs. PGP Certs


Digital certificates are used by a variety of applications to provide user or device identity for authentication. Certs might also contain security policy or rules for authorization. A digital certificate is a collection of multiple attributes (information) which have been cryptographically bound by the digital signature of a CA that is recognized and "trusted" by a community of certificate users. Each certificate is unique and has three primary parts:

1. The subject’s public key value or principal element (a subject can be a person or a device).

2. One or more subject attributes (name, account number, validity period).

3. The CA’s signature, which binds the attributes to the subject’s public key.

Since there is no need to keep the subject’s public key confidential, certificates can be distributed unprotected (however, there may be privacy concerns about data mining of the cert’s attributes).

The two most common certificate types are PGP and X.509. Most secure business applications use an X.509 certificate-based scheme. PGP and X.509 are dramatically different in almost every aspect.

The X.509 certificate format, as defined in the ISO/IEC/ITU, has evolved since 1988 to its current version 3 (1996), with many other standards dependent upon its specification. PGP, on the other hand, was originally defined by a grassroots effort, and then by PGP and Network Associates. It’s now in the IETF arena, with change control owned by the IETF Open-PGP working group.

X.509 has a rigid structure, ASN.1 encoding and a single issuer (CA). PGP is a flexible "wallet" of signatures over specific attributes using RADIX-64 encoding. X.509 was tied to the X.500 directory service, but is now used with LDAP as the standard protocol for accessing the cert in a directory (the same as PGP’s use of LDAP).

Digital certificates are just one small component of the bigger PKI picture, but they’re the fundamental building block that can limit or extend the overall capabilities of a secure infrastructure.

Charles Breed is vice president of Kroll-O’Gara’s Information Security Group, a vendor-neutral security services and risk mitigation firm. Active in the IETF and a frequent lecturer on topics such as PGP, S/MIME, VPNs and PKIs, Charles is also the author/creator of the industry’s de facto "Cryptographic & Security Threats" reference chart, a poster-sized guide distributed to more than 100,000 individuals and organizations worldwide.

 

Source: "Cryptographic & Security Threats," © Charles Breed.

 







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.

 



Part 5: PKI Product Roundup


Baltimore Inc.
www.baltimore.com
Provides CAs that enable companies to build a PKI, as well toolkits to PKI-enable apps.

BCE Emergis
www.bceemergis.com
OnWatch Service utilizes the Entrust/PKI to store, distribute and manage encryption and authentication keys via the ’Net.

Bull Worldwide Information Systems
www.us.bull.com
Compatible with other vendors’ CAs, PKIs perform certificate registration and CA functions.

Celo Communications Inc.
www.celocom.com
Solutions combine user authentication and digital signing over SSL, PKI-enable legacy and client/server intranet applications and add digital signature capability to browsers.

CertCo
www.certco.com
Provides secure root CA services.

Choreo Systems Inc.
www.choreosystems.com
Provides PKI consulting and technical and implementation services.

Chrysalis-ITS
www.chrysalis-its.com
Solutions offload cryptographic processing from CAs in a PKI.

CyberSafe Corp.
www.cybersafe.com
Provides outsourced CA and issues certificates for authentication and access control.

CygnaCom Solutions Inc.
www.cygnacom.com
Offers integration and consulting services with PKI products from Baltimore, Entrust, GTE CyberTrust and VeriSign.

Cylink Corp.
www.cylink.com
Builds PKIs and provides security components for PKIs.

Digital Signature Trust Co.
www.digsigtrust.com
PKI solutions include digital certificate life-cycle management, CA services, repository and business process reengineering services.

Diversinet Corp.
www.diversinet.com
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.
www.elock.com
Offers free PKI security software that can issue an unlimited number of digital certificates with unlimited life.

Entrust Technologies Inc.
www.entrust.com
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.

GTE CyberTrust
www.cybertrust.com
Provides outsourced PKI products and services that allow organizations to issue and manage digital certificates for network-based applications.

IBM Corp.
www.ibm.com
Provides CA and key services, as well as PKI reference code implementation, which can be used to build in-house PKIs.

iD2 Technologies
www.id2tech.com
Solutions combine PKI and smart cards.

KyberPASS Corp.
www.kyberpass.com
Products PKI-enable applications and allow an organization to implement PKI technology to operate their own CA.

Labcal Technologies
www.labcal.com
Offers a CD-ROM package that acts as a guide to implementing a PKI in an organization.

Litronic Inc.
www.litronic.com
Provides 32-bit PKI smart cards, and solutions that combine PKI and smart card technology into enterprise-wide solutions.

LockStar Inc.
www.lockstar.com
PKI-to-legacy integration technology provides digital certificate-based user authentication and secure data transfer between browsers and back-end legacy systems.

Microsoft Corp.
www.microsoft.com
Provides services for creating, deploying and managing PKI-based applications.

Network Associates Inc.
www.nai.com
Net Tools PKI is a solution for issuing and managing X.509 certificates for Network Associates’ products.

nCipher Inc.
www.ncipher.com
Offers nFast cryptographic accelerators.

Phaos Technology Corp.
www.phaos.com
The Centuris PKI Platform is a Java-based solution for building PKI applications.

Rainbow Technologies Inc.
www.rainbow.com
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.
www.shym.com
PKEnable integrates packaged or legacy applications with multiple PKI services.

Thawte Certification
www.thawte.com
Offers software and solutions that help organizations create and deploy PKI solutions.

ValiCert Inc.
www.valicert.com
Validation authority (VA) products and services ascertain digital certificate trust by adding validation to PKI applications.

VeriSign Inc.
www.verisign.com
Offers outsourced PKI software and processing services through its OnSite PKI platform, now in its fourth version.

Xcert Int’l. Inc.
www.xcert.com
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

ROUNDTABLE PARTICIPANTS:

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!