Skip to main content
    Country/region [select]      Terms of use
     Home      Products      Services & solutions      Support & downloads      My account     

developerWorks > Security >
PKI: A primer
e-mail it!
Internal and external security
Public key encryption
PKI components
Life of a certificate
Outsourcing PKI
Future of PKI
About the author
Rate this article
dW newsletters
dW Subscription
(CDs and downloads)
Get the basics on this reliable and commonly-used encryption technology

Joe Rudich (
Network Administrator, St. Paul Companies
01 Dec 2000

With the Internet taking hold, the lax, network-oriented security practices of days gone by are not enough to keep data safe. As a result, Public Key Infrastructure, or PKI, is proving to be a reliable system for encrypting data, and the business world is taking notice. In this article, Joe lays out the fundamentals of PKI -- what's involved and how it's being used.

The Internet has emerged as a vehicle for both general commerce and corporate business, increasingly being used like a remote extension of the private communications networks that connect to it. Security cannot be stressed enough when sending sensitive data through the public Internet; in the case of online commerce, ensuring it is a requirement for maintaining customer confidence. PKI is an outstanding means of providing powerful, open data encryption and the services that support it.

Encryption has played a vital role in data communications since the first computer networks were established, but it is especially critical for companies that are venturing into public networks. The need to encode information and keep it private is hardly new, of course. According to the Roman historian Herodotus, "secret writing" saved Greece from conquest at the hands of the Persian despot Xerxes in 480 B.C., and has played a part in many wars, not to mention national affairs of lesser violence ever since. In World War II, Enigma, perhaps the most famous of wartime codes, gave the German navy the operational advantage that let them nearly win the Battle of the Atlantic.

Internal and external security
Every network manager or application developer pays homage to the importance of data security, but within the friendly confines of a private LAN, security often has a somewhat relaxed meaning. A network that is physically accessible only to employees is the data equivalent of domestic, peacetime communications -- chatting among friends. Internal practices may encrypt authentication (login) messages only, but not the bulk of transmitted data -- or encryption methods may be nominal, but not especially strong.

The openness of the Internet makes it the data communications equivalent of going to war. As private companies consider opening their information systems to the Internet, application builders may try to extend legacy security practices to unaccustomed environments. Existing systems for user validation, designed with internal users in mind, may be sufficient for securing applications that offer information already in the public domain, or of minimal value.

However, internal security systems usually prove inappropriate for securing communications across the Internet because they are either proprietary (to a company or a specific vendor) or don't utilize strong enough data encryption -- or both. Proprietary systems frequently require users to install specific software components on their PCs, which is impractical in an environment of public users. Of course, transmitting unencrypted data is suicidal in online retailing or any other Internet business.

PKI is a combination of software, encryption technology, and server-based services designed to fill this void. It secures communication with the very features that most internal systems lack: It uses open, well-known standards, and encrypts both the authentication process and the data. PKI includes other discrete security technologies, such as digital certificates, but is distinguished by its systemic approach. A complete PKI system manages (or obtains service from) certification authorities, rather than simply assuming their availability and utilizing them within applications.

Public key encryption
In terms of simple functionality, the purpose of PKI is to encrypt data transmissions. A lot of encryption methods are available, of course, but most have one or two limitations that make them unsuitable for transactions across the Internet. One of the most common problems, as mentioned, is proprietary technology with components that have to be manually configured for clients. Thus, most virtual private network (VPN) solutions are unworkable due to the cost of configuring each user, and because users will not wait for access. PKI can be used by virtually any Internet user, because client-side compatibility is incorporated into the browser software that is most commonly used for Internet access (Microsoft Internet Explorer and Netscape Navigator).

Another problem that eliminates many encryption systems is fundamental to their design: They utilize a secret encryption key, a unique mathematical value used to encode text, which must be known to both parties (client and server) in any transaction. This is a classic principle of cryptography; every German U-boat in World War II possessed a key, or sequence of keys, for reading and writing the Enigma cipher. There isn't anything defective about cryptography that uses a shared secret key, provided a secure means of distributing the key exists. For the German navy, that distribution method consisted of bringing the vessels to port periodically and delivering the code books by hand.

Your site's users on the Internet aren't likely to come into your port for code books. Therein lies the problem: If you send the code key through the Internet prior to setting up encryption, it is sent as plain text -- and can be easily intercepted by anyone trying to eavesdrop on transactions. The encryption key itself is the most vulnerable component of any code; Enigma stymied the efforts of the greatest code breakers of Europe and America, including Alan Turing, and was never actually broken. The Allies were able to read it only after U-boats were physically attacked to steal the keys. (This idea was, incidentally, conceived by Ian Fleming, a member of British Intelligence who would later create James Bond.)

The "key feature" of public key encryption is that it utilizes a two-part key, with one half held by the sender and one by the receiver. Imagine one of those divided-heart locket pairs that teenage boys and girls sometimes wear: The message printed it them can only be completely read when both people are together. In a simple manner, this is like a public-key pair, but actually four keys are used in client-server communication: a publicly-known and privately-held key for each party. The key algorithm is constructed to function with a specific combination of these. In transmitting data, a sender uses the recipient's public key; the effect of this encryption is that data can only be translated using the recipient's private key.

Thanks to the mathematical logic of this two-key procedure, it is not necessary for both sides of a communication to know the full key combination, and every key is unique. If the German navy had designed Enigma with PKI, the capture of any ship or submarine's private key would not have been disastrous -- the Allies would only have gained the ability to read messages intended for that specific vessel, not the entire navy. Further, they wouldn't have had to worry about key distribution, because public keys can be transmitted through open communication channels. The critical operation in public-key encryption is verifying the identity of a message's recipient, so as to encrypt with the correct public key.

PKI components
This identification process, as well as the storage of public keys, is the province of a PKI system. At its heart, PKI manages the digital certificates, each of which consists of a public key and a private key, which are used to authenticate users and encrypt data. With certificates properly managed, network security can even be configured to use other open-standard encryption technologies, such as IPSec, for data transmission.

Certificates form the identifiers and code-manipulating pieces of public-key encryption, but the center of the PKI system is the certification authority (CA), which issues and manages those certificates. A CA may be operated locally by an organization, in which case it takes the form of a server (or servers) running a service, such as Microsoft's Certificate Services for Windows 2000. However, CAs are often outsourced. There are widely acknowledged public CAs, such as VeriSign or Entrust, operating on the Internet, whose identities are already programmed into most browser applications.

Locally operated CAs usually control most of the other aspects of a public key infrastructure. The functional pieces that must be considered when building applications to use PKI include:

  • The certification authority
  • Digital certificates
  • A certificate publication point, where certificates are stored and published. This is the point of distribution, which may be a disk directory on the same machine that operates as the CA, or a security directory, like Netscape or Microsoft's Active Directory
  • A certificate revocation list (CRL), which is a reference list of certificates that have been marked for revocation prior to their original expiration date
  • Management tools
  • PKI-enabled applications

Life of a certificate
Any private company or other organization making use of certificates may consider outsourcing part of the management process. Even if the CA role is delegated to an external entity, the level of security will be driven by policies set through the life cycle of a certificate, which moves through five distinct stages:

1. Certificate enrollment: PKI utilization is initiated by users requesting certificates from a CA. (To end users, of course, this should be a transparent process.) This is a cooperative process between a user (actually the user's PKI-aware application, such as a Web browser) and the CA, which begins when the user generates a key pair (public and private).

Enrollment may also involve the collection and presentation of enrollment information, which can have a lot of policy implications. Some CAs are designed to require human approval before granting a certificate, and may demand proof in a personal form such as direct conversation or the presentation of notarized identifying documents. When the user is a public commercial entity, like an online retailer, this is reasonable, as customers need reliable proof that they are communicating with the right company.

The full user request consists of the public key (self-generated) and this enrollment information. Once a user requests a certificate, the CA verifies information based upon its established policy rules. If the information is determined to be valid, the CA creates the certificate. The CA then posts the user's public key in any repository specified (an internal directory or public server), and uses that public key to transmit an identifying certificate to the user. Using PKI encryption, the certificate can only be deciphered by the user who generated the matching private key.

2. Certificate distribution: The other half of the enrollment process, distribution is considered a separate process only because it may involve management intervention at the CA level. This stage also includes the setting of policies affecting the certificate's use.

3. Certificate revocation: When certificates are issued, they are configured with a specific expiration date, depending on distribution policy. If a certificate needs to be revoked earlier than that date, the CA can be instructed to publish and distribute this fact in a certificate revocation list (CRL). Browsers and other PKI-enabled applications are configured to check CAs for their current CRL, and will not operate if they cannot verify that a certificate has not been added to the list. Certificates may be revoked for various reasons, including a certificate recipient being compromised, or the CA itself being hacked.

4. Certificate renewal: When a certificate reaches the expiration date set for it, its user may request (automatically, depending on application configuration) its renewal. Obviously, this is dependent on the initial expiration date that is set, but also on the expiration date of the certificate held by the CA, because a CA cannot issue certificates that will expire after its own expiration.

5. Certificate auditing: The process of certificate auditing is dependent on the type of CA and its management tools, but is a necessary task. This chiefly involves tracking the creation and expiration (as well as possible revocation) of certificates, but in some cases may also record each successful use of a certificate.

Outsourcing PKI
Virtually every component of PKI can be outsourced, in one form or another. Organizations that operate their own CAs generally purchase the service and management software, rather than re-create CA functionality from scratch. There are also vendors that offer consulting services specifically for the purpose of designing, creating, or managing PKI internally.

The most common choice made to involve a third-party company, however, is outsourcing the CA to a commercial party. In some ways this is virtually necessary; when conducting public commerce, it is expected. Users are liable to feel somewhat suspicious if an online retailer has issued its own digital certificate, and browsers can be configured to warn or deny access under those circumstances.

Commercial CAs, on the other hand, are established, and applications expect them to be the source for most Internet certificates. Even companies like Microsoft, which have a strong Internet presence and the ability to issue their own certificates, obtain some certificates from other public CAs for the sake of their own veracity. (See Resources for a list of companies that offer PKI services.)

Future of PKI
The use of public key encryption promises to grow along with the popularity of the Internet: Its effective encryption and openly available standard client software make it an excellent choice for secure communication, and it has the flexibility to improve its encryption strength as demand grows. Although organizations commonly outsource certain aspects of PKI, a thorough understanding of its overall system operation is invaluable in preparing Web-based applications or administering servers.


  • VeriSign is the largest public CA and was one of the first companies to widely promote PKI and establish a public CA. In addition to being recognized as one of the most trusted of public CAs, VeriSign offers private PKI tools, including a certificate-issuing service called OnSite, which acts as a local CA but also connects to VeriSign's public CA.

  • Baltimore Technologies offers a line of PKI products named UniCERT, which are establishing a strong reputation for managing interaction between multiple CAs. This makes them especially well-suited for public CAs and very large organizations.

  • Microsoft has offered a certificate management service as an add-on for Windows NT, and has now incorporated full CA functionality into Windows 2000. The low cost (especially for those who own Windows 2000 servers) makes their tools especially attractive for strictly internal use.

  • Entrust Technologies' line of Entrust/Authority products are distinguished by tools that automate key management. This makes sense for internal CA operation, and can reduce some of the real cost of PKI operation by reducing manual interaction with the CA.

  • Thawte is the second-largest public CA behind VeriSign, and offers a Starter PKI Program for internal PKI management.

About the author
Joe Rudich is a Network Administrator with the St. Paul Companies in St. Paul, Minnesota. He can be contacted at

e-mail it!
Rate this article

This content was helpful to me:

Strongly disagree (1)Disagree (2)Neutral (3)Agree (4)Strongly agree (5)


developerWorks > Security >
  About IBM  |  Privacy  |  Terms of use  |  Contact