With public/private key encryption technology, each key is a unique encryption device. If, in fact, no two keys are ever identical, it’s possible to use a key to identify its owner. Keys are always created and used in pairs: one is the private key; the other is the public key. You can then encrypt data with the public key, which only the corresponding private key can decrypt.
The public key can be distributed to anyone who needs to share secure information with the owner of the private key. The private key, on the other hand, is never duplicated or distributed to anyone: it remains secure on the owner’s computer or server. While not as secure as limiting keys to pairs, the same public key can be duplicated and distributed to multiple users who need to share information with the private key owner. The public key holders would be unable to exchange information using the shared key. The downside is the public key no longer identifies a unique host.
A fundamental problem with public key cryptosystems is this: all users must be careful to make sure they’re always encrypting to the correct person’s key. In an environment where keys can be physically exchanged in person or configured by a single administrator, this shouldn’t be a problem. Unfortunately, neither of these key-exchange methods scales well, particularly over large geographical areas. One common solution for key exchanges is to use public servers, such as e-mail servers. Unfortunately, the threat of man-in-the-middle attacks must be considered a potential threat. Figure 11-1 shows Rtr1 communicating securely with Rtr10, using a public key BCD sent to Rtr10. The attacker can see the traffic, but can’t decrypt it.
In the man-in-the middle scenario, the culprit posts a phony public key using the real name and user ID of the legitimate holder of the private key with whom the user expects to share data. Now any data encrypted using the phony public key can only be decrypted by the holder of the matching private key�"the attacker. In Figure 11-2, the hacker has posted a new public key using Rtr1’s name and ID. Rtr10, not realizing the ruse, implements the new key. The attacker can now decrypt the traffic, but Rtr1 can’t.
In a public key environment, it’s absolutely critical that the public key used to encrypt data is, in fact, a legitimate public key of the intended recipient and not a forgery. Common sense indicates that requiring an administrator to configure both devices or physically deliver the public keys won’t scale well. Even if this is physically possible, the process would present a significant cost burden, even in regional networks. There must be another way. Digital certificates (certs) can simplify the task of sharing public keys, while verifying the public key belongs to the “real” owner.
Sections
Comments (0 posted)
Syndication
