Cifrado autenticado

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) y la autenticidad (en En otras palabras, es infalsificable: el mensaje cifrado incluye una etiqueta de autenticación que el remitente sólo puede calcular mientras posee la clave secreta). Ejemplos de modos de cifrado que proporcionan AE son GCM y CCM.

Muchos (pero no todos) esquemas AE permiten que el mensaje contenga "datos asociados" (AD) que no se hace confidencial, pero su integridad está protegida (es decir, es legible, pero se detectará 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. Los esquemas que permiten datos asociados proporcionan cifrado autenticado con datos asociados, o AEAD.

Interfaz de programación

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

• Encryption
  • Entrada: plaintext, clave, y opcionalmente a header (también conocido como datos autenticados adicionales, AAD o datos asociados, AD) en texto claro que no se cifrará, pero será cubierto por protección de autenticidad.
  • Producto: ciphertext y autenticación tag (código de autenticación de mensajes o MAC).
• Decryption
  • Entrada: ciphertext, clave, autenticación tag, y opcionalmente a header (si se utiliza durante el cifrado).
  • Producto: plaintext, o un error si autenticación tag no coincide con el suministrado ciphertext o header.

La parte encabezado tiene como objetivo proporcionar protección de autenticidad e integridad para metadatos de red o almacenamiento para los cuales la confidencialidad no es necesaria, pero se desea autenticidad.

Historia

La necesidad de un cifrado autenticado surgió de la observación de que combinar de forma segura modos de operación de cifrado de bloque de confidencialidad y autenticación separados podría ser propenso a errores y difícil. Esto fue confirmado por una serie de ataques prácticos introducidos en protocolos y aplicaciones de producción debido a una implementación incorrecta o falta de autenticación.

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

Bellare y Namprempre (2000) analizaron tres composiciones de cifrado y primitivas MAC, y demostraron que cifrar un mensaje y posteriormente aplicar una MAC al texto cifrado (el enfoque Encriptar y luego MAC) implica seguridad contra un ataque de texto cifrado elegido de forma adaptativa. siempre que ambas funciones cumplan con las propiedades mínimas requeridas. Katz y Yung investigaron la noción bajo el nombre de "cifrado inolvidable" y demostró que implica seguridad contra ataques de texto cifrado seleccionados.

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

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 de 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 de un mensaje. 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 ambas necesitan integridad y autenticidad. La noción de AEAD fue formalizada por Rogaway (2002).

AEAD de compromiso clave

AE se diseñó originalmente principalmente para proporcionar 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 manipulado por un adversario Mallory que no poseer el K_A. Los esquemas AE generalmente no proporcionan el compromiso de clave, una garantía de que el descifrado fallará con cualquier otra clave. A partir de 2021, la mayoría de los esquemas AE existentes (incluido el muy popular GCM) permiten decodificar algunos mensajes sin errores utilizando algo más que solo el K_A (correcto); Si bien su texto plano decodificado usando una segunda clave (incorrecta) K_M será incorrecto, la etiqueta de autenticación aún coincidirá. Dado que elaborar un mensaje con tal propiedad requiere que Mallory ya posea tanto K_A como K_M, la cuestión podría parecer de interés puramente académico. Sin embargo, en circunstancias especiales, se pueden realizar 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 elaborar un único mensaje que se descifrará exitosamente usando 1000 claves diferentes asociadas con claves débiles y, por lo tanto, contraseñas potenciales que ella conoce, pueden acelerar su búsqueda de contraseñas en 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 parte de Alice de uno fallido, debido, por ejemplo, a un diseño o implementación de protocolo deficiente que convierte al lado de Alice en un oráculo. Naturalmente, este ataque no se puede montar en absoluto cuando las claves se generan aleatoriamente.

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

Para mitigar el ataque descrito anteriormente sin eliminar el "oracle", se puede utilizar un AEAD de confirmación de clave que no permita que existan este tipo de mensajes manipulados. AEGIS es un ejemplo de AEAD de compromiso de clave rápido (si el conjunto de instrucciones AES está presente). Es posible agregar un compromiso clave a un esquema AEAD existente.

Enfoques para el cifrado autenticado

Cifrar y luego MAC (EtM)

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

IPSec adoptó EtM en 2005. En noviembre de 2014, TLS y DTLS recibieron extensiones para EtM con RFC 7366. También existen varios conjuntos de cifrado EtM para SSHv2 (por ejemplo, hmac-sha1-etm@openssh.com).

Cifrar y MAC (E&M)

Se produce una MAC basada en el texto sin formato y el texto sin formato se cifra sin la MAC. La MAC del texto plano y el texto cifrado se envían juntos. Utilizado, por ejemplo, en SSH. Aunque no se ha demostrado que el enfoque E&M sea totalmente infalsificable en sí mismo, es posible aplicar algunas modificaciones menores a SSH para hacerlo fuertemente infalsificable a pesar del enfoque.

MAC-luego-cifrar (MtE)

Se produce una MAC basada en el texto sin formato, luego el texto sin formato y la MAC se cifran juntos para producir 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.

No se ha demostrado que el MtE sea totalmente infalsificable en sí mismo. Krawczyk ha demostrado que la implementación SSL/TLS es totalmente infalsificable y demostró que SSL/TLS era, de hecho, seguro debido a la codificación utilizada junto con el mecanismo MtE. 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 versiones anteriores.

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