stringtranslate.com

Cifrado autenticado

El cifrado autenticado (AE) es un esquema de cifrado que garantiza simultáneamente la confidencialidad de los datos (también conocida como privacidad: el mensaje cifrado es imposible de entender sin el conocimiento de una clave secreta [1] ) y la autenticidad (en otras palabras, es infalsificable: [2] el mensaje cifrado incluye una etiqueta de autenticación que el remitente puede calcular solo si posee la clave secreta [1] ). Ejemplos de modos de cifrado que proporcionan AE son GCM y CCM . [1]

Muchos esquemas de AE ​​(pero no todos) permiten que el mensaje contenga "datos asociados" (AD) que no se hacen confidenciales, pero su integridad está protegida (es decir, son legibles, pero se detectará su manipulación). Un ejemplo típico es el encabezado de un paquete de red que contiene su dirección de destino. Para enrutar correctamente el paquete, todos los nodos intermedios en la ruta del mensaje necesitan conocer el destino, pero por razones de seguridad no pueden poseer la clave secreta. [3] Los esquemas que permiten datos asociados proporcionan cifrado autenticado con datos asociados, o AEAD . [3]

Interfaz de programación

Una interfaz de programación típica para una implementación de AE ​​proporciona las siguientes funciones:

La parte del encabezado está destinada a brindar autenticidad y protección de integridad para metadatos de redes o almacenamiento para los cuales la confidencialidad no es necesaria, pero se desea la autenticidad.

Historia

La necesidad de un cifrado autenticado surgió de la observación de que la combinación segura de modos de operación de cifrado de bloques de autenticación y confidencialidad separados podía ser propensa a errores y difícil. [4] [5] Esto fue confirmado por una serie de ataques prácticos introducidos en protocolos y aplicaciones de producción por una implementación incorrecta o falta de autenticación. [6]

Alrededor del año 2000, se desarrollaron varios esfuerzos en torno a la noción de estandarizar modos que garantizaran una implementación correcta. En particular, la publicación de los modos CBC con reconocimiento de integridad y los modos paralelizables con reconocimiento de integridad , IAPM, de Charanjit Jutla [7] en 2000 despertó un gran interés en los modos posiblemente seguros (consulte OCB y cronología [8] ). Se han estandarizado seis modos de cifrado autenticado diferentes (a saber, modo de libro de códigos de desplazamiento 2.0 , OCB  2.0; Key Wrap ; contador con CBC-MAC , CCM; cifrar luego autenticar luego traducir , EAX; cifrar luego MAC , EtM; y modo Galois/contador , GCM) en ISO/IEC 19772:2009. [9] Se desarrollaron más métodos de cifrado autenticado en respuesta a la solicitud del NIST . [10] Las funciones Sponge se pueden utilizar en modo dúplex para proporcionar cifrado autenticado. [11]

Bellare y Namprempre (2000) analizaron tres composiciones de cifrado y primitivas MAC, y demostraron que cifrar un mensaje y posteriormente aplicar un MAC al texto cifrado (el enfoque Encrypt-then-MAC) implica seguridad contra un ataque de texto cifrado seleccionado adaptativo , siempre que ambas funciones cumplan con las propiedades mínimas requeridas. Katz y Yung investigaron la noción bajo el nombre de "cifrado infalsificable" y demostraron que implica seguridad contra ataques de texto cifrado seleccionado. [12]

En 2013, se anunció el concurso CAESAR para fomentar el diseño de modos de cifrado autenticados. [13]

En 2015, se agrega ChaCha20-Poly1305 como una construcción AE alternativa a GCM en los protocolos IETF .

Variantes

Cifrado autenticado con datos asociados

El cifrado autenticado con datos asociados (AEAD) es una variante del AE que permite que el mensaje incluya "datos asociados" (AD, información adicional no confidencial, también conocida como "datos autenticados adicionales", AAD). Un destinatario puede comprobar la integridad tanto de los datos asociados como de la información confidencial en un mensaje. El AD es útil, por ejemplo, en paquetes de red donde el encabezado debe ser visible para el enrutamiento , pero la carga útil debe ser confidencial y ambos necesitan integridad y autenticidad . La noción de AEAD fue formalizada por Rogaway (2002). [3]

AEAD, un compromiso clave

AE se diseñó originalmente principalmente para proporcionar la integridad del texto cifrado: la validación exitosa de una etiqueta de autenticación por parte de Alice usando su clave simétrica K A indica que el mensaje no fue alterado por un Mallory adversario que no posee la K A . Los esquemas AE generalmente no proporcionan el compromiso de clave , una garantía de que el descifrado fallaría para cualquier otra clave. [14] A partir de 2021, la mayoría de los esquemas AE existentes (incluido el muy popular GCM) permiten que algunos mensajes se decodifiquen sin un error usando más que solo la (correcta) K A ; si bien su texto simple decodificado usando una segunda clave (incorrecta) K M será incorrecto, la etiqueta de autenticación aún coincidiría. [ cita requerida ] Dado que la elaboración de un mensaje con dicha propiedad requiere que Mallory ya posea tanto K A como K M , el problema puede parecer de interés puramente académico. [15] Sin embargo, en circunstancias especiales, se pueden montar ataques prácticos contra implementaciones vulnerables. Por ejemplo, si un protocolo de autenticación de identidad se basa en el descifrado exitoso de un mensaje que utiliza una clave basada en contraseña, la capacidad de Mallory para crear un solo mensaje que se descifraría exitosamente utilizando 1000 claves diferentes asociadas con contraseñas potenciales débiles y, por lo tanto, conocidas por ella, puede acelerar su búsqueda de contraseñas por un factor de casi 1000. Para que este ataque de diccionario tenga éxito, Mallory también necesita la capacidad de distinguir el descifrado exitoso por Alice de uno fallido, debido, por ejemplo, a un diseño o implementación de protocolo deficiente que convierta el lado de Alice en un oráculo . Naturalmente, este ataque no se puede montar en absoluto cuando las claves se generan aleatoriamente. [16]

El compromiso de clave fue estudiado originalmente en la década de 2010 por Abdalla et al. [17] y Farshim et al. [18] bajo el nombre de "cifrado robusto". [15] [19]

Para mitigar el ataque descrito anteriormente sin eliminar el "oráculo", se puede utilizar un AEAD de compromiso de clave que no permita que existan este tipo de mensajes creados. AEGIS es un ejemplo de AEAD de compromiso de clave rápido (si el conjunto de instrucciones AES está presente). [20] Es posible agregar compromiso de clave a un esquema AEAD existente. [21] [22]

Enfoques para el cifrado autenticado

Cifrado y luego MAC (EtM)

Enfoque EtM

Primero se cifra el texto simple y luego se genera una dirección MAC basada en el texto cifrado resultante. El texto cifrado y su dirección MAC se envían juntos. ETM es el método estándar según la norma ISO/IEC 19772:2009. [9] Es el único método que puede alcanzar la más alta definición de seguridad en AE, pero esto solo se puede lograr cuando la dirección MAC utilizada es "fuertemente infalsificable". [23]

IPSec adoptó EtM en 2005. [24] En noviembre de 2014, TLS y DTLS recibieron extensiones para EtM con RFC  7366. También existen varios conjuntos de cifrados EtM para SSHv2 (por ejemplo,[email protected]).

Enfoque E&M

Se genera una MAC en base al texto simple, y el texto simple se cifra sin la MAC. La MAC del texto simple y el texto cifrado se envían juntos. Se utiliza, por ejemplo, en SSH . [25] Aunque no se ha demostrado que el enfoque E&M sea totalmente infalsificable en sí mismo, [23] es posible aplicar algunas modificaciones menores a SSH para que sea totalmente infalsificable a pesar del enfoque. [26]

MAC y luego cifrado (MtE)

Enfoque MtE

Se genera una MAC a partir del texto simple, luego se cifran el texto simple y la MAC para generar un texto cifrado basado en ambos. Se envía el texto cifrado (que contiene una MAC cifrada). Hasta TLS 1.2, todos los conjuntos de cifrado SSL/TLS disponibles eran MtE. [27]

No se ha demostrado que MtE sea infalsificable por sí mismo. [23] Krawczyk ha demostrado que la implementación de SSL/TLS es infalsificable , ya que demostró que SSL/TLS era, de hecho, segura debido a la codificación utilizada junto con el mecanismo MtE. [28] Sin embargo, la prueba de Krawczyk contiene suposiciones erróneas sobre la aleatoriedad del vector de inicialización (IV). El ataque BEAST de 2011 explotó el IV encadenado no aleatorio y rompió todos los algoritmos CBC en TLS 1.0 y anteriores. [29]

Además, un análisis más profundo de SSL/TLS modeló la protección como MAC-then-pad-then-encrypt, es decir, el texto sin formato primero se rellena hasta el tamaño de bloque de la función de cifrado. Los errores de relleno a menudo dan como resultado errores detectables en el lado del destinatario, lo que a su vez conduce a ataques de oráculo de relleno , como Lucky Thirteen .

Véase también

Referencias

  1. ^ abc Negro 2005, pág. 1.
  2. ^ Katz y Lindell 2020, pág. 116.
  3. ^ abc Negro 2005, pág. 2.
  4. ^ M. Bellare; P. Rogaway; D. Wagner. "Un modo de cifrado autenticado convencional" (PDF) . NIST . Consultado el 12 de marzo de 2013. A la gente le había ido bastante mal cuando intentó combinar un esquema de cifrado tradicional (solo de privacidad) y un código de autenticación de mensajes (MAC).
  5. ^ T. Kohno; J. Viega y D. Whiting. "El modo de cifrado autenticado (datos asociados) de CWC" (PDF) . NIST . Consultado el 12 de marzo de 2013. Es muy fácil combinar accidentalmente esquemas de cifrado seguro con MAC seguras y, aun así, obtener esquemas de cifrado autenticado inseguros.
  6. ^ "Fallos de la criptografía de clave secreta" (PDF) . Daniel J. Bernstein. Archivado desde el original (PDF) el 18 de abril de 2013 . Consultado el 12 de marzo de 2013 .
  7. ^ Jutl, Charanjit S. (1 de agosto de 2000). "Modos de cifrado con integridad de mensajes casi libre". Archivo de criptografía ePrint: Informe 2000/039 . Actas de la IACR EUROCRYPT 2001. IACR . Consultado el 16 de marzo de 2013 .
  8. ^ T. Krovetz; P. Rogaway (1 de marzo de 2011). "El rendimiento del software de los modos de cifrado autenticado" (PDF) . Fast Software Encryption 2011 (FSE 2011) . IACR .
  9. ^ ab "Tecnología de la información - Técnicas de seguridad - Cifrado autenticado". 19772:2009 . ISO/IEC . Consultado el 12 de marzo de 2013 .
  10. ^ "Desarrollo de modos de cifrado". NIST . Consultado el 17 de abril de 2013 .
  11. ^ El equipo de Keccak. "Duplexing The Sponge" (PDF) .
  12. ^ Katz, J.; Yung, M. (2001). "Cifrado infalsificable y modos de operación seguros de texto cifrado elegido". En B. Schneier (ed.). Fast Software Encryption (FSE): 2000 Proceedings . Apuntes de conferencias en informática. Vol. 1978. págs. 284–299. doi :10.1007/3-540-44706-7_20. ISBN 978-3-540-41728-6.
  13. ^ "CESAR: Competencia por el cifrado autenticado: seguridad, aplicabilidad y robustez" . Consultado el 12 de marzo de 2013 .
  14. ^ Albertini y col. 2020, págs. 1-2.
  15. ^ ab Albertini y col. 2020, pág. 2.
  16. ^ Len, Julia; Grubbs, Paul; Ristenpart, Thomas (2021). Particionado de ataques Oracle. USENET '21. págs. 195–212.
  17. ^ Abdalla, Bellare y Neven 2010, págs. 480–497.
  18. ^ Farshim y col. 2013, págs. 352–368.
  19. ^ Bellare y Hoang 2022, pág. 5.
  20. ^ Denis, Frank. "La familia AEGIS de algoritmos de cifrado autenticados". cfrg.github.io .
  21. ^ Gueron, Shay (2020). "AEADs de compromiso clave" (PDF) .
  22. ^ poncho. "AEADs que comprometen claves". Cryptography Stack Exchange . Consultado el 21 de febrero de 2024 .(Consulte también la sección de comentarios que analiza una recomendación revisada de libsodium para agregar key-commitment).
  23. ^ abc «Cifrado autenticado: relaciones entre nociones y análisis del paradigma de composición genérica». M. Bellare y C. Namprempre. Archivado desde el original el 23 de enero de 2018. Consultado el 13 de abril de 2013 .
  24. ^ Kent, Stephen (diciembre de 2005). "Separate Confidentiality and Integrity Algorithms" (Algoritmos separados de confidencialidad e integridad). RFC 4303 - IP Encapsulating Security Payload (ESP) ( Carga útil de seguridad encapsulante de IP [ESP]). Grupo de trabajo de ingeniería de Internet (IETF) . Consultado el 12 de septiembre de 2018 .
  25. ^ Lonvick, Chris M.; Ylonen, Tatu (enero de 2006). "Integridad de datos". RFC 4253 . Grupo de trabajo de ingeniería de Internet (IETF) . Consultado el 12 de septiembre de 2018 .
  26. ^ Bellare, Mihir; Kohno, Tadayoshi; Namprempre, Chanathip. "Romper y reparar de forma demostrable el esquema de cifrado autenticado por SSH: un estudio de caso del paradigma codificar, luego cifrar y MAC" (PDF) . ACM Transactions on Information and System Security . Consultado el 30 de agosto de 2021 .
  27. ^ Rescorla, Eric; Dierks, Tim (agosto de 2008). "Record Payload Protection". RFC 5246. Grupo de trabajo de ingeniería de Internet (IETF) . Consultado el 12 de septiembre de 2018 .
  28. ^ "El orden de cifrado y autenticación para proteger las comunicaciones (o: ¿Qué tan seguro es SSL?)" (PDF) . H. Krawczyk . Consultado el 13 de abril de 2013 .
  29. ^ Duong, Thai; Rizzo, Juliano (13 de mayo de 2011). "Aquí vienen los ⊕ Ninjas" (PDF) .– Documento técnico sobre el ataque BEAST
General

Fuentes