Diffie-Hellman es un algoritmo de intercambio de claves . La pregunta buena que debe hacerse es: intercambiar una clave, sí, ¿pero con quién?
Desde el punto de vista de la red, usted "ve" a otras personas solo a través de los paquetes que le envían; y como todos pueden comprar el mismo tipo de PC, todos pueden enviar los mismos paquetes, excepto para que algunas personas / sistemas conozcan algunos valores que otras no. En criptografía, conocimiento es poder , lo que significa que eres lo que sabes. Si comienzas a intercambiar datos con Alice, sabes que estás hablando con Alice y no con Bob porque Alice puede enviarte un mensaje que podría haber sido calculado solo por alguien que conoce un valor determinado, y de alguna manera saber que hay alguien llamado "Alice" que conoce ese valor y otra persona llamada "Bob" que no.
Si, en su modelo, al menos no define que hay varios posibles interlocutores con conocimiento distinto, entonces la noción de "hombre en el medio" ni siquiera tiene sentido, porque todas las demás personas, En ese modelo, son idénticos. Si desea hablar sobre el ataque del hombre en el medio y cómo evitarlo, primero debe definir con quién quiere hablar, y eso implica especificar qué sabe ese sistema / persona, que el atacante no.
En pocas palabras: MitM es un caso especial de suplantación (una doble suplantación, incluso), donde un atacante asume la identidad de otra persona. Por lo tanto, necesita una noción de "identidad" antes de comenzar a discutir los ataques MitM.
Ahora suponga que ha definido una noción de identidad. P.ej. usted es un navegador web y está intentando acceder a una URL https://www.example.com/foobar.html . Entonces, la noción de identidad es "quien controla el servidor www.example.com , como está registrado en el DNS ".
Diffie-Hellman es un algoritmo de intercambio de claves. Esto significa que no incluye, per se, ningún tipo de autenticación. Esto no significa que DH sea inútil; solo que es poco probable que proporcione a solo la totalidad de la función de seguridad que desea obtener. En la práctica, varios algoritmos criptográficos se ensamblan en un protocolo como SSL / TLS .
De vuelta a nuestro ejemplo, Diffie-Hellman es de hecho ampliamente utilizado en SSL / TLS, con las suites de cifrado "DHE". Toda la torre de criptografía se ve así:
- El servidor tiene un par de claves pública / privada aptos para firmas (RSA, DSA, ECDSA ...).
- El servidor genera la mitad del intercambio de claves DH, luego lo firma (con su clave privada de firma) y lo envía al cliente.
- El servidor también envía su clave pública de firma al cliente, como un certificado emitido por alguna CA.
- El cliente valida el certificado (porque el cliente ya conoce y confía en la CA) y, por lo tanto, aprende la clave pública del servidor.
- El cliente verifica que el certificado del servidor contenga el nombre del servidor esperado (aquí:
www.example.com ).
- El cliente verifica la firma en el medio DH enviado por el servidor, utilizando la clave pública del servidor.
- El cliente calcula su propia mitad DH y la envía al servidor.
- El cliente y el servidor completan el cálculo de DH y obtienen un secreto compartido, que luego se expande en claves simétricas para cifrar todos los datos.
La noción de identidad utilizada por el cliente es que el propietario del servidor no puede obtener certificados válidos de una CA de confianza a menos que controle efectivamente el dominio relevante. Por lo tanto, desde el punto de vista del cliente, el "servidor www.example.com genuino" es "quien conoce una clave privada correspondiente a una clave pública en un certificado de una CA confiable y que contiene el nombre www.example.com ". El conocimiento de la clave privada es lo que hace que el servidor sea "el correcto". La CA vincula esa clave (la clave pública, específicamente) al nombre DNS.
Lo que protege contra MitM aquí es que el hombre en el medio no conoce la clave privada (podría generar sus propias claves privadas, pero no coincidirían con la clave pública en el certificado). La firma es el mecanismo por el cual se promulga esta protección. Eso no es Diffie-Hellman que proporciona esa protección. Por otro lado, la firma no da como resultado un secreto compartido: ese es el trabajo de DH.
Resumen: desea obtener un secreto compartido con algún servidor específico, de modo que pueda cifrar gigabytes de datos que se enviarán a ese servidor. Este es un trabajo de dos partes: usted quiere un secreto compartido , pero también tiene que ser con algún servidor específico . DH hace la parte "secreto compartido". Necesitas algo más para la otra parte, por ejemplo, Algún algoritmo de firma. Esto es lo que sucede en SSL o SSH.