The Sin Explained

Security experts (the authors included) love to warn people not to build their own crypto algorithms and protocols. And, for the most part, development teams take that advice to heart. When they are looking to build secure network connections and recognize the need for key agreement, theyll usually either use SSL, or open up Bruce Schneiers Applied Cryptography and pull out a protocol from there. But there are plenty of ways to get shot in the foot when taking these routes.

A lot of things can go wrong with session initiation. One of the most common is a man-in-the-middle (MITM) attack. Lets look at the attack using a concrete and common example of a generic client/server application, where the client and server use the Diffie-Hellman key exchange protocol, and then authenticate each other using the derived key. The details of Diffie-Hellman are unimportant. At a high level, Diffie-Hellman requires that two people send each other messages based on a random secret. If youve got either secret plus one of the public messages, you can calculate a third secret (the first two secrets are the random secrets chosen by the two participants ). Its believed to be computationally infeasible to calculate that third secret without one of the randomly generated secrets. The third secret is usually called a key , and the process of deriving this key is called the key exchange . This all seems useful, because, without one of the original secrets, nobody can snoop the key that was exchanged.

But, theres a really big problem here if we add no other security defenses. Then were susceptible to a man-in-the-middle attack. Lets say that the client initiates communication, and instead of the server answering, an attacker answers. Theres no step in the protocol to determine whether the client is really talking to a valid server. It turns out to be pretty simple for the attacker to answer instead of the server. The attacker can then exchange a key with the server and act as a proxy for the legitimate traffic, thus playing the part of the man in the middle.

The real problem here is that our key exchange is not authenticated. But wait! We said that we were going to go ahead and use an authentication protocol once we have a secure connection! Probably, well use the key we got from Diffie-Hellman and run a password protocol over that, particularly if we use a password protocol that performs mutual authentication , meaning that both the client and the server have authenticated each other.

If only that solved the problem!

Assume for a second that theres a man in the middle of this password authentication protocol, and that man does nothing but eavesdrop. Assume that the attacker does not know the password, and gets no information about it from the protocol (perhaps we are using a one-time password scheme, such as S/KEY). What does the password authentication protocol prove ? It proves that nobody tampered with the messages in the protocol (therefore, the messages are authentic ). Even if theres a guy sitting in the middle, the authentication will happen just fine.

What doesnt it prove? That the messages in our key exchange protocol were authentic! And, after the authentication completes, were still using the unauthenticated key we exchanged with the attacker to encrypt and decrypt, so the authentication protocol didnt actually give us any foundation for securing messages that we send from here on out.

To have a secure session establishment, both parties generally need to agree on the identity of the opposing party (though, occasionally, anonymous communication is acceptable in one direction). That identity needs to be established over a set of messages that include the key exchange protocol and every subsequent message is sent with the key (authentication requirements go on for the life of the communication, though we often think of this as message integrity ).

In almost every circumstance, it doesnt make sense to do a key exchange without authentication. For that reason, all modern authentication protocols intended to be used over a network are also key exchange protocols. And, nobody builds key exchange protocols to stand on their own anymore since authentication is a core requirement.