ataques MITM en FIDO UAF y U2F [cerrado]

4

En la Sección 6 de Descripción general del segundo factor universal (U2F) , donde se analizan los ataques MITM, cerca del final de la sección, se lee:

It is still possible to MITM a user's authentication to a site if the MITM is 

a. able to get a server cert for the actual origin name issued by a valid CA, and 
b. ChannelIDs are NOT supported by the browser. 

But this is quite a high bar. 

No estoy convencido de que esta sea una barra tan alta. Hemos visto más de algunos casos en los que los atacantes han podido obtener información falsa pero confiable Certificados CA firmados . Y, TLS ChannelID no ha sido adoptado ampliamente por la mayoría de los navegadores y servidores (de hecho, la propuesta borrador de RFC expiró en 2013). Además, incluso si ambos puntos finales admiten el TLS ChannelID, un atacante MITM activo podría evitar que el TLS ChannelID se use por medio de un ataque degradado durante el mensaje de ClientHello.

Aplaudo el salto que FIDO ha dado para reducir nuestra dependencia de las contraseñas y para que la autenticación sea más segura y menos engorrosa para los usuarios. Pero, parece que ha hecho poco para proteger contra un ataque MITM en el que un atacante puede obtener un certificado falso pero confiable, y debemos continuar poniendo toda nuestra fe y confianza en los CA, que tienen una Historia de decepcionarnos. Por supuesto, incluso el protocolo de autenticación más seguro es inútil si la conexión puede verse comprometida por un atacante MITM activo.

Otros protocolos de autenticación basados en claves (como SSH) protegen contra los ataques MITM mediante la fijación de claves públicas incorporadas al protocolo. Con SSH, por ejemplo, los clientes almacenan las claves públicas de los servidores a los que se han conectado. Inmediatamente después de realizar la conexión, durante el intercambio de claves y antes de intentar la autenticación del cliente, el cliente verifica que efectivamente está conectado al servidor deseado, al verificar que la clave pública que está utilizando el servidor es la misma que la del archivo. para ese servidor, y asegurarse de que el servidor esté en posesión de la clave privada asociada con la clave pública a través de alguna operación criptográfica que requiera la clave privada.

Por supuesto, HPKP (sin FIDO) se puede usar para fijar los certificados SSL / TLS de los sitios en el navegador, pero esto tiene su propio conjunto de problemas .

Tengo curiosidad por la razón por la cual los arquitectos de FIDO UAF y U2F no llevaron el protocolo un paso más allá, e incorporaron un método de fijación de clave pública dentro del protocolo (tal vez utilizando diferentes pares de claves que los utilizados para la conexión SSL / TLS). ), para que los clientes puedan asegurarse de que se conectan al servidor legítimo antes de intentar la autenticación, a la SSH. ¿A alguien le gustaría hipotetizar?

    
pregunta weaver 20.04.2017 - 19:53
fuente

1 respuesta

0

Comparto tu sentimiento global acerca de que U2F es un buen trabajo, incluso si es un trabajo a medias. :) Nota: Estoy trabajando como arquitecto de seguridad dentro de una pequeña empresa (miembro de la Alianza FIDO) con sus propios productos certificados U2F.

En lo que respecta a la caducidad de la compatibilidad con TLS ChannelID, se supone que, eventualmente, evolucionará hacia la compatibilidad de enlace de token (especificaciones actualizadas, el mismo objetivo). enlace Sí, no es fácil implementar TlS Channel ID en el lado del servidor (la biblioteca BoringSSL puede ayudar) y sí, solo es compatible con Chrome en el lado del cliente y sí, puede ser degradado ... PERO lo bueno es que si está pensando en utilizar U2F en su propio servidor / servicio, aún puede hacerse y usted puede hacer que se cumpla. Mejor que nada, si bien es cierto que en muchos servicios globales (gmail, facebook ...), la protección de ID de canal TLS simplemente está desactivada.

Con respecto al debate sobre la fijación de claves y por qué la parte de autenticación del servidor se basa en el certificado de servidor SSL antiguo / bueno, la decisión original probablemente sea un resultado mixto de dificultades técnicas y posicionamiento "político". U2F (y UAF) ya atacan a las Autoridades de Certificación establecidas en el lado del cliente ... Nota: estos son pares de claves de clientes anónimos pero los certificados de producción / certificación asociados pueden ser firmados por las claves privadas de la Alianza FIDO (convirtiéndose en su propia Autoridad de Certificación ...).

Tratar con la autenticación mutua también requeriría una memoria más grande ... No me importa, pero puede ser un problema para algunos proveedores de soluciones.

Cualquiera que sea la razón real inicial, no está terminada y, que yo sepa, este tipo de característica no está planeada para futuras versiones de U2F ... y tampoco está planeada para WebAuthN (tipo de sucesor de U2F / UAF).

Pero no significa que U2F no se pueda adaptar para admitir la función de autenticación mutua mejorada ... Estoy trabajando en ello con algunos otros tontos: Bienvenido a nuestra locura :)

    
respondido por el FredericMARTIN 24.04.2017 - 02:14
fuente

Lea otras preguntas en las etiquetas