stringtranslate.com

Ataque de oráculo de relleno

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]

Criptografía asimétrica

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]

Criptografía simétrica

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]

Ataque de relleno de Oracle en el cifrado CBC

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 por 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 . El atacante luego 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.

Cifrado de mensajes con ataque de oráculo Padding (CBC-R)

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.

Ataques que utilizan oráculos de relleno

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 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 , 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]

Referencias

  1. ^ abcde Romain Bardou; Ricardo Focardi; Yusuke Kawamoto; Lorenzo Simionato; Acero Graham; Joe Kai Tsay (2012). Ataques de Oracle con relleno eficiente contra hardware criptográfico. Rr-7944 (informe). INRIA . pag. 19.
  2. ^ Black, John; Urtubia, Hector (2002). Ataques de canal lateral en esquemas de cifrado simétrico: el caso del cifrado autenticado. USENET Security '02.
  3. ^ de Serge Vaudenay (2002). Security Flaws Induced by CBC Padding Applications to SSL, IPSEC, WTLS... (PDF) . EUROCRYPT 2002. 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.
  4. ^ abc Sullivan, Nick (12 de febrero de 2016). "Los oráculos de relleno y el declive de los conjuntos de cifrado en modo CBC". El blog de Cloudflare .
  5. ^ Hanno Böck; Juraj Somorovsky; Craig Young. "Ataque ROBOT: el regreso de la amenaza Oracle de Bleichenbacher" . Consultado el 27 de febrero de 2018 .
  6. ^ Manger, James (2001). "Un ataque de texto cifrado seleccionado en el relleno de cifrado asimétrico óptimo (OAEP) RSA estandarizado en PKCS #1 v2.0" (PDF) . Telstra Research Laboratories.
  7. ^ ¿ El ataque del oráculo de relleno es determinista?
  8. ^ Juliano Rizzo; Thai Duong (25 de mayo de 2010). Ataques prácticos de relleno de Oracle (PDF) . USENIX WOOT 2010.
  9. ^ Brice Canvel; Alain Hiltgen; Serge Vaudenay; Martin Vuagnoux (2003), Interceptación de contraseñas en un canal SSL/TLS (PDF).
  10. ^ Jean Paul Degabriele; Kenneth G. Paterson (2007), Ataque a los estándares IPsec en configuraciones de solo cifrado (PDF) , archivado desde el original el 19 de diciembre de 2018 , consultado el 25 de septiembre de 2018.
  11. ^ Jean Paul Degabriele; Kenneth G. Paterson (2010), Sobre la (in)seguridad de IPsec en configuraciones MAC y luego cifrado , CiteSeerX 10.1.1.185.1534 .
  12. ^ Juliano Rizzo; Thai Duong (25 de mayo de 2010). Ataques prácticos de relleno de Oracle (PDF) . USENIX WOOT 2010.
  13. ^ Thai Duong; Juliano Rizzo (2011). Criptografía en la Web: el caso de los fallos de diseño criptográfico en ASP.NET (PDF) . Simposio IEEE sobre seguridad y privacidad 2011.
  14. ^ Dennis Fisher (13 de septiembre de 2010). "El ataque criptográfico 'Padding Oracle' afecta a millones de aplicaciones ASP.NET". Publicación de amenazas . Archivado desde el original el 13 de octubre de 2010.
  15. ^ Vlad Azarkhin (19 de septiembre de 2010). «Explicación de la vulnerabilidad «Padding Oracle» en ASP.NET». Archivado desde el original el 23 de octubre de 2010. Consultado el 11 de octubre de 2010 .
  16. ^ "Rompiendo la criptografía del cliente de Steam". Base de datos de Steam . Consultado el 1 de mayo de 2016 .
  17. ^ Matthew Green; Nadia Heninger ; Paul Zimmerman; et al. (2015), Secreto imperfecto hacia adelante: cómo falla Diffie-Hellman en la práctica (PDF)Para obtener más información, consulte https://www.weakdh.org Archivado el 22 de diciembre de 2019 en Wayback Machine .
  18. ^ Matthew Green (3 de marzo de 2015). "Ataque de la semana: FREAK (o 'la NSA como factor de diversión y beneficio')".; consulte https://www.freakattack.com Archivado el 5 de marzo de 2015 en Wayback Machine para obtener más información.
  19. ^ Matthew Green (14 de octubre de 2014). "El ataque de la semana: POODLE".; para obtener más información, consulte https://www.poodle.io
  20. ^ Aviso de seguridad de OpenSSL [3 de mayo de 2016], 3 de mayo de 2016
  21. ^ Otro oráculo de relleno más en los conjuntos de cifrados CBC de OpenSSL, Cloudflare, 4 de mayo de 2016