Confianza en el primer uso ( TOFU ), o confianza en el primer uso ( TUFU ), es un esquema de autenticación [1] utilizado por el software cliente que necesita establecer una relación de confianza con un punto final desconocido o aún no confiable. En un modelo TOFU, el cliente intentará buscar el identificador del punto final, generalmente la clave de identidad pública del punto final o la huella digital.de dicha clave de identidad, en su base de datos de confianza local. Si todavía no existe un identificador para el punto final, el software del cliente le pedirá al usuario que confirme que ha verificado que el identificador pretendido es auténtico, o si la verificación manual no se supone que sea posible en el protocolo, el cliente simplemente confiará en el identificador que recibió y registra la relación de confianza en su base de datos de confianza. Si en una conexión posterior se recibe un identificador diferente del extremo opuesto, el software del cliente lo considerará no confiable.
Implementaciones TOFU
En el SSH protocolo, la mayoría del software de cliente (aunque no todos [2] ) será, al conectarse a un servidor que aún no es de confianza-, mostrar huella de la clave pública del servidor, y rápido al usuario para verificar que efectivamente se han autenticado utilizando un autenticados canal . Luego, el cliente registrará la relación de confianza en su base de datos de confianza. El nuevo identificador provocará una advertencia de bloqueo que requiere la eliminación manual del identificador almacenado actualmente.
En HTTP Public Key Pinning, los navegadores siempre aceptarán la primera clave pública devuelta por el servidor y con HTTP Strict Transport Security en la que los navegadores obedecerán la regla de redirección mientras dure la directiva 'age'.
El cliente XMPP Conversations utiliza Blind Trust Before Verification , [3] donde se confía ciegamente en todos los identificadores hasta que el usuario demuestra voluntad y capacidad para autenticar puntos finales escaneando la representación del código QR del identificador. Una vez que se ha escaneado el primer identificador, el cliente mostrará un símbolo de escudo para los mensajes de los puntos finales autenticados y un fondo rojo para los demás.
En Signal, los puntos finales inicialmente confían ciegamente en el identificador y muestran advertencias sin bloqueo cuando cambia. El identificador se puede verificar escaneando un código QR o intercambiando la representación decimal del identificador (llamado número de seguridad) a través de un canal autenticado. A continuación, el identificador se puede marcar como verificado. Esto cambia la naturaleza de las advertencias de cambio de identificador de no bloqueo a bloqueo. [4]
En, por ejemplo, Jami y Ricochet, el identificador es el propio distintivo de llamada del usuario. La ID se puede intercambiar a través de cualquier canal, pero hasta que el identificador se verifique en un canal autenticado, se confía ciegamente en él. El cambio de identificador también requiere un cambio de cuenta, por lo que un ataque MITM para la misma cuenta requiere acceso a la clave privada del endpoint.
En WhatsApp, el punto final inicialmente confía ciegamente en el identificador y, de forma predeterminada, no se muestra ninguna advertencia cuando cambia el identificador. Si el usuario demuestra voluntad y capacidad para autenticar puntos finales accediendo a la huella digital de la clave (llamada Código de seguridad), el cliente le pedirá al usuario que habilite las advertencias sin bloqueo cuando cambie el identificador. El cliente de WhatsApp no permite que el usuario marque el identificador como verificado.
En los chats secretos opcionales de Telegram , los terminales confían ciegamente en el identificador. El identificador cambiado genera una nueva ventana de chat secreta en lugar de mostrar cualquier advertencia. Los identificadores se pueden verificar comparando la representación visual o hexadecimal del identificador. El cliente de Telegram no permite al usuario marcar el identificador como verificado.
En Keybase, los clientes pueden firmar de forma cruzada las claves de los demás, lo que significa que confiar en un único identificador permite la verificación de varios identificadores. Keybase actúa como un tercero de confianza que verifica un vínculo entre una cuenta de Keybase y la cadena de firmas de la cuenta que contiene el historial del identificador. El identificador utilizado en Keybase es el hash de la raíz de la cadena de firmas del usuario o el nombre de la cuenta de Keybase vinculada a él. Hasta que el usuario verifique la autenticidad del hash raíz de la cadena de firmas (o la cuenta de la base de claves) a través de un canal autenticado, la cuenta y sus identificadores asociados son esencialmente de confianza ciega y el usuario es susceptible a un ataque MITM. [ cita requerida ]
Modelar fortalezas y debilidades
La mayor fortaleza de cualquier modelo de estilo TOFU es que un ser humano debe inicialmente validar cada interacción. Una aplicación común de este modelo es el uso de usuarios 'bot' ssh-rpc entre computadoras, mediante el cual las claves públicas se distribuyen a un conjunto de computadoras para el acceso automatizado desde hosts centralizados. El aspecto TOFU de esta aplicación obliga a un administrador de sistemas (u otro usuario de confianza) a validar la identidad del servidor remoto en la primera conexión.
Para la comunicación de extremo a extremo cifrado el modelo TOFU permite autenticado cifrado sin el complejo procedimiento de obtención de un certificado personal que son vulnerables a la CA de transacción . En comparación con Web of Trust , TOFU tiene menos gastos de mantenimiento.
La mayor debilidad de TOFU que requiere verificación manual es su incapacidad para escalar para grupos grandes o redes de computadoras. La sobrecarga de mantenimiento de realizar un seguimiento de los identificadores para cada punto final puede escalar rápidamente más allá de las capacidades de los usuarios.
En entornos donde la autenticidad del identificador no se puede verificar con la suficiente facilidad (por ejemplo, el personal de TI del lugar de trabajo o la instalación educativa puede ser difícil de alcanzar), los usuarios tienden a confiar ciegamente en el identificador del extremo opuesto. Los identificadores de atacantes aprobados accidentalmente también pueden ser difíciles de detectar si el ataque man-in-the-middle persiste.
Como un nuevo punto final siempre implica un nuevo identificador, no se muestra ninguna advertencia sobre un posible ataque. Esto ha provocado un error entre los usuarios de que es seguro continuar sin verificar la autenticidad del identificador inicial, independientemente de si el identificador se presenta al usuario o no.
La fatiga de las advertencias ha llevado a muchas aplicaciones de mensajería a eliminar las advertencias de bloqueo para evitar que los usuarios vuelvan a aplicaciones menos seguras que no cuentan con cifrado de extremo a extremo en primer lugar.
Los mecanismos de verificación de identificadores ocultos reducen la probabilidad de que los usuarios descubran y adopten prácticas de autenticación seguras.
Primer uso conocido del término
El primer uso formal conocido del término TOFU o TUFU fue por los investigadores de CMU Dan Wendlandt, David Andersen y Adrian Perrig en su artículo de investigación "Perspectivas: Mejora de la autenticación de host estilo SSH con sondeo de múltiples rutas" publicado en 2008 en el Usenix Annual Conferencia técnica. [5]
Moxie Marlinspike mencionó Perspectivas y el término TOFU en los procedimientos de DEF CON 18, con referencia a los comentarios hechos por Dan Kaminsky , durante el panel de discusión "Una carta abierta, un llamado a la acción". Se planteó una sugerencia de la audiencia que implicaba la superioridad del modelo de infraestructura de clave pública SSH (PKI) sobre el modelo SSL / TLS PKI, por lo que Moxie respondió:
Anónimo : "... entonces, si no nos gusta el modelo de certificado en (tls) PKI, pero nos gusta, digamos, SSH PKI, que parece funcionar bastante bien, básicamente lo fundamental es: si le doy mis datos a alguien, le confío los datos. Por lo tanto, debería recordar su certificado. Si alguien más llega con un certificado diferente, firmado por una autoridad diferente, todavía no confío en ellos. Y si lo hicimos de esa manera, entonces Eso resolvería muchos de los problemas: resolvería los problemas de las CA no autorizadas, hasta cierto punto, no lo ayudaría con el bootstrapping inicial, pero el bootstrapping inicial usaría el modelo inicial y luego para la interacción continua con el sitio. usaría el modelo ssh que le permitiría una fuerza continua más allá de lo que tenemos ahora. Por lo tanto, el modelo que tenemos ahora se puede continuar reutilizándose, solo por la aceptación inicial. Entonces, ¿por qué no hacemos esto? "
Dan : "Soy un ex desarrollador de SSH, y déjeme caminar muy rápido, cada vez que hay un error en la generación de la clave ssh, se le pregunta al usuario, 'por favor escriba sí para confiar en esta nueva clave', o ' por favor, ingrese a su archivo de hosts conocidos y elimine ese valor ', y la última vez que lo hagan, porque siempre es culpa de una mala configuración del servidor. El modelo SSH es genial, no escala ".
Moxie : " Y solo agregaría, de lo que estás hablando se llama 'Confianza en el primer uso', o 'tofu' , y hay un proyecto en el que estoy involucrado llamado perspectivas, que intenta aprovechar eso para ser menos confuso que el modelo SSH puro, y creo que es un gran proyecto y debería comprobarlo si está interesado en alternativas al sistema CA ".
Trabajo relacionado sobre el tema
- El trabajo para crear representaciones visuales de los hashes de "huellas dactilares" de certificados de servidor se ha implementado en OpenSSH en forma de ASCII Art . La intención es que los usuarios reconozcan visualmente una imagen "gráfica", en lugar de una larga cadena de letras y números. El artículo de investigación original fue escrito por Adrian Perring y Dawn Song , del Departamento de Ciencias de la Computación de la Universidad Carnegie Mellon .
- El creador del acrónimo 'TUFU' estaba describiendo la inspiración para el ' Perspectives Firefox Plug In ', que fue diseñado para fortalecer el modelo SSL / TLS PKI contactando a los notarios de la red cada vez que su navegador se conecta a un sitio web HTTPS.
Trabajo prioritario
Los temas de confianza, validación, no repudio son fundamentales para todo trabajo en el campo de la criptografía y la seguridad digital .
Ver también
Referencias
- ^ TOFU para OpenPGP , Walfield, Koch (EUROSEC'16, 18-21 de abril de 2016)
- ^ ¿Cuál es la forma segura / correcta de agregar github.com al archivo known_hosts? Consultado el 19 de noviembre de 2020.
- ^ Daniel Gultsch (20 de noviembre de 2016). "Confianza ciega antes de la verificación" . Consultado el 19 de enero de 2017 .
- ^ [1]
- ^ http://www.usenix.org/events/usenix08/tech/full_papers/wendlandt/wendlandt_html/index.html
enlaces externos
- "Horario DEF CON 18, Carta abierta - Llamado a la acción"
- Extensión de Firefox que contacta a los notarios de la red cada vez que su navegador conecta un sitio web HTTPS
- Visualización de hash en OpenSSH