En criptografía, un ataque de Oracle 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 sin formato de longitud variable a menudo deben rellenarse (ampliarse) 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 podría darse 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 dentro de cifrados de bloques simétricos . [3] Las variantes de ambos ataques continúan 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 conoció 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 acolchado. [1]
Manger (2001) informa de un ataque al reemplazo del relleno PKCS #1 v1.5, PKCS #1 v2.0 "OAEP". [6]
En criptografía simétrica, el ataque de relleno de Oracle 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.
Comparado 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 tienen como objetivo los criptosistemas comúnmente utilizados en ese momento: CBC es el modo original utilizado en Secure Sockets Layer (SSL) y seguía siendo compatible con TLS. [4]
Se han realizado una serie de mitigaciones para evitar que el software de descifrado actúe como un oráculo, pero nuevos ataques basados en el tiempo han revivido este oráculo repetidamente. TLS 1.2 introduce una serie de cifrado autenticado con modos de datos adicionales que no dependen de CBC. [4]
La implementación estándar del descifrado CBC en cifrados de bloques es 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) mensajes.
La fórmula matemática para el descifrado de CBC es
Como se muestra arriba, el descifrado CBC aplica XOR a cada bloque de texto sin formato con el bloque anterior. Como resultado, una modificación de un solo byte en el bloque realizará un cambio correspondiente a 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 (creating ) y lo envía al servidor. Luego, el servidor devuelve si el relleno del último bloque descifrado ( ) es correcto o no (un relleno PKCS#7 válido). Si el relleno es correcto, el atacante ahora sabe que el último byte de es , los dos últimos bytes son 0x02, los últimos tres bytes son 0x03,… o los últimos ocho bytes son 0x08. El atacante puede modificar el penúltimo byte (voltear cualquier bit) para garantizar que el último byte sea 0x01. (Como alternativa, el atacante puede invertir bytes anteriores y realizar una búsqueda binaria de la posición para identificar el relleno. Por ejemplo, si modificar el penúltimo byte es correcto, pero modificar el penúltimo byte es incorrecto, entonces se conocen los dos últimos bytes. ser 0x02, lo que permite descifrar ambos). Por lo tanto, el último byte de es igual a . Si el relleno es incorrecto, el atacante puede cambiar el último byte al siguiente valor posible. Como máximo, el atacante necesitará realizar 256 intentos para encontrar el último byte de , 255 intentos por cada byte posible (256 posibles, menos uno según el principio de casillero ), más un intento adicional para eliminar un relleno ambiguo. [7]
Después de determinar el último byte de , el atacante puede utilizar la misma técnica para obtener el penúltimo byte de . El atacante establece el último byte de a estableciendo el último byte de a . Luego, el atacante utiliza 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), que son 16 bytes, el atacante obtendrá 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.
Utilizando el ataque de relleno de Oracle, 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 números de ataques de Oracle de relleno. Estos ataques se encadenan entre sí para que el texto sin formato adecuado se construya en orden inverso, desde el final del mensaje ( C N ) hasta el inicio del mensaje ( C 0 , IV). En cada paso, se utiliza un 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 (mediante un código de autenticación de mensajes 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 a otro software, como el cliente de juegos Steam . . [16] En 2012 se demostró que era eficaz contra los tokens criptográficos PKCS 11 . [1]
Si bien estos ataques anteriores fueron reparados por la mayoría de los implementadores de TLS luego de su anuncio público, una nueva variante, el ataque Lucky Thirteen , publicado en 2013, utilizó un canal lateral de sincronización para reabrir la vulnerabilidad incluso en implementaciones que habían sido reparadas previamente. A principios de 2014, el ataque ya no se considera una amenaza en la vida real, aunque todavía es viable en teoría (ver relación señal-ruido ) contra una determinada 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 los ataques Logjam [17] y Export RSA/FREAK [18] , que engañan a los clientes para que utilicen operaciones criptográficas menos seguras. Se proporciona compatibilidad con clientes heredados cuando hay otros más seguros disponibles. Un ataque llamado POODLE [19] (finales de 2014) combina un ataque de degradación (a SSL 3.0) con un ataque de relleno de Oracle en el protocolo más antiguo e inseguro para permitir comprometer los datos transmitidos. En mayo de 2016, se reveló en CVE - 2016-2107 que la solución contra Lucky Thirteen en OpenSSL introdujo otro oráculo de relleno basado en tiempos. [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 ataques similares son factibles en el mundo de la clave simétrica.
