¿Ataque de tiempo contra HMAC en cifrado autenticado?

15

En una respuesta a otra pregunta mía , se observó que una clase que usa funciones de comparación de cadenas estándar cuando revisar el HMAC en cifrado autenticado haría a la clase vulnerable a ataques de tiempo contra el HMAC.

No puedo ver cómo este es un problema con un ataque de tiempo contra el HMAC del cifrado autenticado.

En primer lugar, las implementaciones deben ser consideradas conocidas por el atacante (en este caso particular, la fuente simplemente se publica), por lo que la única clave secreta sería la clave. Siguiendo esta línea de razonamiento, ¿cómo protegería contra cualquier cosa una función de comparación de tiempo constante en la implementación? (Espero que el atacante simplemente lo elimine, si incluso usara el mismo código).

Y segundo, si quisiera pensar en la implementación como una caja negra, la comparación es contra un HMAC de los datos con una clave derivada de PBKDF2. ¿El intento de un ataque de tiempo contra el HMAC no sería tan lento como tratar de forzar con fuerza una contraseña protegida por PBKDF2 b) en realidad no revelaría información útil en ningún intento de descifrar los datos? (el HMAC incluso se adjunta al texto cifrado, disponible para todos los que tengan acceso a los datos cifrados).

Entonces, ¿qué es lo que me falta aquí, ¿por qué los ataques de tiempo en este escenario se consideran un riesgo que debe protegerse?


Actualización rápida:
Entiendo cómo funcionan los ataques de tiempo, pero no comprendo qué se obtendría al emplear un ataque de tiempo en un escenario en el que la función de descifrado se vea así:

/**
 * @param binary $data Where $data = salt, IV, encrypted data, HMAC(salt, IV, encrypted data)
 * @param string $password The decrypt-password
 * @return string|null plain text if data was successfully decrypted, null otherwise
 */
function decrypt($data, $password) {
    ...
}
    
pregunta Monika 08.12.2014 - 16:42
fuente

2 respuestas

10

El riesgo es que un atacante pueda falsificar datos. En otras palabras, pueden crear su propio texto cifrado y luego calcular el HMAC esperado para que su sistema acepte la entrada como válida.

El punto central de la HMAC es que solo usted como propietario de la clave puede "firmar" los datos. Sin embargo, si la aplicación filtra información sobre el HMAC esperado de la entrada, entonces un atacante puede "firmar" sus propios datos.

En pocas palabras, funciona así:

El atacante ha generado algunos datos y desea que su sistema los acepte. Para eso, necesitan saber el HMAC correcto. Como el atacante no tiene la clave, no pueden simplemente calcular el HMAC. Sin embargo, al medir las diferencias de tiempo sutiles, pueden "preguntarle" a su sistema el valor esperado:

  • Atacante: "Tengo este dato, y supongo que el HMAC comienza con el byte 0x00. ¿Es esto correcto?
  • Tú: "No."
  • Atacante: "¿La HMAC comienza con 0x01?"
  • Tú: "No."
  • ...
  • Atacante: "¿La HMAC comienza con 0xAB?"
  • Usted: "Sí, el primer byte es correcto".
  • Atacante: "OK. ¿El siguiente byte es 0x00? "
  • Tú: "No."
  • ...

Al final, el atacante conoce todos los bytes.

El problema es que la aplicación no solo rechaza el HMAC incorrecto. En realidad, ayuda al atacante diciéndoles cómo debe verse el HMAC

Mirando tu actualización, parece que generalmente no entiendes el propósito de HMAC y por qué es importante.

Digamos que no había HMAC. En ese caso, solo protegerá la confidencialidad de los datos, no su integridad . La gente podría manipular el texto cifrado existente o crear su propio texto cifrado, y su aplicación con gusto lo convertiría en cualquier texto plano que aparezca. En muchos casos, este es un problema grave. Piense en una cookie de sesión cifrada que contenga el ID de usuario: no quiere que la gente cambie eso.

Por lo tanto, agrega un HMAC como una especie de "firma" para evitar que los usuarios manipulen el texto cifrado. Quieres confidencialidad y integridad. Sin embargo, si un usuario puede encontrar el HMAC correcto para datos arbitrarios, todo el ejercicio no tiene sentido. Pierde la protección de integridad y vuelve al cifrado simple. Ahora, de nuevo, cualquiera puede meterse con el texto cifrado.

    
respondido por el Fleche 08.12.2014 - 17:31
fuente
22

Permite el potencial de una falsificación existencial. Un atacante puede crear un HMAC válido para un mensaje elegido sin conocer la clave HMAC.

Básicamente, la forma en que funciona el ataque es la siguiente:

  1. El atacante envía un mensaje y un HMAC (en realidad, solo una secuencia de bytes de la misma longitud que el HMAC) y cronometra la respuesta del sistema de descifrado.

  2. El atacante luego envía el mismo mensaje, y el mismo pseudo-HMAC repetidamente, con la excepción de que ahora itera cada (256) valor posible para el primer byte del HMAC.

  3. Si el sistema de descifrado está devolviendo un error inmediatamente al encontrar una falta de coincidencia entre los bytes, una de estas iteraciones (la que tiene el mismo valor del primer byte calculado por el sistema de descifrado) debería tomar ligeramente más tiempo para volver. Si el atacante puede detectar esa diferencia, ahora conoce el primer byte correcto para el HMAC correcto para el mensaje dado la clave HMAC del sistema de descifrado.

  4. El atacante envía el mismo mensaje y HMAC, esta vez con el primer byte correcto conocido, iterando sobre el segundo byte, hasta que de nuevo, encuentra el byte que hace que el sistema de descifrado tarde un poco más en responder con un error. El atacante ahora sabe el segundo byte del HMAC correcto.

  5. Enjuague y repita para cada byte sucesivo en el HMAC, hasta que se haya derivado un HMAC válido para el mensaje elegido por el atacante, sin clave.

Esta es la razón por la que la comparación HMAC debe ser constante, comparando todos los bytes del HMAC enviado con el HMAC calculado antes de devolver una respuesta. De esta manera, sin importar la posición de los bytes incorrectos, el tiempo de error siempre será igual. El atacante ya no tiene una manera de decir qué o dónde están los bytes incorrectos.

Actualizar

En el escenario específico que presenta, el HMAC le brinda protección de integridad o es la pieza de "autenticación" del "cifrado autenticado". Si un atacante puede falsificarlo, el texto cifrado puede modificarse sin su conocimiento, y ya no tendrá cifrado autenticado, sino cifrado no autenticado y será vulnerable a los ataques de texto cifrado elegidos.

    
respondido por el Xander 08.12.2014 - 17:08
fuente

Lea otras preguntas en las etiquetas