Man in the Middle
Public Key cryptography shares one critical flaw with Shared Secret cryptography: the first introduction. As mentioned earlier, if Bob intends to send Joe an encrypted message, he'll ask Joe for his public key. Joe will provide it, and Bob will use this public key to encrypt the message so that only Joe can read it.
Now, what if Hacker Hal has broken into one of the routers between Joe and Bob? From this position, Hal could see and intercept all the packets traded by Joe and Bob. If all Hal was doing was looking at the packets, he'd see nothing useful because the data was encrypted. However, as long as Hal had the right software in place when Bob asked Joe for his public key, Hal could intercept that request and send his own public key back instead. Then when Bob uses that public key to encrypt his message and send it, Hal could intercept this message again and be able to decrypt it with his own private key because it was originally encoded with his public key instead of Joe's.
If the message from Bob to Joe required a replyfor example, an interactive chat sessionHacker Hal could simply ask Joe for his real public key and reencrypt the message himself using Joe's actual public key and reverse the process for sending replies back to Bob. This lets Hal spy on the conversation almost as though it had never been encrypted.
There are two workarounds for this problem. The first requires that parties who expect to communicate with each other introduce themselves in advance and keep a copy of the other party's key on file. Enthusiasts of secure email often hold events known as "key signing parties" for just this purpose. Although this prevents a man in the middle from offering a fake key, it has the crippling drawback of becoming unmanageable on a large scale or with unknown audiences.
The second approach involves both parties knowing and trusting a third party, which is sort of like being introduced by a common friend. Joe and Bob both know Alice. Joe trusts Alice when she says that the person you're talking to is Bob and this is his public key. Similarly, Bob trusts Alice when she introduces him to Joe.
The way this is implemented in the public key world is that Joe generates his public/private key pair, then takes his public key to Alice and says, "Would you sign this for me?" (We'll refer to this later as his Certificate Signing Request, or CSR). Alice then uses her private key to electronically sign Joe's public key the way P. H. Boss signed his own letter to Bob. Anyone receiving Joe's public key now knows that the ever trustworthy Alice has vouched for Joe's identity and has proclaimed that the Joe who made this public key and the real live Joe are one and the same.
In the land of Web browsers and servers using the secure HTTPs protocol, the role of Alice is played by any one of several major corporations, including VeriSign, Thawte, Equifax, and others.
Tags:
Add more tags...,
|
