Algunas Reflexiones sobre Ingeniería Criptográfica

Hace unas semanas escribí un largo post sobre el proyecto ‘BULLRUN’ de la NSA para subvertir los estándares de cifrado modernos. Tenía la intención de volver a esto en algún momento, ya que no tenía tiempo para discutir los temas en detalle. Pero luego las cosas se interpusieron. Muchas cosas, en realidad. Algunos de los cuales espero escribir en un futuro cercano.

Pero antes de llegar allí, y a riesgo de aburrirlos a todos hasta las lágrimas, quería volver a este tema al menos una vez más, aunque solo sea para pontificar un poco sobre una pregunta que me ha estado molestando.

Verá, la hoja informativa de BULLRUN de la NSA menciona que la NSA ha estado rompiendo varias tecnologías de cifrado, algunas de las cuales son más interesantes que otras. Una de esas tecnologías es particularmente sorprendente para mí, ya que no puedo imaginar cómo podría hacerlo la NSA. En este post extremadamente largo voy a tratar de profundizar un poco más en la pregunta más importante que enfrenta Internet hoy en día.

Específicamente: ¿cómo diablos está rompiendo SSL la NSA?

Sección de la hoja informativa de BULLRUN. Fuente: New York Times.

Para mantener las cosas en el objetivo, voy a hacer algunas reglas básicas.

En primer lugar, soy consciente de que la NSA puede instalar malware en su computadora y pwnear cualquier criptografía que elija. Eso no me interesa en absoluto, por la sencilla razón de que no se escala bien. La NSA puede hacerte esto, pero no pueden hacerlo por toda una población. Y eso es lo que realmente me preocupa de las filtraciones recientes: la posibilidad de que la NSA esté rompiendo el cifrado para fines de vigilancia masiva.

Por la misma razón, no nos vamos a preocupar de los ataques man-in-the-middle (MITM). Si bien sabemos que la NSA ejecuta estos, también son un ataque muy dirigido. Los MITM no solo son detectables si los haces a gran escala, sino que no concuerdan con lo que sabemos sobre cómo la NSA realiza la interceptación a gran escala, principalmente a través de divisores de haz y grifos. En otras palabras: estamos muy preocupados por la vigilancia pasiva.

Las reglas anteriores no son absolutas, por supuesto. Consideraremos ataques dirigidos limitados a los servidores, siempre que posteriormente permitan el descifrado pasivo de grandes cantidades de tráfico; por ejemplo, el descifrado del tráfico a los principales sitios web. También consideraremos modificaciones arbitrarias en el software y el hardware, algo que sabemos que la NSA ya está haciendo.

Un último punto: para evitar que las cosas se descarrilen, he dividido este artículo en dos secciones. El primero cubrirá ataques que utilizan solo técnicas conocidas. Todo en esta sección puede ser implementado por un empleado de TAO con suficiente inteligencia y acceso al software. La segunda sección, que he titulado «Espectro de Sombreros de papel de aluminio», cubre las cosas divertidas y especulativas, que van desde los nuevos ataques de canales laterales hasta ese enorme ordenador cuántico que la NSA mantiene junto a la ICM.

Comenzaremos con lo práctico.

Ataques que utilizan Técnicas Conocidas

Robo de claves RSA. La forma más obvia de «descifrar» SSL realmente no implica descifrar nada. ¿Por qué perder tiempo y dinero en criptoanálisis cuando puedes robar las llaves? Este problema es particularmente preocupante en los servidores configurados para el protocolo de enlace TLS RSA, donde una única clave de servidor de 128 bytes es todo lo que necesita para descifrar todas las conexiones pasadas y futuras realizadas desde el dispositivo.

De hecho, esta técnica es tan obvia que es difícil imaginar que la NSA gaste muchos recursos en sofisticados ataques criptoanalíticos. Sabemos que GCHQ y NSA son perfectamente cómodos sobornando incluso a proveedores estadounidenses en el extranjero. Y dentro de nuestras fronteras, han demostrado su voluntad de obtener claves TLS/SSL usando poderes de citación y órdenes de mordaza. Si está utilizando una conexión RSA a un sitio web importante, puede ser sensato asumir que la clave ya se conoce.

Por supuesto, incluso donde la NSA no recurra a medidas directas, siempre existe la posibilidad de obtener claves a través de un exploit de software remoto. La belleza es que estos ataques ni siquiera requieren la ejecución remota de código. Dada la vulnerabilidad correcta, puede requerir simplemente un puñado de solicitudes SSL mal formadas para mapear el contenido completo del montón de OpenSSL/SChannel.

Fuente: New York Times

Chips de cifrado de hardware de subordinación. Una fracción significativa del tráfico SSL en Internet es producida por dispositivos de hardware como terminadores SSL y enrutadores habilitados para VPN. Afortunadamente, no tenemos que especular sobre la seguridad de estos dispositivos, ya sabemos que NSA/GCHQ han estado colaborando con fabricantes de hardware para «habilitar» el descifrado en varios chips de cifrado VPN importantes.

Los documentos de la NSA no tienen claro cómo funciona esta capacidad, o si incluso involucra SSL. Si lo hace, la suposición obvia es que cada chip encripta y exflitrata bits de la clave de sesión a través de campos ‘aleatorios’ como IVs y nonces de apretón de manos. De hecho, esto es relativamente fácil de implementar en un dispositivo de hardware opaco. La pregunta interesante es cómo se garantiza que estas puertas traseras solo puedan ser explotadas por la NSA, y no por agencias de inteligencia rivales. (Algunas ideas sobre eso aquí.)

Ataques de canal lateral. Tradicionalmente, cuando analizamos algoritmos criptográficos, nos preocupamos por las entradas y salidas esperadas del sistema. Pero los sistemas reales filtran todo tipo de información adicional. Estos «canales laterales», que incluyen el tiempo de operación, el consumo de recursos, el tiempo de caché y las emisiones de RF, a menudo se pueden usar para extraer material de clave secreta.

La buena noticia es que la mayoría de estos canales solo son explotables cuando el atacante está en proximidad física a un servidor TLS. La mala noticia es que hay condiciones en las que el atacante puede acercarse. El ejemplo más obvio involucra servidores TLS virtualizados en la configuración de la nube, donde un atacante inteligente puede compartir recursos físicos con el dispositivo de destino.

Una segunda clase de ataque utiliza información de temporización remota para recuperar lentamente una clave RSA. Estos ataques se pueden desactivar a través de contramedidas como el cegamiento RSA, aunque de manera divertida, algunos coprocesadores de hardware «seguros» pueden desactivar estas contramedidas de forma predeterminada. Al menos, esto hace que el hardware sea vulnerable a los ataques de un usuario local, e incluso podría facilitar la recuperación remota de claves RSA.

Generadores de números aleatorios débiles. Incluso si está utilizando sólidos conjuntos de cifrado de Secreto Directo Perfecto, la seguridad de TLS depende fundamentalmente de la disponibilidad de números aleatorios impredecibles. No por casualidad, la manipulación de los estándares de generadores de números aleatorios parece haber sido un enfoque particular de los esfuerzos de la NSA.

Los números aleatorios son críticos para varios elementos en TLS, pero son particularmente importantes en tres lugares:

  1. Del lado del cliente, durante el apretón de manos de RSA. El RNG se utiliza para generar el secreto pre-maestro RSA y el relleno de cifrado. Si el atacante puede predecir la salida de este generador, posteriormente puede descifrar toda la sesión. Irónicamente, un fallo del RNG del servidor es mucho menos devastador para el apretón de manos RSA.*
  2. En el lado del cliente o del servidor, durante los apretones de manos Diffie-Hellman. Dado que Diffie-Hellman requiere una contribución de cada lado de la conexión, un RNG predecible en cada lado hace que la sesión sea completamente transparente.
  3. Durante la generación de claves a largo plazo, particularmente de claves RSA. Si esto pasa, estás jodido.

Y no necesitas ser tan sofisticado para debilitar un generador de números aleatorios. Estos generadores ya son sorprendentemente frágiles, y es terriblemente difícil de detectar cuando uno está roto. Los mantenedores de Debian hicieron este punto maravillosamente en 2008, cuando una limpieza de código errante redujo la entropía efectiva de OpenSSL a solo 16 bits. De hecho, los RNG son tan vulnerables que el desafío aquí no es debilitar el RNG, cualquier idiota con un teclado puede hacerlo, lo hace sin hacer que la implementación sea trivialmente vulnerable para todos los demás.

La buena noticia es que es relativamente fácil manipular una implementación SSL para cifrar y exfiltrar la semilla RNG actual. Esto todavía requiere que alguien altere físicamente la biblioteca, o instale un exploit persistente, pero se puede hacer inteligentemente sin siquiera agregar mucho código nuevo al código OpenSSL existente. (El amor de OpenSSL por los punteros de función hace que sea particularmente fácil manipular estas cosas.)

Si la manipulación no es su estilo, ¿por qué no poner la puerta trasera a la vista de todos? Ese es el enfoque que tomó la NSA con el RNG Dual_EC, estandarizado por el NIST en la Publicación Especial 800-90. Hay pruebas convincentes de que la NSA diseñó deliberadamente este generador con una puerta trasera, una que les permite romper cualquier conexión TLS/SSL realizada con él. Dado que el generador es (era) el predeterminado en la biblioteca BSAFE de RSA, debe esperar que todas las conexiones TLS realizadas con ese software se vean potencialmente comprometidas.

Y ni siquiera he mencionado los planes de Intel para reemplazar el RNG del núcleo Linux con su propio RNG de hardware.

Debilidades esotéricas en los sistemas de SLP. Muchos servidores web, incluidos Google y Facebook, ahora usan conjuntos de cifrado de secreto Directo Perfecto como Diffie-Hellman efímero (DHE y ECDHE). En teoría, estos conjuntos de cifrado proporcionan lo mejor de todos los mundos posibles: las claves persisten durante una sesión y luego desaparecen una vez que se termina la conexión. Si bien esto no lo salva de problemas de RNG, hace que el robo de llaves sea mucho más difícil.

Los conjuntos de cifrado PFS son algo bueno, pero una variedad de problemas sutiles pueden dificultar su estilo. Por un lado, el mecanismo de reanudación de la sesión puede ser meticuloso: las claves de sesión deben almacenarse localmente o cifrarse y entregarse a los usuarios en forma de tickets de sesión. Desafortunadamente, el uso de tickets de sesión disminuye un poco la «perfección» de los sistemas PFS, ya que las claves utilizadas para cifrar los tickets ahora representan una debilidad importante en el sistema. Además, ni siquiera puede mantenerlos internos en un servidor, ya que deben compartirse entre todos los servidores front-end de un sitio. En resumen, parecen una especie de pesadilla.

Un área de preocupación final es la validación de los parámetros Diffie-Hellman. El diseño SSL actual asume que los grupos DH siempre son generados honestamente por el servidor. Pero una implementación maliciosa puede violar esta suposición y usar parámetros incorrectos, lo que permite la escucha de terceros. Esto parece una vía bastante improbable para permitir la vigilancia, pero demuestra lo delicados que son estos sistemas.

El Espectro del Sombrero de papel de aluminio

Me voy a referir al siguiente lote de ataques como vulnerabilidades de ‘sombrero de papel de aluminio’. Donde todos los números anteriores aprovechan técnicas bien conocidas, cada una de las siguientes propuestas requiere técnicas criptoanalíticas totalmente nuevas. Todo lo cual es una forma de decir que la siguiente sección es pura especulación. Es divertido especular, por supuesto. Pero requiere que asumamos hechos que no están en evidencia. Además, tenemos que ser un poco cuidadosos sobre dónde paramos.

Así que de aquí en adelante esencialmente estamos llevando a cabo un experimento mental. Imaginemos que la NSA tiene una capacidad pasiva de ruptura de SSL; y además, que no se basa en los trucos de la sección anterior. ¿Qué queda?

La siguiente lista comienza con las teorías más «probables» y trabaja hacia los verdaderamente locos.

Romper claves RSA. Hay un rumor persistente en nuestro campo de que la NSA está descifrando claves RSA de 1024 bits. Es dudoso que este rumor provenga de un conocimiento real de las operaciones de la NSA. Lo más probable es que esté impulsado por el hecho de que descifrar claves de 1024 bits es altamente factible para una organización con recursos de la NSA.

¿Qué tan factible? Varios investigadores creíbles han intentado responder a esta pregunta, y resulta que el costo es más bajo de lo que crees. En 2003, Shamir y Tromer calcularon 10 millones de dólares para una máquina especialmente diseñada que podría tener en cuenta una llave de 1024 bits por año. En 2013, Tromer redujo esos números a aproximadamente 1 millón de dólares, teniendo en cuenta los avances de hardware. Y podría ser significativamente menor. Esto es cambio de bolsillo para la NSA.

En líneas similares, Bernstein, Heninger y Lange examinaron la viabilidad de craquear RSA utilizando redes distribuidas de PC estándar. Sus resultados son bastante inquietantes: en principio, un clúster del tamaño de la botnet Conficker de la vida real podría provocar una violencia grave contra las claves de 1024 bits.

Dado todo esto, podría preguntarse por qué esta posibilidad está incluso en la categoría ‘sombrero de papel de aluminio’. La respuesta simple es: porque en realidad nadie lo ha hecho. Eso significa que es al menos concebible que las estimaciones anteriores sean dramáticamente demasiado altas, o incluso demasiado bajas. Además, las llaves RSA-1024 se están eliminando rápidamente. Descifrar claves de 2048 bits requeriría avances matemáticos significativos, llevándonos mucho más profundo en el sombrero de papel de aluminio.**

Craqueo RC4. En papel, TLS admite una variedad de algoritmos de cifrado sólidos. En la práctica, alrededor de la mitad de todo el tráfico TLS está asegurado con el viejo y crujiente cifrado RC4. Y esto debería preocuparle, porque RC4 está empezando a mostrar su edad. De hecho, como se usa en TLS, ya es vulnerable a ataques prácticos (límite). Por lo tanto, parece un buen candidato para un verdadero avance criptoanalítico por parte de la NSA.

Desafortunadamente, el problema con esta teoría es que simplemente no sabemos de ningún ataque que le permita a la NSA romper el RC4 de manera útil. Las técnicas conocidas requieren que un atacante recopile miles o millones de textos cifrados que (a) estén cifrados con claves relacionadas (como en WEP) o (b) contengan el mismo texto sin formato. El ataque más conocido contra TLS toma la última forma: requiere que la víctima establezca miles de millones de sesiones, e incluso entonces solo recupera elementos de texto plano fijos como cookies o contraseñas.

El contraargumento es que la comunidad de investigadores públicos no ha estado pensando mucho en RC4 durante la última década — en parte porque pensamos que estaba tan roto que la gente había dejado de usarlo (¡oops! Si hubiéramos estado centrando toda nuestra atención en él (o mejor, la atención de la NSA), quién sabe lo que tendríamos hoy.

Si me dijeras que la NSA tiene una capacidad criptoanalítica verdaderamente nueva, estaría de acuerdo con Jake y señalaría con el dedo a RC4. Sobre todo porque las alternativas son mucho más aterradoras.

Nuevos ataques de canal lateral. En su mayor parte, los ataques de sincronización remota parecen haber sido eliminados por la implementación de contramedidas como el cegamiento RSA, que confunden el tiempo al multiplicar un factor de cegamiento aleatorio en cada texto cifrado antes del descifrado. En teoría, esto debería hacer que la información sobre el tiempo sea esencialmente inútil. En la práctica, muchas implementaciones de TLS implementan compromisos en el código cegador que podrían resucitar estos ataques, cosas como cuadrar un factor cegador entre operaciones de descifrado, en lugar de generar uno nuevo cada vez. Es poco probable que haya ataques aquí, pero quién sabe.

Cosas tontas. Tal vez la NSA tiene algo realmente increíble bajo la manga. El problema de abrir esta caja de Pandora es que es muy difícil volver a cerrarla. ¿Jerry Solinas realmente cocinó las curvas P del NIST para apoyar un nuevo ataque increíble (que la NSA conocía a finales de la década de 1990, pero aún no lo hemos descubierto)? ¿La NSA tiene una supercomputadora gigante llamada TRANSLTR que puede forzar brutalmente cualquier criptosistema? ¿Hay una computadora cuántica gigante en el anexo de Amistad de la ICM? Para obtener respuestas a estas preguntas, también puede sacudir la Bola Mágica 8, porque no tengo ni idea.

Conclusión

No sabemos ni podemos saber la respuesta a estas cosas, y honestamente te volverá loco si empiezas a pensar en ello. Todo lo que realmente podemos hacer es tomar la palabra de la NSA/GCHQ cuando nos dicen que estas capacidades son «extremadamente frágiles». Al menos eso debería darnos esperanza.

La pregunta ahora es si podemos adivinar lo suficientemente bien como para convertir esa fragilidad de una advertencia en una promesa.
Notas:

* Un fallo del RNG del servidor podría dar lugar a algunos valores predecibles, como el ServerRandom y los ID de sesión. Un atacante que puede predecir estos valores puede ejecutar ataques activos contra el protocolo, pero, al menos en el cifrado RSA, no admite compromiso pasivo.

** A pesar de que se están eliminando las claves RSA de 1024 bits, muchos servidores todavía usan 1024 bits para Diffie-Hellman (principalmente por razones de eficiencia). Los ataques a estas claves son similares a los que se usan contra RSA, sin embargo, la principal diferencia es que se generan nuevas claves «efímeras» Diffie — Hellman para cada nueva conexión. Romper grandes cantidades de tráfico parece bastante costoso.

Deja una respuesta

Tu dirección de correo electrónico no será publicada.