PKI represents a host of features and solutions that all focus on security protocols and procedures that use objects that are known as public and private keys.

There are so many different ways of metaphorically describing how keys work, and ironically, nothing fits perfectly to help the understanding. Instead, it’s better to take a practical example of public and private keys in action.

There is a program on the market called PGP (Pretty Good Privacy) that uses keys to encrypt data. While data encryption is nothing new, it’s the fact that this program and others add an extra, very specific layer of encryption for data that enables key technology to be so good. During installation, PGP will create both a public and a private key with your name on it. Both keys are based upon a single password that you type in. The private key is used to decrypt data that has been specifically encrypted using your public key. As you may guess, the public key is used to encrypt the data that’s destined for you to begin with. So, the idea is that you keep your private key private, along with its password, and you give your public key to anyone wishing to send you encrypted data.

Once PGP is configured, it taps into e-mail programs and word processors in order to offer the option of encrypting data when it is saved, or when it is sent to someone. The practical application of how PGP uses key technology can be shown in a standard office environment. A manager needs to forward some employee reviews to his boss. He receives his boss’s public key (from the boss, of course). He crafts an e-mail, and taps PGP to encrypt it using his boss’s public key. Once the boss receives it, she uses her private key to decrypt the data. If she subsequently needs to return the e-mail, she will similarly need the manager’s public key.

Now, let’s say that the boss frequently conducts business using public and private-key encrypted data. What prevents her secretary from reading the encrypted contents on her machine? First, when the boss encrypts data, she encrypts it using one or more public keys. If the boss doesn’t use her own public key during the encryption process, she can’t read the mail after it’s been decrypted. Now, let’s say that the boss has learned this, and is in the habit of encrypting to her own public key, as well as that of the intended recipient. Even then, any outsider will need to know the boss’s private key password in order to decrypt any data that was encrypted using the corresponding public key.

Now, Windows Server 2003 uses keys to communicate with client systems in order to confirm identity, which incidentally is the overall intention of authentication to begin with. On the surface, the only difference is that key technology doesn’t require the user to type in a username or password, while domain and workgroup authentication do. In the above example, private keys required passwords, and this doesn’t change with Windows Server 2003, but this, and the overall mechanics of the PKI suite within Windows Server 2003 adds a level of subtlety by almost completely removing the user intervention piece from the picture. In order to remove one player (the user) from the field, the system compensates by adding a different player, which is an object called a certificate.