Diffie-Hellman and man-in-the-middle attacks

Question

See here for the man-in-the-middle attack on Diffie-Hellman that I'm concerned about: What is Diffie-Hellman?

How do we combat this? I have two questions:

1. Is one solution for both Alice and Bob just using a certificate authority, then they can each look up the other's certificate and know the secret key without really communicating (through Eve)?

2. The other solution I heard about is using RSA for signatures. My question in this case is that, if Alice and Bob are using RSA, why doesn't Alice just send Bob a secret symmetric key using Bob's public RSA key (signed with her private RSA key)? Isn't this basically what PGP does? I don't see the point in using DH if we're using RSA anyway.

Answer 1

Well, as it says in your link the problem is authentication. So somehow Alice and Bob must set up an authenticated channel. One way of implementing such a channel is by Alice and Bob holding each others public verification key for a signature scheme.

1. A CA would probably not hold a secret key for Alice and Bob. However, using a CA to get an authentic copy of the other parties public key for a signature scheme that would allow to set up an authenticated channel between Alice and Bob, so they could do DH key exchange. Apart from not trusting the CA with secret information, this has the benefit that Alice and Bob can now generate many secret keys with out involving the CA.

2. It is true that if Alice has a public encryption key for Bob and Bob has a public signature verification key for Alice, they could use the protocol you describe. However in general public key encryption and signature schemes are not the same(although for the particular instance of RSA there may be some overlap). If Alice and Bob only have keys set up for a signature scheme, they could use DH exchange to get a secret key.

Answer 2

The problem about Man-in-the-Middle attack on Diffie-Hellman is that both sides are not confident about other side's public key (g^a and g^b). If they were sure that they have correct public key of their's friend Man-in-the-Middle attack wouldn't be possible, because MITM attack is based on the forgery of public keys by adversary! If for instance Bob and Alice meet at home each other and exchange theirs keys using a USB flash they will be certain that they have each others public keys not the adversary's (except for the rare case if the adversary has set up a special trojan on their's flash card or computer to copy wrong (forged) public key).

So the task is to securely (with total confidence) obtain each others public key. There are many solutions for that. First descibed above is exchange in private presence of each other without using public networks. Second is to provide public keys certificates signed by common trusted third party (which confirms that public keys belong to Alice and Bob), but third party CA (certificate authority) is not very reliable because they may suffer from Man-in-the-Middle attack when some adversary intercepts all traffic between certificate receiver and CA injecting forged public keys... Third possibility is to use some shared secret and exchange public keys encrypted and MACed (MAC is a kind of signature showing that the data wasn't modified and was encrypted by shared symmetric key), and decrypt shared key and check MAC on the other side. Fourth possibility is to use asymmetric shared secret, e.g. if they are confident about other public key e.g. RSA then they can sign (in RSA it means encryption) DH public key using RSA private key and send it to each other and verify RSA signature using RSA public key of each other. Fifth solution is to establish web of trust using e.g. PGP. Sixth is to use some well-known website to share public keys, e.g. put public keys on FaceBook's user's page (this solution expects that FaceBook is hard to break and an adversary can't inject forged public key on user's page). Using several solutions to exchange public key increases confidence about the key.

Answer 3

The question Alex linked in comments explains why authentication works to prevent a man-in-the-middle attack on Diffie–Hellman. So, whenever you can do the key exchange in an authenticated channel, you can be sure there is no MitM attack. (Assuming DH problem remains unbroken, of course.)

Now, your questions:

1. Is one solution for both Alice and Bob just using a certificate authority, then they can each look up the other's certificate and know the secret key without really communicating (through Eve)?

If they look up each others' Diffie–Hellman public keys in a CA and can trust that CA, then yes, they have a secure shared secret. However, in practice it is nice to use ephemeral Diffie–Hellman keys for perfect forward secrecy, and this is not possible with a static CA. Also, this ties the symmetric key lifetime to the certificates': e.g. AES requires relatively frequent rekeying in many modes, while you would often like to have any CA keys be rather long term.

2. The other solution I heard about is using RSA for signatures. My question in this case is that, if Alice and Bob are using RSA, why doesn't Alice just send Bob a secret symmetric key using Bob's public RSA key (signed with her private RSA key)? Isn't this basically what PGP does? I don't see the point in using DH if we're using RSA anyway.

Here, again, using an authenticated Diffie–Hellman key exchange allows ephemeral keys and thus forward secrecy. Further, your idea of sending an encrypted key over allows an attacker who knows only Bob's private key to eavesdrop on the whole protocol. In comparison, with authenticated Diffie–Hellman, you need to know both users' private authentication keys to even set up a successful man-in-the-middle attack.

Answer 4

I would also mention that there are many required properties that you want a authenticated key exchange (AKE) protocol to satisfy, e.g. authentication, key confirmation, forward secrecy, key freshness, secrecy on the session key.

What you want is allow Alice and Bob to stablish "session keys" for each session of communication. These session keys are established on some secret which has to be shared befor the protocol starts, i.e. long term symmetric keys or long term public keys.

Why do you want session keys to be established rather than using the long term keys for communication? One could say: 1. You want each session to be encrypted with a different key, 2. If you encrypt several sessions with the same key, it is subject to cryptoanalysis (for example, in cases of password based authentication where the entropy of the keys is relatively low), 3. You want to ensure that if some session key is revealed, it does not compromise previous communications. 4. Also, as here in the forum, AES requires fresh keys when establishment of communications.

Going back to your question, I would suggest that look at the properties I mentioned above and see if your solution satisfies them (Which I would say, your solution does not satisfy). This explain why there is a huge research going around Key exchange protocols and why the naive solution is not the best. Hope this helps.

There is a very good book for key exchange protocols, called "Protocols for Authentication and Key Establishment", by Colin Boyd. Just in case you are interested on the topic :)