Trust and the Man in the Middle|Public-Key Encryption

Trust and the Man in the Middle

Suppose Alice wants to send Bob a message. Where does she find Bob’s public key EB?

An Introduction to Computer Networks, Release 2.0.4

If Alice goes to a public directory that is not completely secure and trustworthy, she may find a key that in fact belongs to Mallory instead. Alice may now fall victim to a man-in-the-middle attack, like that at the end of 28.8 Diffie-Hellman-Merkle Exchange:

• Alice encrypts Bob’s message using Mallory’s public key EMal, thinking it is Bob’s
• Mallory intercepts and decrypts the message, using his own decryption key DMal
• Mallory re-encrypts the message with Bob’s real public key EBob
• Bob decrypts the message with DBob

Despite Mallory’s inability to break RSA directly, he has read (and may even modify) Alice’s message.

Alice can, of course, get Bob’s key directly from Bob. Of course, if Alice met Bob, the two could also exchange a key for a shared-key cipher.

We now come to the mysterious world of trust. Alice might trust Charlie for Bob’s key, but not Dave. Alice doesn’t have to meet Charlie to get Bob’s key; all she needs is

• a trusted copy of Charlie’s public key
• a copy of Bob’s public key, together with Bob’s name, signed by Charlie

At the same time, Alice might trust Dave but not Charlie for Evan’s key. And Bob might not trust Charlie or Dave for Alice’s key. Mathematically, the trust relationship is neither symmetric nor transitive. To handle the possibility that trust might erode with time, signed keys often have an expiration date.

At the small scale, key-signing parties are sometimes held in which participants exchange some keys directly and others indirectly through signing. This approach is sometimes known as the web of trust. At the large scale, certificate authorities (29.5.2.1 Certificate Authorities) are entities built into the TLS framework (29.5.2 TLS) that verify that a website’s public key is as claimed; you are implicitly trusting these certificate authorities if your browser vendor trusts them. Both the web of trust and certificate authorities are examples of “public-key infrastructure” or PKI, which is, broadly, any mechanism for reliably tying public keys to their owners. For applications of public-key encryption that manage to avoid the need for PKI, by use of cryptographically generated addresses, see 11.6.4 Security and Neighbor Discovery and the discussion of .onion addresses at the end of 10.1 DNS.

Frequently Asked Questions