Cuando escuchas la palabra "criptografía", algunas personas recuerdan su contraseña de WiFi, el candado verde al lado de la dirección de su sitio web favorito y lo difícil que es acceder al correo electrónico de otra persona. Otros recuerdan una serie de vulnerabilidades de los últimos años con abreviaturas reveladoras (DROWN, FREAK, POODLE...), logotipos elegantes y una advertencia para actualizar urgentemente el navegador.

La criptografía lo cubre todo, pero la esencia en otro. La cuestión es que existe una delgada línea entre lo simple y lo complejo. Algunas cosas son fáciles de hacer, pero difíciles de recomponer, como romper un huevo. Otras cosas son fáciles de hacer pero difíciles de recuperar cuando falta una parte pequeña, importante y crucial: por ejemplo, abrir una puerta cerrada cuando la "parte crucial" es la llave. La criptografía estudia estas situaciones y cómo se pueden utilizar en la práctica.

En los últimos años, la colección de ataques criptográficos se ha convertido en un zoológico de logotipos llamativos, llenos de fórmulas de artículos científicos, y ha dado lugar a una sensación sombría general de que todo está roto. Pero, de hecho, muchos de los ataques se basan en unos pocos principios generales, y páginas interminables de fórmulas a menudo se reducen a ideas fáciles de entender.

En esta serie de artículos, veremos los diferentes tipos de ataques criptográficos, con énfasis en los principios básicos. En términos generales y no exactamente en este orden, pero cubriremos lo siguiente:

• Estrategias básicas: fuerza bruta, análisis de frecuencia, interpolación, degradación y protocolos cruzados.
• Vulnerabilidades de marca: FREAK, CRIMEN, CANICHE, AHOGADO, Logjam.
• Estrategias avanzadas: ataques de oráculo (ataque Vodenet, ataque Kelsey); método de encuentro en el medio, ataque de cumpleaños, sesgo estadístico (criptoanálisis diferencial, criptoanálisis integral, etc.).
• Ataques de canal lateral y sus parientes cercanos, métodos de análisis de fallas.
• Ataques a la criptografía de clave pública: raíz cúbica, difusión, mensaje relacionado, ataque Coppersmith, algoritmo Pohlig-Hellman, tamiz numérico, ataque Wiener, ataque Bleichenbacher.

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

Estrategias básicas

Los siguientes ataques son simples en el sentido de que pueden explicarse casi por completo sin muchos detalles técnicos. Expliquemos cada tipo de ataque en los términos más simples, sin entrar en ejemplos complejos ni casos de uso avanzados.

Algunos de estos ataques se han vuelto obsoletos y no se han utilizado durante muchos años. Otros son veteranos que todavía siguen sorprendiendo a los desarrolladores desprevenidos de criptosistemas en el siglo XXI. Se puede considerar que la era de la criptografía moderna comenzó con la llegada 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) la función de cifrado, que toma un mensaje (texto sin formato) combinado 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 produce texto sin formato. Tanto el cifrado como el descifrado deben ser fáciles de calcular con la clave y difíciles de calcular sin ella.

Supongamos que vemos el texto cifrado e intentamos descifrarlo sin ninguna información adicional (esto se denomina ataque de sólo texto cifrado). Si de alguna manera encontramos mágicamente la clave correcta, podemos verificar fácilmente que efectivamente es correcta si el resultado es un mensaje razonable.

Tenga en cuenta que aquí hay dos suposiciones implícitas. Primero, sabemos cómo realizar el descifrado, es decir, cómo funciona el criptosistema. Esta es una suposición estándar cuando se habla de criptografía. Ocultar los detalles de implementación del cifrado a los atacantes puede parecer una medida de seguridad adicional, pero una vez que el atacante descubre estos detalles, esta seguridad adicional se pierde silenciosa e irreversiblemente. Así es como Principio de Kerchhoff: Que el sistema caiga en manos del enemigo no debería causar inconvenientes.

En segundo lugar, asumimos que la clave correcta es la única clave que conducirá a un descifrado razonable. Ésta también es una suposición razonable; se satisface si el texto cifrado es mucho más largo que la clave y es legible. Esto suele ser lo que sucede en el mundo real, excepto enormes claves poco prácticas o Otras travesuras que es mejor dejar de lado (Si no le gusta que nos hayamos saltado la explicación, consulte el Teorema 3.8 aquí).

Dado lo anterior, surge una estrategia: revisar todas las claves posibles. Esto se llama fuerza bruta, y se garantiza que un ataque de este tipo funcionará contra todos los cifrados prácticos, eventualmente. Por ejemplo, la fuerza bruta es suficiente para hackear cifrado César, un cifrado antiguo donde la clave es una letra del alfabeto, lo que implica poco más de 20 claves posibles.

Desafortunadamente para los criptoanalistas, aumentar el tamaño de la clave es una buena defensa 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 de clave modernos, la simple fuerza bruta es completamente impracticable. 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 1017 operaciones por segundo. Hoy en día, la longitud de clave típica es de 128 bits, lo que significa 2128 combinaciones posibles. Para buscar todas las claves, la supercomputadora Summit necesitará un tiempo aproximadamente 7800 veces la edad del Universo.

¿Debería considerarse la fuerza bruta una curiosidad histórica? En absoluto: es un ingrediente necesario en el recetario del criptoanálisis. Rara vez los cifrados son tan débiles que sólo pueden romperse mediante un ataque inteligente, sin el uso de la fuerza en un grado u otro. Muchos hacks exitosos utilizan un método algorítmico para debilitar primero el cifrado objetivo y luego realizar un ataque de fuerza bruta.

Análisis de frecuencia

La mayoría de los textos no son galimatías. Por ejemplo, en los textos en inglés hay muchas letras 'e' y artículos 'the'; En los archivos binarios, hay muchos bytes cero como relleno entre piezas de información. El análisis de frecuencia es cualquier ataque que se aproveche de este hecho.

El ejemplo canónico de un cifrado vulnerable a este ataque es el cifrado de sustitución simple. En este cifrado, la clave es una tabla con todas las letras reemplazadas. 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 aplicar por fuerza bruta porque hay muchas tablas de búsqueda posibles. Si está interesado en las matemáticas, la longitud efectiva de la clave es de aproximadamente 88 bits: eso es
. Pero el análisis de frecuencia suele hacer el trabajo rápidamente.

Considere el siguiente texto cifrado procesado con un cifrado de sustitución simple:

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

Desde Y aparece con frecuencia, incluso al final de muchas palabras, podemos suponer tentativamente que esta es la letra e:

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

Pareja XD repetido al comienzo de varias palabras. En particular, la combinación XDeLe sugiere claramente la palabra these o there, así que continuemos:

theLe ALe UGLe thWNKE WN HEAJeN ANF EALth DGLAtWG THAN Ale FLeAUt GR WN OGQL ZDWBGEGZDO

Supongamos además que L partido r, A - a etcétera. Probablemente serán necesarios algunos intentos, pero en comparación con un ataque completo de fuerza bruta, este ataque restaura el texto original en poco tiempo:

hay más cosas en el cielo y en la tierra horatio de las que se sueñan en tu filosofía

Para algunos, resolver este tipo de “criptogramas” es un pasatiempo apasionante.

La idea del análisis de frecuencia es más fundamental de lo que parece a primera vista. Y se aplica a cifrados mucho más complejos. A lo largo de la historia, varios diseños de cifrado han intentado contrarrestar tal ataque utilizando "sustitución polialfabética". Aquí, durante el proceso de cifrado, la tabla de sustitución de letras se modifica de formas complejas pero predecibles que dependen de la clave. Todos estos cifrados se consideraron difíciles de descifrar al mismo tiempo; y, sin embargo, un modesto análisis de frecuencia finalmente los derrotó a todos.

El cifrado polialfabético más ambicioso de la historia, y probablemente el más famoso, fue el cifrado Enigma de la Segunda Guerra Mundial. Era relativamente complejo en comparación con sus predecesores, pero después de mucho trabajo, los criptoanalistas británicos lo descifraron mediante análisis de frecuencia. Por supuesto, no pudieron desarrollar un ataque elegante como el que se muestra arriba; tuvieron que comparar pares conocidos de texto plano y texto cifrado (el llamado "ataque de texto plano"), provocando incluso a los usuarios de Enigma a cifrar ciertos mensajes y analizar el resultado (el "ataque de texto plano elegido"). Pero esto no facilitó el destino de los ejércitos enemigos derrotados y de los submarinos hundidos.

Tras este triunfo, el análisis de frecuencia desapareció de la historia del criptoanálisis. Los cifrados en la era digital moderna están diseñados para funcionar con bits, no con letras. Más importante aún, estos cifrados fueron diseñados con la oscura comprensión de lo que más tarde se conoció como ley de schneier: Cualquiera puede crear un algoritmo de cifrado que él mismo no pueda descifrar. No es suficiente para el sistema de cifrado. parecía difícil: para demostrar su valor, debe someterse a una revisión de seguridad despiadada por parte de muchos criptoanalistas que harán todo lo posible para descifrar el cifrado.

Cálculos preliminares

Tomemos como ejemplo la ciudad hipotética de Precom Heights, con una población de 200 habitantes. Cada casa de la ciudad contiene un promedio de $ 000 30 en objetos de valor, pero no más de $ 000 50. El mercado de seguridad en Precom está monopolizado por ACME Industries, que produce las legendarias cerraduras de puerta clase Coyote™. Según el análisis de los expertos, una cerradura de clase Coyote sólo puede romperse mediante una máquina hipotética muy compleja, cuya creación requiere unos cinco años y una inversión de 000 dólares. ¿Es segura la ciudad?

Lo más probable es que no. Al final aparecerá un criminal bastante ambicioso. Razonará así: “Sí, incurriré en grandes costos iniciales. Cinco años de paciente espera y 50 000 dólares, pero cuando termine tendré acceso a toda la riqueza de esta ciudad. Si juego bien mis cartas, esta inversión se amortizará muchas veces”.

Lo mismo ocurre con la criptografía. Los ataques contra un cifrado concreto están sujetos a un análisis despiadado de coste-beneficio. Si la relación es favorable, el ataque no se producirá. Pero los ataques que funcionan contra muchas víctimas potenciales a la vez casi siempre dan resultados, en cuyo caso la mejor práctica de diseño es asumir que comenzaron desde el primer día. Básicamente tenemos 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 un ataque de precomputación es un cifrado constante sin clave. Este fue el caso con El cifrado de César, que simplemente desplaza cada letra del alfabeto tres letras hacia adelante (la tabla se repite, por lo que la última letra del alfabeto se cifra en tercer lugar). Aquí nuevamente entra en juego el principio de Kerchhoff: una vez que un sistema es pirateado, queda pirateado para siempre.

El concepto es simple. Incluso un desarrollador de criptosistemas novato probablemente reconocerá la amenaza y se preparará en consecuencia. Si observamos la evolución de la criptografía, estos ataques fueron inapropiados para la mayoría de los cifrados, desde las primeras versiones mejoradas del cifrado César hasta el declive de los cifrados polialfabéticos. Estos ataques sólo volvieron con el advenimiento de la era moderna de la criptografía.

Este retorno se debe a dos factores. En primer lugar, finalmente aparecieron criptosistemas suficientemente complejos, donde la posibilidad de explotación después de un hackeo no era obvia. En segundo lugar, la criptografía se generalizó tanto que millones de personas no profesionales tomaban decisiones todos los días sobre dónde y qué partes de la criptografía reutilizar. Pasó algún tiempo antes de que los expertos se dieran cuenta de los riesgos y dieran la alarma.

Recuerde el ataque de precómputo: al final del artículo veremos dos ejemplos criptográficos de la vida real en los que jugó un papel importante.

Interpolación

Aquí está el famoso detective Sherlock Holmes, realizando un ataque de interpolación contra el desventurado Dr. Watson:

Inmediatamente supuse que usted venía de Afganistán... Mi línea de pensamiento fue la siguiente: “Este hombre es médico por naturaleza, pero tiene porte militar. Entonces, un médico militar. Acaba de llegar del trópico: su rostro es oscuro, pero este no es el tono natural de su piel, ya que sus muñecas son mucho más blancas. El rostro está demacrado; obviamente, ha sufrido mucho y ha padecido una enfermedad. Fue herido en la mano izquierda; la mantiene inmóvil y de forma un poco antinatural. ¿En qué lugar del trópico podría un médico militar inglés sufrir penurias y resultar herido? Por supuesto, en Afganistán". Toda la línea de pensamiento no tomó ni un segundo. Entonces dije que venías de Afganistán y te sorprendiste.

Holmes pudo extraer muy poca información de cada pieza de evidencia individualmente. Sólo pudo llegar a su conclusión considerándolos todos juntos. Un ataque de interpolación funciona de manera similar al examinar pares conocidos de texto sin formato y texto cifrado que resultan de la misma clave. De cada par se extraen observaciones individuales que permiten sacar una conclusión general sobre la clave. Todas estas inferencias son vagas y parecen inútiles hasta que de repente alcanzan una masa crítica y conducen a la única conclusión posible: por increíble que sea, debe ser verdad. Después de esto, o se revela la clave o el proceso de descifrado se vuelve tan refinado que puede replicarse.

Ilustremos con un ejemplo sencillo cómo funciona la interpolación. Digamos que queremos leer el diario personal de nuestro enemigo, Bob. Cifra cada número de su diario utilizando un criptosistema simple que conoció en un anuncio de la revista "A Mock of Cryptography". El sistema funciona así: Bob elige dos números que le gustan: и . A partir de ahora, para cifrar cualquier número , calcula . Por ejemplo, si Bob eligiera и , entonces el número se cifrará como .

Digamos que el 28 de diciembre notamos que Bob estaba tacando algo en su diario. Cuando haya terminado, lo recogeremos en silencio y veremos la última entrada:

Fecha: 235/520

Querido diario,

Hoy fue un buen día. A través de 64 hoy tengo una cita con Alisa, que vive en un departamento 843. Realmente creo que ella podría ser 26!

Dado que nos tomamos muy en serio seguir a Bob en su cita (ambos tenemos 15 años en este escenario), es fundamental saber la fecha y la dirección de Alice. Afortunadamente, notamos que el criptosistema de Bob es vulnerable a un ataque de interpolación. Puede que no lo sepamos и , pero sabemos la fecha de hoy, por lo que tenemos dos pares de texto sin formato y texto cifrado. Es decir, sabemos que cifrado en Y - en . Esto es lo que anotaremos:

Desde que tenemos 15 años ya conocemos un sistema de dos ecuaciones con dos incógnitas, lo cual en esta situación es suficiente para encontrar и sin ningún problema. Cada par de texto sin formato y texto cifrado impone una restricción a la clave de Bob, y las dos restricciones juntas son suficientes para recuperar completamente la clave. En nuestro ejemplo la respuesta es и (a de modo que 26 en el diario corresponde a la palabra 'el indicado', es decir, “el mismo” - aprox. carril).

Los ataques de interpolación, por supuesto, no se limitan a ejemplos tan simples. Todo criptosistema que se reduce a un objeto matemático bien entendido y una lista de parámetros corre el riesgo de sufrir un ataque de interpolación: cuanto más comprensible sea el objeto, mayor será el riesgo.

Los recién llegados suelen quejarse de que la criptografía es "el arte de diseñar cosas lo más feas posible". Probablemente los ataques de interpolación sean los principales culpables. Bob puede usar un diseño matemático elegante o mantener su cita con Alice en privado, pero, por desgracia, normalmente no es posible tener las dos cosas. Esto quedará muy claro cuando finalmente lleguemos al tema de la criptografía de clave pública.

Protocolo cruzado/baja de categoría

En Ahora me ves (2013), un grupo de ilusionistas intenta estafar al corrupto magnate de los seguros Arthur Tressler con toda su fortuna. Para obtener acceso a la cuenta bancaria de Arthur, los ilusionistas deben proporcionar su nombre de usuario y contraseña o obligarlo a presentarse personalmente en el banco y participar en el plan.

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

(Según una leyenda urbana que hemos verificado y verificado personalmente, el criptógrafo Eli Beaham se encontró una vez con un cajero de banco que insistía en hacer una pregunta de seguridad. Cuando el cajero preguntó el nombre de su abuela materna, Beaham comenzó a dictar: ​​“Capital X, pequeña y, tres... ").

Lo mismo ocurre en criptografía, si se utilizan dos protocolos criptográficos en paralelo para proteger el mismo activo y uno es mucho más débil que el otro. El sistema resultante se vuelve vulnerable a un ataque entre protocolos, en el que se ataca un protocolo más débil para conseguir el premio sin tocar el más fuerte.

En algunos casos complejos, no basta con contactar al servidor utilizando un protocolo más débil, sino que se requiere la participación involuntaria de un cliente legítimo. Esto se puede organizar mediante el llamado ataque de degradación. Para entender este ataque, supongamos que nuestros ilusionistas tienen una tarea más difícil que en la película. Supongamos que un empleado del banco (cajero) y Arthur se encontraron con algunas circunstancias imprevistas, lo que resultó en el siguiente diálogo:

Ladrón: ¿Hola? Este es Arthur Tressler. Me gustaría restablecer mi contraseña.

Cajero Excelente. Eche un vistazo a su libro de códigos secretos personales, página 28, palabra 3. Todos los mensajes siguientes se cifrarán utilizando esta palabra específica como clave. PQJGH. LOTJNAM PGGY MXVRL ZZLQ SRIU HHNMLPPPV…

Ladrón: Oye, oye, espera, espera. ¿Es esto realmente necesario? ¿No podemos simplemente hablar como gente normal?

Cajero No recomiendo hacer esto.

Ladrón: Yo sólo... mira, tuve un mal día, ¿vale? Soy un cliente VIP y no estoy de humor para revisar estos estúpidos libros de códigos.

Cajero Bien. Si insiste, Sr. Tressler. ¿Qué deseas?

Ladrón: Por favor, me gustaría donar todo mi dinero al Fondo Nacional de Víctimas Arthur Tressler.

(Pausa).

Cajero ¿Está claro ahora? Proporcione su PIN para transacciones grandes.

Ladrón: ¿Mi qué?

Cajero A petición personal, las transacciones de este tamaño requieren un PIN para transacciones grandes. Este código se le proporcionó cuando abrió su cuenta.

Ladrón:... Lo perdí. ¿Es esto realmente necesario? ¿No puedes simplemente aprobar el trato?

Cajero No. Lo siento, Sr. Tressler. Nuevamente, esta es la medida de seguridad que solicitó. Si lo deseas, podemos enviarte un nuevo código PIN a tu buzón.

Nuestros héroes posponen la operación. Escuchan a escondidas varias de las grandes transacciones de Tressler, con la esperanza de escuchar el PIN; pero cada vez la conversación se convierte en un galimatías codificado antes de que se diga algo interesante. Finalmente, un buen día, el plan se pone en marcha. Esperan pacientemente el momento en que Tressler tiene que hacer una transacción importante por teléfono, se pone al teléfono y luego...

Tressler: Hola. Me gustaría completar una transacción remota, por favor.

Cajero Excelente. Por favor, eche un vistazo a su libro de códigos secretos personales, página...

(El ladrón presiona el botón; la voz del cajero se convierte en un ruido ininteligible).

Cajero - #@$#@$#*@$$@#* se cifrará con esta palabra como clave. AAAYRR PLRQRZ MMNJK LOJBAN…

Tressler: Lo siento, no lo entendí del todo. ¿De nuevo? ¿En qué página? ¿Que palabra?

Cajero Esta es la página @#$@#*$)#*#@()#@$(#@*$(#@*.

Tressler: ¿Qué?

Cajero Palabra número veinte @$#@$#%#$.

Tressler: ¡En serio! ¡Basta ya! Tú y tu protocolo de seguridad sois una especie de circo. Sé que puedes hablar conmigo normalmente.

Cajero No lo recomiendo…

Tressler: Y no te aconsejo que me hagas perder el tiempo. No quiero saber más sobre esto hasta que arregles los problemas de tu línea telefónica. ¿Podemos finalizar este acuerdo o no?

Cajero… Sí. Bien. ¿Qué deseas?

Tressler: Me gustaría transferir $20 a Lord Business Investments, número de cuenta...

Cajero Un minuto por favor. Este es un gran problema. Proporcione su PIN para transacciones grandes.

Tressler: ¿Qué? Ah, exactamente. 1234.

Aquí hay un ataque hacia abajo. El protocolo más débil "simplemente habla directamente" fue concebido como opción en caso de emergencia. Y sin embargo, aquí estamos.

Quizás se pregunte quién en su sano juicio diseñaría un sistema real "seguro hasta que se le solicite lo contrario" como el descrito anteriormente. Pero así como un banco ficticio asume riesgos para retener a clientes a quienes no les gusta la criptografía, los sistemas en general a menudo gravitan hacia requisitos que son indiferentes o incluso francamente hostiles a la seguridad.

Esto es exactamente lo que ocurrió con el protocolo SSLv2 en 1995. El gobierno de Estados Unidos hace tiempo que comenzó a considerar la criptografía como un arma que es mejor mantener alejada de los enemigos internos y externos. Se aprobaron individualmente fragmentos de código para su exportación desde Estados Unidos, a menudo con la condición de que el algoritmo se debilitara deliberadamente. Netscape, el desarrollador del navegador más popular, Netscape Navigator, recibió permiso para SSLv2 sólo con la clave RSA inherentemente vulnerable de 512 bits (y de 40 bits para RC4).

A finales del milenio, las reglas se habían relajado y el acceso al cifrado moderno estuvo ampliamente disponible. Sin embargo, los clientes y servidores han soportado durante años una criptografía de "exportación" debilitada debido a la misma inercia que mantiene el soporte para cualquier sistema heredado. Los clientes creían que podrían encontrar un servidor que no admitiera nada más. Los servidores hicieron lo mismo. Por supuesto, el protocolo SSL dicta que los clientes y servidores nunca deben utilizar un protocolo débil cuando hay uno mejor disponible. Pero la misma premisa se aplicó a Tressler y su banco.

Esta teoría se abrió camino en dos ataques de alto perfil que sacudieron la seguridad del protocolo SSL en 2015, ambos descubiertos por investigadores de Microsoft y INRIA. Primero, los detalles del ataque FREAK se revelaron en febrero, seguido tres meses después por otro ataque similar llamado Logjam, que discutiremos con más detalle cuando pasemos a los ataques a la criptografía de clave pública.

Vulnerabilidad FREAK (también conocido como "Smack TLS") salió a la luz cuando los investigadores analizaron las implementaciones de cliente/servidor TLS y descubrieron un error curioso. En estas implementaciones, si el cliente ni siquiera solicita utilizar criptografía de exportación débil, pero el servidor aún responde con dichas claves, el cliente dice "Oh, bueno" y cambia a un conjunto de cifrado débil.

En ese momento, la criptografía de exportación se consideraba obsoleta y prohibida, por lo que el ataque fue un completo shock y afectó a muchos dominios importantes, incluidos los sitios de la Casa Blanca, el IRS y la NSA. Peor aún, resulta que muchos servidores vulnerables optimizaban el rendimiento reutilizando las mismas claves en lugar de generar otras nuevas para cada sesión. Esto hizo posible, después de degradar el protocolo, llevar a cabo un ataque previo al cálculo: descifrar una clave siguió siendo relativamente costoso ($100 y 12 horas en el momento de la publicación), pero el costo práctico de atacar la conexión se redujo significativamente. Basta con seleccionar la clave del servidor una vez y descifrar el cifrado para todas las conexiones posteriores a partir de ese momento.

Y antes de continuar, hay un ataque avanzado que es necesario mencionar...

Ataque de oráculo

Moxie Marlinspike mejor conocido como el padre de la aplicación de mensajería criptográfica multiplataforma Signal; pero personalmente nos gusta una de sus innovaciones menos conocidas: principio de fatalidad criptográfica (Principio de fatalidad criptográfica). Parafraseando ligeramente, podemos decir esto: “Si el protocolo realiza cualquier realiza una operación criptográfica en un mensaje de una fuente potencialmente maliciosa y se comporta de manera diferente dependiendo del resultado, está condenado". O en una forma más tajante: "No tomes información del enemigo para procesarla y, si es necesario, al menos no muestres el resultado".

Dejemos de lado los desbordamientos de búfer, las inyecciones de comandos y cosas por el estilo; están más allá del alcance de esta discusión. La violación del "principio fatal" conduce a graves ataques criptográficos debido al hecho de que el protocolo se comporta exactamente como se esperaba.

Como ejemplo, tomemos un diseño ficticio con un cifrado de sustitución vulnerable y luego demostremos un posible ataque. Si bien ya hemos visto un ataque a un cifrado de sustitución mediante análisis de frecuencia, no se trata simplemente de "otra forma de descifrar el mismo cifrado". Por el contrario, los ataques de Oracle son una invención mucho más moderna, aplicable a muchas situaciones en las que falla el análisis de frecuencia, y veremos una demostración de esto en la siguiente sección. Aquí se elige el cifrado simple sólo para aclarar el ejemplo.

Entonces Alice y Bob se comunican usando un cifrado de sustitución simple usando una clave que solo ellos conocen. Son muy estrictos con la longitud de los mensajes: tienen exactamente 20 caracteres. Entonces acordaron que si alguien quería enviar un mensaje más corto, debía agregar un texto ficticio al final del mensaje para que tuviera exactamente 20 caracteres. Después de algunas discusiones, decidieron que solo aceptarían los siguientes textos ficticios: a, bb, ccc, dddd etc. De este modo se conoce un texto ficticio de cualquier longitud requerida.

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 este no es el caso, responden con un mensaje de error apropiado. Si la longitud del texto y el texto ficticio están bien, el destinatario lee el mensaje y envía una respuesta cifrada.

Durante el ataque, el atacante se hace pasar por Bob y envía mensajes falsos a Alice. Los mensajes son una completa tontería: 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 perdición, un atacante aún puede atrapar a Alice para que revele la información clave, como se muestra a continuación.

Ladrón: PREWF ZHJKL MMMN. LA

Alice Texto ficticio no válido.

Ladrón: PREWF ZHJKL MMMN. LB

Alice Texto ficticio no válido.

Ladrón: PREWF ZHJKL MMMN. LC

Alice ILCT? TLCT RUWO PUT KCAW CPS OWPOW!

El ladrón no tiene idea de lo que acaba de decir Alice, pero nota que el símbolo C debe corresponder a, ya que Alice aceptó el texto ficticio.

Ladrón: REWF ZHJKL MMMN. LAA

Alice Texto ficticio no válido.

Ladrón: REWF ZHJKL MMMN. LBB

Alice Texto ficticio no válido.

Después de varios intentos...

Ladrón: REWF ZHJKL MMMN. LGG

Alice Texto ficticio no válido.

Ladrón: 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 observa que H debe coincidir con b ya que Alice aceptó el texto ficticio.

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

A primera vista, el método se parece a un ataque de texto plano elegido. Al final, el atacante selecciona los textos cifrados y el servidor los procesa obedientemente. La principal diferencia que hace que estos ataques sean viables en el mundo real es que el atacante no necesita acceso a la transcripción real; una respuesta del servidor, incluso una tan inocua como "Texto ficticio no válido", es suficiente.

Si bien este ataque en particular es instructivo, no se obsesione demasiado con los detalles del esquema de "texto ficticio", el criptosistema específico utilizado o la secuencia exacta de mensajes enviados por el atacante. La idea básica es cómo Alice reacciona de manera diferente según las propiedades del texto sin formato y lo hace sin verificar que el texto cifrado correspondiente realmente provenga de una parte confiable. Así, Alice permite que el atacante extraiga información secreta de sus respuestas.

Hay muchas cosas que se pueden cambiar en este escenario. Los símbolos a los que reacciona Alice, o la diferencia misma en su comportamiento, o incluso el criptosistema utilizado. Pero el principio seguirá siendo el mismo y el ataque en su conjunto seguirá siendo viable de una forma u otra. La implementación básica de este ataque ayudó a descubrir varios errores de seguridad, que veremos en breve; pero primero hay que aprender algunas lecciones teóricas. ¿Cómo utilizar este "script de Alice" ficticio en un ataque que pueda funcionar con un cifrado moderno real? ¿Es esto posible, incluso en teoría?

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

Cuatro años más tarde, en 2002, el criptógrafo francés Serge Vaudenay demostró un ataque de oráculo casi idéntico al descrito en el escenario de Alice anterior, excepto que en lugar de un cifrado ficticio, rompió toda una respetable clase de cifrados modernos que la gente realmente utiliza. En particular, el ataque de Vaudenay tiene como objetivo cifrados de tamaño de entrada fijo ("cifrados de bloque") cuando se utilizan en el llamado "modo de cifrado CBC" y con un cierto esquema de relleno popular, básicamente equivalente al del escenario de Alice.

También en 2002, el criptógrafo estadounidense John Kelsey - coautor Twofish - propuso varios ataques de Oracle a sistemas que comprimen mensajes y luego los cifran. El más notable de ellos fue un ataque que aprovechó el hecho de que a menudo es posible inferir la longitud original del texto claro a partir de la longitud del texto cifrado. En teoría, esto permite un ataque de Oracle que recupera partes del texto sin formato original.

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

El ataque de Vodene

Para comprender el ataque de Vaudenay, primero debemos hablar un poco más sobre los cifrados en bloque y los modos de cifrado. Un "cifrado de bloque" es, como se mencionó, un cifrado que toma una clave y una entrada de una determinada longitud fija ("longitud de bloque") y produce un bloque cifrado de la misma longitud. Los cifrados en bloque se utilizan ampliamente y se consideran relativamente seguros. El DES, ahora retirado, considerado el primer cifrado moderno, era un cifrado en bloque. Como se mencionó anteriormente, lo mismo ocurre con AES, que se usa ampliamente en la actualidad.

Desafortunadamente, los cifrados en bloque tienen una debilidad evidente. El tamaño de bloque típico es de 128 bits o 16 caracteres. Obviamente, la criptografía moderna requiere trabajar con datos de entrada más grandes, y aquí es donde entran en juego los modos de cifrado. El modo de cifrado es esencialmente un truco: es una forma de aplicar de alguna manera un cifrado de bloque que solo acepta entradas de un cierto tamaño a entradas de una longitud arbitraria.

El ataque de Vodene se centra en el popular modo de operación CBC (Cipher Block Chaining). El ataque trata el cifrado de bloque subyacente como una caja negra mágica e inexpugnable y elude por completo su seguridad.

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

El signo más encerrado en un círculo indica la operación XOR (OR exclusiva). Por ejemplo, se recibe el segundo bloque de texto cifrado:

1. Realizando una operación XOR en el segundo bloque de texto sin formato con el primer bloque de texto cifrado.
2. Cifrar el bloque resultante con un cifrado de bloque utilizando una clave.

Dado que CBC hace un uso tan intensivo de la operación binaria XOR, tomemos un momento para recordar algunas de sus propiedades:

• Idempotencia:
• Conmutatividad:
• Asociatividad:
• Autorreversibilidad:
• Recuento de bytes: byte n de = (byte n de ) (byte n de )

Normalmente, 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 lo desconocido y famoso и , entonces podemos confiar en las propiedades mencionadas anteriormente para resolver la ecuación para . Aplicando XOR en ambos lados de la ecuación con , obtenemos . Todo esto será muy relevante en un momento.

Hay dos diferencias menores y una diferencia importante entre nuestro escenario de Alice y el ataque de Vaudenay. Dos menores:

• En el guión, Alice esperaba que los textos sin formato terminaran con los caracteres a, bb, ccc etcétera. En el ataque Wodene, la víctima espera que los textos sin formato terminen N veces con el N byte (es decir, hexadecimal 01 o 02 02, o 03 03 03, etc.). Esta es una diferencia puramente cosmética.
• En el escenario de Alice, era fácil saber si Alice había aceptado el mensaje mediante la respuesta "Texto ficticio incorrecto". En el ataque de Vodene, se requiere más análisis y una implementación precisa por parte de la víctima es importante; pero en aras de la brevedad, demos por sentado que este análisis todavía es posible.

Diferencia principal:

• Dado que no utilizamos el mismo criptosistema, la relación entre los bytes de texto cifrado controlados por el atacante y los secretos (clave y texto plano) obviamente será diferente. Por lo tanto, el atacante tendrá que utilizar una estrategia diferente al crear textos cifrados e interpretar las respuestas del servidor.

Esta gran diferencia es la última pieza del rompecabezas para comprender el ataque de Vaudenay, así que tomemos un momento para pensar en por qué y cómo se puede montar un ataque de Oracle contra CBC en primer lugar.

Supongamos que nos dan un texto cifrado CBC de 247 bloques y queremos descifrarlo. Podemos enviar mensajes falsos al servidor, tal como antes podíamos enviar mensajes falsos a Alice. El servidor descifrará los mensajes por nosotros, pero no mostrará el descifrado; en cambio, nuevamente, como con Alice, el servidor informará solo un bit de información: si el texto sin formato tiene un relleno válido o no.

Considere que en el escenario de Alice teníamos las siguientes relaciones:

$$mostrar$$texto{SIMPLE_SUBSTITUTION}(texto{texto cifrado},texto{clave}) = texto{texto sin formato}$$mostrar$$

Llamemos a esto "ecuación de Alice". Controlamos el texto cifrado; el servidor (Alice) filtró información vaga sobre el texto sin formato recibido; y esto nos permitió deducir información sobre el último factor: la clave. Por analogía, si podemos encontrar dicha conexión para el script CBC, es posible que también podamos extraer información secreta allí.

Afortunadamente, realmente existen relaciones que podemos utilizar. Considere el resultado de la llamada final para descifrar un cifrado de bloque y denote este resultado como . También denotamos bloques de texto sin formato. y bloques de texto cifrado . Eche otro vistazo al diagrama CBC y observe lo que sucede:

Llamemos a esto la "ecuación CBC".

En el escenario de Alice, al monitorear el texto cifrado y observar la filtración de texto plano correspondiente, pudimos montar un ataque que recuperó el tercer término de la ecuación: la clave. En el escenario CBC, también monitoreamos el texto cifrado y observamos fugas de información en el texto sin formato correspondiente. Si la analogía es válida, podemos obtener información sobre .

Supongamos que realmente restauramos , ¿entonces que? Bueno, entonces podemos imprimir todo el último bloque de texto sin formato de una vez (), simplemente ingresando (que tenemos) y
recibido en la ecuación CBC.

Ahora que somos optimistas sobre el plan general de ataque, es hora de resolver los detalles. Preste atención a cómo exactamente se filtra la información de texto sin formato en el servidor. En el script de Alice, la filtración se produjo porque Alice solo respondería con el mensaje correcto si $inline$text{SIMPLE_SUBSTITUTION}(text{ciphertext},text{key})$inline$ terminaba con la línea a (o bb, etc., pero las posibilidades de que estas condiciones se desencadenaran por casualidad eran muy pequeñas). Similar a CBC, el servidor acepta el relleno si y sólo si termina en hexadecimal 01. Entonces, probemos el mismo truco: enviar textos cifrados falsos con nuestros propios valores falsos. hasta que el servidor acepte el relleno.

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

Ahora usamos la propiedad XOR byte-byte:

Conocemos el primer y tercer término. Y ya hemos visto que esto nos permite recuperar el término restante -el último byte de :

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

Podríamos dejarlo así y estar satisfechos de haber llevado a cabo un ataque a un cifrado teóricamente fuerte. Pero en realidad podemos hacer mucho más: podemos recuperar todo el texto. Esto requiere un truco que no estaba en el guión original de Alice y no es necesario para el ataque del oráculo, pero aún así vale la pena aprenderlo.

Para entenderlo, primero tenga en cuenta que el resultado de generar el valor correcto del último byte es Tenemos una nueva habilidad. Ahora, al falsificar textos cifrados, podemos manipular el último byte del texto sin formato correspondiente. Nuevamente, esto está relacionado con la ecuación CBC y la propiedad byte por byte:

Como ahora conocemos el segundo término, podemos usar nuestro control sobre el primero para controlar el tercero. Simplemente calculamos:

No pudimos hacer esto antes porque aún no teníamos el último byte. .

¿Cómo nos ayudará esto? Supongamos que ahora creamos todos los textos cifrados de modo que en los textos sin formato correspondientes el último byte sea igual a 02. El servidor ahora sólo acepta relleno si el texto sin formato termina en 02 02. Como corregimos el último byte, esto solo sucederá si el penúltimo byte del texto sin formato también es 02. Seguimos enviando bloques de texto cifrado falsos, cambiando el penúltimo byte, hasta que el servidor acepta el relleno para uno de ellos. En este punto obtenemos:

Y restauramos el penúltimo byte. tal como se restauró el último. Seguimos con el mismo espíritu: corregimos los dos últimos bytes del texto plano para 03 03, repetimos este ataque para el tercer byte desde el final y así sucesivamente, hasta restaurar completamente .

¿Qué pasa con el resto del texto? Tenga en cuenta que el valor es en realidad $inline$text{BLOCK_DECRYPT}(text{key},C_{247})$inline$. Podemos poner cualquier otro bloque en su lugar. , y el ataque seguirá teniendo éxito. De hecho, podemos pedirle al servidor que haga $inline$text{BLOCK_DECRYPT}$inline$ para cualquier dato. En este punto, se acabó el juego: podemos descifrar cualquier texto cifrado (eche otro vistazo al diagrama de descifrado de CBC para ver esto; y tenga en cuenta que el IV es público).

Este método particular juega un papel crucial en el ataque del oráculo que encontraremos más adelante.

El ataque de Kelsey

Nuestro simpático John Kelsey expuso los principios que subyacen a muchos posibles ataques, no sólo los detalles de un ataque específico a un cifrado específico. Su Artículo 2002 del año es un estudio de posibles ataques a datos comprimidos cifrados. ¿Creías que la información que tenían los datos comprimidos antes del cifrado no era suficiente para realizar un ataque? Resulta que es suficiente.

Este sorprendente resultado se debe a dos principios. En primer lugar, existe una fuerte correlación entre la longitud del texto claro y la longitud del texto cifrado; para muchas cifras la igualdad exacta. En segundo lugar, cuando se realiza la compresión, también existe una fuerte correlación entre la longitud del mensaje comprimido y el grado de "ruido" del texto sin formato, es decir, la proporción de caracteres que no se repiten (el término técnico es "alta entropía" ).

Para ver el principio en acción, considere dos textos claros:

Texto sin formato 1: AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA

Texto sin formato 2: ATVXCAGTRSVPTVVULSJQHGEYCMQPCRQBGCYIXCFJGJ

Supongamos que ambos textos planos están comprimidos y luego cifrados. Obtienes dos textos cifrados resultantes y tienes que adivinar qué texto cifrado coincide con qué texto sin formato:

Texto cifrado 1: PVOVEYBPJDPVANEAWVGCIUWAABCIYIKOOURMYDTA

Texto cifrado 2: DWKJZXYU

La respuesta es clara. Entre los textos sin formato, sólo el texto sin formato 1 se podía comprimir en la escasa longitud del segundo texto cifrado. Descubrimos 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 locura.

Kelsey señala además que, en determinadas circunstancias inusuales, este principio también puede utilizarse para llevar a cabo un ataque de oráculo. En particular, describe cómo un atacante puede recuperar el texto sin formato secreto si puede obligar al servidor a cifrar los datos del formulario (el texto sin formato seguido de mientras él tiene el control y de alguna manera puede verificar la longitud del resultado cifrado.

Nuevamente, al igual que otros ataques de Oracle, tenemos la relación:

Nuevamente, controlamos un término (), vemos una pequeña filtración de información sobre otro miembro (texto cifrado) e intentamos recuperar el último (texto sin formato). A pesar de la analogía, esta es una situación algo inusual en comparación con otros ataques de oráculos que hemos visto.

Para ilustrar cómo podría funcionar un ataque de este tipo, usemos un esquema de compresión ficticio que acabamos de idear: TOYZIP. Busca líneas de texto que han aparecido anteriormente en el texto y las reemplaza con tres bytes de marcador de posición que indican dónde encontrar una instancia anterior de la línea y cuántas veces aparece allí. Por ejemplo, la línea helloworldhello se puede comprimir en helloworld[00][00][05] 13 bytes de longitud en comparación con los 15 bytes originales.

Supongamos que un atacante intenta recuperar el texto sin formato de un formulario. password=..., donde se desconoce la contraseña. Según el modelo de ataque de Kelsey, un atacante podría pedirle al servidor que comprima y luego cifre los mensajes (texto sin formato seguido de ), donde  - texto libre. Cuando el servidor ha terminado de funcionar, informa la duración del resultado. El ataque es el siguiente:

Ladrón: Comprima y cifre el texto sin formato sin ningún relleno.

Servidor: Longitud del resultado 14.

Ladrón: Comprima y cifre el texto sin formato al que se adjunta password=a.

Servidor: Longitud del resultado 18.

El cracker señala: [original 14] + [tres bytes que reemplazaron password=] + a

Ladrón: Comprima y cifre el texto sin formato al que se agrega password=b.

Servidor: Longitud del resultado 18.

Ladrón: Comprima y cifre el texto sin formato al que se agrega password=с.

Servidor: Longitud del resultado 17.

El cracker señala: [original 14] + [tres bytes que reemplazaron password=c]. Esto supone que el texto sin formato original contiene la cadena password=c. Es decir, la contraseña comienza con una letra. c

Ladrón: Comprima y cifre el texto sin formato al que se agrega password=сa.

Servidor: Longitud del resultado 18.

El cracker señala: [original 14] + [tres bytes que reemplazaron password=с] + a

Ladrón: Comprima y cifre el texto sin formato al que se agrega password=сb.

Servidor: Longitud del resultado 18.

(… Algún tiempo después…)

Ladrón: Comprima y cifre el texto sin formato al que se agrega password=со.

Servidor: Longitud del resultado 17.

El cracker señala: [original 14] + [tres bytes que reemplazaron password=co]. Usando la misma lógica, el atacante concluye que la contraseña comienza con las letras co

Y así sucesivamente hasta restaurar la contraseña completa.

Se perdonará al lector si piensa que se trata de un ejercicio puramente académico y que un escenario de ataque así nunca surgiría en el mundo real. Por desgracia, como veremos pronto, es mejor no renunciar a la criptografía.

Vulnerabilidades de marca: DELITO, CANICHE, AHOGADO

Finalmente, tras estudiar la teoría en detalle, podemos ver cómo se aplican estas técnicas en ataques criptográficos de la vida real.

CRIMEN

Si el ataque está dirigido al navegador y a la red de la víctima, algunos serán más fáciles y otros más difíciles. Por ejemplo, es fácil ver el tráfico de la víctima: basta con sentarse con él en la misma cafetería con WiFi. Por este motivo, generalmente se recomienda a las víctimas potenciales (es decir, a todos) que utilicen una conexión cifrada. Será más difícil, pero aún posible, realizar solicitudes HTTP en nombre de la víctima a algún sitio de terceros (por ejemplo, Google). El atacante debe atraer a la víctima a una página web maliciosa con un script que realice la solicitud. El navegador web proporcionará automáticamente la correspondiente cookie de sesión.

Esto parece asombroso. Si Bob fuera a evil.com, ¿podría el script de este sitio simplemente pedirle a Google que envíe la contraseña de Bob por correo electrónico a [email protected]? Bueno, en teoría sí, pero en realidad no. Este escenario se denomina ataque de falsificación de solicitudes entre sitios (Falsificación de solicitudes entre sitios, CSRF), y fue popular a mediados de los años 90. hoy si evil.com Si intenta este truco, Google (o cualquier sitio web que se precie) normalmente responderá: "Genial, pero su token CSRF para esta transacción será... um... три триллиона и семь. Por favor repita este número." Los navegadores modernos tienen algo llamado "política del mismo origen", según la cual los scripts del sitio A no tienen acceso a la información enviada por el sitio web B. Entonces, los scripts del sitio A no tienen acceso a la información enviada por el sitio web B. evil.com puede enviar solicitudes a google.com, pero no puede leer las respuestas ni completar la transacción.

Debemos enfatizar que, a menos que Bob esté usando una conexión cifrada, todas estas protecciones no tienen sentido. Un atacante puede simplemente leer el tráfico de Bob y recuperar la cookie de sesión de Google. Con esta cookie, simplemente abrirá una nueva pestaña de Google sin salir de su propio navegador y se hará pasar por Bob sin encontrarse con molestas políticas del mismo origen. Pero, por desgracia para los ladrones, esto es cada vez menos común. Internet en su conjunto ha declarado durante mucho tiempo la guerra a las conexiones no cifradas, y el tráfico saliente de Bob probablemente esté cifrado, le guste o no. Además, desde el inicio de la implementación del protocolo, el tráfico también fue se encogió antes del cifrado; esta era una práctica común para reducir la latencia.

Aquí es donde entra en juego CRIMEN (Relación de compresión Infoleak Made Easy, fuga simple a través de la relación de compresión). La vulnerabilidad fue revelada en septiembre de 2012 por los investigadores de seguridad Juliano Rizzo y Thai Duong. Ya hemos examinado toda la base teórica, lo que nos permite comprender qué hicieron y cómo. Un atacante podría obligar al navegador de Bob a enviar solicitudes a Google y luego escuchar las respuestas en la red local en forma comprimida y cifrada. Por lo tanto tenemos:

Aquí el atacante controla la solicitud y tiene acceso al rastreador de tráfico, incluido el tamaño del paquete. El escenario ficticio de Kelsey cobró vida.

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

CANICHE

En octubre de 2014, el equipo de seguridad de Google causó sensación en la comunidad de seguridad. Pudieron explotar una vulnerabilidad en el protocolo SSL que había sido parcheada hace más de diez años.

Resulta que mientras los servidores ejecutan el nuevo y brillante TLSv1.2, muchos han dejado el soporte para el SSLv3 heredado para compatibilidad con Internet Explorer 6. Ya hemos hablado de ataques de degradación, así que puedes imaginar lo que está pasando. Un sabotaje bien orquestado del protocolo de protocolo de enlace y los servidores están listos para volver al viejo SSLv3, esencialmente deshaciendo los últimos 15 años de investigación de seguridad.

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

Transport Layer Security (TLS) es el protocolo de seguridad más importante de Internet. [...] casi todas las transacciones que realiza en Internet dependen de TLS. [..] Pero TLS no siempre fue TLS. El protocolo comenzó su vida en Comunicaciones Netscape llamado "Capa de sockets seguros" o SSL. Se rumorea que la primera versión de SSL era tan terrible que los desarrolladores recogieron todas las impresiones del código y las enterraron en un vertedero secreto en Nuevo México. Como consecuencia, la primera versión pública de SSL es en realidad versión SSL 2. Da bastante miedo y [...] fue un producto de mediados de los años 90, que los criptógrafos modernos consideran "edades oscuras de la criptografía" Muchos de los ataques criptográficos más atroces que conocemos hoy en día aún no han sido descubiertos. Como resultado, los desarrolladores del protocolo SSLv2 tuvieron que buscar su camino en la oscuridad, y se enfrentaron muchos monstruos terribles - para su disgusto y nuestro beneficio, ya que los ataques a SSLv2 dejaron lecciones invaluables para la próxima generación de protocolos.

Después de estos acontecimientos, en 1996, Netscape, frustrado, rediseñó el protocolo SSL desde cero. El resultado fue SSL versión 3, que Se corrigieron varios problemas de seguridad conocidos de su predecesor..

Afortunadamente para los ladrones, "algunos" no significa "todos". En general, SSLv3 proporcionó todos los componentes básicos necesarios para lanzar un ataque Vodene. El protocolo utilizaba un cifrado de bloque en modo CBC y un esquema de relleno inseguro (esto se corrigió en TLS; de ahí la necesidad de un ataque de degradación). Si recuerda el esquema de relleno en nuestra descripción original del ataque de Vaudenay, el esquema SSLv3 es muy similar.

Pero, lamentablemente para los ladrones, “similar” no significa “idéntico”. El esquema de relleno SSLv3 es "N bytes aleatorios seguidos del número N". Intente, en estas condiciones, seleccionar un bloque imaginario de texto cifrado y seguir todos los pasos del esquema original de Vaudene: descubrirá que el ataque extrae con éxito el último byte del bloque de texto plano correspondiente, pero no avanza más. Descifrar cada 16 bytes del texto cifrado es un gran truco, pero no es una victoria.

Ante el fracaso, el equipo de Google recurrió a un último recurso: cambiaron a un modelo de amenaza más potente: el utilizado 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. Si bien el modelo de amenaza más amplio es menos realista, vimos en la sección anterior que este modelo en particular es factible.

Dadas estas capacidades de ataque más poderosas, el ataque ahora puede continuar. Tenga en cuenta que el atacante sabe dónde aparece la cookie de sesión cifrada en el encabezado y controla la longitud de la solicitud HTTP que la precede. Por lo tanto, es capaz de manipular la solicitud HTTP para que el último byte de la cookie esté alineado con el final del bloque. Ahora este byte es adecuado para descifrarlo. Simplemente puede agregar un carácter a la solicitud y el penúltimo byte de la cookie permanecerá en el mismo lugar y podrá seleccionarse utilizando el mismo método. El ataque continúa de esta manera hasta que el archivo cookie se restaure por completo. Se llama POODLE: Padding Oracle en cifrado heredado degradado.

AHOGAR

Como mencionamos, SSLv3 tenía sus defectos, pero era fundamentalmente diferente de su predecesor, ya que el SSLv2 con fugas era producto de una época diferente. Allí podrías interrumpir el mensaje a la mitad: соглашусь на это только через мой труп convertido en соглашусь на это; el cliente y el servidor podrían reunirse en línea, establecer confianza e intercambiar secretos frente al atacante, quien luego podría hacerse pasar por ambos fácilmente. También está el problema con la exportación de criptografía, que mencionamos al considerar FREAK. Éstas eran Sodoma y Gomorra criptográficas.

En marzo de 2016, un equipo de investigadores de diferentes campos técnicos se reunió e hizo un descubrimiento sorprendente: SSLv2 todavía se utiliza en sistemas de seguridad. Sí, los atacantes ya no podían degradar las sesiones TLS modernas a SSLv2 ya que ese agujero se cerró después de FREAK y POODLE, pero aún pueden conectarse a servidores e iniciar sesiones SSLv2 ellos mismos.

Te preguntarás, ¿por qué nos importa lo que hagan allí? Tienen una sesión vulnerable, pero no debería afectar a otras sesiones ni a la seguridad del servidor, ¿verdad? Bueno, no del todo. Sí, así debería ser en teoría. Pero no, porque generar certificados SSL impone una cierta carga, lo que hace que muchos servidores utilicen los mismos certificados y, como resultado, las mismas claves RSA para conexiones TLS y SSLv2. Para empeorar las cosas, debido a un error de OpenSSL, la opción "Desactivar SSLv2" en esta popular implementación de SSL en realidad no funcionó.

Esto hizo posible un ataque entre protocolos en TLS, llamado AHOGAR (Descifrar RSA con cifrado electrónico obsoleto y debilitado, descifrar RSA con cifrado obsoleto y debilitado). Recuerde que esto no es lo mismo que un ataque corto; el atacante no necesita actuar como un "intermediario" y no necesita involucrar al cliente para que participe 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 RSA del servidor. Esta clave también es válida para conexiones TLS y, a partir de este momento, ninguna cantidad de seguridad TLS evitará que se vea comprometida.

Pero para descifrarlo, necesita un ataque funcional contra SSLv2, que le permita recuperar no solo el tráfico específico, sino también la clave secreta del servidor RSA. Aunque se trata de una configuración compleja, los investigadores pudieron elegir cualquier vulnerabilidad que se cerrara por completo después de SSLv2. Finalmente encontraron una opción adecuada: el ataque Bleichenbacher, que mencionamos anteriormente y que explicaremos en detalle en el próximo artículo. SSL y TLS están protegidos contra este ataque, pero algunas características aleatorias de SSL, combinadas con claves cortas en criptografía de grado de exportación, lo hicieron posible. una implementación específica de DROWN.

En el momento de esta publicación, el 25% de los principales sitios de Internet se vieron afectados por la vulnerabilidad DROWN, y el ataque podría llevarse a cabo con recursos modestos disponibles incluso para piratas informáticos solitarios y traviesos. Recuperar la clave RSA del servidor requirió ocho horas de cálculo y 440 dólares, y SSLv2 pasó de obsoleto a radioactivo.

Espera, ¿qué pasa con Heartbleed?

Este no es un ataque criptográfico en el sentido descrito anteriormente; Este es un desbordamiento del búfer.

Tomemos un descanso

Comenzamos con algunas técnicas básicas: fuerza bruta, interpolación, degradación, protocolo cruzado y precálculo. Luego analizamos una técnica avanzada, quizás el componente principal de los ataques criptográficos modernos: el ataque Oracle. Pasamos bastante tiempo averiguándolo y comprendimos no solo el principio subyacente, sino también los detalles técnicos de dos implementaciones específicas: el ataque de Vaudenay al modo de cifrado CBC y el ataque de Kelsey a los protocolos de cifrado de precompresión.

Al revisar los ataques de degradación y precómputo, describimos brevemente el ataque FREAK, que utiliza ambos métodos al hacer que los sitios objetivo degraden a claves débiles y luego reutilicen las mismas claves. Para el próximo artículo, guardaremos el ataque Logjam (muy similar), que apunta a algoritmos de clave pública.

Luego analizamos tres ejemplos más de la aplicación de estos principios. Primero, CRIME y POODLE: dos ataques que se basaban en la capacidad del atacante para inyectar texto sin formato arbitrario junto al texto sin formato objetivo, luego examinaban las respuestas del servidor y nos balanceamosUtilizando la metodología de ataque de Oracle, explota esta escasa información para recuperar parcialmente el texto sin formato. CRIME siguió la ruta del ataque de Kelsey a la compresión SSL, mientras que POODLE utilizó una variante del ataque de Vaudenay a CBC con el mismo efecto.

Luego centramos nuestra atención en el ataque DROWN entre protocolos, que establece una conexión con el servidor utilizando el protocolo SSLv2 heredado y luego recupera las claves secretas del servidor mediante el ataque Bleichenbacher. Por ahora nos hemos saltado los detalles técnicos de este ataque; Al igual que Logjam, tendrá que esperar hasta que comprendamos bien los criptosistemas de clave pública y sus vulnerabilidades.

En el próximo artículo hablaremos sobre ataques avanzados como meet-in-the-middle, criptoanálisis diferencial y ataques de cumpleaños. Hagamos una rápida incursión en los ataques de canal lateral y luego pasemos a la parte divertida: los criptosistemas de clave pública.

Fuente: habr.com