encryption - operacion - ¿Cómo elegir un modo de cifrado AES(CBC ECB CTR OCB CFB)?

cipher block chaining (7)

¿Cuáles de ellos son los preferidos en qué circunstancias?

Me gustaría ver la lista de criterios de evaluación para los distintos modos, y tal vez una discusión de la aplicabilidad de cada criterio.

Por ejemplo, creo que uno de los criterios es el "tamaño del código" para el cifrado y descifrado, que es importante para los sistemas integrados de microcódigo, como los adaptadores de red 802.11. Si el código requerido para implementar CBC es mucho más pequeño que el requerido para CTR (no sé si esto es cierto, es solo un ejemplo), entonces podría entender por qué sería preferible el modo con el código más pequeño. Pero si estoy escribiendo una aplicación que se ejecuta en un servidor, y la biblioteca AES que estoy usando implementa CBC y CTR de todos modos, este criterio es irrelevante.

¿A qué me refiero con "lista de criterios de evaluación y aplicabilidad de cada criterio"?

Esto no está realmente relacionado con la programación, pero está relacionado con el algoritmo.

Cualquier cosa menos el BCE.
Si usa CTR, es imperativo que use un IV diferente para cada mensaje, de lo contrario, el atacante podrá tomar dos textos cifrados y derivar un texto sin cifrar combinado sin cifrar. La razón es que el modo CTR esencialmente convierte un cifrado de bloque en un cifrado de flujo, y la primera regla de los cifrados de flujo es nunca usar la misma clave + IV dos veces.
Realmente no hay mucha diferencia en lo difícil que es implementar los modos. Algunos modos solo requieren el cifrado de bloque para operar en la dirección de cifrado. Sin embargo, la mayoría de los cifrados de bloque, incluido AES, no requieren mucho más código para implementar el descifrado.
Para todos los modos de cifrado, es importante usar diferentes IV para cada mensaje si sus mensajes pueden ser idénticos en los primeros bytes, y no quiere que un atacante lo sepa.

¿Comenzó por leer la información sobre esto en Wikipedia - Bloquear los modos de operación de cifrado ? Luego siga el enlace de referencia en Wikipedia a NIST: Recomendación para los modos de operación de cifrado de bloque .

Conozco un aspecto: aunque CBC brinda mayor seguridad al cambiar el IV para cada bloque, no es aplicable al contenido cifrado al que se accede de forma aleatoria (como un disco duro cifrado).

Por lo tanto, use CBC (y los otros modos secuenciales) para flujos secuenciales y ECB para acceso aleatorio.

Es posible que desee elegir en función de lo que está ampliamente disponible. Tenía la misma pregunta y aquí están los resultados de mi investigación limitada.

Limitaciones de hardware

STM32L (low energy ARM cores) from ST Micro support ECB, CBC,CTR GCM CC2541 (Bluetooth Low Energy) from TI supports ECB, CBC, CFB, OFB, CTR, and CBC-MAC

Limitaciones de código abierto

Original rijndael-api source - ECB, CBC, CFB1 OpenSSL - command line CBC, CFB, CFB1, CFB8, ECB, OFB OpenSSL - C/C++ API CBC, CFB, CFB1, CFB8, ECB, OFB and CTR EFAES lib [1] - ECB, CBC, PCBC, OFB, CFB, CRT ([sic] CTR mispelled) OpenAES [2] - ECB, CBC

[1] http://www.codeproject.com/Articles/57478/A-Fast-and-Easy-to-Use-AES-Library

[2] https://openaes.googlecode.com/files/OpenAES-0.8.0.zip

Phil Rogaway ha realizado un análisis formal en 2011, here . La Sección 1.6 ofrece un resumen que transcribo aquí, agregando mi propio énfasis en negrita (si está impaciente, su recomendación es usar el modo CTR, pero le sugiero que lea mis párrafos sobre la integridad del mensaje en lugar del cifrado a continuación).

Tenga en cuenta que la mayoría de estos requieren que el IV sea aleatorio, lo que significa que no es predecible y, por lo tanto, debe generarse con seguridad criptográfica. Sin embargo, algunos requieren solo un "nonce", que no exige esa propiedad, sino que solo requiere que no se reutilice. Por lo tanto, los diseños que se basan en un nonce son menos propensos a errores que los diseños que no lo hacen (y créanme, he visto muchos casos en los que CBC no se implementa con la selección IV adecuada). Entonces, verá que he agregado negrita cuando Rogaway dice algo como "no se logra la confidencialidad cuando la IV es un nonce", significa que si elige su IV criptográficamente segura (impredecible), entonces no hay problema. Pero si no lo hace, entonces está perdiendo las buenas propiedades de seguridad. Nunca reutilice un IV para ninguno de estos modos.

Además, es importante comprender la diferencia entre la integridad del mensaje y el cifrado. El cifrado oculta los datos, pero un atacante podría modificar los datos cifrados, y su software puede aceptar los resultados si no verifica la integridad del mensaje. Mientras que el desarrollador dirá "pero los datos modificados volverán como basura después del descifrado", un buen ingeniero de seguridad encontrará la probabilidad de que la basura cause un comportamiento adverso en el software, y luego convertirá ese análisis en un ataque real. He visto muchos casos en los que se utilizó el cifrado, pero la integridad del mensaje realmente se necesitaba más que el cifrado. Entiende lo que necesitas.

Debo decir que, aunque GCM tiene tanto cifrado como integridad de mensajes, es un diseño muy frágil: si reutilizas un IV, estás equivocado: el atacante puede recuperar tu clave. Otros diseños son menos frágiles, por lo que personalmente temo recomendar GCM en función de la cantidad de código de cifrado deficiente que he visto en la práctica.

Si necesita ambos, la integridad del mensaje y el cifrado, puede combinar dos algoritmos: por lo general vemos CBC con HMAC, pero no hay razón para vincularse con CBC. Lo importante que se debe saber es cifrar primero, luego MAC el contenido cifrado , y no al revés. Además, la IV debe ser parte del cálculo de MAC.

No estoy al tanto de los problemas de propiedad intelectual.

Ahora a lo bueno del profesor Rogaway:

Bloquee los modos de cifrado, cifrado pero no la integridad del mensaje

ECB : A blockcipher, el modo encripta mensajes que son un múltiplo de n bits al cifrar por separado cada parte de n bits. Las propiedades de seguridad son débiles , el método pierde la igualdad de los bloques tanto en las posiciones de bloque como en el tiempo. De considerable valor heredado, y de valor como elemento de construcción para otros esquemas, pero el modo no logra ningún objetivo de seguridad generalmente deseable por derecho propio y debe usarse con considerable precaución; El BCE no debe considerarse como un modo de confidencialidad de "propósito general" .

CBC : un esquema de encriptación basado en IV, el modo es seguro como un esquema de encriptación probabilístico, logrando la indistinguibilidad de los bits aleatorios, asumiendo un IV aleatorio. La confidencialidad no se logra si el IV es simplemente un nonce , ni si es un nonce cifrado bajo la misma clave utilizada por el esquema, como lo sugiere la norma de forma incorrecta. Los textos cifrados son altamente maleables. No hay seguridad de ataque de texto cifrado (CCA) elegida. La confidencialidad se pierde en presencia de un oráculo de relleno correcto para muchos métodos de relleno. El cifrado es ineficiente por ser inherentemente serial. Ampliamente utilizado, las propiedades de seguridad de solo privacidad del modo resultan en un uso incorrecto frecuente. Puede utilizarse como un bloque de construcción para algoritmos CBC-MAC. No puedo identificar ventajas importantes sobre el modo CTR.

CFB : un esquema de encriptación basado en IV, el modo es seguro como un esquema de encriptación probabilístico, logrando la indistinguibilidad de los bits aleatorios, asumiendo un IV aleatorio. La confidencialidad no se logra si la IV es predecible , ni si se realiza mediante un código cifrado bajo la misma clave utilizada por el esquema, como lo sugiere la norma de forma incorrecta. Los textos cifrados son maleables. No CCA-seguridad. El cifrado es ineficiente por ser inherentemente serial. El esquema depende de un parámetro s, 1 ≤ s ≤ n, típicamente s = 1 o s = 8. Ineficiente por necesitar una llamada de cifrado de bloque para procesar solo s bits. El modo logra una interesante propiedad de "auto-sincronización"; la inserción o eliminación de cualquier número de caracteres de s-bit en el texto cifrado solo interrumpe temporalmente el descifrado correcto.

OFB : un esquema de encriptación basado en IV, el modo es seguro como un esquema de encriptación probabilístico, logrando la indistinguibilidad de los bits aleatorios, asumiendo un IV aleatorio. La confidencialidad no se logra si el IV es un nonce, aunque una secuencia fija de IV (por ejemplo, un contador) funciona bien. Los textos cifrados son altamente maleables. No hay seguridad CCA. El cifrado y el descifrado son ineficientes por ser inherentemente seriales. Cifra de forma nativa cadenas de cualquier longitud de bit (no se necesita relleno). No puedo identificar ventajas importantes sobre el modo CTR.

CTR : un esquema de encriptación basado en IV, el modo logra la indistinguibilidad de los bits aleatorios, asumiendo que no existe IV. Como un esquema seguro basado en nonce, el modo también se puede utilizar como un esquema de cifrado probabilístico, con un IV aleatorio. Falla completa de la privacidad si un nonce se reutiliza en el cifrado o descifrado. La paralelización del modo a menudo lo hace más rápido, en algunas configuraciones mucho más rápido, que otros modos de confidencialidad. Un bloque de construcción importante para esquemas de cifrado autenticado. En general, generalmente es la mejor y más moderna forma de lograr el cifrado de privacidad.

XTS : un esquema de cifrado basado en IV, el modo funciona mediante la aplicación de un cifrado de bloques modificable (seguro como un PRP fuerte) a cada fragmento de n bits. Para mensajes con longitudes no divisibles por n, los dos últimos bloques se tratan especialmente. El único uso permitido del modo es para cifrar datos en un dispositivo de almacenamiento estructurado por bloques. El ancho estrecho del PRP subyacente y el tratamiento deficiente de los bloques finales fraccionados son problemas. Sería más eficiente pero menos deseable que un cifrado de bloque seguro de PRP (bloque amplio).

MACs (integridad del mensaje pero no cifrado)

ALG1–6 : Una colección de MAC, todas ellas basadas en el CBC-MAC. Demasiados esquemas. Algunos son seguros como VIL PRF, otros como FIL PRF y otros no tienen seguridad comprobable. Algunos de los esquemas admiten ataques dañinos. Algunos de los modos están fechados. La separación de teclas no se atiende adecuadamente para los modos que la tienen. No debe adoptarse en masa, pero es posible elegir selectivamente los "mejores" esquemas. También estaría bien no adoptar ninguno de estos modos, a favor de CMAC. Algunos de los ISO 9797-1 MAC están ampliamente estandarizados y utilizados, especialmente en la banca. Una versión revisada de la norma (ISO / IEC FDIS 9797-1: 2010) pronto será lanzada [93].

CMAC : un MAC basado en el CBC-MAC, el modo es probablemente seguro (hasta el límite de cumpleaños) como un PRF (VIL) (suponiendo que el cifrado de bloques subyacente es un buen PRP). Esencialmente mínima sobrecarga para un esquema basado en CBCMAC. De forma inherente, la naturaleza en serie, un problema en algunos dominios de aplicación, y el uso con un cifrado de bloque de 64 bits requeriría una reingreso ocasional. Más limpio que la colección ISO 9797-1 de MAC.

HMAC : un MAC basado en una función de cifrado criptográfico en lugar de un cifrado de bloque (aunque la mayoría de las funciones de cifrado criptográfico se basan en cifrados de bloque). El mecanismo goza de fuertes límites de seguridad demostrable, aunque no de supuestos preferidos. Múltiples variantes estrechamente relacionadas en la literatura complican obtener una comprensión de lo que se conoce. Nunca se han sugerido ataques dañinos. Ampliamente estandarizado y utilizado.

GMAC : Un MAC basado en nonce que es un caso especial de GCM. Hereda muchas de las características buenas y malas de GCM. Pero el requisito de nonce no es necesario para un MAC, y aquí compra pocos beneficios. Ataques prácticos si las etiquetas se truncan a ≤ 64 bits y la extensión del descifrado no se monitorea ni se reduce. Fallo completo en la no reutilización. El uso es implícito de todos modos si se adopta GCM. No se recomienda para la estandarización por separado.

cifrado autenticado (cifrado e integridad del mensaje)

CCM : un esquema AEAD basado en nonce que combina el cifrado en modo CTR y el CBC-MAC sin formato. Inherentemente serial, limitando la velocidad en algunos contextos. Provablemente seguro, con buenos límites, suponiendo que el código de bloque subyacente sea un buen PRP. Construcción desagradable que demostrablemente hace el trabajo. Más simple de implementar que GCM. Puede ser utilizado como un MAC basado en nonce. Ampliamente estandarizado y utilizado.

GCM : un esquema AEAD basado en nonce que combina el cifrado en modo CTR y una función hash universal basada en GF (2128). Buenas características de eficiencia para algunos entornos de implementación. Buenos resultados, de forma segura y segura, suponiendo un truncamiento mínimo de la etiqueta. Ataques y límites de baja seguridad demostrable en presencia de un truncamiento de etiqueta sustancial. Se puede utilizar como un MAC basado en nonce, que luego se llama GMAC. Opción cuestionable para permitir nonces distintos de 96 bits. Se recomienda restringir los nonces a 96 bits y las etiquetas a al menos 96 bits. Ampliamente estandarizado y utilizado.

Una palabra de introducción: esta respuesta fue en parte una respuesta a muchas de las preguntas que he visto bajo la etiqueta [encryption] que mostraba a las personas que implementaban código totalmente inseguro. Dirigiéndome a estos programadores, escribí la siguiente oración inicial con la intención de sacudirlos lo suficiente como para reconsiderar su enfoque de la criptografía, antes de que su aplicación sea atacada. Si estás aquí en el proceso de aprendizaje, ¡eso es genial! Necesitamos más programadores con conocimientos de base en criptografía. Sigue preguntando y añade un silencioso "¡todavía!" a mi apertura:

Si necesita hacer esta pregunta, es probable que no sepa lo suficiente sobre la criptografía para implementar un sistema seguro.

Sé que esto suena duro, así que déjame ilustrar mi punto: imagina que estás creando una aplicación web y necesitas almacenar algunos datos de sesión. Puede asignar a cada usuario un ID de sesión y almacenar los datos de la sesión en el servidor en el mapeo de hash que asigna el ID de sesión a los datos de la sesión. Pero luego tiene que lidiar con este estado molesto en el servidor y si en algún momento necesita más de un servidor, las cosas se pondrán desordenadas. Entonces, en cambio, tiene la idea de almacenar los datos de la sesión en una cookie en el lado del cliente. Por supuesto, lo cifrará para que el usuario no pueda leer ni manipular los datos. Entonces, ¿qué modo debes usar? Al llegar aquí, leíste la respuesta principal (perdón por haberte seleccionado mi forfork). El primero cubierto, el BCE, no es para usted, desea cifrar más de un bloque, el siguiente, el CBC, suena bien y no necesita el paralelismo del CTR, no necesita acceso aleatorio, por lo que no XTS y las patentes son un PITA, por lo que no hay OCB. Al usar su biblioteca criptográfica, se da cuenta de que necesita algo de relleno porque solo puede cifrar múltiplos del tamaño de bloque. Usted elige PKCS7 porque se definió en algunos estándares de criptografía serios. Después de leer en algún lugar que el CBC es seguro si se usa con un IV aleatorio y un cifrado de bloque seguro, puede estar tranquilo aunque esté almacenando sus datos confidenciales en el lado del cliente.

Años más tarde, después de que su servicio haya alcanzado un tamaño significativo, un especialista en seguridad de TI se comunica con usted en una divulgación responsable. Ella le está diciendo que puede descifrar todas sus cookies usando un ataque oracle de relleno , porque su código produce una página de error si el relleno está roto de alguna manera.

Este no es un escenario hipotético: Microsoft tuvo este defecto exacto en ASP.NET hasta hace unos años.

El problema es que hay muchos escollos con respecto a la criptografía y es extremadamente fácil construir un sistema que parezca seguro para el lego, pero es trivial de romper para un atacante bien informado.

¿Qué hacer si necesita cifrar datos?

Para conexiones en vivo use TLS (asegúrese de verificar el nombre de host del certificado y la cadena del emisor). Si no puede usar TLS, busque la API de nivel más alto que su sistema puede ofrecer para su tarea y asegúrese de que comprende las garantías que ofrece y, lo que es más importante, lo que no garantiza. Sin embargo, para el ejemplo anterior, un marco como Play ofrece instalaciones de almacenamiento del lado del cliente , no invalida los datos almacenados después de un tiempo, y si cambia el estado del lado del cliente, un atacante puede restaurar un estado anterior sin que se dé cuenta.

Si no hay una abstracción de alto nivel disponible, use una biblioteca criptográfica de alto nivel. Un ejemplo destacado es NaCl y una implementación portátil con muchos enlaces de idiomas es Sodium . Al usar una biblioteca de este tipo, no tiene que preocuparse por los modos de cifrado, etc., pero tiene que ser incluso más cuidadoso con los detalles de uso que con una abstracción de mayor nivel, como nunca usar un nonce dos veces.

Si, por algún motivo, no puede utilizar una biblioteca criptográfica de alto nivel, por ejemplo, porque necesita interactuar con el sistema existente de una manera específica, no hay forma de educarse a fondo. Recomiendo leer Ingeniería de Criptografía de Ferguson, Kohno y Schneier . Por favor, no se engañe creyendo que puede construir un sistema seguro sin los antecedentes necesarios. La criptografía es extremadamente sutil y es casi imposible probar la seguridad de un sistema.

Para fines educativos una comparación de los modos.

Sólo encriptación:

Modos que requieren relleno : Como en el ejemplo, el relleno generalmente puede ser peligroso porque abre la posibilidad de rellenar ataques de Oracle. La defensa más fácil es autenticar cada mensaje antes de descifrarlo. Vea abajo.
- ECB cifra cada bloque de datos de forma independiente y el mismo bloque de texto simple dará como resultado el mismo bloque de texto cifrado. Eche un vistazo a la imagen Tux encriptada del ECB en la página de Wikipedia del BCE para ver por qué este es un problema grave. No conozco ningún caso de uso en el que el BCE sea aceptable.
- CBC tiene un IV y, por lo tanto, necesita aleatoriedad cada vez que se encripta un mensaje, cambiar una parte del mensaje requiere volver a cifrar todo después del cambio, los errores de transmisión en un bloque de texto cifrado destruyen completamente el texto simple y cambian el descifrado del siguiente bloque, descifrado puede ser paralelizado / cifrado, el texto plano es maleable hasta cierto punto, esto puede ser un problema .
Modos de cifrado de flujo : estos modos generan un flujo de datos pseudoaleatorio que puede o no depender del texto sin formato. De manera similar a los cifrados de flujo en general, el flujo pseudoaleatorio generado se XOR con el texto sin formato para generar el texto cifrado. Como puede usar tantos bits de la secuencia aleatoria como desee, no necesita ningún tipo de relleno. La desventaja de esta simplicidad es que el cifrado es completamente malleable , lo que significa que un atacante puede cambiar el descifrado de cualquier manera que le guste como en un texto plano p1, un texto cifrado c1 y un pseudoaleatorio ry el atacante puede elegir una diferencia d tal que el descifrado de un texto cifrado c2 = c1⊕d es p2 = p1⊕d, como p2 = c2⊕r = (c1 ⊕ d) ⊕ r = d ⊕ (c1 ⊕ r). Además, el mismo flujo pseudoaleatorio nunca se debe usar dos veces como para dos textos cifrados c1 = p1⊕r y c2 = p2⊕r, un atacante puede calcular el xor de los dos colores planos como c1⊕c2 = p1⊕r⊕p2⊕r = p1⊕p2. Eso también significa que cambiar el mensaje requiere un nuevo cifrado, si el atacante pudo haber obtenido el mensaje original. Todos los siguientes modos de cifrado de vapor solo necesitan la operación de cifrado del cifrado de bloque, por lo que, dependiendo del cifrado, esto podría ahorrar algo de espacio (de silicio o de código de máquina) en entornos extremadamente restringidos.
- El CTR es simple, crea un flujo pseudoaleatorio que es independiente del texto plano, se obtienen diferentes flujos pseudo aleatorios contando desde diferentes nonces / IV que se multiplican por una longitud máxima de mensaje para evitar la superposición, utilizando el cifrado de mensajes de nonces es posible sin aleatoriedad por mensaje, el descifrado y el cifrado se completan en paralelo, los errores de transmisión solo afectan los bits incorrectos y nada más
- OFB también crea un flujo pseudoaleatorio independiente del texto sin formato, se obtienen diferentes flujos pseudoaleatorios comenzando con un nonce diferente o aleatorio IV para cada mensaje, ni el cifrado ni el descifrado son paralelizables, ya que con CTR es posible usar el cifrado de mensajes de nonces sin mensaje aleatoriedad, ya que con los errores de transmisión CTR solo afectan a los bits incorrectos y nada más
- El flujo pseudoaleatorio de CFB depende del texto sin formato, se necesita un nonce diferente o un IV aleatorio para cada mensaje, al igual que con CTR y OFB se puede usar el cifrado de mensajes nonces sin aleatoriedad por mensaje, el descifrado es paralelizable / cifrado no, los errores de transmisión son completamente destruye el siguiente bloque, pero solo afecta los bits incorrectos en el bloque actual
Modos de cifrado de disco : estos modos están especializados para cifrar datos debajo de la abstracción del sistema de archivos. Por razones de eficiencia, cambiar algunos datos en el disco solo debe requerir la reescritura de como máximo un bloque de disco (512 bytes o 4 kib). Están fuera del alcance de esta respuesta ya que tienen escenarios de uso muy diferentes a los otros. No los use para nada excepto para el cifrado de discos a nivel de bloque . Algunos miembros: XEX, XTS, LRW.

Encriptación autenticada:

Para evitar el relleno de ataques de Oracle y los cambios en el texto cifrado, se puede calcular un código de autenticación de mensaje (MAC) en el texto cifrado y descifrarlo solo si no se ha manipulado. Esto se llama encrypt-then-mac y debería preferirse a cualquier otra orden . Excepto en muy pocos casos de uso, la autenticidad es tan importante como la confidencialidad (el último de los cuales es el objetivo del cifrado). Los esquemas de cifrado autenticados (con datos asociados (AEAD)) combinan el proceso de cifrado y autenticación de dos partes en un modo de cifrado de un bloque que también produce una etiqueta de autenticación en el proceso. En la mayoría de los casos, esto resulta en una mejora de la velocidad.

CCM es una combinación simple de modo CTR y CBC-MAC. El uso de dos cifrados de cifrado de bloque por bloque es muy lento.
OCB es más rápido pero está gravado por las patentes. Sin embargo, para el software libre (como en libertad) o no militar, el titular de la patente ha otorgado una licencia gratuita .
GCM es una combinación muy rápida pero posiblemente compleja de modo CTR y GHASH, un MAC sobre el campo Galois con 2 ^ 128 elementos. Su amplio uso en importantes estándares de red como TLS 1.2 se refleja en una instrucción especial que Intel ha introducido para acelerar el cálculo de GHASH.

Recomendación:

Teniendo en cuenta la importancia de la autenticación, recomendaría los siguientes dos modos de cifrado de bloque para la mayoría de los casos de uso (excepto para propósitos de cifrado de disco): Si los datos se autentican mediante una firma asimétrica, use CBC, de lo contrario use GCM.

No se debe utilizar ECB si se encripta más de un bloque de datos con la misma clave.
CBC, OFB y CFB son similares, sin embargo, OFB / CFB es mejor porque solo necesita cifrado y no descifrado, lo que puede ahorrar espacio de código.
CTR se utiliza si desea una buena paralelización (es decir, velocidad), en lugar de CBC / OFB / CFB.
El modo XTS es el más común si está codificando datos de acceso aleatorio (como un disco duro o RAM).
OCB es, con mucho, el mejor modo, ya que permite el cifrado y la autenticación en una sola pasada. Sin embargo, hay patentes en EE.UU.

Lo único que realmente debe saber es que el BCE no debe usarse a menos que solo esté cifrando 1 bloque. Se debe usar XTS si está cifrando datos de acceso aleatorio y no una transmisión.

SIEMPRE debes usar IV ''s únicos cada vez que cifres, y deben ser random . Si no puede garantizar que sean random , use OCB ya que solo requiere un nonce , no un IV , y hay una diferencia clara. Un nonce no elimina la seguridad si las personas pueden adivinar la siguiente, una IV puede causar este problema.