En los mensajeros con cifrado de extremo a extremo (E2E), el usuario es responsable de sus claves. Cuando los pierde, se ve obligado a restablecer su cuenta.

Restablecer una cuenta es peligroso. Borras las claves públicas y en todas las conversaciones te conviertes en un extraño criptográfico. Debe restaurar su identidad y, en casi todos los casos, esto significa una reunión personal y una comparación de "números de seguridad" con cada uno de los contactos. ¿Con qué frecuencia realmente pasa por esa prueba, que es la única protección de MiTM?

Incluso si se toma en serio los números de seguridad, ve a muchos socios de chat solo una vez al año en una conferencia, por lo que está estancado.

Pero esto sucede con poca frecuencia, ¿verdad?

¿Con qué frecuencia ocurre un reinicio? Respuesta: en la mayoría de las aplicaciones de chat E2E todo el tiempo.

En estos mensajeros instantáneos, suelta la criptografía y simplemente comienza a confiar en el servidor: (1) cada vez que cambia a un nuevo teléfono; (2) cada vez que un interlocutor cambia a un nuevo teléfono; (3) cuando se restablece la configuración de fábrica del teléfono; (4) cuando cualquier interlocutor realiza un restablecimiento a la configuración de fábrica; (5) cada vez que desinstala y reinstala la aplicación, o (6) cuando cualquier persona con la que está hablando lo desinstala y lo vuelve a instalar. Si tiene docenas de contactos, se realizará un reinicio cada pocos días.

El restablecimiento ocurre tan regularmente que estas aplicaciones fingen que esto no es un problema:

¡Parece que tenemos una actualización de seguridad! (Pero no realmente)

¿Es realmente TOFU?

En criptografía, el término TOFU ("confianza en el primer uso") describe un juego de azar cuando dos partes hablan por primera vez. En lugar de reunirse en persona, el mediador es responsable de cada lado ... y luego, después de que las partes se presenten, cada lado monitorea cuidadosamente las claves para asegurarse de que nada haya cambiado. Si la llave ha cambiado, cada lado emite una alarma.

Si la clave del host remoto cambia en SSH en tal situación, no "simplemente funcionará", sino que se volverá completamente beligerante:

@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ @ WARNING: REMOTE HOST IDENTIFICATION HAS CHANGED! @ @@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@@ IT IS POSSIBLE THAT SOMEONE IS DOING SOMETHING NASTY! Someone could be eavesdropping on you right now (man-in-the-middle attack)! It is also possible that a host key has just been changed. The fingerprint for the RSA key sent by the remote host is 00:11:22:33:44:55:66:77:88:99:aa:bb:cc:dd:ee:ff Please contact your system administrator. Add correct host key in /Users/rmueller/.ssh/known_hosts to get rid of this message. Offending RSA key in /Users/rmueller/.ssh/known_hosts:12 RSA host key for 8.8.8.8 has changed and you have requested strict checking. Host key verification failed.

Aquí está el comportamiento correcto. Y recuerde: esto no es TOFU si le permite trabajar más lejos con una pequeña advertencia. Deberías ver una calavera gigante con huesos cruzados .

Por supuesto, estos mensajeros instantáneos afirmarán que todo está bien, porque el usuario está advertido. Si quiere, puede verificar los números de seguridad. Por eso no estamos de acuerdo:

La verificación no se realiza porque ocurre con demasiada frecuencia.
El control apesta.
Incluso una encuesta superficial de nuestros amigos que están preocupados por la seguridad mostró que a nadie le preocupa esta prueba.
Así que solo confía en el servidor y confía en los SMS (¡bueno, bueno!) Una y otra vez .
Finalmente, estas aplicaciones no deberían funcionar de esta manera. Especialmente cuando se cambian dispositivos. Un caso normal típico puede manejarse sin problemas y de forma segura, y cuanto más rara sea la situación, peor debería verse. En un minuto, muestre la solución Keybase.

Deja de llamarlo TOFU

Hay un ataque muy efectivo. Supongamos que Eve quiere irrumpir en la conversación existente de Alice y Bob y ponerse entre ellos. Alice y Bob han estado en contacto durante muchos años, desde hace mucho tiempo que pasaron TOFU.

Eve solo le hace pensar a Alice que Bob compró un teléfono nuevo:

Bob (Eve): ¡Oye, oye!

Alice: ¡ Yo Bob! Parece que tienes nuevos números de seguridad.

Bob (Eve): Sí, compré el iPhone XS, un buen teléfono, muy satisfecho con él. Intercambiemos números de seguridad en el RWC 2020. Oye, ¿tienes tu dirección actual de Caroline? Quiero sorprenderla mientras estoy en San Francisco.

Alice: No puedo comparar, Android 4 life! Sí, calle acogedora 555.

Por lo tanto, es poco probable que la mayoría de los mensajeros cifrados ganen el cumplimiento de TOFU. Esto es más como TADA: confianza después de agregar dispositivos. Este es un problema real, no ficticio, porque crea la oportunidad de implementación maliciosa en una conversación preexistente. En TOFU real, cuando alguien esté interesado en tu conversación, no podrá infiltrarse en ella. Con TADA, esto es posible.

En los chats grupales, la situación es aún peor. Cuantas más personas participen en el chat, más a menudo se reinstalará la cuenta. En una empresa de solo 20 personas, esto sucederá aproximadamente cada dos semanas, según nuestro cálculo. Y cada persona en la empresa debe conocer a esta persona. Personalmente De lo contrario, todo el chat se ve comprometido por un topo o hacker.

Solución

¿Existe una buena solución que no implique confianza en servidores de clave privada? Creemos que existe: soporte real para múltiples dispositivos. Esto significa que administra una cadena de dispositivos que representan su identidad. Cuando recibe un nuevo dispositivo (teléfono, computadora portátil, computadora de escritorio, iPad, etc.), genera su propio par de claves y su dispositivo anterior lo firma. Si pierde el dispositivo, entonces "bórrelo" de uno de los restantes. Técnicamente, dicha eliminación es un recuerdo, y en este caso también hay algún tipo de inversión clave que ocurre automáticamente.

Como resultado, no necesita confiar en el servidor o reunirse en persona cuando el interlocutor o colega recibe un nuevo dispositivo . Del mismo modo, no es necesario que confíe en el servidor o se reúna en persona cuando retire el dispositivo, si no fue el último. El único momento en que necesita ver una advertencia es cuando alguien realmente pierde el acceso a todas sus configuraciones. Y en este caso, verá una advertencia seria, como debería:

Especialmente muy feo

Como resultado, se restablecen y reinstalan muchas menos cuentas. Históricamente, en Keybase, el número total de complementos y revisiones de dispositivos es diez veces el número de descargas de cuentas (no es necesario que confíe en nuestra palabra, está disponible públicamente en nuestro árbol de Merkle). A diferencia de otros mensajeros, podemos mostrar una advertencia realmente aterradora cuando habla con alguien que recientemente ha reinstalado las llaves.

La administración de dispositivos es una operación de ingeniería compleja que hemos refinado varias veces. El dispositivo existente firma las claves públicas del nuevo dispositivo y cifra todos los datos secretos importantes para la clave pública del nuevo dispositivo. Esta operación debe realizarse rápidamente (en un segundo), ya que estamos hablando del rango de atención del usuario. Como resultado, Keybase utiliza una jerarquía de claves, de modo que al transferir 32 bytes de datos secretos desde un dispositivo antiguo, el nuevo dispositivo puede ver todos los datos criptográficos de larga duración (consulte las preguntas frecuentes a continuación para obtener más detalles). Esto puede parecer un poco sorprendente, pero ese es exactamente el punto de la criptografía . No resuelve sus problemas de gestión de secretos; solo hace que el sistema sea más escalable.

La imagen completa de seguridad

Ahora podemos formular cuatro propiedades de seguridad básicas para la aplicación Keybase:

las claves secretas duraderas nunca abandonan los dispositivos en los que se crean
El soporte completo para múltiples dispositivos minimiza las caídas de cuentas
la revocación de claves no se puede retrasar o revertir maliciosamente
secreto directo usando mensajes de tiempo efímero

Los dos primeros parecen entendibles. Un tercero se vuelve importante en un diseño donde el retiro del dispositivo se espera y se considera normal. El sistema debe tener comprobaciones de que los servidores maliciosos no pueden retrasar las revisiones de dispositivos, sobre lo que escribimos anteriormente .

Consulte nuestro artículo sobre mensajes efímeros para obtener más información sobre la cuarta característica de seguridad.

Mucha nueva criptografía, ¿está todo implementado correctamente?

Keybase nunca antes ha implementado las funciones básicas de seguridad y nunca lo ha descrito en artículos científicos. Tuvimos que inventar algunos protocolos criptográficos nosotros mismos. Afortunadamente, hay muchos algoritmos criptográficos estandarizados y ampliamente utilizados para cualquier situación. Todo nuestro código de cliente está abierto . Teóricamente, cualquiera puede encontrar errores de diseño o implementación. Pero queríamos demostrar la estructura interna y contratamos a la mejor firma de auditoría de seguridad para un análisis completo.

Hoy presentamos el informe del Grupo NCC y estamos extremadamente alentados por los resultados. Keybase gastó más de $ 100,000 en auditoría, y el Grupo NCC contrató expertos en seguridad y criptografía de alto nivel. Encontraron dos errores importantes en nuestra implementación, y los reparamos rápidamente. Estos errores solo pueden aparecer si nuestros servidores actúan de manera maliciosa. Podemos asegurar que no actuarán así, pero no tiene motivos para creernos. Esa es la cosa!

Creemos que el equipo de NCC ha hecho un excelente trabajo. Respeto por el tiempo que dedicaron a comprender completamente nuestra arquitectura e implementación. Encontraron errores sutiles que pasaron la atención de nuestros desarrolladores, aunque recientemente hemos visto esta parte de la base del código repetidamente. Le recomendamos que mire el informe aquí o consulte nuestras Preguntas frecuentes.

FAQ

¿Cómo te atreves a atacar un producto XYZ?

Ya hemos eliminado las referencias a productos específicos del artículo.

Que mas

Estamos orgullosos de que Keybase no requiera números de teléfono y pueda verificar criptográficamente los identificadores de Twitter, HackerNews, Reddit y Github si conoce a alguien.

Y ... muy pronto ... habrá apoyo para Mastodon.

¿Qué pasa con los ataques de redirección de teléfono?

Muchas aplicaciones son susceptibles a ataques de redireccionamiento. Eve entra a un quiosco en un centro comercial y convence a Bob, el operador de telefonía móvil, de que envíe el número de teléfono de Bob a su dispositivo. O ella convence al representante por teléfono. Ahora, Eve puede autenticarse en los servidores de mensajería, alegando que ella es Bob. El resultado parece que nuestro ejemplo de Alice, Bob y Eve es más alto, pero Eve no necesita penetrar en ningún servidor. Algunas aplicaciones ofrecen "bloqueo de registro" para protegerse contra este ataque, pero por defecto son molestas.

¿Escuché que Keybase envía algunas claves privadas al servidor?

En los primeros días (2014 y principios de 2015), Keybase funcionaba como una aplicación web PGP, y el usuario podía elegir la función para almacenar sus claves PGP privadas en nuestros servidores, cifradas con frases de contraseña (que Keybase no conocía).

En septiembre de 2015, presentamos el nuevo modelo Keybase. Las claves PGP nunca se usan (y nunca se usan) en el chat de Keybase o en el sistema de archivos.

¿Cómo aparecen instantáneamente los viejos chats en los nuevos teléfonos?

En algunas otras aplicaciones, los dispositivos nuevos no ven mensajes antiguos, ya que sincronizar mensajes antiguos a través del servidor es contrario al secreto directo. La aplicación Keybase le permite designar ciertos mensajes, o conversaciones completas, como "efímeras". Se destruyen después de un cierto tiempo y se cifran dos veces: una usando claves de cifrado de chat de larga duración, y la otra utilizando claves efímeras que cambian con frecuencia. Por lo tanto, los mensajes efímeros proporcionan secreto directo y no pueden sincronizarse entre teléfonos.

Los mensajes no efímeros permanecen hasta que el usuario los elimina explícitamente y sincroniza E2E con los nuevos dispositivos de estilo Slack, ¡solo con cifrado! Por lo tanto, cuando agrega a alguien a un equipo o agrega un nuevo dispositivo para usted, los mensajes se desbloquean.

Más sobre sincronización en el siguiente párrafo.

¡Cuéntanos sobre los PUK!

Hace dos años, presentamos claves para usuarios (PUK) . La mitad pública del PUK se anuncia en el sigchain público de los usuarios. La mitad secreta se cifra para la clave pública de cada dispositivo. Cuando Alice está preparando un nuevo dispositivo, su antiguo dispositivo conoce la mitad secreta de su PUK y la clave pública del nuevo dispositivo. Cifra la mitad secreta del PUK para la clave pública del nuevo dispositivo, y el nuevo dispositivo descarga este texto cifrado a través del servidor. El nuevo dispositivo descifra el PUK y puede acceder de inmediato a todos los mensajes de chat de larga duración.

Cada vez que Alice recuerda un dispositivo, cambia su PUK, de modo que todos sus dispositivos, excepto el más reciente, reciben un nuevo PUK.

Este esquema de sincronización es fundamentalmente diferente del anterior sistema Keybase PGP. Aquí, todas las claves involucradas tienen 32 bytes de entropía verdadera; no se rompen con fuerza bruta en caso de un pirateo del servidor. Es cierto, si el Curve25519 o el PRNG de Go están rotos, entonces todo se rompe. Pero la sincronización PUK no hace otras suposiciones criptográficas significativas.

¿Qué pasa con los chats de grupos grandes?

Los grupos tL; dr tienen sus propias cadenas de firmas auditadas para cambiar roles, agregar y eliminar miembros.

Los investigadores de seguridad escribieron sobre ataques fantasmas de usuarios en chats grupales. Si los clientes de los usuarios no pueden verificar criptográficamente la pertenencia al grupo, los servidores maliciosos pueden incrustar spyware y moles en los chats grupales. Keybase tiene un sistema muy confiable en forma de una función especial de grupos , sobre lo que escribiremos en el futuro.

¿Puedes hablar sobre NCC-KB2018-001?

Creemos que este error es el hallazgo más significativo de la auditoría de NCC. Keybase utiliza activamente estructuras de datos inmutables para proteger contra la ambigüedad del servidor de solo agregar. En el caso de un error, un servidor honesto puede comenzar a evadir: "Te dije A antes, pero ocurrió un error, quise decir B". Pero nuestros clientes tienen una política común de no permitir al servidor tal flexibilidad: tienen excepciones codificadas en caso de errores.

Recientemente, también presentamos Sigchain V2 : este sistema resuelve los problemas de escalabilidad que no predecimos correctamente en la primera versión. Ahora los clientes son más económicos con los datos criptográficos que obtienen del servidor, ya que reciben solo una firma de la cola de la cadena de firmas, en lugar de la firma de cada enlace intermedio. Por lo tanto, los clientes han perdido la oportunidad de ir en ciclos en la búsqueda de un hash de firma específico, pero anteriormente utilizamos estos hash para buscar enlaces de cadena defectuosos en esta lista de excepciones codificadas. Nos estábamos preparando para el lanzamiento de Sigchain V2, olvidando este detalle oculto bajo varias capas de abstracciones, por lo que el sistema simplemente confió en el campo desde la respuesta del servidor.

Una vez que el NCC descubrió este error, la solución fue lo suficientemente simple: buscando excepciones codificadas con un hash de chainlink en lugar de un hash de chainlink. El cliente siempre puede calcular directamente estos hashes.

También podemos atribuir este error a la complejidad adicional requerida para soportar Sigchain V1 y Sigchain V2 simultáneamente. Los clientes modernos escriben enlaces Sigchain V2, pero todos los clientes deben admitir enlaces v1 heredados por un tiempo ilimitado. Recuerde que los clientes firman enlaces con sus claves privadas para cada dispositivo. No podemos coordinar a todos los clientes que sobrescriban datos históricos en un período de tiempo razonable, ya que estos clientes pueden simplemente estar desconectados.

¿Puedes hablar sobre NCC-KB2018-004?

Al igual que en 001 (ver arriba), nos decepcionó una cierta combinación de soporte simultáneo para soluciones obsoletas y optimización, lo que parecía importante a medida que ganábamos más experiencia trabajando con el sistema.

En Sigchain V2, reducimos el tamaño de las cadenas en bytes para reducir el ancho de banda necesario para buscar usuarios. Este ahorro es especialmente importante en los teléfonos móviles. Por lo tanto, codificamos enlaces de cadena con MessagePack , no JSON , lo que ofrece buenos ahorros. A su vez, los clientes firman y verifican las firmas en estas cadenas. Los investigadores de NCC han encontrado formas difíciles de crear "firmas" que se parecen a JSON y MessagePack al mismo tiempo, lo que lleva a un conflicto. Involuntariamente presentamos esta ambigüedad de decodificación durante la optimización cuando cambiamos los analizadores JSON del analizador Go estándar a uno más eficiente. Este analizador rápido omitió silenciosamente un montón de basura antes de encontrar el JSON real, que incluía esta función de ataque políglota. El error se corrige mediante una verificación de entrada adicional .

En Sigchain V2, también aceptamos la sugerencia de Adam Langley de que los firmantes preceden sus paquetes con firmas por el prefijo de la línea de contexto y el byte \0 para que los verificadores no se confundan con las intenciones del firmante. En el lado de verificación de esta idea de prefijo de contexto, hubo errores que podrían conducir a otros ataques políglotas. Rápidamente arreglamos esta falla con una lista blanca .

Después de corregir ambos errores, el servidor rechaza las cargas maliciosas del ataque políglota, por lo que la explotación de estas vulnerabilidades solo es posible con la ayuda de un servidor comprometido.

¿Dónde está la documentación?

https://keybase.io/docs

En los próximos meses, dedicaremos más tiempo a trabajar en la documentación.

Puede proporcionar más información sobre esta declaración de NCC: "Sin embargo, un atacante puede negarse a actualizar sigchain o revertir la cadena de un usuario a un estado anterior truncando los enlaces posteriores en la cadena"

Keybase hace un uso extensivo de estructuras de datos públicos inmutables de solo agregado que obligan a la infraestructura del servidor a capturar una representación real de los identificadores de usuario. Podemos garantizar la retirada de dispositivos y la eliminación de los miembros del grupo de tal manera que un servidor comprometido no pueda retroceder. Si el servidor decide mostrar una vista inconsistente, esta desviación se convierte en parte del registro público inmutable. Los clientes de Keybase o un auditor externo pueden detectar un desajuste en cualquier momento después del ataque. Creemos que estas garantías superan con creces las garantías de los productos de la competencia y son casi óptimas, teniendo en cuenta las limitaciones prácticas de los teléfonos móviles y los clientes con potencia informática limitada.

En pocas palabras, Keybase no puede inventar las firmas de otra persona. Como cualquier servidor, puede contener datos. Pero nuestro árbol Merkle transparente está diseñado para almacenarlos durante un período de tiempo muy corto, y siempre es reconocible.

¿Cómo maneja Keybase los reinicios de cuenta?

Cuando los usuarios de Keybase realmente pierden todos sus dispositivos (en lugar de agregar nuevos o perder algunos), deben reiniciar. Después de restablecer la cuenta, el usuario es básicamente nuevo, pero tiene el mismo nombre de usuario. No puede firmar la "instrucción de reinicio" porque ha perdido todas sus claves. Entonces, en cambio, el servidor Keybase confirma la declaración no borrable en el árbol Merkle, lo que significa restablecer. Los clientes fuerzan la imposibilidad de revertir estas instrucciones. En un artículo futuro, se describirán en detalle mecanismos específicos.

Este usuario tendrá que volver a agregar verificaciones de identidad (Twitter, Github, lo que sea) con las nuevas claves.

¿Puede un servidor simplemente intercambiar la hoja del árbol Merkle de alguien para anunciar un conjunto de claves completamente diferente?

Los autores de NCC están considerando un servidor Keybase hostil que cambia completamente la hoja del árbol de Merkle, reemplazando el verdadero conjunto de claves de Bob con un conjunto falso completamente nuevo. Un servidor atacante tiene dos opciones. Primero, puede bifurcar el estado del mundo colocando a Bob en una bifurcación, y a los que quiere engañar en otra. En segundo lugar, puede "engañar" al publicar una versión del árbol de Merkle con el juego correcto de llaves Bob y otras versiones con un juego falso. Los usuarios que interactúan regularmente con Bob descubrirán este ataque, ya que verificarán que las versiones descargadas previamente del historial de Bob son prefijos válidos de las nuevas versiones que descargan del servidor. Los validadores de terceros que analizan todas las actualizaciones de Keybase también notarán este ataque. Si escribe un validador de Keybase de terceros que nos gusta, podemos ofrecerle una recompensa significativa. Consulte max en Keybase. De lo contrario, esperamos planificar pronto la creación de un validador autónomo.

¿Puedes creer lo que leí hasta el final?

¿Leer o simplemente desplazarse hacia abajo?

Keybase y verdadero TOFU