Criptografía (CCLXXXII): Ataque de intermediario al Intercambio de clave de Diffie-Hellman

Ya expliqué en este post en que consistía el ataque de intermediario (MitM, por las siglas en inglés de 'Man in the Middle') aplicado al criptosistema RSA, y en esta entrada aplico este mismo ataque al intercambio de clave de Diffie-Hellman, que como decía en este otro post es un protocolo que se utiliza para el intercambio seguro de una clave entre dos interlocutores a través de un canal inseguro, como puede ser Internet.

Como también decía en el último de los citados posts, este protocolo de intercambio de clave es vulnerable a este tipo de ataques cuando se realiza de forma no autenticada, y que consiste en que un atacante se interponga en las comunicaciones entre A y B, suplantando a uno frente al otro y haciendo que ninguno de los dos se dé cuenta de que están siendo hackeados.

Pero veamos cómo:

Si un atacante (C) se interpone en las comunicaciones entre A y B, suplantando a uno frente al otro:

1.- C se hará con el valor de g^a mod p que A ha calculado con su número secreto 'a' y que cree que está enviando a B.

2.-  Seguidamente, C enviará a B el valor de g^c mod p, que ha calculado con su propio número secreto 'c', y que B cree estar recibiendo de A.

3.- C se hará con el valor de g^b mod p que B ha calculado con su número secreto 'b' y que cree que está enviando a A.

4.-  Seguidamente, C enviará a A el valor de g^c mod p, que ha calculado con su propio número secreto 'c', y que A cree estar recibiendo de B.

A partir de ahí, A y B realmente comparten la clave de sesión ('K') con C y no entre ellos, y, por tanto, cuando C reciba un mensaje cifrado de A con la clave de sesión que cree compartir con B cuando realmente la comparte con C, éste lo descifrará, es decir, tendrá acceso a su contenido, y, además, se lo enviará a B para que no se dé cuenta de que el mensaje ha sido interceptado y leído, nótese que si lo desea, además, podrá modificarlo a su entera conveniencia y volver a cifrarlo con la clave que comparte con B, y B lo descifrará con la clave de sesión que cree compartir con A cuando realmente la comparte con C, y viceversa cuando C reciba un mensaje cifrado de B.

De esta forma A y B han sido hackeados y sus comunicaciones cifradas se encuentran totalmente comprometidas, pudiendo el atacante no sólo tener acceso a su contenido sino también modificarlas a conveniencia sin que ninguno de los dos se dé cuenta. 

Evidentemente, para que esto no ocurra, la autenticación con certificados es totalmente recomendable antes de la negociación de la clave entre los intervinientes, bien se trate de clientes o de servidores.

Quizás también te interese: