¿Es imposible el cifrado (seguro) sobre la línea comprometida?

Si el atacante solo está escuchando pasivamente la conexión, entonces Diffie Hellman Key Exchange puede ser hecho para crear una clave común que solo conocen los interlocutores de la comunicación.

Pero, si el atacante no solo puede escuchar la conexión sino también modificar activamente los datos transferidos, entonces el atacante podría montar un ataque de hombre en el medio y afirmar ser el compañero de comunicación esperado tanto para A como para B Esto solo se puede evitar si A puede identificar B antes de iniciar la comunicación cifrada y, por lo tanto, sabe que intercambió la clave con el socio esperado . Para esto necesita una forma segura de verificar la identidad incluso si la línea está comprometida. Esto se puede hacer por criptografía de clave pública. Pero, por supuesto, necesita algún tipo de conocimiento previo sobre la identidad esperada de B, es decir, A ya sabe B (confianza directa) o conoce a alguien que conoce B, etc. (cadena de confianza).

Encontrará una implementación para todo esto con SSL / TLS y la PKI asociada. Esto se usa con https en los navegadores y los anclajes de confianza necesarios para construir la cadena de confianza son las agencias de certificados públicas conocidas por el sistema operativo o por el navegador. Para obtener más información, consulte ¿Cómo funciona SSL / TLS? .

¡Hay una solución para este problema! Se llama el protocolo de intercambio de claves Diffie-Hellman .

Puedes leer una buena descripción en el enlace de wikipedia, pero la idea básica es que Alice y Bob tienen cada uno su private keys y el correspondiente public keys . De la magia de las matemáticas Diffie-Hellman,

PublicKey_Alice + PrivateKey_Bob = SharedSecret

y

PublicKey_Bob + PrivateKey_Alice = SharedSecret

ambas partes terminan con el mismo secreto compartido. Por lo tanto, A) solo se intercambiaron claves públicas a través de la red insegura, y B) para descifrar el secreto compartido, debe saber cualquiera de ellas la clave privada de Alice o la clave privada de Bob. (Puedes encontrar los detalles de las matemáticas en un rápido Google, así que no voy a entrar en ellos aquí).

Entonces, sí , Diffie-Hellman se considera una forma segura para que dos partes establezcan una clave de cifrado simétrica compartida, incluso en una red insegura donde Charlie está escuchando todo lo que intercambian.

Es posible si y solo si, en algún punto del pasado , se estableció una cadena de confianza que le permitió autenticar a su segunda parte. Debe ser de sentido común que si A nunca tuviera alguna idea de cómo identificar B (o cómo identificar a cualquier otra persona que pudiera identificar indirectamente a B), luego, por definición , A simplemente no tiene suficiente información para distinguir entre B y alguna otra entidad, C.

Las matemáticas no son magia. Si nunca supiste cómo identificar a alguien directa o indirectamente, las matemáticas no te dan esa información mágicamente.

No solo no se ha demostrado que sea imposible, y no solo es posible en la práctica con un nivel de seguridad suficiente. También existe un método comprobadamente seguro ("seguro" en el sentido de poder elegir arbitrariamente la mayor probabilidad posible).

Como se mencionó en otras respuestas, el intercambio de claves Diffie-Helmann con PKI es una forma razonablemente segura de establecer una clave compartida que no puede ser escuchada a escondidas. Obviamente, mientras no controle completamente su propia PKI muy privada , una CA maliciosa puede (y lo hacen actualmente) subvertir este sistema. Sin embargo, es razonablemente seguro contra la mayoría de los atacantes.

Aparte de PKI, los enfoques como, por ejemplo, el protocolo de interbloqueo de latencia forzada o el protocolo de estación a estación, o los derivados DH-EKE (como los descritos en RFC5247), aunque no irrompibles , pueden prevenir con éxito la mayoría de los hombres en el medio atacan con una probabilidad razonablemente buena, incluso sin PKI.
Si la probabilidad de que un atacante pueda "adivinar" correctamente es lo suficientemente baja, eso puede pasar a ser "seguro" en la práctica.

La distribución de claves cuánticas aún no está lista para el público en general, pero ya funciona por una década. No en teoría, pero en la práctica.

A diferencia de los otros enfoques, garantiza que tiene una clave compartida que nadie más conoce (o, más bien, puede establecer un umbral arbitrariamente bajo para la probabilidad de que alguien pueda conoce tu clave, pero eso es tan bueno como "garantizado").
Espero que esto pueda llegar a la corriente principal algún tiempo después de que se implementen computadoras cuánticas a gran escala para atacar a DH (o tal vez no, porque todo lo que necesita hacer para vencer los poderes cuánticos mágicos es duplicar su longitud de clave, por lo que es en realidad no es tan aterrador).

Pasé mucho tiempo tratando de razonar esto. Encontré una solución real, pero no una que se pueda empaquetar y convertir en un producto. Verás, un oyente pasivo quedará absolutamente frustrado por Diffie-Hellman con un tamaño de clave suficientemente grande. Pero si el chico está dispuesto a MITM, se derrumba.

Si conocemos la topología, podemos saber cuánto tiempo debe durar un paquete, y si estamos dispuestos a construir tableros ASIC para DH hasta el nivel de la puerta, de modo que sepamos que ningún posible atacante MITM no puede hacer un DH más rápido y no puede procesar mensajes en vuelo sin ser capturado por medidas de tiempo, entonces sabemos que era seguro. Pero en general, no puede hacer esto ya que Internet no tiene una topología fija.

Hay algunas situaciones desagradables para cosas como SSH sujetas al problema de la detención, como pedirle al equipo remoto que ejecute programas e incluir la clave de sesión en el entorno, pero esto tiene el mismo inconveniente. Si hicieras un producto con él, caería.

La conversación de Defcon 22 de Phil Zimmerman promocionando su compañía telefónica (SilentCircle) como libre de escuchas telefónicas enlace

Su idea es deshacerse de la infraestructura de clave pública comparando verbalmente los hashes de clave de sesión, también da ejemplos interesantes de fallas de PKI, el público hace muchas preguntas que, en mi opinión, son precisas y relevantes.

Dice que este método es a prueba de manipulaciones, porque en el caso de un hombre en el ataque central, los hashes de clave de sesión serían diferentes entre los usuarios que se comunican y lo sabrían de inmediato. Menciona que la clave se está intercambiando a través de la capa de medios, en lugar de confiarle a quien sea el propietario de la línea "haciendo la seguridad".