¿Por qué TLS 1.3 eliminó AES-CBC?

El problema aquí no es tanto con CBC, sino con alternativas que son más fáciles de implementar de manera segura, sin perder la seguridad matemática. De hecho, AES-CBC resultó ser muy difícil de implementar correctamente. Recuerdo que las implementaciones anteriores de seguridad de la capa de transporte no tienen vectores de inicialización criptográficamente seguros, que son indispensables para el modo CBC

Muchos de los ataques recientes están rellenando ataques de Oracle, como el ataque de Bleichenbacher . Estos dependen especialmente de los modos antiguos mantenidos para soporte. POODLE es una vulnerabilidad de downgrade. LOGJAM está reduciendo la calificación de TLS a antiguas suites criptográficas de grado de exportación (leer saboteada por la NSA).

Para el modo CBC, existe el ataque Vaudenay. Estos ataques dependen de que el servidor diga explícitamente "relleno no válido", por lo que pierde 1 bit de información en cada transacción. Se eliminaron los mensajes de error, pero el problema del tiempo se mantuvo. El servidor aún usaba más tiempo antes de responder si el relleno era válido.

En respuesta, se vieron obligados a encontrar la solución peculiar de generar una clave ficticia y usarla para descifrar, por lo que fallaría en otra parte de la implementación. En cada implementación. Así que decidieron no forzar más eso en los desarrolladores al admitirlo en las especificaciones.

La criptografía es un campo muy amplio y una especialidad en sí misma. La historia había aprendido a través de la experiencia incómoda, que hacerlo correctamente es imposible hacerlo perfectamente, incluso para los mejores en el campo. Por ejemplo, el MD5, creado por Ron Rivest, co-inventor (y parte del mismo nombre) de RSA se usó ampliamente y luego se rompió en 2013. Su resistencia a la colisión fue eludida en 2 ^ 18, menos de un segundo en una computadora de escritorio para hashes de 128 bits.

CBC es un buen modo de cifrado si se implementa correctamente. En una breve oración, he señalado dos defectos de CBC.

• CBC es solo un modo de cifrado: proporciona confidencialidad, pero no autenticidad o integridad. Es necesario autenticar los datos por separado. Se puede hacer, por supuesto, y esa era la única manera de hacerlo antes de TLS 1.2. Pero es difícil hacerlo bien , que Es por eso que se recomiendan los modos de cifrado autenticados . TLS 1.3 empuja GCM en lugar de CBC + HMAC.
• CBC es difícil de implementar correctamente. Está el problema de cómo combinarlo con un MAC que ya mencioné. Otro problema es que no filtre información a través de errores de relleno . La IV realmente debe ser aleatoria; una IV que está influenciada por un adversario es inseguro y es al menos un BEAST .

Si es tan difícil de implementar correctamente, es mejor que no esté permitido por el protocolo. El diseño de criptografía avanza lentamente desde tener unos pocos primitivos flexibles y bien estudiados a unos pocos primitivos sólidos y bien estudiados, porque en la práctica el problema es menos que las personas no pueden hacer lo que quieren, pero más que hacer cosas. que funcionan en el caso nominal pero caen a los ataques.

"Por qué" siempre es difícil de responder sin especulación. En el caso de la criptografía, nuestras mejores guías para el futuro son los ataques del pasado. En este caso en particular, simplemente tener presente la implementación de CBC defectuosa contribuyó al ataque POODLE.

Ahora podemos pensar que todos saben que deberían probar sus esquemas de bytes de relleno, pero eso es solo una suposición. Lamentablemente, muchas personas dejan de realizar pruebas una vez que obtienen los buenos resultados que esperan, sin asegurarse de que no haya efectos secundarios en sus sobras.

Ahora, considere el costo de implementar TLS 1.3. Escribir el código es fácil. Pero los desarrolladores luego tendrán que probar una pesadilla combinatoria de versiones, algoritmos, intercambios de claves, etc. Y sabemos que los atacantes con frecuencia han explotado los protocolos al combinar elementos de formas inesperadas y novedosas. Cualquier cosa que puedan tirar fuera de la suite hace que estudiarla y probarla en órdenes de magnitud sea más simple.

¿Era realmente culpable el CBC, o simplemente condujo por un camino donde un error inesperado creó una vulnerabilidad? La respuesta es si ese es un camino que no necesitamos, tal vez lo mejor sea cerrarlo por completo, reduciendo la superficie de ataque.

Creo que AES-CBC sigue siendo bueno, siempre que lo uses correctamente . Debido a que TLS usa mac-then-encrypt, es un campo peligroso que permite múltiples vulnerabilidades. Las implementaciones actuales de TLS contienen varios hacks para implementarlo (con suerte) de forma segura. Por ejemplo, cuando un compañero ve un relleno no válido, simplemente destruye algunos datos (probablemente a través de xor) para interrumpir la comprobación de MAC un tiempo después. Todo el proceso debe tomar la misma cantidad de tiempo independientemente del tipo de error (relleno incorrecto o error de MAC) y la posición de error para no filtrar ninguna información en el tiempo.

Eliminar CBC es una forma de solucionarlo para la nueva versión del protocolo. Usar cifrar y luego mac sería otra forma, pero esto AFAIK cambiaría las estructuras de TLS, lo que podría causar dificultades de implementación, supongo. Cambiar las estructuras del protocolo podría ser doloroso en el código que admite varias versiones de TLS. Como hay otros modos buenos, probablemente sea más fácil cambiarlos que cambiar las estructuras de protocolo.