¿Cuál es la debilidad de Key-MD5 para la autenticación de mensajes?

4

He visto API web públicas que utilizan el MD5 con clave para generar un código de autenticación de mensaje en lugar de adoptar el algoritmo HMAC. La gente no solo inventaría HMAC por diversión, por lo que debe tener algunas ventajas sobre el MD5 con clave. (Sin embargo, tenemos un estándar de autenticación MD5 con clave descrito en RFC 1828 ). ¿Existe alguna vulnerabilidad conocida de Key-MD5? como un algoritmo de MAC en comparación con HMAC?

De RFC 1828 - Autenticación de IP usando Keyed MD5 :

   The form of the authenticated message is

            key, keyfill, datagram, key, MD5fill
    
pregunta Simon Liu 22.07.2015 - 12:11
fuente

1 respuesta

2

El "MD5 con llave" descrito en RFC 1828 se puede resumir de la siguiente manera: para la tecla K y datos D , el valor MAC es MD5 ( K || D || K ) (en el RFC, K se rellena primero con un múltiplo de longitud de 512 bits, pero aquí no cambia sustancialmente las cosas). Que yo sepa, no hay debilidad conocida en esa construcción, pero tampoco hay mucho análisis de seguridad.

HMAC se ha diseñado para proporcionar seguridad cuando se utiliza con una función hash que se basa en Merkle–Damgård construction . Se ha demostrado que SI la "función de compresión" interna de la función hash actúa como una familia de funciones pseudorandom , entonces HMAC es seguro. No conocemos ninguna prueba de seguridad similar para la construcción del "hash codificado". En ese sentido, creemos más en la seguridad de HMAC que en la seguridad del "hash codificado".

Si las funciones hash fueran "perfectas" en un sentido que se relaciona con la noción de oracles aleatorios , entonces el hash con clave sería "obviamente" seguro, como una serie de otras construcciones, por ejemplo, h ( K || D ). Este último ejemplo recae en el ataque de extensión de longitud cuando la función hash usa la construcción MD (que es el caso de MD5 pero también SHA-1, SHA-256 ...); esto no afecta directamente al "hash codificado" de RFC 1828, pero es suficiente para demostrar que las funciones de hash basadas en MD no son perfectas en el sentido aludido anteriormente, y por lo tanto la seguridad de cualquier construcción de MAC no puede simplemente asumirse. Necesitamos más detalles, y con HMAC tenemos estos detalles.

Algunas notas adicionales:

  • El "ataque de extensión de longitud" no contradice la seguridad clásica de la función hash , es decir, resistencia a Preimágenes, segundas preimágenes y colisiones. En particular, SHA-256 y SHA-512 se consideran "seguros" y, sin embargo, están incluidos en el alcance del ataque de extensión de longitud.

  • Las colisiones no son un problema aquí, y, más generalmente, no son un problema en construcciones que usan entradas desconocidas para el atacante (como es habitual en MAC, debido a la clave). Sabemos cómo producir colisiones para MD5 de manera muy eficiente; pero no sabemos cómo atacar HMAC / MD5 o incluso el "MD5 con clave". (Es posible diseñar un MAC ideado que use MD5 y sea débil debido a las colisiones de MD5, pero no es el caso de HMAC ni del "MD5 codificado" que estamos discutiendo aquí.)

  • Por el contrario, mientras que las colisiones no se aplican a HMAC, la mera existencia de métodos eficientes para calcular las colisiones MD5 demuestra que la función de compresión interna de MD5 es no un PRF, y por lo tanto el HMAC La prueba de seguridad no se aplica a HMAC / MD5. Es una pena, ya que el objetivo principal de usar HMAC y no el "hash codificado" es beneficiarse de la prueba de seguridad. Sin embargo, tenga en cuenta que la falta de pruebas de seguridad no significa que los ataques sean posibles; solo que si se encuentra un ataque, entonces no contradeciría la prueba de seguridad HMAC genérica.

respondido por el Thomas Pornin 22.07.2015 - 14:30
fuente

Lea otras preguntas en las etiquetas