Al mencionar la palabra «criptografía», algunos recuerdan su contraseña de WiFi, el candado verde junto a la dirección de su sitio web favorito y lo difícil que es acceder al correo ajeno. Otros piensan en la serie de vulnerabilidades de los últimos años con acrónimos que hablan por sí mismos (DROWN, FREAK, POODLE…), logotipos llamativos y el aviso de actualizar urgentemente el navegador.

La criptografía abarca todo esto, pero su esencia radica en algo diferente. La esencia está en la delgada línea entre lo simple y lo complejo. Algunas cosas son fáciles de hacer, pero difíciles de revertir: por ejemplo, romper un huevo. Otras son fáciles de hacer, pero difíciles de revertir cuando falta una pequeña parte esencial: como abrir una puerta cerrada cuando la «parte esencial» es la llave. La criptografía estudia estas situaciones y las formas de su uso práctico.

En los últimos años, la colección de ataques criptográficos se ha transformado en un zoológico de logotipos llamativos, llenos de fórmulas de artículos científicos, y ha generado una sensación general de desasosiego, como si todo estuviera roto. Sin embargo, muchas de las ataques se basan en algunos principios comunes, y las interminables páginas de fórmulas a menudo se reducen a ideas fáciles de entender.

En esta serie de artículos, revisaremos diferentes tipos de ataques criptográficos, centrándonos en los principios fundamentales. En términos generales y no necesariamente en este orden, pero abordaremos lo siguiente:

Estrategias básicas: fuerza bruta, análisis de frecuencia, interpolación, degradación y protocolos cruzados.
Vulnerabilidades «de marca»: FREAK, CRIME, POODLE, DROWN, Logjam.
Estrategias avanzadas: ataques de oráculo (ataque de Vodené, ataque de Kelsey); método de encuentro a medio camino (meet-in-the-middle), ataque de cumpleaños, sesgo estadístico (análisis criptográfico diferencial, análisis criptográfico integral, etc.).
Ataques por canales auxiliares y sus parientes cercanos, métodos de análisis de fallos.
Ataques a la criptografía de clave pública: raíz cúbica, broadcast, mensaje relacionado, ataque de Coppersmith, algoritmo de Polignac-Hellman, tamiz numérico, ataque de Wiener, ataque de Bleichenbacher.

Este artículo en particular cubre el material mencionado hasta el ataque de Kelsey.

Estrategias básicas

Los siguientes ataques son simples en el sentido de que se pueden explicar prácticamente sin detalles técnicos. Explicaremos cada tipo de ataque en los términos más simples, sin profundizar en ejemplos complejos o usos avanzados.

Algunos de estos ataques han perdido relevancia y no se han aplicado en muchos años. Otros son veteranos, ya que todavía acechan regularmente a desarrolladores desprevenidos de criptosistemas en el siglo XXI. Se puede considerar que la era de la criptografía moderna comenzó con la aparición de IBM DES, el primer cifrado que resistió todos los ataques de esta lista.

Fuerza bruta simple

El esquema de cifrado consta de dos partes: 1) una función de cifrado que toma un mensaje (texto en claro) junto con una clave y luego crea un mensaje cifrado (texto cifrado); 2) una función de descifrado que toma el texto cifrado y la clave y genera el texto en claro. Tanto el cifrado como el descifrado deben ser fácilmente computables con la clave, y difíciles sin ella.

Supongamos que vemos el texto cifrado y tratamos de descifrarlo sin ninguna información adicional (esto se llama ataque de "solo texto cifrado"). Si de alguna manera encontramos la clave correcta, podemos verificar fácilmente que es realmente correcta si el resultado es un mensaje razonable.

Tenga en cuenta que hay dos suposiciones implícitas aquí. Primero, que sabemos cómo realizar el descifrado, es decir, cómo funciona el sistema criptográfico. Esta es una suposición estándar al discutir sobre criptografía. Ocultar los detalles de la implementación del cifrado de los atacantes puede parecer una medida de seguridad adicional, pero en cuanto el atacante descubre esos detalles, esta seguridad adicional se pierde de manera imperceptible e irreversible. Así es el principio de Kerckhoffs: la captura del sistema por el enemigo no debe causar inconvenientes.

En segundo lugar, suponemos que la clave correcta es la única que dará lugar a un descifrado razonable. Esta también es una suposición razonable; se cumple si el texto cifrado es mucho más largo que la clave y es legible. Por lo general, es así en el mundo real, excepto por claves gigantescas e imprácticas o u otras maniobras que es mejor dejar de lado (si no le gusta que hemos pasado por alto las explicaciones, consulte el teorema 3.8 aquí).

Dado lo anterior, surge una estrategia: comprobar cada clave posible. Esto se llama fuerza bruta, y este tipo de ataque funciona garantizado contra todos los cifrados prácticos — al final. Por ejemplo, la fuerza bruta es suficiente para romper el cifrado César, un antiguo cifrado donde la clave es una letra del alfabeto, lo que implica un poco más de 20 claves posibles.

Desafortunadamente para los criptoanalistas, aumentar el tamaño de la clave protege bien contra la fuerza bruta. A medida que aumenta el tamaño de la clave, el número de claves posibles aumenta exponencialmente. Con los tamaños modernos de clave, la fuerza bruta simple es completamente poco práctica. Para entender lo que queremos decir, tomemos la supercomputadora más rápida conocida a mediados de 2019: Summit de IBM, con un rendimiento máximo de aproximadamente 10^17 operaciones por segundo. Hoy, la longitud típica de la clave es de 128 bits, lo que significa que hay 2^128 combinaciones posibles. Para probar todas las claves, la supercomputadora Summit necesitaría un tiempo que es aproximadamente 7800 veces la edad del universo.

¿Deberíamos considerar la fuerza bruta un fenómeno histórico? En absoluto: es un ingrediente necesario en el recetario de criptoanálisis. Rara vez se encuentran cifrados tan débiles que se puedan romper solo con un ataque inteligente, sin el uso de fuerza de alguna manera. Muchos ataques exitosos utilizan primero un método algorítmico para debilitar el cifrado objetivo y luego lanzan la fuerza bruta.

Análisis de frecuencia

La mayoría de los textos no son jerigonza. Por ejemplo, en textos en inglés hay muchas letras ‘e’ y artículos ‘the’; en archivos binarios, hay muchos bytes nulos como relleno entre fragmentos de información. El análisis de frecuencia es cualquier ataque que utiliza este hecho.

Un ejemplo canónico de un cifrado vulnerable a este ataque es un simple cifrado por sustitución. En este cifrado, la clave es una tabla que reemplaza todas las letras. Por ejemplo, ‘g’ se reemplaza por ‘h’, ‘o’ por ‘j’, por lo que la palabra ‘go’ se convierte en ‘hj’. Este cifrado es difícil de romper solo con fuerza bruta, ya que hay muchas tablas de sustitución posibles. Si le interesa la matemática, la longitud efectiva de la clave es de aproximadamente 88 bits: esto
. Pero el análisis de frecuencia generalmente maneja la tarea rápidamente.

Consideremos el siguiente texto cifrado, procesado mediante un cifrado de sustitución simple:

XDYLY ALY UGLY XDWNKE WN DYAJYN ANF YALXD DGLAXWG XDAN ALY FLYAUX GR WN OGQL ZDWBGEGZDO

Dado que Y aparece con frecuencia, incluida al final de muchas palabras, podemos suponer preliminarmente que esta es la letra e:

XDeLe ALe UGLe XDWNKE WN DeAJeN ANF eALXD DGLAXWG XDAN ALe FLeAUX GR WN OGQL ZDWBGEGZDO

El par XD se repite al comienzo de varias palabras. En particular, la combinación XDeLe sugiere claramente la palabra these o there, así que continuamos:

theLe ALe UGLe thWNKE WN heAJeN ANF eALth DGLAtWG thAN ALe FLeAUt GR WN OGQL ZDWBGEGZDO

A continuación, supongamos que L corresponde a r, A — a y así sucesivamente. Es probable que haya que hacer varios intentos, pero en comparación con un ataque de fuerza bruta completo, este enfoque recupera el texto original en el menor tiempo posible:

there are more things in heaven and earth horatio than are dreamt of in your philosophy

Para algunos, resolver tales "criptogramas" es un pasatiempo fascinante.

La idea del análisis de frecuencia es más fundamental de lo que parece a simple vista. Y se aplica a cifrados mucho más complejos. A lo largo de la historia, diversas construcciones de cifrados han intentado contrarrestar este tipo de ataque mediante una 'sustitución polialfabética'. En este proceso de cifrado, la tabla de sustitución de letras se modifica de maneras complejas pero predecibles, que dependen de la clave. Todos estos cifrados se consideraron difíciles de romper en su tiempo; y aun así, el modesto análisis de frecuencia finalmente los superó.

El cifrado poli-alfabético más ambicioso de la historia y, probablemente, el más conocido, fue el cifrado 'Enigma' durante la Segunda Guerra Mundial. Era relativamente complejo en comparación con sus predecesores, pero tras un largo y arduo trabajo, los criptoanalistas británicos lo rompieron mediante el análisis de frecuencia. Por supuesto, no pudieron desarrollar un ataque elegante como el mostrado arriba; tuvieron que comparar pares conocidos de texto claro y cifrado (el llamado 'ataque basado en texto claro') e incluso inducir a los usuarios de 'Enigma' a cifrar ciertos mensajes para analizar el resultado ('ataque basado en texto claro seleccionado'). Pero esto no alivió la suerte de los ejércitos derrotados enemigos y de los submarinos hundidos.

Después de este triunfo, el análisis de frecuencias desapareció de la historia de la criptoanálisis. Los cifrados de la era digital moderna están diseñados para trabajar con bits, no con letras. Lo que es aún más importante, estos cifrados fueron concebidos con la oscura comprensión de lo que más tarde se conoció como la ley de Schneier: cualquiera puede crear un algoritmo de cifrado que no pueda romper por sí mismo. No es suficiente que un sistema de cifrado parezca complejo: para demostrar su valía, debe pasar por un implacable escrutinio de seguridad por parte de numerosos criptoanalistas que harán todo lo posible por desbaratar el cifrado.

Cálculos previos

Tomemos la hipotética ciudad de Prekom Heights con una población de 200,000 personas. En cada hogar de la ciudad hay bienes valiosos que promedian $30,000, pero no más de $50,000. El mercado de la seguridad en Prekom ha sido monopolizado por la empresa ACME Industries, que fabrica las legendarias cerraduras de puerta de clase Coyote ™. Según el análisis de expertos, solo una máquina hipotética muy complicada puede romper una cerradura de clase Coyote, cuya creación requiere alrededor de cinco años y una inversión de $50,000. ¿Está la ciudad a salvo?

Probablemente no. Al final, aparecerá un delincuente lo suficientemente ambicioso. Pensará así: "Sí, asumiré grandes gastos iniciales. Cinco años de espera paciente, y $50,000. Pero al final del trabajo, tendré acceso a t toda la riqueza de esta ciudad. Si juego bien mis cartas, esta inversión se multiplicará con creces".

De manera similar en criptografía. Los ataques contra un cifrado específico son sometidos a un análisis implacable de costos y beneficios. Si la relación es favorable, no se llevará a cabo un ataque. Pero los ataques que van directamente contra muchas víctimas potenciales casi siempre valen la pena, y en este caso, la mejor práctica de diseño es suponer que comenzaron desde el primer día. Tenemos, en esencia, una versión criptográfica de la ley de Murphy: "Cualquier cosa que realmente pueda romper el sistema, romperá el sistema".

El ejemplo más simple de un criptosistema vulnerable a ataques de cálculos previos es un cifrado con un algoritmo constante sin uso de clave. Así sucedió en el caso de el cifrado César, que simplemente desplaza cada letra del alfabeto tres posiciones hacia adelante (la tabla es cíclica, por lo que la última letra se cifra con la tercera). Aquí se manifiesta nuevamente el principio de Kerckhoffs: una vez que el sistema es hackeado, está hackeado para siempre.

El concepto es simple. Incluso un desarrollador principiante de criptosistemas probablemente será consciente de la amenaza y se preparará en consecuencia. Si observamos la evolución de la criptografía, tales ataques eran irrelevantes para la mayoría de los cifrados, desde las primeras versiones mejoradas del cifrado César hasta el declive de los cifrados polialfabéticos. Tales ataques solo regresaron con el advenimiento de la era moderna de la criptografía.

Este regreso se debe a dos factores. Primero, finalmente aparecieron criptosistemas lo suficientemente complejos, donde la posibilidad de explotación tras un hackeo no era obvia. Segundo, la criptografía se ha difundido tanto que millones de no profesionales toman decisiones cada día sobre dónde y qué partes de la criptografía reutilizar. Pasó un tiempo antes de que los expertos se dieran cuenta de los riesgos emergentes y levantaran la alarma.

Recuerde el ataque de precomputación: al final del artículo revisaremos dos ejemplos criptográficos de la vida real donde desempeñó un papel importante.

Interpolación

Ante ustedes, el famoso detective Sherlock Holmes, realizando un ataque de interpolación sobre el desafortunado Dr. Watson:

Inmediatamente deduje que venía de Afganistán… Mi línea de pensamiento fue la siguiente: ‘Este hombre por su tipo es médico, pero su porte es militar. Entonces, es un médico militar. Acaba de llegar de los trópicos: su rostro es moreno, pero ese no es el tono natural de su piel, ya que sus muñecas son mucho más claras. Su rostro está demacrado, evidentemente ha sufrido y padecido enfermedades. Ha sido herido en el brazo izquierdo: lo sostiene inmóvil y un poco antinatural. ¿Dónde podría un médico militar inglés haber sufrido privaciones y recibir una herida en los trópicos? Por supuesto, en Afganistán’. Todo el proceso de pensamiento no tomó más de un segundo. Y entonces dije que venía de Afganistán, y usted se sorprendió.

De cada colmena, Holmes podía extraer muy poca información. Solo podía llegar a su conclusión al considerar todas juntas. Así funciona el ataque de interpolación, investigando pares conocidos de texto claro y texto cifrado obtenidos mediante la aplicación de la misma clave. De cada par se extraen observaciones individuales que permiten hacer una conclusión general sobre la clave. Todas estas inferencias son borrosas y parecen inútiles, hasta que de repente alcanzan una masa crítica y conducen a una única conclusión posible: por increíble que parezca, debe ser verdadera. Después de esto, o se revela la clave, o el proceso de descifrado se vuelve tan perfeccionado que se puede replicar.

Ilustremos con un ejemplo sencillo cómo funciona la interpolación. Supongamos que queremos leer el diario personal de nuestro enemigo, Bob. Él cifra cada número en su diario con un simple sistema criptográfico que conoció a través de un anuncio en la revista «Burla sobre Criptografía». El sistema funciona de la siguiente manera: Bob elige dos números que le gustan: y . A partir de aquí, para cifrar cualquier número , él calcula . Por ejemplo, si Bob eligió y , entonces el dígito se cifrará como .

Supongamos que el 28 de diciembre notamos que Bob está escribiendo algo en su diario. Cuando termine, lo tomamos disimuladamente y miramos la última entrada:

Fecha: 235/520
Querido diario,
Hoy fue un buen día. En 64 días tengo una cita con Alicia, que vive en el apartamento 843. Realmente creo que ella podría ser 26!

Dado que estamos muy decididos a seguir a Bob en su cita (en este escenario, tenemos 15 años), es fundamental conocer la fecha y la dirección de Alicia. Afortunadamente, notamos que el sistema criptográfico de Bob es vulnerable a un ataque de interpolación. Podríamos no conocer y , pero sabemos la fecha de hoy, así que tenemos dos pares de "texto claro - texto cifrado". Específicamente, sabemos que se cifra en , y — en . Lo que anotaremos:

Dado que tenemos 15 años, ya sabemos sobre el sistema de dos ecuaciones con dos incógnitas, lo cual es suficiente en esta situación para resolver. y sin problemas. Cada par de «texto claro-texto cifrado» impone una restricción a la clave de Bob, y con dos restricciones juntas es suficiente para restaurar completamente la clave. En nuestro ejemplo, la respuesta y (al , así que 26 en el diario corresponde a la palabra ‘el que’, es decir, «el mismo» — nota del traductor.

Los ataques de interpolación, por supuesto, no se limitan a ejemplos tan simples. Cada criptosistema que se reduce a un objeto matemático bien entendible y una lista de parámetros está en riesgo de ataques de interpolación: cuanto más claro sea el objeto, mayor será el riesgo.

Los principiantes a menudo se quejan de que la criptografía es «el arte de diseñar cosas lo más feas posible». Probablemente, mucho tiene que ver con los ataques de interpolación. Bob puede optar por utilizar un diseño matemático elegante o por mantener en secreto la cita con Alicia, pero desafortunadamente, generalmente no se puede obtener ambos. Esto se volverá extremadamente claro cuando finalmente avancemos al tema de la criptografía de clave pública.

Cruce de protocolos/descenso

En la película 'La ilusión del engaño' (2013), un grupo de ilusionistas intenta engañar para despojar de toda su fortuna al corrupto magnate de seguros Arthur Tressler. Para acceder a la cuenta bancaria de Arthur, los ilusionistas deben presentar su nombre de usuario y contraseña, o hacer que aparezca en persona en el banco y participar en el esquema.

Ambas opciones son muy difíciles; los chicos están acostumbrados a actuar en el escenario, no a participar en operaciones de inteligencia. Por lo tanto, eligen una tercera opción posible: su cómplice llama al banco y se hace pasar por Arthur. El banco hace algunas preguntas para verificar la identidad, como el nombre del tío y el nombre de la primera mascota; nuestros héroes logran obtener fácilmente esta información de Arthur mediante astuta ingeniería social.. A partir de este momento, una excelente seguridad de contraseña ya no importa.

(Según una leyenda urbana que hemos verificado y confirmado personalmente, el criptógrafo Eli Biham se encontró una vez con un cajero de banco que insistía en establecer una pregunta secreta. Cuando el cajero preguntó el nombre de la abuela por parte de madre, Biham comenzó a dictar: «Mayúscula X, minúscula y, tres...».

De la misma manera en la criptografía, si se utilizan paralelamente dos protocolos criptográficos para proteger un mismo activo, y uno de ellos es significativamente más débil que el otro, el sistema final se vuelve vulnerable a un ataque cruzado, donde se ataca el protocolo más débil para llegar al objetivo sin tocar el más fuerte.

En algunos casos complejos, no basta con simplemente conectarse al servidor a través de un protocolo más débil, sino que se requiere la participación involuntaria de un cliente legítimo. Esto se puede organizar mediante lo que se llama un ataque de degradación (downgrade). Para entender este ataque, supongamos que nuestros ilusionistas tienen un desafío más complicado que en la película. Supongamos que el empleado del banco (el cajero) y Arthur enfrentaron circunstancias imprevistas, dando lugar a un diálogo como el siguiente:

Pirata: ¿Hola? Soy Arthur Tresler. Quisiera restablecer mi contraseña.
Cajero: Perfecto. Por favor, mire en su libro personal de códigos secretos, página 28, palabra 3. Todos los siguientes mensajes serán cifrados utilizando esta palabra como clave. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…
Pirata: Oye, espera, espera. ¿Es realmente necesario? ¿No podemos simplemente hablar como personas normales?
Cajero: No te recomendaría hacer eso.
Pirata: Solo... escucha, he tenido un día horrible, ¿de acuerdo? Soy un cliente VIP y no estoy de humor para hurgar en esos estúpidos libros de códigos.
Cajero: Está bien. Si insistes, señor Tresler. ¿Qué deseas?
Pirata: Por favor, quisiera transferir todo mi dinero al Fondo Nacional de Víctimas de Arthur Tresler.
(Pausa).
Cajero: Entiendo. Por favor, indíque su PIN para grandes transacciones.
Pirata: ¿Mi qué?
Cajero: Por su solicitud personal, las transacciones de ese tamaño requieren la introducción de un PIN para grandes transacciones. Este código le fue proporcionado al abrir la cuenta.
Pirata:… Lo perdí. ¿Es realmente necesario? ¿No puedes simplemente aprobar la transacción?
Cajero: No. Lo siento, señor Tresler. De nuevo, es una medida de seguridad que usted solicitó. Si lo desea, podemos enviar un nuevo PIN a su buzón.

Nuestros héroes posponen la operación. Escuchan varias transacciones importantes de Tresler, esperando escuchar el PIN; pero cada vez la conversación se convierte en un galimatías cifrado antes de que suene algo interesante. Finalmente, un buen día ponen en marcha el plan. Esperan pacientemente el momento en que Tresler tiene que hacer una gran transacción por teléfono, se conecta a la línea y luego…

Tresler: Hola. Me gustaría realizar una transacción remota, por favor.
Cajero: Excelente. Por favor, mire su libro personal de códigos secretos, página…
(El hacker presiona un botón; la voz del cajero se convierte en un ruido ininteligible).
Cajero: — #@$#@$#*@$$@#* se cifrará con esta palabra como clave. AAAYRR PLRQRZ MMNJK LOJBAN…
Tresler: Disculpe, no entendí muy bien. ¿Puede repetir? ¿En qué página? ¿Qué palabra?
Cajero: Es la página @#$@#*$)#*#@()#@$(#@*$(#@*.
Tresler: ¿Qué?
Cajero: La palabra número veinte @$#@$#%#$.
Tresler: ¡En serio! ¡Ya basta! Tu protocolo de seguridad es un circo. Sé que puedes simplemente hablar normalmente conmigo.
Cajero: No recomendaría…
Tresler: Y yo no te recomendaría que desperdicies mi tiempo. No quiero volver a oír de esto hasta que arreglen los problemas con su línea telefónica. ¿Podemos hacer este trato o no?
Cajero:… sí. Está bien. ¿Qué desea?
Tresler: Me gustaría transferir $20,000 a la empresa Lord Business Investments, número de cuenta…
Cajero: Un momento, por favor. Es una gran transacción. Por favor, indique su PIN para transacciones grandes.
Tresler: ¿Qué? Ah, cierto. 1234.

Aquí hay un ataque de disminución. Un protocolo más débil de «simplemente hable directamente» estaba destinado a ser opción un último recurso. Y aun así estamos aquí.

Puedes preguntarte quién en su sano juicio diseñaría un sistema real del tipo «seguro, hasta que se pida lo contrario», como el descrito arriba. Pero así como un banco ficticio corre el riesgo de mantener clientes que no aman la criptografía, los sistemas en general a menudo sucumben a requisitos que son indiferentes o incluso abiertamente hostiles a la seguridad.

La historia del protocolo SSLv2 es un claro ejemplo de esto, sucedió en 1995. El gobierno de EE. UU. había comenzado a considerar la criptografía como un arma y buscaba mantenerla alejada de enemigos internos y externos. Fragmentos de código se aprobaban individualmente para su exportación desde EE. UU., a menudo bajo la condición de debilitar intencionadamente el algoritmo. A la empresa Netscape, creadora del navegador más popular, Netscape Navigator, se le otorgó permiso para SSLv2 solo con una clave RSA de 512 bits inicialmente vulnerable (y 40 bits para RC4).

Para finales de milenio, las reglas se habían flexibilizado y el acceso a cifrados modernos se volvió bastante común. No obstante, tanto clientes como servidores mantuvieron durante años la criptografía 'exportación' debilitada debido a la misma inercia que sostiene cualquier sistema obsoleto. Los clientes creían que podrían encontrarse con un servidor que no admitiera nada más. Los servidores hacían lo mismo. Claro está, el protocolo SSL establece que los clientes y servidores nunca deben usar un protocolo débil cuando hay uno mejor disponible. Pero la misma premisa se aplicó a Tressler y su banco.

Esta teoría se aplicó en dos ataques notables que sacudieron la seguridad del protocolo SSL en 2015, ambos descubiertos por investigadores de Microsoft y INRIA. Primero, en febrero se divulgaron los detalles del ataque FREAK, y tres meses después, otro ataque similar llamado Logjam, que discutiremos más a fondo cuando abordemos ataques a la criptografía de clave pública.

Vulnerabilidad FREAK también conocido como 'Smack TLS', se manifestó cuando los investigadores analizaron implementaciones de cliente/servidor TLS y encontraron un error curioso. En estas implementaciones, si el cliente ni siquiera solicita usar criptografía de exportación débil, pero el servidor aún responde con esas claves, el cliente dice 'Está bien' y pasa a un conjunto de cifrados débiles.

En ese momento, todos consideraban que la criptografía de exportación estaba desactualizada y prohibida para su uso, por lo que el ataque resultó ser un verdadero shock, afectando a muchos dominios importantes, incluidos los sitios de la Casa Blanca, el Servicio de Impuestos Internos de EE. UU. y la NSA. Peor aún, resultó que muchos servidores vulnerables optimizaron su rendimiento reutilizando las mismas claves, en lugar de crear nuevas para cada sesión. Esto permitió realizar un ataque con precomputación después de disminuir el protocolo: quebrar una clave seguía siendo relativamente costoso (100 dólares y 12 horas en el momento de la publicación), pero el costo práctico del ataque a la conexión disminuyó significativamente. Solo necesitas adivinar una vez la clave del servidor para comprometer los cifrados de todas las conexiones subsiguientes desde ese momento.

Y antes de avanzar, es necesario mencionar un ataque avanzado...

Ataque del oráculo

Moxie Marlinspike es más conocido como el padre del criptomensaje multiplataforma Signal; pero personalmente, nos gusta una de sus innovaciones menos conocidas... el principio de la fatalidad criptográfica (Cryptographic Doom Principle). Parafraseando un poco, se puede decir así: "Si un protocolo realiza cualquier operación criptográfica sobre un mensaje de una fuente potencialmente maliciosa y se comporta de manera diferente dependiendo del resultado, está condenado". O en una forma más contundente: "No tomes información del enemigo para procesarla, y si tienes que hacerlo, al menos no muestres el resultado".

Dejemos de lado los desbordamientos de búfer, inyecciones de comandos y similares; ellos quedan fuera del alcance de esta discusión. Romper el "principio de fatalidad" conduce a graves compromisos de la criptografía debido a que el protocolo se comporta exactamente como se esperaba.

Tomemos como ejemplo una construcción ficticia con un cifrado de sustitución vulnerable y luego demostraremos un ataque posible. Aunque ya hemos visto un ataque al cifrado de sustitución mediante el análisis de frecuencia, no es simplemente "otra forma de romper el mismo cifrado". Por el contrario, los ataques del oráculo son una invención mucho más contemporánea, aplicable a muchas situaciones donde el análisis de frecuencia falla, y veremos una demostración de esto en la siguiente sección. Aquí, un cifrado simple se elige solo para hacer el ejemplo más claro.

Así que, Alice y Bob se comunican utilizando un simple cifrado por sustitución, empleando una clave conocida solo por ellos. Son muy estrictos respecto a la longitud de los mensajes: deben tener exactamente 20 caracteres. Por lo tanto, acordaron que si alguien quiere enviar un mensaje más corto, debe añadir algún texto ficticio al final del mensaje para que tenga exactamente 20 caracteres. Tras algo de discusión, decidieron que solo aceptarían los siguientes textos ficticios: a, bb, ccc, dddd y así sucesivamente. De este modo, se conoce el texto ficticio de cualquier longitud necesaria.

Cuando Alice o Bob reciben un mensaje, primero verifican que el mensaje tenga la longitud correcta (20 caracteres) y que el sufijo sea el texto ficticio correcto. Si no es así, responden con un mensaje de error apropiado. Si la longitud del texto y el texto ficticio son correctos, el receptor lee el mensaje en sí y envía una respuesta cifrada.

En el transcurso de un ataque, un atacante se hace pasar por Bob y envía mensajes falsos a Alice. Los mensajes son un completo disparate: el atacante no tiene la clave y, por lo tanto, no puede falsificar un mensaje significativo. Pero dado que el protocolo viola el principio de inevitabilidad, el atacante aún puede atraer a Alice a una trampa, de modo que ella revele información sobre la clave, como se muestra a continuación.

Pirata: PREWF ZHJKL MMMN. LA
Alice: Texto ficticio incorrecto.
Pirata: PREWF ZHJKL MMMN. LB
Alice: Texto ficticio incorrecto.
Pirata: PREWF ZHJKL MMMN. LC
Alice: ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

El atacante no tiene idea de lo que acaba de decir Alice, pero nota que el carácter C debe coincidir con a, dado que Alice aceptó el texto ficticio.

Pirata: REWF ZHJKL MMMN. LAA
Alice: Texto ficticio incorrecto.
Pirata: REWF ZHJKL MMMN. LBB
Alice: Texto ficticio incorrecto.
Después de varios intentos…
Pirata: REWF ZHJKL MMMN. LGG
Alice: Texto ficticio incorrecto.
Pirata: REWF ZHJKL MMMN. LHH
Alice: TLQO JWCRO FQAW SUY LCR C OWQXYJW. IW PWWR TU TCFA CHUYT TLQO JWFCTQUPOLQZ.

Nuevamente, el atacante no tiene idea de lo que acaba de decir Alice, pero nota que H debe coincidir con b, dado que Alice aceptó el texto ficticio.

Y así sucesivamente, hasta que el atacante descubra el significado de cada carácter.

A primera vista, el método se asemeja a un ataque basado en texto plano elegido. Al final, el atacante selecciona los textos cifrados y el servidor los procesa fielmente. La principal diferencia que hace que estos ataques sean viables en el mundo real es que el atacante no necesita acceso a la verdadera desencriptación; una respuesta del servidor basta, incluso una tan inofensiva como "Texto ficticio incorrecto".

Aunque este ataque en particular es educativo, no se debe obsesionarse demasiado con la especificidad del esquema de "texto ficticio", la criptosistema utilizada o la secuencia exacta de mensajes enviados por el atacante. La idea principal es cómo Alice reacciona de manera diferente, según las propiedades del texto plano, y lo hace sin verificar que el texto cifrado correspondiente provenga realmente de una fuente confiable. Así, Alice permite que el atacante extraiga información secreta de sus respuestas.

En este escenario, se puede variar mucho. Los símbolos a los que Alice reacciona, la propia diferencia en su comportamiento, o incluso la criptosistema utilizada. Pero el principio seguirá siendo el mismo, y el ataque en general seguirá siendo viable de una forma u otra. La implementación básica de este ataque ha ayudado a descubrir varios errores de seguridad que pronto examinaremos; pero primero se deben asimilar algunas lecciones teóricas. ¿Cómo se puede utilizar este "escenario de Alice" ficticio en un ataque que podría funcionar en un cifrado moderno real? ¿Es esto posible en teoría?

En 1998, el criptógrafo suizo Daniel Bleichenbacher respondió afirmativamente a esta pregunta. Demostró un ataque de oráculo en un ampliamente utilizado criptosistema de clave pública RSA, utilizando un esquema de mensajes específico. En algunas implementaciones de RSA, el servidor responde con diferentes mensajes de error, dependiendo de si el texto plano se ajusta al esquema o no; esto fue suficiente para llevar a cabo el ataque.

Cuatro años después, en 2002, el criptógrafo francés Serge Vaudenay demostró un ataque de oráculo, casi idéntico al descrito anteriormente en el escenario de Alicia, salvo que en lugar de un cifrado ficticio rompió toda una clase respetable de cifrados modernos que las personas realmente utilizan. En particular, el ataque de Vaudenay se centra en cifrados de longitud de entrada fija ('cifrados por bloques'), cuando se utilizan en el llamado 'modo de cifrado CBC' y con un esquema de relleno popular, en gran medida equivalente al del escenario de Alicia.

También en 2002, el criptógrafo estadounidense John Kelsey, coautor Twofish — propuso varios ataques de oráculo a sistemas que comprimen mensajes y luego los cifran. El más notable entre ellos fue un ataque que utilizó el hecho de que a menudo se puede deducir la longitud original del texto plano a partir de la longitud del texto cifrado. En teoría, esto permite realizar un ataque de oráculo que recupera partes del texto plano original.

A continuación, proporcionamos una descripción más detallada de los ataques de Vaudenay y Kelsey (daremos una descripción más exhaustiva del ataque de Bleichenbacher cuando pasemos a los ataques en criptografía de clave pública). A pesar de todos nuestros esfuerzos, el texto se vuelve algo técnico; por lo tanto, si lo anterior es suficiente para usted, omita las siguientes dos secciones.

Ataque de Vaudenay

Para entender el ataque de Vaudenay, primero es necesario hablar un poco más sobre los cifrados por bloques y los modos de cifrado. Un 'cifrado por bloques' es, como se mencionó, un cifrado que toma una clave y una entrada de longitud fija determinada ('longitud de bloque') y produce un bloque cifrado de la misma longitud. Los cifrados por bloques se utilizan ampliamente y se consideran relativamente seguros. El DES, ahora retirado, que se considera el primer cifrado moderno, era por bloques. Como se mencionó anteriormente, lo mismo es cierto para el AES, que se utiliza ampliamente hoy en día.

Lamentablemente, los cifrados por bloques tienen una debilidad evidente. El tamaño típico del bloque es de 128 bits, o 16 caracteres. Es obvio que la criptografía moderna necesita trabajar con datos de entrada de mayor tamaño, y aquí es donde entran en juego los modos de cifrado. Un modo de cifrado es, en esencia, un truco: es una forma de aplicar un cifrado por bloques, que solo acepta datos de entrada de un tamaño específico, a datos de entrada de longitud arbitraria.

El ataque de Vaudenay está dirigido al popular modo de operación CBC (Cipher Block Chaining, modo de encadenamiento de bloques de cifrado). El ataque considera el cifrado por bloques básico como una caja negra mágica inaccesible y elude por completo su seguridad.

Aquí hay un diagrama que muestra cómo funciona el modo CBC:

El signo más rodeado indica la operación XOR (o exclusivo). Por ejemplo, el segundo bloque de cifrado se obtiene:

Ejecutando la operación XOR en el segundo bloque de texto plano con el primer bloque de texto cifrado.
Cifrando el bloque obtenido con el cifrador por bloques, utilizando la clave.

Dado que CBC utiliza intensivamente la operación binaria XOR, aprovechemos la oportunidad para recordar algunas de sus propiedades:

Idempotencia:
Conmutatividad:
Asociatividad:
Involutividad:
Por bytes: el byte n de = (byte n de ) (byte n de )

Como regla general, estas propiedades implican que si tenemos una ecuación que involucra operaciones XOR y una incógnita, se puede resolver. Por ejemplo, si sabemos que con la incógnita y conocidas y , podemos apoyarnos en las propiedades mencionadas anteriormente para resolver la ecuación para . Aplicando XOR en ambos lados de la ecuación con , obtenemos . Dentro de un momento, todo esto se volverá muy relevante.

Entre nuestro escenario de Alicia y el ataque de Vaudenay hay dos diferencias menores y una diferencia principal. Dos menores:

En el escenario, Alicia esperaba que los textos claros terminaban con los caracteres a, bb, ccc y así sucesivamente. En el ataque de Vaudenay, la víctima en cambio espera que los textos claros terminen con el byte N (es decir, hexadecimal 01 o 02 02, o 03 03 03 y así sucesivamente). Esta es una diferencia puramente cosmética.
En el escenario de Alicia, era fácil decir si recibió el mensaje, a partir de la respuesta "Texto ficticio incorrecto". En el ataque de Vodene se requiere un análisis más profundo y es importante una implementación exacta del lado de la víctima; pero para simplificar, asumamos que este análisis sigue siendo posible.

La principal diferencia:

Dado que no estamos utilizando el mismo sistema de criptografía, la relación entre los bytes del texto cifrado controlados por el atacante y los secretos (clave y texto plano) será, evidentemente, diferente. Por lo tanto, el atacante deberá utilizar una estrategia diferente al crear los cifrados y al interpretar las respuestas del servidor.

Esta es la principal diferencia: el último fragmento del rompecabezas para entender el ataque de Vodene, así que reflexionemos por un momento sobre cómo se puede llevar a cabo un ataque de oráculo en CBC.

Supongamos que tenemos un texto cifrado CBC de 247 bloques y queremos descifrarlo. Podemos enviar mensajes falsos al servidor, como antes se podía enviar mensajes falsos a Alicia. El servidor descifrará los mensajes para nosotros, pero no mostrará la descifración; en su lugar, nuevamente, como en el caso de Alicia, el servidor solo informará un bit de información: si el texto plano tiene un relleno válido o no.

Tenga en cuenta que en el escenario de Alicia teníamos las siguientes relaciones:

$$display$$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key}) = text{plaintext}$$display$$

Llamemos a esto "la ecuación de Alicia". Controlábamos el texto cifrado; el servidor (Alicia) filtraba información difusa sobre el texto plano recibido; y esto nos permitió deducir información sobre el último factor: la clave. Por analogía, si pudiéramos encontrar tal relación para el escenario CBC, podríamos extraer alguna información secreta allí también.

Afortunadamente, existen relaciones que podemos utilizar. Consideremos la salida de la última llamada de descifrado del cifrador de bloques y designemos estos datos como . También designamos bloques de texto plano y bloques de texto cifrado . Mire de nuevo el diagrama de CBC y observe qué se obtiene:

Llamemos a esto "la ecuación CBC".

En el escenario de Alice, al controlar el texto cifrado y observar las filtraciones de información sobre el texto plano correspondiente, pudimos organizar un ataque que recuperó el tercer componente de la ecuación: la clave. En el escenario CBC, también controlamos el texto cifrado y observamos filtraciones de información sobre el texto plano correspondiente. Si la analogía es correcta, podremos obtener información sobre .

Supongamos que realmente hemos recuperado , ¿qué pasa entonces? Bueno, entonces podemos revelar de inmediato todo el último bloque de texto plano (), simplemente ingresando (que tenemos) y
obtenido en la ecuación CBC.

Así que nos sentimos optimistas sobre el plan general del ataque, y es hora de trabajar en los detalles. Prestemos atención a la forma en que el servidor filtra la información sobre el texto plano. En el escenario de Alice, la filtración ocurrió porque Alice solo respondía con el mensaje correcto si $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ terminaba con la cadena a (o bb, y así sucesivamente, pero las posibilidades de que estas condiciones se activaran por casualidad eran muy bajas). Similarmente en CBC, el servidor acepta el relleno si y solo si termina con un hexadecimal 01. Así que intentemos el mismo truco: enviar textos cifrados falsos con nuestros propios valores falsos , hasta que el servidor acepte el relleno.

Cuando el servidor acepta el relleno para uno de nuestros mensajes falsos, significa que:

Ahora usemos la propiedad de byte a byte de XOR:

Conocemos el primer y tercer componente. Y ya hemos visto que esto permite recuperar el componente restante: el último byte de :

Esto también nos da el último byte del bloque final de texto plano a través de la ecuación CBC y la propiedad de byte a byte.

Podríamos detenernos aquí y contentarnos con haber llevado a cabo un ataque contra un cifrado teóricamente resistente. Pero en realidad podemos hacer mucho más: podemos realmente recuperar todo el texto. Esto requiere un truco que no estaba en el escenario original de Alice y que no forma parte de los requisitos obligatorios del ataque del oráculo, pero el método aún vale la pena estudiar.

Para entenderlo, primero observa que como resultado de deducir el valor correcto del último byte Tenemos una nueva capacidad. Ahora, al falsificar textos cifrados, podemos controlar el último byte del texto plano correspondiente. Nuevamente, esto está relacionado con la ecuación CBC y la propiedad byte por byte:

Dado que ahora conocemos el segundo término, podemos usar nuestro control sobre el primero para manipular el tercero. Simplemente lo calculamos:

Antes no podíamos hacer esto porque aún no teníamos el último byte. .

¿Cómo nos ayudará esto? Supongamos que ahora generaremos todos los textos cifrados de tal manera que en los textos planos correspondientes el último byte sea 02. Ahora, el servidor acepta el relleno solo si el texto claro termina en 02 02. Dado que hemos corregido el último byte, esto solo ocurrirá si el penúltimo byte del texto plano también es igual a 02. Continuamos enviando bloques de texto cifrado falsificados, cambiando el penúltimo byte, hasta que el servidor acepte el relleno de uno de ellos. En este momento obtenemos:

Y restauramos el penúltimo byte exactamente como restauramos el último. Continuamos en la misma línea: corregimos los últimos dos bytes del texto plano a 03 03, repetimos este ataque para el tercer byte desde el final y así sucesivamente, hasta que finalmente restauramos completamente .

¿Qué pasa con el resto del texto? Observe que el valor es en realidad $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Podemos poner cualquier otro bloque en lugar de , y el ataque seguirá siendo exitoso. De hecho, podemos pedirle al servidor que haga $inline$text{BLOCK_DECRYPT}$inline$ para cualquier dato. En este punto, el juego ha terminado: podemos descifrar cualquier texto cifrado (vuelva a mirar el diagrama de descifrado de CBC para confirmar esto; y tenga en cuenta que el vector IV es de dominio público).

Este método específico desempeña un papel crucial en el ataque oráculo, que enfrentaremos más adelante.

Ataque de Kelsey

John Kelsey, cercano a nosotros en espíritu, expuso los principios que subyacen en muchos ataques posibles, no solo los detalles específicos de un ataque particular a un cifrado específico. Su artículo de 2002 es un estudio de ataques posibles a datos comprimidos cifrados. ¿Pensaste que no había suficiente información para llevar a cabo un ataque porque los datos fueron comprimidos antes de cifrarse? Resulta que sí.

Este sorprendente resultado se basa en dos principios. En primer lugar, hay una fuerte correlación entre la longitud del texto en claro y la longitud del texto cifrado; para muchos cifrados, una igualdad exacta. En segundo lugar, cuando se lleva a cabo la compresión, también existe una fuerte correlación entre la longitud del mensaje comprimido y el grado de "ruido" del texto en claro, es decir, la proporción de caracteres no repetidos (término técnico: "alta entropía").

Para ver el principio en acción, consideremos dos textos en claro:

Texto en claro 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
Texto en claro 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Supongamos que ambos textos en claro fueron comprimidos y luego cifrados. Obtienes dos textos cifrados resultantes y debes adivinar qué texto cifrado corresponde a qué texto en claro:

Texto cifrado 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA
Texto cifrado 2: DWKJZXYU

La respuesta es clara. Entre los textos en claro, solo el texto en claro 1 podría haberse comprimido a la escasa longitud del segundo texto cifrado. Hemos deducido esto sin saber nada sobre el algoritmo de compresión, la clave de cifrado o incluso el cifrado mismo. Comparado con la jerarquía de posibles ataques criptográficos, esto es una especie de locura.

Kelsey indica además que en ciertas circunstancias inusuales, este principio también se puede utilizar para llevar a cabo un ataque de oráculo. En particular, describe cómo un atacante puede recuperar el texto en claro secreto, si puede hacer que el servidor cifre los datos del formulario (texto en claro, seguido de , mientras controla y puede de alguna manera verificar la longitud del resultado cifrado.

Nuevamente, al igual que en otros ataques de oráculo, tenemos una relación:

Una vez más, controlamos un miembro (), vemos una ligera filtración de información sobre el otro miembro (texto cifrado) y tratamos de recuperar el último (texto en claro). A pesar de la analogía, esta es una situación algo inusual en comparación con otros ataques de oráculo que hemos visto.

Para ilustrar cómo podría funcionar tal ataque, utilizamos un esquema de compresión ficticio que acabamos de inventar: TOYZIP. Busca cadenas de texto que ya han aparecido anteriormente en el texto y las reemplaza con tres bytes de relleno que indican dónde encontrar una instancia anterior de la cadena y cuántas veces aparece allí. Por ejemplo, la cadena helloworldhello puede ser comprimido en helloworld[00][00][05] una longitud de 13 bytes en comparación con el original de 15 bytes.

Supongamos que un hacker intenta recuperar el texto plano del formulario password=..., donde la contraseña misma es desconocida. De acuerdo con el modelo de ataque de Kelsey, el hacker puede pedir al servidor que comprima y luego encripte los mensajes del formulario (texto plano seguido de ), donde — es un texto arbitrario. Cuando el servidor ha terminado, informa la longitud del resultado. El ataque procede de la siguiente manera:

Pirata: Por favor, comprime y encripta el texto plano sin ningún relleno.
Servidor: Longitud del resultado 14.
Pirata: Por favor, comprime y encripta el texto plano al que se le agregó password=a.
Servidor: Longitud del resultado 18.

El hacker nota: [original 14] + [tres bytes que reemplazaron password=] + a

Pirata: Por favor, comprime y encripta el texto plano al que se le agregó password=b.
Servidor: Longitud del resultado 18.
Pirata: Por favor, comprime y encripta el texto plano al que se le agregó password=c.
Servidor: Longitud del resultado 17.

El hacker nota: [original 14] + [tres bytes que reemplazaron password=c]. Esto implica que el texto plano original contiene la cadena password=c. Es decir, la contraseña comienza con la letra c

Pirata: Por favor, comprime y encripta el texto plano al que se le agregó password=сa.
Servidor: Longitud del resultado 18.

El hacker nota: [original 14] + [tres bytes que reemplazaron password=c] + a

Pirata: Por favor, comprime y encripta el texto plano al que se le agregó password=сb.
Servidor: Longitud del resultado 18.

(… un tiempo después…)

Pirata: Por favor, comprime y encripta el texto plano al que se le agregó password=со.
Servidor: Longitud del resultado 17.

El hacker nota: [original 14] + [tres bytes que reemplazaron password=co]. Siguiendo la misma lógica, el hacker deduce que la contraseña comienza con las letras co

Y así sucesivamente hasta que se recupere toda la contraseña.

Es comprensible que el lector piense que esto es un ejercicio puramente académico y que ese tipo de escenario de ataque nunca ocurrirá en el mundo real. Lamentablemente, como pronto veremos, en criptografía es mejor no hacer suposiciones.

Vulnerabilidades de marca: CRIME, POODLE, DROWN

Finalmente, después de un estudio detallado de la teoría, podemos ver cómo se aplican estos métodos en ataques criptográficos reales.

CRIME

Si el ataque se dirige al navegador y a la red de la víctima, algunas cosas serán más fáciles y otras más difíciles. Por ejemplo, ver el tráfico de la víctima es fácil: basta con estar en el mismo café con WiFi. Por esta razón, a las víctimas potenciales (es decir, a todos) se les recomienda generalmente usar una conexión encriptada. Será más complicado, pero aún posible, realizar solicitudes HTTP en nombre de la víctima a algún sitio externo (por ejemplo, Google). El delincuente debe atraer a la víctima a una página web maliciosa con un script que haga la solicitud. El navegador web proporcionará automáticamente la cookie de sesión correspondiente.

Esto parece sorprendente. Si Bob accedió a evil.com, ¿acaso un script en este sitio puede simplemente pedirle a Google que envíe la contraseña de Bob por correo electrónico a attacker@evil.com? Ну, в теории да, но на самом деле нет. Такой сценарий называется атакой на подделку межсайтовых запросов (Falsificación de Solicitud En Cross-Site, CSRF), y fue popular alrededor de mediados de los años 90. Hoy en día, si evil.com intenta un truco así, Google (o cualquier sitio respetable) generalmente responderá: «Genial, pero tu token CSRF para esta transacción será… mmm… tres billones y siete. Por favor, repite ese número». Los navegadores modernos aplican algo llamado «política de mismo origen» (same-origin policy), que impide que los scripts en el sitio A accedan a la información enviada por el sitio web B. Por lo tanto, un script en evil.com puede enviar solicitudes a google.com, pero no puede leer las respuestas ni completar realmente la transacción.

Debemos enfatizar que si Bob no utiliza una conexión encriptada, todas estas protecciones son inútiles. Un atacante puede simplemente leer el tráfico de Bob y recuperar la cookie de sesión de Google. Con esta cookie, abrirá una nueva pestaña de Google sin salir de su navegador y se hará pasar por Bob, eludiendo las molestas políticas de mismo origen. Pero, desafortunadamente para el atacante, esto es cada vez más raro. En general, Internet ha declarado la guerra a las conexiones sin cifrado, y el tráfico saliente de Bob probablemente esté encriptado, le guste o no. Además, desde el principio de la implementación del protocolo, el tráfico también se comprimía antes de ser cifrado; era una práctica habitual para reducir la latencia.

Aquí entra en juego CRIME (Información de Fuga de Tasa de Compresión Hecha Fácil, una fuga simple a través del coeficiente de compresión). Vulnerabilidad que demostraron en septiembre de 2012 los investigadores de seguridad Giuliano Rizzo y Thai Duong. Ya hemos desglosado toda la base teórica que permite entender lo que hicieron y cómo. Un atacante puede hacer que el navegador de Bob envíe solicitudes a Google y luego interceptar las respuestas en la red local en un formato comprimido y cifrado. Por lo tanto, tenemos:

Aquí el atacante controla la solicitud y tiene acceso a un sniffer de tráfico, incluyendo el tamaño de los paquetes. El escenario ficticio de Kelsey se ha materializado.

Entendiendo la teoría, los autores de CRIME crearon un exploit que puede robar cookies de sesión para una amplia variedad de sitios, incluyendo Gmail, Twitter, Dropbox y Github. La vulnerabilidad afectó a la mayoría de los navegadores web modernos, lo que resultó en la emisión de parches que silenciosamente enterraron la función de compresión en SSL, para que no se utilizara en absoluto. El único que estaba protegido de la vulnerabilidad fue el venerable Internet Explorer, que nunca utilizó la compresión SSL.

POODLE

En octubre de 2014, el equipo de seguridad de Google causó revuelo en la comunidad de seguridad. Lograron explotar una vulnerabilidad en el protocolo SSL que había sido corregida más de diez años antes.

Resultó que, aunque en los servidores funcionaba un nuevo y brillante TLSv1.2, muchos dejaron habilitado el soporte para SSLv3 obsoleto por compatibilidad con Internet Explorer 6. Ya hemos hablado sobre los ataques de retroceso, así que pueden imaginar lo que estaba sucediendo. Un sabotaje bien orquestado del protocolo de enlace y los servidores estaban listos para volver al viejo SSLv3, esencialmente cancelando los últimos 15 años de investigación en seguridad.

Para poner esto en contexto histórico, aquí hay un breve resumen de la historia de SSL hasta la versión 2 por Matthew Green:

Transport Layer Security (TLS) es el protocolo de seguridad más importante en internet. [..] casi cada transacción que realiza en internet depende de TLS. [..] Pero TLS no siempre fue TLS. El protocolo comenzó su vida en Netscape Communications bajo el nombre de 'Secure Sockets Layer' o SSL. Se dice que la primera versión de SSL fue tan horrible que los desarrolladores recopilaron todo el código y lo enterraron en un vertedero secreto en Nuevo México. Como resultado, la primera versión pública de SSL es en realidad la versión SSL 2. Es bastante horrible, y [..] era un producto de mediados de los 90, que los criptógrafos modernos consideran como 'la oscuridad de la criptografía'. Muchos de los ataques criptográficos más horribles que conocemos hoy no habían sido descubiertos. Como resultado, los desarrolladores del protocolo SSLv2 tuvieron que esencialmente palpar en la oscuridad, y se encontraron con un montón de monstruos horribles — para su consternación y nuestro beneficio, ya que los ataques a SSLv2 dejaron lecciones invaluables para la próxima generación de protocolos.

Después de estos eventos, en 1996, la decepcionada compañía Netscape rehízo el protocolo SSL desde cero. El resultado fue SSL versión 3, que corregía algunos problemas de seguridad conocidos de su predecesor..

Afortunadamente para los hackers, "algunos" no significa "todos". En general, SSLv3 proporcionaba todos los bloques de construcción necesarios para llevar a cabo el ataque de Vaudenay. El protocolo utilizaba un cifrado de bloque en modo CBC y un esquema de padding inseguro (esto fue corregido en TLS; por lo tanto, surgió la necesidad de un ataque de degradación). Si recuerdas el esquema de padding en nuestra descripción original del ataque de Vaudenay, el esquema SSLv3 es muy similar.

Pero, desafortunadamente para los hackers, "similar" no significa "idéntico". El esquema de padding de SSLv3 tiene la forma de "N bytes arbitrarios, seguidos de un número N". Intenta en tales condiciones elegir un bloque imaginario de texto cifrado y pasar por todas las etapas del esquema original de Vaudenay: descubrirás que el ataque logra extraer el último byte del bloque de texto plano correspondiente, pero no va más allá. Desencriptar cada 16º byte del texto cifrado es un excelente truco, pero no es una victoria.

Frente al fracaso, el equipo de Google recurrió a una variante extrema: cambiaron a un modelo de amenaza más potente - el que se utilizó en CRIME. Suponiendo que el atacante es un script que se ejecuta en la pestaña del navegador de la víctima y puede extraer cookies de sesión, el ataque sigue siendo impresionante. Aunque el modelo de amenaza más amplio es menos realista, ya hemos visto en la sección anterior que este modelo específico es factible.

Dado los potentes recursos del hacker, el ataque ahora puede continuar. Tenga en cuenta que el atacante sabe dónde se muestra el archivo de cookies de sesión cifrado en el encabezado y controla la longitud de la solicitud HTTP anterior. Por lo tanto, puede manipular la solicitud HTTP para alinear el último byte de la cookie con el final del bloque. Ahora, este byte es adecuado para la descifrado. Simplemente se puede agregar un carácter a la solicitud, y el penúltimo byte de la cookie permanecerá en su lugar y será adecuado para el mismo método de prueba. El ataque continúa de esta manera hasta que el archivo de cookies se haya recuperado completamente. Esto se llama POODLE: Padding Oracle on Downgraded Legacy Encryption.

DROWN

Como ya mencionamos, SSLv3 tenía fallas, pero era radicalmente diferente de su predecesor, ya que el SSLv2 con fallas era un producto de otra época. Allí se podía interrumpir un mensaje a la mitad: solo aceptaré esto sobre mi cadáver se convertía en aceptaré esto; el cliente y el servidor podían encontrarse en Internet, establecer confianza e intercambiar secretos frente a los ojos del atacante, quien luego podía hacerse pasar fácilmente por uno y otro. También había un problema con la criptografía de exportación, que mencionamos al discutir FREAK. Era el Sodom y Gomorra criptográfico.

En marzo de 2016, un equipo de investigadores de diversas áreas técnicas se reunió y realizó un descubrimiento sorprendente: todavía se utiliza SSLv2 en los sistemas de seguridad. Sí, los atacantes ya no podían degradar las sesiones modernas de TLS a SSLv2, ya que esta brecha se cerró después de FREAK y POODLE, pero aún podían conectarse a servidores e iniciar sesiones SSLv2 por su cuenta.

¿Te preguntas qué nos importa lo que estén haciendo allá? Tienen una sesión vulnerable, pero esto no debería afectar a otras sesiones o a la seguridad del servidor, ¿verdad? Bueno, no del todo. Sí, así debería ser en teoría. Pero no, porque la generación de certificados SSL impone ciertas cargas, lo que lleva a que muchos servidores utilicen los mismos certificados y, como consecuencia, las mismas claves RSA para las conexiones TLS y SSLv2. Lo que es peor, debido a un bug en OpenSSL en esta popular implementación, la opción 'Deshabilitar SSLv2' realmente no funcionaba.

Esto permitió un ataque de protocolo cruzado contra TLS, que se llamó DROWN (Decrypting RSA with Obsolete and Weakened eNcryption, descifrado de RSA con cifrado obsoleto y debilitado). Cabe recordar que esto no es lo mismo que un ataque de degradación; el hacker no necesita actuar como un 'hombre en el medio' ni involucrar al cliente para participar en una sesión insegura. Los atacantes simplemente inician una sesión SSLv2 insegura con el servidor, atacan el protocolo débil y recuperan la clave privada del servidor RSA. Esta clave también es válida para las conexiones TLS, y a partir de este momento, ninguna seguridad de TLS lo protegerá de ser comprometido.

Pero para el ataque se necesita un ataque efectivo contra SSLv2 que permita recuperar no solo tráfico específico, sino también la clave privada del servidor RSA. Si bien esta es una tarea complicada, los investigadores pudieron elegir cualquier vulnerabilidad que se hubiera cerrado por completo después de SSLv2. Finalmente, encontraron una opción adecuada: el ataque de Bleichenbacher, del que hablamos anteriormente y que explicaremos en detalle en el siguiente artículo. SSL y TLS están protegidos contra este ataque, pero algunas características aleatorias de SSL junto con claves cortas en la criptografía de clase exportación hicieron posible una determinada implementación de DROWN..

En el momento de la publicación, el 25% de los principales sitios web de internet eran vulnerables a DROWN, y el ataque se podía llevar a cabo con recursos modestos, accesibles incluso para traviesos hackers solitarios. Se requerían ocho horas de cálculos y $440 para extraer la clave RSA del servidor, y SSLv2 pasó de ser 'obsoleto' a 'radiactivo'.

Espera, ¿y qué hay de Heartbleed?

No es un ataque criptográfico en el sentido que describimos anteriormente; es un desbordamiento de búfer.

Tomemos un descanso.

Comenzamos con algunos métodos básicos: fuerza bruta, interpolación, descenso, ataque cruzado y precomputación. Luego examinamos una técnica avanzada, posiblemente el componente principal de los ataques criptográficos modernos: el ataque de oráculo. Pasamos bastante tiempo desentrañando su funcionamiento, y entendimos no solo el principio subyacente, sino también los detalles técnicos de dos implementaciones específicas: el ataque de Wodean al modo de cifrado CBC y el ataque de Kelsey a los protocolos de cifrado con compresión previa.

Al revisar los ataques de descenso y con precomputación, resumimos brevemente el ataque FREAK, que utiliza ambos métodos, ya que los sitios objetivo retroceden a claves débiles y luego reutilizan las mismas claves. Para el próximo artículo, dejamos un ataque muy similar llamado Logjam, que apunta a algoritmos de clave pública.

Luego examinamos tres ejemplos más de la aplicación de estos principios. Primero, CRIME y POODLE: dos ataques que dependían de la capacidad del atacante para insertar texto abierto arbitrario junto al texto abierto objetivo, para luego estudiar las respuestas del servidor y luego, utilizando la metodología del ataque de oráculo, aprovechar esta escasa información para recuperar parcialmente el texto abierto. CRIME siguió el camino del ataque de Kelsey a la compresión SSL, mientras que POODLE utilizó en su lugar una variante del ataque de Wodean al CBC con el mismo efecto.

Luego nos enfocamos en el ataque cruzado DROWN, que establece una conexión con el servidor utilizando el obsoleto protocolo SSLv2, y luego recupera las claves secretas del servidor mediante el ataque de Bleichenbacher. Hasta ahora, hemos omitido los detalles técnicos de este ataque; al igual que Logjam, tendrá que esperar hasta que estudiemos a fondo los sistemas criptográficos de clave pública y sus vulnerabilidades.

En el próximo artículo hablaremos sobre ataques avanzados — como el método de encuentro en el medio (meet-in-the-middle), el análisis criptográfico diferencial y el ataque de 'cumpleaños'. Haremos una breve incursión en los ataques por canales laterales, y luego nos aventuraremos en lo más interesante: los sistemas criptográficos de clave pública.

Fuente: habr.com