En otra pregunta, respuesta , DW escribió:
Asegúrese de que haya protección de autenticidad para los datos cifrados (por ejemplo, cifrar y luego firmar / MAC): necesitará protección de confidencialidad y autenticidad. Un error muy común es cifrar pero no firmar; este error puede introducir problemas de seguridad sutiles
¿Cuáles son exactamente esos problemas de seguridad?
Un buen ejemplo es la falla en CBC, demostrada dentro de SSL y en particular para la recuperación de contraseña en una configuración de IMAP sobre SSL. Consulte para obtener más información . En pocas palabras, SSL tiene un MAC, pero una pequeña parte de él hacía cosas con los datos cifrados recibidos después de descifrado pero antes verificando el MAC . Es decir, el sistema de recepción estaba descifrando los datos, verificando que el relleno era correcto, informaba de un error al interlocutor si ese no era el caso, y luego solo revisaba el MAC. El mensaje de error era diferente si el MAC estaba equivocado. Por lo tanto, el receptor (el servidor, en el caso de la recuperación de la contraseña de IMAPS) estaba perdiendo un solo bit de información sobre si el relleno encontrado después del descifrado era correcto o no. Sucede que SSL utiliza un relleno similar al descrito en PKCS # 5. Los detalles son sutiles (pero no matemáticamente difíciles, una vez que entiendes que XOR es conmutativo y asociativo) pero permitió al atacante, al modificar algunos bytes bien elegidos, adivinar uno por uno los bytes de datos simples. Asumiendo un intento de conexión regular con contenidos idénticos (por lo general, un Outlook Express que verifica el servidor por correo nuevo cada 5 minutos), el atacante tenía 1/256 de probabilidades de adivinar un nuevo byte en cada conexión. Al final del día, ¡voilá! una contraseña completa.
Este caso muestra lo que puede suceder en presencia de atacantes activos y no MAC, incluso cuando la parte "no MAC" es muy transitoria; porque SSL tiene un MAC, solo se verificó demasiado tarde en el proceso. La corrección es siempre verificar el MAC, independientemente de si el relleno fue bueno o no, y reportar un mal relleno y un MAC incorrecto con el mismo código de error (debe verificar el MAC, porque no lo hace si el relleno es incorrecto puede hacer que el servidor responda un poco demasiado rápido en ese caso, perdiendo el bit de información a través del tiempo) Sin esa corrección, el servidor pierde cierta información a través de su comportamiento, ya sea un mensaje de error distinto o incluso un ligero retraso (o falta de ella) al responder. Eso es un bit único en cada intento. Sin embargo, es suficiente montar un ataque de recuperación de contraseña.
Ese ataque se publicó en 2002. Sin embargo, en 2010, el mismo error todavía estaba presente en cómo ASP maneja cookies encriptadas , permitiendo que un atacante activo secuestre una sesión protegida en menos de una hora. El ataque se demostró como práctico en 2002; en 2010, se demostró que se practicaba realmente en el campo.
No tenemos una lista exhaustiva de los ataques posibles por la falta de MAC. Entonces, la opinión general es que no hay una seguridad adecuada contra un atacante activo cuando no hay una verificación de integridad dedicada, y eso es un MAC. El error común es creer que en cualquier situación, los atacantes solo pueden ser pasivos. Las comunicaciones alámbricas e inalámbricas están sujetas a ataques activos, incluso por parte de personas malas de baja potencia (por ejemplo, estudiantes aburridos en un cibercafé).
Al realizar un cifrado simétrico, la forma correcta de agregar un MAC es utilizar un modo combinado de cifrado y MAC como GCM o EAX . Estos son modos que se basan en un cifrado de bloque (típicamente AES). Hay otros modos similares, pero algunos están patentados; estos dos se cree que no son.
Las firmas (a diferencia de MAC) son un asunto totalmente distinto, en particular en su relación con la confidencialidad.
Lea otras preguntas en las etiquetas cryptography encryption digital-signature