En criptografía, un ataque de oráculo de relleno es un ataque que utiliza la validación de relleno de un mensaje criptográfico para descifrar el texto cifrado. En criptografía, los mensajes de texto simple de longitud variable a menudo deben rellenarse (expandirse) para que sean compatibles con la primitiva criptográfica subyacente . El ataque se basa en tener un " oráculo de relleno " que responde libremente a las consultas sobre si un mensaje está correctamente rellenado o no. La información puede proporcionarse directamente o filtrarse a través de un canal lateral .
El primer ataque conocido que utiliza un oráculo de relleno es el ataque de Bleichenbacher de 1998, que ataca a RSA con relleno PKCS #1 v1.5 . [1] El término "oráculo de relleno" apareció en la literatura en 2002, [2] después del ataque de Serge Vaudenay al descifrado en modo CBC utilizado en los cifrados de bloques simétricos . [3] Las variantes de ambos ataques siguen teniendo éxito más de una década después de su publicación original. [1] [4] [5]
En 1998, Daniel Bleichenbacher publicó un artículo fundamental sobre lo que se conocería como el ataque de Bleichenbacher (también conocido como "ataque del millón de mensajes"). El ataque utiliza un oráculo de relleno contra RSA con relleno PKCS #1 v1.5 , pero no incluye el término. Autores posteriores han clasificado su ataque como un ataque de oráculo de relleno. [1]
Manger (2001) informa sobre un ataque al sustituto del relleno de PKCS #1 v1.5, PKCS #1 v2.0 "OAEP". [6]
En criptografía simétrica, el ataque de relleno de oráculos se puede aplicar al modo de operación CBC . Los datos filtrados sobre la validez del relleno pueden permitir a los atacantes descifrar (y a veces cifrar) mensajes a través del oráculo utilizando la clave del oráculo, sin conocer la clave de cifrado.
En comparación con el ataque de Bleichenbacher a RSA con PKCS #1 v1.5, el ataque de Vaudenay a CBC es mucho más eficiente. [1] Ambos ataques apuntan a sistemas criptográficos comúnmente utilizados en ese momento: CBC es el modo original utilizado en Secure Sockets Layer (SSL) y había seguido siendo compatible con TLS. [4]
Se han llevado a cabo varias mitigaciones para evitar que el software de descifrado actúe como un oráculo, pero los ataques más recientes basados en el tiempo han revivido repetidamente este oráculo. TLS 1.2 introduce una serie de cifrados autenticados con modos de datos adicionales que no dependen de CBC. [4]
La implementación estándar del descifrado CBC en cifrados de bloques consiste en descifrar todos los bloques de texto cifrado, validar el relleno, eliminar el relleno PKCS7 y devolver el texto sin formato del mensaje. Si el servidor devuelve un error de "relleno no válido" en lugar de un error genérico de "error de descifrado", el atacante puede utilizar el servidor como un oráculo de relleno para descifrar (y, a veces, cifrar) los mensajes.
La fórmula matemática para el descifrado de CBC es
Como se muestra arriba, el descifrado CBC realiza una operación XOR entre cada bloque de texto sin formato y el bloque anterior. Como resultado, una modificación de un solo byte en un bloque generará un cambio correspondiente en un solo byte en .
Supongamos que el atacante tiene dos bloques de texto cifrado y quiere descifrar el segundo bloque para obtener texto sin formato . El atacante cambia el último byte de (creando ) y envía al servidor. El servidor luego devuelve si el relleno del último bloque descifrado ( ) es correcto (un relleno PKCS#7 válido). Si el relleno es correcto, el atacante ahora sabe que el último byte de es , los últimos dos bytes son 0x02, los últimos tres bytes son 0x03, …, o los últimos ocho bytes son 0x08. El atacante puede modificar el segundo último byte (invertir cualquier bit) para asegurarse de que el último byte sea 0x01. (Alternativamente, el atacante puede voltear los bytes anteriores y realizar una búsqueda binaria de la posición para identificar el relleno. Por ejemplo, si modificar el tercer último byte es correcto, pero modificar el segundo último byte es incorrecto, entonces se sabe que los dos últimos bytes son 0x02, lo que permite descifrarlos a ambos). Por lo tanto, el último byte de es igual a . Si el relleno es incorrecto, el atacante puede cambiar el último byte de al siguiente valor posible. Como máximo, el atacante necesitará hacer 256 intentos para encontrar el último byte de , 255 intentos para cada byte posible (256 posibles, menos uno por el principio de palomar ), más un intento adicional para eliminar un relleno ambiguo. [7]
Después de determinar el último byte de , el atacante puede usar la misma técnica para obtener el penúltimo byte de . El atacante establece el último byte de en estableciendo el último byte de en . Luego, el atacante usa el mismo enfoque descrito anteriormente, esta vez modificando el penúltimo byte hasta que el relleno sea correcto (0x02, 0x02).
Si un bloque consta de 128 bits ( AES , por ejemplo), es decir, 16 bytes, el atacante obtendrá el texto sin formato en no más de 256⋅16 = 4096 intentos. Esto es significativamente más rápido que los intentos necesarios para forzar una clave de 128 bits.
CBC-R [8] convierte un oráculo de descifrado en un oráculo de cifrado y se demuestra principalmente contra oráculos de relleno.
Mediante el uso del ataque de oráculo de relleno, CBC-R puede crear un vector de inicialización y un bloque de texto cifrado para cualquier texto sin formato:
Para generar un texto cifrado de N bloques de longitud, el atacante debe realizar N cantidad de ataques de oráculo de relleno. Estos ataques se encadenan entre sí para que el texto sin formato correcto se construya en orden inverso, desde el final del mensaje ( C N ) hasta el comienzo del mensaje ( C 0 , IV). En cada paso, se utiliza el ataque de oráculo de relleno para construir el IV del texto cifrado elegido anteriormente.
El ataque CBC-R no funcionará contra un esquema de cifrado que autentique el texto cifrado (utilizando un código de autenticación de mensaje o similar) antes de descifrarlo.
El ataque original contra CBC fue publicado en 2002 por Serge Vaudenay . [3] Posteriormente se realizaron instancias concretas del ataque contra SSL [9] e IPSec. [10] [11] También se aplicó a varios marcos web , incluidos JavaServer Faces , Ruby on Rails [12] y ASP.NET [13] [14] [15] , así como otro software, como el cliente de juegos Steam . [16] En 2012 se demostró que era eficaz contra tokens criptográficos PKCS 11. [1]
Si bien la mayoría de los implementadores de TLS solucionaron estos ataques anteriores después de su anuncio público, una nueva variante, el ataque Lucky Thirteen , publicada en 2013, utilizó un canal lateral de tiempo para reabrir la vulnerabilidad incluso en implementaciones que se habían solucionado previamente. A principios de 2014, el ataque ya no se considera una amenaza en la operación de la vida real, aunque todavía es viable en teoría (ver relación señal-ruido ) contra una cierta clase de máquinas. A partir de 2015 [actualizar], el área de desarrollo más activa para los ataques a los protocolos criptográficos utilizados para proteger el tráfico de Internet son los ataques de degradación , como Logjam [17] y Export RSA/FREAK [18] , que engañan a los clientes para que utilicen operaciones criptográficas menos seguras proporcionadas para la compatibilidad con clientes heredados cuando hay otras más seguras disponibles. Un ataque llamado POODLE [19] (finales de 2014) combina un ataque de degradación (a SSL 3.0) con un ataque de oráculo de relleno en el protocolo más antiguo e inseguro para permitir la vulneración de los datos transmitidos. En mayo de 2016 se reveló en CVE - 2016-2107 que la corrección contra Lucky Thirteen en OpenSSL introdujo otro oráculo de relleno basado en el tiempo. [20] [21]
Bleichenbacher utilizó un modelo de ataque similar contra PKCS#1 v1.5 [5] y Manger contra PKCS#1 v2.0 [13]. Este artículo muestra que es posible realizar ataques similares en el mundo de las claves simétricas.
