desafío-respuesta y hombre en el medio

No es posible responder a su pregunta sin más información. "Desafío-respuesta" es una técnica general. Existen muchos protocolos que incorporan algún tipo de mecanismo de desafío-respuesta para un propósito u otro. Algunos de esos protocolos son vulnerables a los ataques de intermediarios; algunos no lo son.

En términos generales, si la autenticación de desafío-respuesta es el mecanismo solo que se utiliza para la autenticación, es probable que el protocolo sea vulnerable a los ataques de intermediarios. Por ejemplo, un ataque contra sistemas simples de desafío-respuesta es esperar a que los dos puntos finales legítimos terminen la parte de desafío-respuesta del protocolo, y solo después de eso, comenzar a manipular el tráfico.

En términos generales, para garantizar la seguridad frente a un intermediario, necesita algún protocolo que proporcione un canal seguro. Para la mayoría de los propósitos, recomendaría simplemente usar SSL / TLS. Está bien estudiado y puede proporcionar una fuerte resistencia a los ataques del hombre en el medio, si se usa correctamente.

Actualización (15/11) : ahora parece que estaba preguntando específicamente sobre el documento al que se vinculó, por Yang et al. Aquí está mi análisis:

• No recomendaría usar el esquema propuesto en ese documento. Tengo serias dudas sobre su seguridad.

• El documento no proporciona un análisis de seguridad convincente. Los estándares aceptados en el campo hoy requieren una prueba de seguridad de cualquier nuevo protocolo criptográfico propuesto, o al menos un análisis muy completo de la seguridad contra ataques conocidos. El papel no ofrece ninguno. Dicho de otra manera, la carga de la prueba está en el papel para proporcionar evidencia convincente de que su propuesta es segura. Creo que el documento no cumple con esa carga.

• @Thomas Pornin señala que el protocolo en ese documento será débil para la mayoría de las opciones de parámetros, o completamente inseguro para algunas opciones de parámetros. Thomas lo explica bien: "Si la función hash F tiene una salida mayor que p o del mismo tamaño, entonces cualquier intercambio espionaje proporciona un oráculo para un ataque de diccionario sin conexión que puede descartar la mitad de las contraseñas posibles. Si el valor g genera un subgrupo más pequeño que ( p -1) / 2, luego un intercambio a escondidas proporciona un mejor oráculo para los ataques sin conexión. En resumen, imitan a EKE pero lo hacen mal. No utilice este protocolo. "

• El papel intenta "reinventar la rueda". Hay soluciones en la literatura para exactamente el problema que plantea el documento; se denominan protocolos de intercambio de claves autenticado por contraseña (PAKE). El documento no parece estar al tanto de la extensión del trabajo previo sobre PAKE que se había hecho antes del momento de su publicación.

  Hay varios protocolos PAKE que han sido bien examinados: si desea seguir el enfoque descrito en el documento, le propongo que utilice un protocolo PAKE bien conocido, no el esquema ad-hoc presentado en el documento.

• Además, el esquema propuesto puede tener una debilidad de seguridad elemental, dependiendo de cómo esté integrado en el SIP. El documento no describe lo que sucede después de que se completa el protocolo y cada parte ha autenticado la otra. Si en este punto la conexión continúa en texto claro, entonces hay un ataque directo de intermediario: el atacante simplemente espera hasta después de que el protocolo de autenticación se haya completado con éxito (sin alterar los pasos de respuesta de desafío), y luego manipule Los mensajes enviados después de que ambos lados se hayan autenticado con éxito. El documento no deja claro si o cómo se previene este ataque.