Information Security Today Home

New Books

Data-driven Block Ciphers for Fast Telecommunication Systems
A Technical Guide to IPSec Virtual Private Networks
Public Key Infrastructure: Building Trusted Applications and Web Services

Getting Started with PKI

by Harry DeMaio

In the recent history of information protection, there has been an ongoing parade of technologies that loudly promise new and total solutions but frequently do not make it past the reviewing stand. In some cases, they break down completely at the start of the march. In others, they end up turning down a side street. Is Public Key Infrastructure (PKI) just another gaudy float behind more brass bands, or is there sufficient rationale to believe that this one might make it? There are some very good reasons for optimism in this case, but we have been overly optimistic before.

This article examines PKI as objectively as possible, in hopes of arriving at some sort of consensus. To do that, one needs to know more than just the design principles. Many a slick and sophisticated design has turned embarrassingly sour when implemented and put into application and operational contexts. There are also the questions of economics, market readiness, and operational/technological prerequisites, all of which can march a brilliant idea into a blind alley.

Approach and Preliminary Discussion
One can begin with a short review of the changing requirements for security. Is there really a need, especially in networking, that did not exist before for new security technologies and approaches? This article

  • Briefly describes encryption, public key encryption, and PKI
  • Illustrates how well PKI satisfies today's needs from a design standpoint
  • Delves into what is involved in actually making PKI a cost-effective reality
  • Questions whether PKI is an exceptional approach or just one of many alternatives worth looking at


Take a moment to compare a few characteristics of yesterday's and today's network-based information processing. If the differences can be summed up in a single phrase, it is "accelerated dynamics." The structure and components of most major networks are in a constant state of flux - as are the applications, transactions, and users that traverse its pathways. This has a profound influence on the nature, location, scope, and effectiveness of protective mechanisms.

Exhibit 1 illustrates some of the fundamental differences between traditional closed systems and open (often Internet-based) environments. These differences do much to explain the significant upsurge in interest in encryption technologies.

Exhibit 1. Open versus Closed Networks
Legacy/Closed NetworkModern Open Network
User environmentsKnown and stableMobile/variable
End pointsEstablishedDynamic/open
Network structureEstablished/knownDynamic/open
ProcessingMainframe/internally distributedMulti-site/multi-enterprise
Data objectsLinked to defined processOften independent

Clearly, each network is unique and most display a mix of the above characteristics. But the trends toward openness and variability are clear. The implications for security can be profound. Security embedded or "hard-wired" to the system and network infrastructure cannot carry the entire load in many of the more mobile and open environments, especially where dial-up is dominant. A more flexible mode that addresses the infrastructure, user, workstation, environment, and data objects is required.

An example: envision the following differences:

  • A route salesperson who returns to the office workstation in the evening to enter the day's orders (online batch)
  • That same worker now entering, on a laptop through a radio or dial-up phone link, those same orders as they are being taken at the customer's premises (dial-up interactive)
  • Third-party operators taking orders at an 800-888 call center
  • Those same orders being entered by the customer on a Web site
  • A combination of the above

The application is still the same: order entry. However, the process is dramatically different, ranging from batch entry to Web-based E-commerce.

In the first case, the infrastructure, environment, process, and user are known, stable, and can be well controlled. The classic access control facility or security server generally carries the load.

In the second (interactive dial-up) instance, the employee (one needs to verify that it is an employee) is still directly involved. However, now one has a portable device and its on-board functions and data, the dial-up connections, the network, the points of entry to the enterprise, and the enterprise processes themselves to protect if one wants to achieve the same level of control as in the first instance.

The third instance involves a third party and the network connection can be closed or open.

The fourth (Web-based) approach adds the unknowns created by the customer's direct involvement and linkage through the Internet to the company's system.

Finally, the fifth, hybrid scenario calls for significant compatibility adjustments on top of the other considerations. By the way, this scenario is not unlikely. A fallacious assumption in promoting Web-based services is that one can readily discontinue the other service modes. It seldom happens.

Consider the changes to identification, authentication, and authorization targets and processes in each instance. Consider monitoring and the audit trail. Then consider the integrity and availability issues. Finally, the potential for repudiation begins to rear its ugly head. The differences are real and significant.


Remember, too, that most network-based systems in operation today have evolved, or in many cases, accreted into their current state - adding infrastructures and applications on demand and using the technology available at the time. Darwin notwithstanding, some of the currently surviving networks are not necessarily the fittest. In most of the literature, networks are characterized as examples of a specific class - open/closed; intranet/extranet; LAN/WAN/Internet; protocol-X or protocol-Y.

While these necessary and valuable distinctions can be used to describe physical and logical infrastructures, one must remember that when viewed from the business processes they support - supply chain, order entry, funds transfer, patient record processing - most "business process" nets are technological and structural hybrids.

The important point is that today security strategy and architecture decisions are being increasingly driven by specific business requirements, not just technology. This is especially true in the application of encryption-related techniques such as PKI.

Looking again at the order entry example above, the application of consistent protective mechanisms for a hybrid order entry scenario will undoubtedly require compatibility and interoperability across platform and network types unless the entire system is rebuilt to one specification. This seldom happens unless the enterprise is embarking on a massive reengineering effort or deploying major application suites like SAP or PeopleSoft.


To be effective, a protective mechanism must appropriately bind with the object and the environment requiring protection. In open networks, the connection, structure, and relationship of the components are more loosely defined and variable. Therefore, the protective mechanisms must be more granular, focused, and more directly linked to the object or process to be protected than was the case with legacy systems. Formerly, protection processes operated primarily at a "subterranean plumbing" level, surfacing only in password and authorization administration and logons. Now the castle moat is being supplemented with "no-go" zones, personal bodyguards posted at strategic spots, food tasters, and trusted messengers.

Encryption mechanisms fit this direct, granular requirement, often ideally, because they can protect individual files, data elements (including passwords), and paths (tunneling and virtual private networks), and manage access management requirements. (Identification and authentication through encryption is easier than authorization.) But saying that encryption is granular is not the same as saying that a PKI system is interoperable, portable, or scalable. In fact, it means that most encryption-related systems today are still piece parts, although some effective suites like Entrust are on the market and several others (e.g., IBM SecureWay and RSA/SD Keon) are now just entering.

This "dis-integrated" and specialized approach to providing security functions creates a frustrating problem for the security professional accustomed to integrated suites. Now the user becomes the integrator or must use a third-party integrator. The products may not integrate well or even be interface compatible. At the 1999 RSA Conference in San Jose, California, the clarion call for security suites was loud and clear. We will discuss this topic again shortly but first, a short digression.

The reader is probably familiar with encryption, but a brief summary follows.

Encryption is a process for making intelligible information unintelligible through the application of sophisticated mathematical conversion techniques. Obviously, to be useful, the process must be reversible (decryption). The three major components of the encryption-decryption process are:

  1. The information stream in clear or encrypted form.
  2. The mathematical encryption process - the algorithm. Interestingly enough, most commercial algorithms are publicly available and are not secret. What turns a public process into a uniquely secret one is the encryption key.
  3. The encryption key. The encryption key is a data string that is mathematically combined with the information (clear or encrypted) by the algorithm to produce the opposite version of the data (encrypted or clear). Remember that all data on computers is represented in binary number coding. Binary numbers can be operated upon by the same arithmetic functions as those that apply to decimal numbers. Thus, by a combining process of complex arithmetic operations, the data and key are converted into an encrypted message form and decrypted using the same process and same key, but with one critical exception.

Before explaining the exception, one more definition is required. The process that uses the same key to decrypt and encrypt is called symmetric cryptography. However, it also has several advantages, including exceptional speed on computers. It has a serious drawback. In any population of communicating users (n), in order to have individually unique links between each pair of users, the total number of keys required is n(n + 1)/2. (Try it with a small number and round up.) If the population of users gets large enough, the number of individual keys required rapidly becomes unmanageable. This is one (but not the only) reason why symmetric cryptography has not had a great reception in the commercial marketplace in the last 20 years.

The salvation of cryptography for practical business use has been the application of a different class of cryptographic algorithms using asymmetric key pairs. The mathematics is complex and not intuitively obvious, but the result is a pair of linked keys that must be used together. However, only one of the pair - the private key - must be kept secret by the key owner. The other half of the pair - the public key - can be openly distributed to anyone wishing to communicate with the key owner. A partial analogy is the cash depository in which all customers have the same key for depositing through a one-way door, but only the bank official has a key to open the door for extracting the cash. This technique vastly reduces the number of keys required for the same population to communicate safely and uniquely.


If the public key is distributed openly, how does one know that it is valid and belongs with the appropriate secret key and the key owner? How does one manage the creation, use, and termination of these key pairs. That is the foundation of Public Key Infrastructure (PKI). Several definitions follow:

The comprehensive system required to provide public key encryption and digital signature services is known as the public key infrastructure (PKI). The purpose of a public key infrastructure is to manage keys and certificates.
- Entrust Inc.

A public key infrastructure (PKI) consists of the programs, data formats, communications protocols, institutional policies, and procedures required for enterprise use of public key cryptography.
- Office of Information Technology, University of Minnesota

In its most simple form, a PKI is a system for publishing the public key values used in public key cryptography. There are two basic operations common to all PKIs:
1. Certification is the process of binding a public key value to an individual organization or other entity, or even to some other piece of information such as a permission or credential.
2. Validation is the process of verifying that a certificate is still valid. How these two operations are implemented is the basic defining characteristic of all PKIs.
-Marc Branchaud


Obviously, from these definitions, a digital certificate is the focal point of the PKI process. What is it? In simplest terms, a digital certificate is a credential (in digital form) in which the public key of the individual is embedded along with other identifying data. That credential is encrypted (signed) by a trusted third party or certificate authority (CA) who has established the identity of the key owner (similar to but more rigorous than notarization). The "signing key" ties the certificate back to the CA and ultimately to the process that bound the certificate holder to his or her credentials and identity proof process.

By "signing" the certificate, the CA establishes and takes liability for the authenticity of the public key contained in the certificate and the fact that it is bound to the named user. Now, total strangers who know or at least trust a common CA can use encryption not just to conceal the data, but also to authenticate the other party. The integrity of the message is also ensured. If one changes the message once encrypted, it will not decrypt. The message cannot be repudiated because it has been encrypted using the sender's certificate.

Who are CAs? Some large institutions are their own CAs - especially banks (private CAs). There are some independent services (public CAs) developing, and government, using the licensing model as a takeoff point, is moving into this environment. It may become a new security industry. In the Netherlands, KNB, the Dutch notary service, supplies digital certificates.

As one might expect, there has been a move on the part of some security professionals to include more and more information in the certificate, making it a multi-purpose "document." There is one major problem with this. Consider a driver's license, printed on special watermarked paper, with one's picture and encapsulated in plastic. If one wanted to maintain more volatile information on it, such as current make of car(s), doctor's name and address, or next of kin, one would have to get a new license for each change.

The same is true for a certificate. Back one goes to the CA for a new certificate each time one wants to make a change. For a small and readily accessible population, this may be reasonable. However, PKI is usually justified based on large populations in open environments, and often across multiple enterprises. The cost and administrative logjam can build up with the addition of authorization updates, embedded in the certificate. This is why relatively changeable authorization data (permissions) is seldom embedded in the certificate, but rather attached. There are several certificate structures that allow attachments or permissions that can be changed independently of the certificate itself.

To review: the certificate is the heart of the PKI system. A given population of users who wish to intercommunicate selects or is required to use a specific CA to obtain a certificate. That certificate contains the public key half of an asymmetric key pair as well as other indicative information about the target individual. This individual is referred to as the "distinguished name" - implying that there can be no ambiguities in certificate-based identification; all Smiths must be separately distinguished by ancillary data.

Where Are Certificates Used?
Certificates are used primarily in open environments where closed-network security techniques are inappropriate or insufficient for any or all of the following:

  • Identification/authentication
  • Confidentiality
  • Message/transaction integrity
  • Non-repudiation

Not all PKI systems serve the same purposes or have the same protective priorities. This is very important to understand when one is trying to justify a PKI system for a specific business environment.

How Does PKI Satisfy Those Business Environment Needs?

Market Expectation. As PKI becomes interoperable, scalable, and generally accepted, companies will begin to accept the wide use of encryption-related products. Large enterprises such as government, banks, and large commercial firms will develop trust models to easily incorporate PKI into everyday business use.

Current Reality. It is not that easy! Thus far, a significant number of PKI projects have been curtailed, revised, or temporarily shelved for reevaluation. The reasons most often given are:

  • Immature technology
  • Insufficient planning and preparation
  • Underestimated scope
  • Infrastructure and procedural costs
  • Operational and technical incompatibilities
  • Unclear cost-benefits


PKI has compelling justifications for many enterprises, but there are usually more variables and pitfalls than anticipated. Broadside implementation, while sometimes necessary, has not been as cost-effective. Pilots and test beds are strongly recommended. A properly designed CA/RA administrative function is always a critical success factor.


How do they work and how are they related?

First take a look at the PKI certificate life cycle itself. It is more involved than one might think. A digital certificate is a secure and trustworthy credential; and the process of its creation, use, and termination must be appropriately controlled.

Not all certificates are considered equally secure and trustworthy and this in itself is an active subject of standards and industry discussion. The strength of the cryptography supporting the certificate is actually only one discriminating factor. The degree to which the certificate complies with a given standard (e.g., X.509) is another criterion for trustworthiness.

The standards cover a wide range of requirements, including content, configuration, and process. Spend a moment on process. The following is hardly an exhaustive list, but it does provide some insight into some of the basic requirements.

  1. Application. How do the "certificate owners to-be" apply for a certificate? To whom do they apply? What supporting materials are required? Must a face-to-face interview be conducted, or can a surrogate act for the subject? What sanctions are imposed for false, incomplete, or misleading statements? How is the application stored and protected, etc.?
  2. Validation. How is the applicant's identity validated? By what instruments? By what agencies? For what period of time?
  3. Issuance. Assuming the application meets the criteria and the validation is successful, how is the certificate actually issued? Are third parties involved? Is the certificate sent to the individual, or in the case of an organization, some officer of that organization? How is issuance recorded? How are those records maintained and protected?
  4. Acceptance. How does the applicant indicate acceptance of the certificate? To whom? Is non-repudiation of acceptance eliminated?
  5. Use. What are the conditions of use? Environments, systems, applications?
  6. Suspension or revocation. In the event of compromise or suspension, who must be notified? How? How soon after the event? How is the notice of revocation published?
  7. Expiration and renewal. Terms, process, and authority?

Who and What Are the PKI Functional Entities to Consider?

Certification Authority (CA)

  1. A person or institution
  2. Trusted by others
  3. Vouch for the authenticity of a public key
  4. May be a principal (e.g., management, bank, credit card issuer)
  5. Secretary of a "club" (e.g., bank clearing house)
  6. A government agency or designee (e.g., notary public, DMV, or post office)
  7. An independent third party operating for profit (e.g., VeriSign)
  8. Makes a decision on evidence or knowledge, after due diligence
  9. Records the decision by signing a certificate with its private key
  10. Authorizes issuance of certificate

Registration Authority (RA)

  1. Manages certificate life cycle, including:
      a. Certificate directory maintenance
      b. CRL (certificate revocation list(s)) maintenance and publication
  2. thus can be:
      a. A critical choke point in PKI process
      b. A critical liability point, especially as relates to CRLs
  3. An RA may or may not be a CA

Other Entities

  1. Other trusted third parties. These may be service organizations that manage the PKI process, brokers who procure certificates from certificate suppliers, or independent audit or consulting groups that evaluate the security of the PKI procedure
  2. Individual subscribers.
  3. Business subscribers. In many large organizations, two additional constructs are used:
     a. The responsible individual (RI). The enterprise certificate administrator
     b. The responsible officer (RO). The enterprise officer who legally assures the company's commitment to the certificate. In many business instances, it is actually more important to know that this certificate is backed by a viable organization that will accept liability than to be able to fully identify the actual certificate holder.

PKI policies and related statements include:

  1. Certificate policy
  2. Named set of rules governing certificate usage, with common security requirements tailored to the operating environment within the enterprise
  3. Certificate Practices Statement (CPS):
     a. Detailed set of rules governing the Certificate Authority's operations
     b. Technical and administrative security controls
     c. Audit
  4. Key management
  5. Liability, financial stability, due diligence
  6. CA contractual requirements and documents
  7. Subscriber enrollment and termination processes


Of all the administrative and control mechanisms required by a PKI, the CRL function can be one of the more complex and subtle activities. The CRL is an important index of the overall trustworthiness of the specific PKI environment. Normally, it is considered part of the RA's duties. Essentially, the CRL is the instrument for checking the continued validity of the certificates for which the RA has responsibility. If a certificate is compromised, if the holder is no longer authorized to use the certificate, or if there is a fault in the binding of the certificate to the holder, it must be revoked and taken out of circulation as rapidly as possible. All parties in the trust relationship must be informed. The CRL is usually a highly controlled, online database (it may take any number of graphic forms) from which subscribers and administrators can determine the currency of a target partner's certificate. This process can vary dramatically in terms of:

  1. Timing/frequency of update. Be careful of the language here. Many RAs claim a 24-hour update. That means the CRL is refreshed every 24 hours. It does not necessarily mean that the total cycle time for a particular revocation to be posted is 24 hours. It may be longer.
  2. Push-pull. This refers to the way in which subscribers can get updates from the CRL. Most CRLs today require subscribers to pull the current update. A few private RAs (see below) employ a push methodology. There is a significant difference in cost and complexity and, more importantly, the line of demarcation between the RAs and the subscriber's responsibility and liability. For lessened liability alone, most RAs prefer the pull mode.
  3. Up link/down link. There are two transmissions in the CRL process: the link from the revoking agent to the CRL and the distribution by the CRL to the subscribing universe. Much work has been exerted by RAs to increase the efficiency of the latter process; but because it depends on the revoking agency, the uplink is often an Achilles' heel. Obviously, the overall time is a combination of both processes, plus file update time.
  4. Cross domain. The world of certificates can involve multiple domains and hierarchies. Each domain has a need to know the validity status of all certificates used within its bounds. In some large extranet environments, this may involve multiple and multi-layer RA and CRL structures. Think this one through very carefully and be aware that the relationships may change each time the network encompasses a new environment.
  5. Integrity. A major way to undermine the trustworthiness of a PKI environment is to compromise the integrity of the CRL process. If one cannot ensure the continued validity of the certificate population, the entire system is at risk.
  6. Archiving. How long should individual CRLs be kept, and for what purposes?
  7. Liabilities and commitments. These should be clearly, unambiguously, and completely stated by all parties involved. In any case of message or transaction compromise traceable to faulty PKI process, the RA is invariably going to be involved. Ensure a common understanding.

As one might expect, CAs and RAs come in a variety of types. Some of the more common are:

  1. Full-service public CA, providing RA, certificate generation, issuance, and life-cycle management [Examples: VeriSign, U.S. Postal Service (USPS), TradeWave]
  2. Branded public CA, providing RA, certificate issuance, and life cycle management
  3. Certificates generated by a trusted party [Examples: VeriSign and GTE CyberTrust; IDMetrix/GTE CyberTrust and Sumitomo Bank/VeriSign]
  4. Private CAs, using CA turnkey system solutions internally [Examples: ScotiaBank (Entrust), Lexis-Nexis (VeriSign On-Site)]
  5. IBM Vault Registry

There are also wide variations in trust structure models. This is driven by the business process and network architecture:

  • Hierarchical trust (a classical hierarchy that may involve multiple levels and a large number of individual domains)
  • VeriSign, Entrust
  • X.509v3 certificates
  • One-to-one binding of certificate and public key
  • Web of Trust (a variation on peer relationships between domains)
  • PGP
  • Many-to-one binding of certificates and public key
  • Constrained or lattice-of-trust structures
  • Hybrid of hierarchical and Web models
  • Xcert

There are a large number of standards, guidelines, and practices that are applicable to PKI. This is both a blessing and a curse. The most common are listed below. Individual explanations can be obtained from several Web sites.

  • X.500 Directory Services and X.509 Authentication
  • Common Criteria (CC)
  • ANSI X9 series
  • DoD standards
  • S/MIME, SSL, IPSec
  • SET
  • ABA guidelines
  • Digital signatures, certification practices
  • FIPS Publications 46, 140-1, 180-1, 186

CA/RA Targets of Evaluation. To comprehensively assess the trustworthiness of the individual CA/RA and the associated processes, Deloitte & Touche has developed the following list of required evaluation targets.

  • System level (in support of the CA/RA process and certificate usage if applicable):
    -System components comprising CA/RA environment
    -Network devices
    -Firewalls, routers, and switches
    -Network servers
    -IP addresses of all devices
    -Client workstations
    -Operating systems and application software
    -Cryptographic devices
    -Physical security, monitoring, and authentication capabilities
  • Data object level (in support of the CA/RA process and certificate usage):
    -Data structures used
    -Critical information flows
    -Configuration management of critical data items
    -Cryptographic data
    -Sensitive software applications
    -Audit records
    -Subscriber and certificate data
    -Standards compliance where appropriate
  • Application and operational level (repeated from above):
    -Certificate policy
    -Named set of rules governing certificate usage, with common security requirements tailored to the operating environment within the enterprise
    -Certificate Practices Statement (CPS)
    -Detailed set of rules governing the Certificate Authority's operations
    -Technical and administrative security controls
    -Key management
    -Liability, financial stability, due diligence
    -CA contractual requirements and documents
    -Subscriber enrollment and termination processes

How Well Does PKI Satisfy Today's Open Systems Security Needs?
In a nutshell, PKI is an evolving process. It has the fundamental strength, granularity, and flexibility required to support the security requirements outlined at the beginning of this chapter. In that respect it is the best available alternative. But wholesale adoption of PKI as the best, final, and global solution for security needs is naive and dangerous. It should be examined selectively by business process or application to determine whether there is sufficient "value-added" to justify the direct and indirect cost associated with deployment. As suites such as Entrust and others become more adaptive and rich interfaces to ERP systems like SAP become more commonplace, PKI will likely become the security technology of choice for major, high-value processes. It will never be the only game in town. Uncomfortable or disillusioning as it may be, the security world will be a multi-solution environment for quite a while.

What Is Involved in Actually Making PKI a Cost-Effective Reality?
The most common approach to launching PKI is a pilot environment. Get your feet wet. Map the due diligence and procedural requirements against the organization's culture. Look at the volatility of the certificates that will be issued. What is their life expectancy and need for modification? Check the interface issues. What is the prospective growth curve for certificate use? How many entities will be involved? Is cross-certification a necessity? Above all else, examine the authorization process requirements that must coexist with PKI. PKI is not a full-function access control process. Look into the standards and regulations that affect your industry. Are there export control issues associated with the PKI solution one is attempting to deploy? Is interoperability a major requirement? If so, how flexible is the design of the solutions being considered?

The most popular approach to PKI today is the pilot project. This is not a "sandbox" or theoretical exercise. It usually involves putting an actual environment into play.


Type of pilot:

  • Proof of concept: may be a test bed or an actual production environment
  • Operational: a total but carefully scoped environment. Make sure there is a clear statement of expectations against which to measure functional and business results.
  • Inter-enterprise: avoid this as a startup if possible, but sometimes it is the real justification for adopting PKI. If so, spend considerable time and effort getting a set of procedures and objectives agreed upon by all the partners involved. An objective third-party evaluation can be very helpful here.
  • Examine standards alternatives and requirements carefully - especially in a regulated industry.
  • Check product and package compatibility, interoperability, and scalability VERY CAREFULLY.
  • Develop alternative compatible product scenarios. At this stage of market maturity, a plan B is essential. Obviously, not all products are universally interchangeable. Develop a backup suite and do some preliminary testing on it.
  • Investigate outsourced support as an initial step into the environment. While the company's philosophy may dictate an internally developed solution, the first round may be better deployed using outside resources.
  • What are the service levels explicitly or implicitly required?
  • Start internally with friendly environment. You need all the support you can get, especially from business process owners.
  • Provide sufficient time and resource for procedural infrastructure development including CA policy, CPS, and training.
  • Do not promise more than you can deliver!

Is PKI an Exceptional Approach or Just One of Many Alternatives Worth Evaluating?
The answer to this question depends primarily on the security objectives of the organization. PKI is ideal (but potentially expensive) for extranets and environments in which more traditional identification and authentication are insufficient. Tempting as it may be, resist the urge to find the single solution.

Most networked-based environments and the associated enterprises are too complex at this moment for one single global solution. Examine the potential for SSL, SMIME, Kerberos, single-sign-on, and VPNs. If one can make the technical, operational, and cost-justification case for a single, PKI-based security approach, do so. PKI is a powerful structure but it is not a religious icon. Leave room for tailored multi-solution environments.


To learn more about cryptography, visit Understanding and Applying Cryptography and Data Security

Subscribe to
Information Security Today

Powered by VerticalResponse

© Copyright 2008-2013 Auerbach Publications