The Need for a PKI

Scalable and secure key exchange is the main issue when deploying cryptography. Depending on the cryptographic algorithm that is used, there are different needs. In symmetric encryption, the keys should be changed frequently. They are shared between two peers. But how can you exchange these keys safely between the peers? Symmetric keys should be known only by the two peers using them, and, therefore, confidentiality must be ensured for the key exchange.

In asymmetric encryption, the public key of a device has to be known by all other devices (made public). But how can you distribute the public keys safely to your devices? You have to ensure that the public keys that are exchanged over the network are authentic, and hence authenticity must be ensured for that key exchange.

Key Exchange in Symmetric Cryptography

When exchanging keys in symmetric cryptography, you have two possible options: You can use out-of-band manual key exchange or you can use in-band automated key exchange.

Manual key exchange is the simplest method of exchanging secret keying material. However, it does not scale and often relies on the human operator to perform the procedure securely. Every peer with which the entity wants to exchange encrypted traffic must go through a one-time manual key exchange. After the keys are generated, the two parties exchange the keys manually, through a secure channel (for example, by telephone or in person). This process should include an out-of-band method of authentication to ensure that the keys were exchanged unaltered with the correct party. This concept is often applied when using authenticated routing protocol updates, where the symmetric key that is used for the authentication has to be entered on all participating routers. If multiple router administrators are involved, they can exchange the symmetric key in person or use some other protected channel (such as encrypted e-mail and Secure Shell [SSH Protocol]).

Most key exchanges are automated and do not require any human intervention. A couple of good methods for automatic key exchange are heavily used in modern cryptosystems. One of them is the Diffie-Hellman algorithm, which allows two peers to compute the same value (key) without exchanging all information that is needed for that computation. Another method is to send the actual symmetric keys but encrypt them using an asymmetric encryption algorithm first. In Cisco IP telephony, asymmetric encryption algorithms are used to exchange symmetric keys securely.

Key Exchange Protected by Asymmetric Encryption

When using asymmetric encryption to secure the automated exchange of symmetric keys, the keys are encrypted with the public key of the receiver and then sent over the untrusted network. Only the receiver can decrypt the message (the keys) because only the receiver knows the corresponding private key. This solution relies on the knowledge of public keys of all possible peers at all the participating devices.

In the example shown in Figure 25-1, user A wants to use symmetric encryption with user B.

Figure 25-1. Using Asymmetric Cryptography to Securely Exchange Symmetric Keys

For secure key exchange, asymmetric encryption will be used in this way:

Step 1.	User A generates the symmetric key.
Step 2.	User A encrypts the symmetric key with the public RSA key of user B and sends the encrypted key over the untrusted network to user B.
Step 3.	User B decrypts the key using his private RSA key.
Step 4.	Now both of them know the symmetric key and can start using it for encrypting their communication channel.

As mentioned previously, this solution assumes that user A knows the public key of user B.

The Pitfall of Asymmetric Key Exchange

Asymmetric algorithms offer the advantage of one of the keys being public, which simplifies key exchange and distribution. The pitfall of this approach is not obvious at first glance. Obtaining the public key from another person can be very tricky. Although it is true that public keys are public information and can be published in a well-known directory, an extremely important issue remains: When you receive a public key from someone, how do you really know it belongs to that person?

When a public key is requested or is sent over an untrusted network, an attacker could intercept that key and substitute another public key for it. This man-in-the-middle attack would cause the message sender to encrypt all messages with the public key of the attacker. A mechanism is, therefore, needed that allows verification of the relationship between a name of an entity and its public key. The PKI is the solution to this problem and allows such systems to scale, although, on a smaller scale, alternative, manual solutions can be devised.

PKI as a Trusted Third Party Protocol