Un cifrado de bloque como AES es determinista: para la misma clave y la misma entrada, obtienes la misma salida. Debido a que los datos de la vida real tienden a mostrar redundancia, esto hace que el BCE, el modo de cifrado más básico, bastante débil . CBC intenta evitar ese problema "aleatorizando" los bloques de entrada, a través de un XOR con el bloque cifrado anterior: la idea es que la salida de un cifrado de bloque debe parecer "lo suficientemente aleatoria". El AES sigue siendo determinista, pero la aleatorización asegura que el riesgo de colisión seguirá siendo muy bajo (AES tiene bloques de 128 bits, por lo que la primera colisión se debe encontrar después de cifrar, en promedio, aproximadamente 2 64 bloques, que son 256 exabytes, también conocidos como "una gran cantidad de datos"; esto no sucederá a menudo). Como el primer bloque no tiene un bloque anterior, necesitamos un "bloque anterior artificial" y ese es el IV. Por lo tanto, el IV debe ser "de apariencia aleatoria".
Una primera observación básica es que una simple política de +1 en la IV puede no ser lo suficientemente aleatoria. Imagine que encripta mensajes que contienen algunos datos como una lista de pares "clave = valor" (por ejemplo, la codificación estándar de un objeto Java Properties ), y que todos los mensajes comienzan con userPassword = thepassword (para varias contraseñas de usuario). Con AES y sus bloques de 16 bytes, tenga en cuenta que el primer bloque termina inmediatamente después de la primera letra de la contraseña. Por lo tanto, los primeros bloques sucesivos serán casi idénticos, a excepción de su último byte. Supongamos que el IV y los mensajes son:
IV message
--------------------------------------------------------------------------------
5c17eacc047fd32fdecc2e0f226e4e86 userPassword = mypassword
5c17eacc047fd32fdecc2e0f226e4e87 userPassword = PaSSwo3D!
5c17eacc047fd32fdecc2e0f226e4e88 userPassword = bob
5c17eacc047fd32fdecc2e0f226e4e89 userPassword = z!Ghj0$.\+
5c17eacc047fd32fdecc2e0f226e4e8a userPassword = anotherpassword
5c17eacc047fd32fdecc2e0f226e4e8b userPassword = correcthorsebatterystaple
Si calcula los valores para el primer bloque pasado como entrada al AES para cada mensaje, encontrará que para el primer y quinto mensaje terminará con el mismo bloque (29648fbe541ea05ca9a35c6b02536ee7). Así que los primeros dieciséis bytes de los dos mensajes cifrados serán idénticos. Al detectar esa igualdad, el atacante deducirá exactamente qué bits difieren en el primer byte de cada contraseña. Al observar muchos mensajes sucesivos, el atacante puede acumular muchas de estas ecuaciones en los datos desconocidos. Este es exactamente el tipo de fuga que debe evitar un buen cifrado.
La situación es mucho peor en presencia de ataques de texto sin formato elegido : estos son ataques donde el villano Consigue elegir parte del texto plano. En el ejemplo descrito anteriormente, suponga que el atacante es uno de los usuarios y que su contraseña está en el primer mensaje. Por lo tanto, el atacante sabe que su contraseña comienza con una 'm'; Al observar el cifrado de los mensajes sucesivos, infiere que la contraseña en el quinto mensaje comienza con una 'a'. Además, el atacante puede cambiar su contraseña y volver a intentarlo, obtener información sobre otras contraseñas, etc.
El recientemente anunciado BEAST attack se basa en un CPA, en un escenario más realista que involucra un navegador web, una conexión HTTPS y una cookie de Paypal "segura". La piedra angular del ataque es que los datos en una conexión SSL se dividen en "registros", cada registro se cifra en modo CBC y el último bloque de un registro se usa como IV para el siguiente. El atacante luego fuerza sus propios datos en la conexión, observa el primer registro, y calcula a partir de eso los datos que luego agrega (que se cifrarán como el segundo registro), de modo que el primer bloque de esos datos XORed con el IV produce un valor predecible. Los detalles son intrincados, pero terminan revelando la cookie segura. Para que el ataque funcione, todo lo que necesita el atacante es un predecible IV, que obtiene al observar los registros ( TLS 1.1 lo corrige al agregar IV por registro aleatorio).
Para resumir, el ataque BEAST demuestra que el CBC con un IV que puede predecir un atacante que puede realizar ataques de texto sin formato elegido es débil. Una política de +1 para la administración de IV conduce a IV que puede predecirse fácilmente. Por lo tanto ...
Se debe tener en cuenta que si bien el CBC requiere un IV aleatorio, uniforme e impredecible, no todos los modos de operación de cifrado de bloque son tan exigentes. Muchos modos nuevos y geniales, especialmente aquellos que combinan el cifrado y la verificación de integridad, pueden vivir con IV no repetitivo, incluso si los valores IV son totalmente no aleatorios (por ejemplo, EAX o GCM ); Para ellos, un +1 en IV está perfectamente bien. En algunos protocolos, esto permite un implícito IV (un número de secuencia, para mensajes sucesivos enviados a través de un cable) que puede ahorrar un poco de ancho de banda.
No usar un IV aleatorio con modo CBC es una vulnerabilidad reconocida por CWE-329
El atacante casi siempre conoce la IV, e idealmente este valor es inútil sin la clave secreta.
Sin embargo, si el atacante sabe cuál será el IV para un determinado mensaje de texto sin formato o si el atacante puede controlar el mensaje, entonces puede calcular todas las claves posibles para esa combinación de Mensaje + IV. El cifrado producido por este Mensaje + IV + Clave se puede buscar en la tabla precomputada para obtener la clave secreta en un período de tiempo muy corto.
Hice esta pregunta en Stack Overflow y erickson dio una gran respuesta .
Lea otras preguntas en las etiquetas encryption aes