¿Puede la verificación de hash manual defenderse contra un ataque DH MITM?

1

Entiendo que el intercambio de claves DH es vulnerable a un ataque MITM.

Cuando Alice envía a Bob g, p y su clave pública, si también envió un valor H que fue un hashing de los valores g, p y clave pública concatenados, ¿podrían ella y Bob recibir una llamada telefónica donde verifican que H es el mismo valor para ambos, y luego confían en que cada uno tenga los mismos valores para g, p y la clave pública?

Me doy cuenta de que el punto principal del intercambio de claves DH es que las partes anónimas pueden intercambiar una clave y que un paso manual como este, de alguna manera, pierde completamente el punto de intercambio de claves DH.

Aún así, ¿esto funcionaría?

    
pregunta Jeff 14.08.2013 - 17:31
fuente

1 respuesta

1

Alice no tendría que enviar el valor de hash a través del cable; en su lugar, Bob debe volver a calcular el valor de hash de su lado, según los valores que recibió, y luego comparar el valor de hash con una fuente autorizada (la llamada telefónica).

Esto funciona. Es fácil ver si lo consideramos en dos pasos:

  1. En presencia de Diffie-Hellman, un ataque Man-in-the-Middle requiere que el atacante ponga su propia clave pública DH en lugar de eso de Alice o Bob (un MitM es una doble personificación, por lo que el atacante debe hacer la sustitución dos veces). Para Bob es suficiente "asegurarse" de que lo que recibió es, de hecho, lo que Alice envió para detectar dicha sustitución. Bob puede llamar a Alice y deletrear, a través de la línea telefónica, la clave pública DH que recibió (que incluye los parámetros de grupo DH p y g , y la clave pública DH real) de Alice ga mod p).

  2. En lugar de deletrear los tres grandes enteros (que serían más de 1500 caracteres hexadecimales), Alice y Bob simplemente pueden usar el hash de los valores. Siempre que la función de hash sea resistente a la preimagen de segundo , verificar el valor de hash es tan bueno como verificar la clave pública completa.

Este método es exactamente lo que sucede con SSH . La primera vez que te conectas a un servidor SSH desconocido hasta ahora, obtienes algo como esto:

The authenticity of host 'foo.example.com (42.17.131.8)' can't be established.
RSA key fingerprint is 45:77:d0:f0:b1:76:ce:cf:14:60:e4:89:54:20:c5:3d.
Are you sure you want to continue connecting (yes/no)?

En este punto, se supone que debe llamar al administrador del sistema de destino para verificar el valor de hash (o compararlo con cualquier otra fuente autorizada, que depende del contexto). Esto es exactamente lo que sugieres. El cliente SSH luego registra la clave pública del servidor, de modo que no se necesita ninguna pregunta para las conexiones posteriores.

    
respondido por el Thomas Pornin 14.08.2013 - 17:44
fuente

Lea otras preguntas en las etiquetas