Diffie-Hellman Key Exchange with Authentication: Man-in-the-Middle query

Question

I have been reading up on MiTM attacks, and the prevention of them using public key certificates. Recently I learnt about Diffie-Hellman Key Exchange with Authentication, and how it uses signed parameters for preventing MiTM.

I'm not fully clear on the process used with the protocol (as listed in RFC5246, appendix-F.1.1.3) with respect to authentication. I understand how Diffie-Hellman is vulnerable to such attacks when used without it, but how exactly does it prevent these attacks?

I understand that the messages are signed, so the attacker Mallory can't modify messages between Alice and Bob. Why is Mallory not able to forward say, Bob's certificate through to Alice, including any of Bob's signed parameters, and eventually intercept the negotiated session key through relaying all messages between the two parties?

Is it simply because Alice and Bob both generate their own secret keys, which means the session key isn't recoverable? (Mallory is more like an eavesdropper/Eve in this scenario?) Additionally, does this mean if Mallory were able to recover the private key somehow, that he/she could compute 2 separate key exchanges and modify traffic as before with no authentication?

Lastly, say Mallory manages to compromise the private key and can intercept and modify traffic. Without changing the certificate/key, is there any other way to authenticate Bob in this scenario, or is this impossible?

Answer 1

Firstly, PKI makes use of a private key and a public key. The private key is known only to the user, while the public key is communicated securely via the use of certificates. To provide authentication and non-repudiation, users may sign a message with their private keys and obtain a digital signature. Any other users can verify that the signed signature is authentic by "decrypting" it with the claimed user's public keys.

So to answer your questions:

1. Mallory is unable to intercept the negotiated session key due to the Diffie–Hellman problem whereby it is hard to compute $g^{ab}$ given $g^a$ and $g^b$. He is unable to impersonate Bob if he does not prossess Bob's private keys.

2. Yes, your are correct. Mallory can only eavesdrop the encrypted ciphertext and is unable to learn its contents.

3. No, Mallory is unable to obtain the session key (of the communication between Alice and Bob) even if he has knowledge of Bob's private keys due to the Diffie–Hellman problem. Mallory is able to impersonate Bob when communicating to Alice but unable to impersonate Alice with communicating to Bob. However, if Mallory has access to both Alice and Bob's private keys then a MiTM attack is possible.

4. No, Bob has to change his public-private key pair including his certificate unless there is 2-factor authentication in place (e.g. via voice/text message or tokens).

Hope this helps.

Answer 2

Simply put, there are two key-pairs for DHE_RSA instead one key-pair of RSA_RSA.

For example,

1. for AES128_CBC_SHA(long name is RSA_RSA_AES128_CBC_SHA), you have one key-pair for both key-exchange and authentication.

2. for ECDHE_RSA_AES_CBC_SHA, you have two key-pairs. The ECC key-pair is temporary for key-exchange. The RSA key-pair from cert is used for authentication.

As a result, for second case, it does not matter if you lose your RSA certificate private key.

Answer 3

Why is Mallory not able to forward say, Bob's certificate through to Alice, including any of Bob's signed parameters, and eventually intercept the negotiated session key through relaying all messages between the two parties?

It is always possible to forward a certificate, a certificate is public information. It is also possible to forward the DH public key and the signature over it (and other data). However, that would not allow Mallory to derive the secret key because she doesn't have any of the two DH private keys involved.

She cannot replace the DH public key either (for a key pair she has generated) because that would require her to replace the signature, and she doesn't have the RSA (or ECDSA) private key to generate a signature over it.

Additionally, does this mean if Mallory were able to recover the private key somehow, that he/she could compute 2 separate key exchanges and modify traffic as before with no authentication?

Which private key? If you mean one of the DH private keys then yes, the secret key can be computed and the messages decrypted. Any messages that are still accepted for that secret key can be generated by Mallory - so she is indeed able to interfere with any ongoing session.

If it is the RSA private key then the session itself is still secure, but obviously now Mallory is able to setup a new connection, or indeed perform a man-in-the-middle attack and impersonate the person from which she obtained the private authentication key.

Answer 4

I think the point missing from the answers is that the certificates containing the public keys are validated up through the CA that signed the public key certificate (if you trust the signing CA). If you just get a public key or public key certificate from someone and don't check it (either out of band with the person you think you are communicating to, or with the trusted third party (CA)), then a MitM can produce their own key pair and establish session keys with both sides, thereby able to decrypt the messages from Alice to Bob, read them/change them, and re-encrypt to send to Bob. I don't think the CA part (also referred to as a Public Key Infrastructure) is 100%, but it is a lot better than "trusting" that the public key is from the other party or trying to verify with them directly (think how would you contact Amazon.com to ask them to read their public key so you know you have the right one).