Understanding the Role of the PKI


For more information about encryption and pubic key cryptography, see Chapter 7 in my book, Scene of the Cybercrime (published by Syngress Media), www.sceneofthecybercrime.com


What is a PKI?


First, let’s be clear about what a PKI is not. A PKI is not an authentication method; rather it is an infrastructure that uses digital certificates as an authentication mechanism and is built to better manage certificates and their associated keys. A digital certificate is itself a way to reliably identify the user or computer claiming to be the owner of a specific public key.


Public key encryption, also called asymmetric encryption, is popular because it is more secure than secret key (symmetric) encryption. Two mathematically related keys, a public key and a private key, work together, with one used for encrypting and the other for decrypting (which one is used for which purpose depends on whether your goal is confidentiality of the data or authentication of the sender). The public key is made known to everyone who wants to engage in encrypted communications with the owner of the key pair. The private key never has to be shared with anyone; it is known only to its owner. This makes for a more secure system than the secret key method in which the same key is used for encrypting and decrypting and thus must be shared between the two communicating parties.


The problem with public key encryption is the difficulty of knowing whether a public key is really owned by the person it is claimed to belong to. A user could advertise that a public key belongs to Joe Jones when in fact it doesn’t; that user could then intercept messages intended for Joe Jones and decrypt them with the private key belonging to the key pair. Thus, a method was needed for verifying the identity of the holder of key pairs.


That’s where digital certificates come in. A trusted third party, called a certification authority, issues a certificate associated with a key pair to a user (or computer) whose identity it has already verified. Then other users and computers can rely on the veracity of the key holder’s identity. This works somewhat like the issuance of identification cards by governmental entities or employers. The issuer has already checked out the identity of the person to whom the card is issued, so others (for example, stores to which the card holder writes checks) depend on the issuer’s certification that the card holder is really whomever he/she claims to be.


Digital certificates contain information about the holder, the holder’s public key, an expiration date, and the digital signature of the issuer (the certification authority). Managing digital certificates and their associated keys is complex, so the PKI was created to provide a framework for the issuance, renewal, revocation and management of certificates. Industry standard PKIs and their certificates are built on the X.509 specifications of the ISO.


What is the PKI Made Of?


A PKI can be implemented within an organization, for the use of the users on its network, or it can be a commercial entity that issues certificates to Internet users, for example. Either way, the PKI consists of the following components:




  • At least one certification authority (CA) to issue certificates.


  • Policies that govern the operation of the PKI.


  • The digital certificates themselves.


  • Applications that are written to use the PKI.

The Certification Authority


The certification authority is the primary component of a PKI. Most PKIs will have more than one CA. A CA is simply a server that runs some sort of certificate services software. An example is the Microsoft Windows 2000 certificate services, which is included with the Windows 2000 server operating systems. The PKI will generally have a root CA, which is at the top of the CA hierarchy. This CA issues certificates to other CAs, but best practices dictate that it not issue certificates directly to users. Lower level CAs, called subordinate CAs, perform the daily task of issuing user and computer certificates. The root CA is the most trusted, so it should be kept in a very secure physical location or even taken off line when it is not in use. All CAs should be backed up regularly, because they store the private keys that are at the heart of the PKI’s authentication system.


Microsoft’s certificate services also distinguish between enterprise CAs (which require Active Directory and thus can only function in a Windows 2000 or 2003 domain) and standalone CAs, which can utilize the Active Directory database but do not require it.


Administrators can assign policies to the CA(s) that will be used in verifying the identity of users and computers that request certificates. In a Microsoft domain, users can request certificates for various uses (for example, email security) by logging on to the certificate server’s web page or by adding the Certificates snap-in to an MMC (only the web page is used for requesting a certificate from a standalone CA). In some cases, certificates are requested by the system without user action; for example, the first time a user attempts to encrypt data on the disk using EFS, an EFS certificate is transparently requested and issued.


PKI Policies


PKI policies lay out rules governing key security, the process for issuing, renewing and revoking certificates, default certificate lifetimes, and so forth. Public (commercial) PKIs such as VeriSign are required to publish a document called a Certificate Practice Statement (CPS). The CPS addresses issues such as how keys are generated and stored, issuance and revocation of certificates, etc. Private PKIs (those run internally by a company or organization) should also establish clear policies to make sure the method for validating the identity of certificate holders is reliable, to establish who can revoke certificates, how the revocation lists should be distributed, how often to archive certificates, and identify the applications that can and can’t use certificates.


Issuance, Management and Revocation of Certificates


The process involved in issuing and managing certificates is complex. When a request for a certificate is made to a CA, a key pair must be created and signed by the requestor, then the public key is sent to the CA. The CA must verify the signature and identity based on its policies. When this is done, the CA signs the user’s public key with the CA’s private key. This creates the certificate, which is then sent back to the requestor. The certificate can then be published. Certificates can be issued for a number of different uses, including smart cards, IPSec, EFS, logon authentication, web authentication, email, and more.


Certificates are generally stored on the requestor’s computer, but they can be moved (exported) to another computer. You also can export the certificate to back it up, and then import it to restore it.


There are many reasons a certificate might need to be revoked. If the key is compromised or the user leaves the organization, you’ll want to revoke the certificate(s). In other words, you don’t want other users, computers and applications to rely on that certificate anymore, so you must make it known to them that the certificate is no longer good. This is done by publishing and distributing a Certificate Revocation List (CRL). You can think of this as similar to the list of revoked credit cards that credit card companies distributed to merchants in the past. When you presented a credit card for payment, the merchant would check your card against the list to make certain it hadn’t been revoked. Now the process is usually computerized; the card number is entered and the computer checks it against a database of revoked cards that is updated automatically.


Applications


Applications must be PKI-aware in order to work with the certificates and use them for authentication purposes. Web browsers, email clients and many applications that are built into the Windows 2000/XP operating systems such as EFS and IPSec are PKI-aware, as are the operating systems themselves.


Summary


The Public Key Infrastructure is a framework for using digital certificates and their associated keys to verify the identity of users and computers to other users, computers and applications. PKIs are important elements in network and Internet security because many communications, such as business and e-commerce transactions, are dependent on a reliable method to identify the parties to the transaction.


The PKI is not itself an authentication method, but is a system for issuing, managing and revoking the digital certificates and key pairs that are used to authenticate users and computers within a private network or across the Internet. The components of a PKI include special servers called certification authorities, policies governing how the CAs issue, manage and revoke certificates and store keys, digital certificates and their keys, and applications that are able to use the PKI.


This is only a basic overview of how a standard PKI works. In a multi-CA enterprise network, the infrastructure may be complex, with several levels in the CA hierarchy and different CAs specializing in the issuance of specific types of certificates. For an extensive list of public PKIs, see the PKI Page at http://www.pki-page.org/. For more detailed information about the Windows 2000 PKI, see Public Key Infrastructure in Windows 2000 at http://www.windowsitpro.com/Articles/Index.cfm?ArticleID=4691

About The Author

Leave a Comment

Your email address will not be published. Required fields are marked *

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms of Service apply.

Scroll to Top