está encriptado pero no firmado, ¿debilidad?

Question

A través de los años he encontrado este escenario más de una vez. Tiene una gran cantidad de datos relacionados con el usuario que desea enviar de una aplicación a otra. Se espera que la segunda aplicación "confíe" en este "token" y use los datos que contiene. Se incluye una marca de tiempo en el token para evitar un ataque de robo/reutilización. Por la razón que sea (no nos preocupemos aquí), se ha elegido una solución personalizada en lugar de un estándar industrial como SAML.

Para mí, parece que la firma digital de los datos es lo que desea aquí. Si los datos deben ser secretos, también puede encriptarlos.

Pero lo que veo mucho es que los desarrolladores usarán encriptación simétrica, p. AES. Están asumiendo que, además de hacer que los datos sean "secretos", el cifrado también proporciona 1) integridad del mensaje y 2) confianza (autenticación de la fuente).

¿Tengo razón en sospechar que hay una debilidad inherente aquí? En su valor nominal, parece funcionar, si la clave simétrica se gestiona correctamente. Al carecer de esa clave, ciertamente no sabría cómo modificar un token encriptado, o lanzar algún tipo de ataque criptográfico después de interceptar varios tokens. ¿Pero un atacante más sofisticado podría explotar algo aquí?

Answer 1

Parte de esto depende del modo de encriptación. Si usa BCE (¡Qué vergüenza!) Podría intercambiar bloques, alterando el mensaje. Stackoverflow got hit by this very bug.

Menos amenazante: sin ninguna comprobación de integridad, podría realizar un ataque de hombre en el medio e intercambiar todo tipo de bits, y lo recibiría e intentaría descifrarlo. Por supuesto, fallarías, pero el intento puede ser revelador. Hay ataques de canal lateral de "Bernstein (explotando una combinación de caché y características microarquitectónicas) y Osvik, Shamir y Tromer (explotando las colisiones de caché) dependen de obtener datos estadísticos basados ​​en una gran cantidad de pruebas aleatorias". 1 El artículo es una nota al pie por un criptógrafo de mayor nota que yo, y aconseja reducir la superficie de ataque con un MAC:

si puede asegurarse de que un atacante que no tiene acceso a su MAC clave no puede nunca alimentar el mal de entrada a un bloque de código , sin embargo, que reducir drásticamente la posibilidad de que será capaz de aprovechar cualquier error

Answer 2

Un enfoque de encriptación simétrica es tan seguro como la clave. Si a ambos sistemas se les puede dar la clave y mantener presionada la tecla de forma segura, esto está bien. La criptografía de clave pública es sin duda un ajuste más natural.

Answer 3

Sip. El cifrado solo no proporciona autenticación. Si desea autenticación, debe usar un código de autenticación de mensaje, como HMAC o firmas digitales (según sus requisitos).

Hay un número bastante grande de ataques que son posibles si los mensajes solo están encriptados, pero no autenticados. Aquí hay solo un ejemplo muy simple. Suponga que los mensajes se cifran usando CBC. Este modo usa una IV para aleatorizar el texto cifrado de modo que al cifrar el mismo mensaje dos veces no se obtenga el mismo texto cifrado. Ahora mira lo que sucede durante el desencriptado si el atacante simplemente modifica el IV pero deja el resto del texto cifrado como está. Solo cambiará el primer bloque del mensaje descifrado. Además, exactamente esos bits cambiaron en el cambio IV en el mensaje. Por lo tanto, el atacante sabe exactamente qué cambiará cuando el receptor descifre el mensaje.Si ese primer bloque fue, por ejemplo, una marca de tiempo que el atacante conoce cuando se envió el mensaje original, entonces puede arreglar fácilmente la marca de tiempo en cualquier otro momento, simplemente volteando los bits correctos.

También se pueden manipular otros bloques del mensaje, aunque esto es un poco más complicado. Tenga en cuenta también que esto no es solo una debilidad de CBC. Otros modos como OFB, CFB tienen debilidades similares. Así que esperar que solo el cifrado proporcione autenticación es solo una suposición muy peligrosa