En el modo de operación CBC, el texto cifrado del bloque anterior se usa como IV en el siguiente bloque. Entonces, ¿cómo se puede utilizar AES-CBC para el cifrado de disco (LUKS), cuando los datos en el disco (es decir, el texto cifrado) siguen cambiando?
Cada vez que se escriben datos en el disco, se cambia el texto cifrado. Obviamente, no puede ser que todos los bloques subsiguientes deban recalcularse con el IV modificado. Debe haber algún otro mecanismo.
¿Cómo funciona?
Este es realmente un problema bastante complicado sin una solución perfecta.
Si el sistema de archivos era uno donde los datos se escriben solo una vez y se escriben de manera totalmente secuencial, sería adecuado un solo cifrado CBC desde el inicio de los medios hasta el final. Puedes hacer descifrado de acceso aleatorio de CBC, solo necesitas leer un bloque de cifrado adicional. Esto podría funcionar para encriptar algo como ISO9660.
Pero cuando se requieren escrituras de acceso aleatorio, no funcionará un solo cifrado CBC de todos los medios.
Formas de elegir un IV
En su lugar, uno tiene que cifrar cada sector con un nuevo IV. Esto conduce a un nuevo problema, que es que los datos cifrados son más grandes que el texto sin formato. Si los medios subyacentes fueron diseñados para ser utilizados con un cifrado seguro, muy bien podrían haber sido diseñados para usar sectores físicos ligeramente más grandes para resolver ese problema. No he encontrado ningún medio en este caso. Los CD tienen un tamaño de bloque físico inusual, pero las razones históricas de esto no están relacionadas con el cifrado.
Ante el problema de dónde almacenar el IV, se han visto varias formas de cortar esquinas. El primer y muy pobre enfoque fue simplemente usar el número de sector como IV.
El número de sector es predecible. Y un adversario puede construir fácilmente patrones de datos que harán que el IV en sectores vecinos se cancele con patrones en los datos y dé lugar a dos sectores vecinos en los medios cifrados que tengan texto cifrado exactamente idéntico. Varios productos de cifrado de almacenamiento han tenido esta vulnerabilidad.
Un enfoque ligeramente mejor es cifrar el número de sector y usarlo como IV. Si solo tiene una única instantánea de los medios cifrados, no conozco ninguna forma de explotar esto. Sin embargo, las copias de seguridad, los sectores reasignados en los discos duros, la nivelación del desgaste en SSD, el uso de SAN, etc. pueden llevar a escenarios en los que un adversario puede ver más de un cifrado de texto cifrado con el mismo IV. En ese punto, el adversario podrá ver cuántos bloques de cifrado desde el inicio de los datos son idénticos entre las dos versiones.
Un enfoque aún mejor es calcular un hash criptográfico del número de sector y todo el texto sin formato, excepto el primer bloque del sector. Luego encripta el hash y úsalo como IV. Entonces, si está utilizando AES, que tiene un tamaño de bloque de 16 bytes, y encripta sectores de 512 bytes, tendría el número de sector y 496 bytes del sector. Esto significa que la reutilización IV solo ocurre si escribe exactamente los mismos datos en el mismo número de sector. Esto sigue siendo una fuga, aunque uno muy pequeño en comparación con el simple uso del número de sector como IV. Desafortunadamente, el paso de hash aumenta el uso de la CPU para este enfoque.
Utilizando un IV aleatorio
Puede usar un IV aleatorio si de alguna manera puede almacenar los datos adicionales. Pero si los sectores físicos y lógicos tienen tamaños idénticos, esto significa que cada vez que se escribe un sector de texto sin formato, debe escribir dos sectores físicos. Este es un problema importante porque si se interrumpe una operación de escritura, perderá datos. La escritura detrás del almacenamiento en caché puede abordar la desaceleración asociada a la necesidad de múltiples escrituras, pero empeora el riesgo de pérdida de datos.
El diario podría resolver el problema de pérdida de datos. Pero en ese punto, estaría moviendo mucha funcionalidad a la capa de cifrado, que normalmente desearía en una capa diferente.
GBDE es el único ejemplo que conozco sobre el uso de un diseño de disco en el que cada sector lógico se almacena como los 512 + 16 bytes completos en el disco. Esto significa que cada 32 sectores lógicos se almacenan como 33 sectores físicos. Sin embargo, se diseñó sin la capa de registro por diario, lo que significa que existe un riesgo de pérdida de datos. Además, el autor de GBDE inventó su propio PRNG que resultó ser débil, por lo que no es un gran ejemplo de cómo diseñar un cifrado de almacenamiento.
Alternativas a CBC
Los muchos casos de IV mal elegidos para el CBC han llevado a una percepción bastante común de que el CBC es débil. Por esas razones, se han considerado alternativas a CBC para el cifrado de almacenamiento. Sin embargo, algunas de las alternativas que se han propuesto son incluso peores, por ejemplo, se ha propuesto utilizar el modo CTR, que genera un pad de una sola vez pseudoaleatorio. El simple uso de esto para cifrar un medio llevará a la reutilización de partes del teclado de una sola vez cada vez que escriba en un sector que se haya escrito anteriormente.
La mayoría del uso de CBC en el cifrado de almacenamiento, así como todas las alternativas que he visto, tienen algo en común. Cifran un sector de texto plano lógico en un solo sector de texto cifrado físico del mismo tamaño. Esto significa que ninguno de ellos puede lograr seguridad semántica.
Lea otras preguntas en las etiquetas disk-encryption aes luks