|PKI: A primer|
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
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
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.
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:
Life of a certificate
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.
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