How does the Diffie-Hellman algorithm prevent MITM attack?
I have tried to search about it but i couldn't find any understandable reasons.
Cryptography Stack Exchange is a question and answer site for software developers, mathematicians and others interested in cryptography. It only takes a minute to sign up.Sign up to join this community
The problem lies in the trust of the public key. If an attacker can simply replace one of the exchanged public keys with his own then an active MITM attack is possible. The attacker simply replaces both public keys with his own and proceeds to create two channels that rely on the shared secrets. For ephemeral key pairs - as commonly used - the key pairs are short lived and the public key is not trusted so DH key agreement is then inherently insecure against MITM attacks.
This is the default for all TLS 1.3 cipher suites and all TLS 1.2 suites that start with DHE or ECDHE. These suites therefore have to rely on other methods of authentication to mitigate the MITM attacks.
So the common ephemeral-ephemeral Diffie-Hellman scheme does not protect against MITM attacks, and your premise is false.
Some DH protocols where both parties are authenticated may actually prevent MITM attacks. In static-static DH the public keys of both parties may be trusted and therefore the DH will provide entity authentication of both sides, rendering MITM impossible.
This is not a common method of operation at all. It seems TLS can offer static-static DH, but it seems a rare find. Because the key pairs are always identical the protocol relies on an additional nonce - applied during or after the key agreement - to make sure that the resulting shared secret changes on every execution of the DH key agreement protocol. The scheme where the nonce is applied during key agreement is not offered by many implementations.
If just one key pair is static and the public key is trusted then the party verifying the validity of the public key will see the invalid public key, and break off the handshake of the protocol used. Ephemeral-static DH is therefore also invulnerable against MITM attacks, even if just one party gets authenticated. Of course the party that accepts the ephemeral public key will still not have any idea who he's talking to. This is e.g. not a problem on internet sites as they don't care about who reads them - they offer additional password authentication where required.
Ephemeral-static key agreement is present in the TLS cipher suites starting with DH_ and ECDH_. This method of authentication is however not present in TLS 1.3 anymore. The authenticated DH protocol requires an DH-based certificate to be able to trust the public key. These kind of certificates are hard to come by. In practice only certificates that use RSA or ECDSA for authentication are used, rendering these suites useless.
Ephemeral means temporary, or fleeting. Ephemeral key pairs should be generated on each invocation of DH, and the private key should be destroyed to achieve so called forward secrecy. Some servers cheat - because key pair generation can be relatively CPU expensive - and reuse the key pairs for a longer time or even until the server is rebooted.
The answer depends on the attack your are interested in.
For passive attackers who are eavesdropping on the exchanging of information, the attacker has to solve an instance of the Diffie-Hellman problem which is believed to be difficult.
For active attackers who can tamper with the information exchanging, "textbook" Diffie-Hellman is not safe. To prevent this class of attacks you would need to use an authenticated key exchange (AKE).
How DH Key Exchange works:
Server sends group parameters i.e.
g which is generator and a large prime
p.Server choose a random
a and calculate
g^a mod p. This value is signed with the private key from the server's certificate, an MiTM cannot change this value. Also Discrete logarithm Problem states that give above value and
p, it is tough to
a. These value are sent to client in
ServerKeyEchange. Similarly client also choose
b and send
g^b mod p. Both client and server now have shared secret of
g^ab mod p.
MiTM cannot get these value unless
p is small like 768 bits of lesser for which we know its already broken(LogJam attack). Another point is server value of
g^a mod p is signed so MiTM cannot tamper with it. Further in future
b value chosen by Server & Client respectively can be thrown and a new value
b' are chosen , this provide perfect forward secrecy. So even if somehow MiTM break
g^ a mod p for
a , he cannot do again and again as the value keep changing.