Determinar la potencia de HMAC truncada

Los detalles son importantes.

Como @Ricky señala, mostrar valores HMAC truncados no ayudará al atacante a encontrar la clave secreta, en comparación con una situación similar en la que los valores HMAC no se truncarían. Esto tiene sentido: el truncamiento solo elimina información.

Sin embargo , el atacante no está en última instancia después de la clave secreta. Lo que realmente quiere el atacante es hacer falsificaciones , es decir, calcular algunos valores HMAC que la computadora aceptará como propios. Descubrir la clave secreta permite realizar falsificaciones, pero la capacidad de realizar falsificaciones no implica necesariamente el conocimiento de la clave privada.

Afortunadamente , HMAC tiende a comportarse como un PRF , por lo que existen dos métodos conocidos para hacer una falsificación:

1. Realice una enumeración de fuerza bruta de las claves posibles hasta que se encuentre la correcta (una que coincida con algunos valores conocidos + pares HMAC). Este ataque se derrota al elegir que la clave esté en el espacio lo suficientemente grande como para hacer que la enumeración sea poco realista (es decir, se genera una clave de 128 bits con un PRNG criptográficamente sólido).

2. Suerte. El atacante envía una secuencia aleatoria de bits como valor HMAC y espera que funcione. Este ataque se derrota al no truncar los valores de HMAC en una longitud demasiado pequeña y / o aplicar otras mitigaciones como permitir solo un intento y rechazar de forma irrevocable los dispositivos que una vez mostraron incluso un solo valor HMAC falso (como lo hace usted).

El ataque "suerte" funciona con probabilidad 2 ^{- n} , donde n es el tamaño (en bits) de su salida HMAC truncada . Es decir. con una salida de 32 bits, entonces una falsificación basada en la suerte tiene una probabilidad de 1 en 4 billones o menos que no se detecte. Esto es lo mejor que se puede hacer con una salida de 32 bits, en general; que HMAC se comporte como un PRF significa que es "óptimo" a ese respecto. Si trunca a 8 bits, entonces la probabilidad de éxito de ataque es de 1 en 256, lo que probablemente sea demasiado para la comodidad. Pero esta es tu decisión, según tu contexto de uso.

También (nuevamente, como lo señala @Ricky), ten cuidado con los ataques de repetición . Un MAC válido, asumiendo que no hubo falsificación, solo demuestra al equipo que vio y "aprobó" el contenido del mensaje en algún momento, pero no que fue el mensaje último que vio. Un dispositivo falso puede volver a enviar los antiguos pares de mensajes HMAC. Para anular los ataques de reproducción, debe mantener cierto estado en la computadora (la computadora debe recordar algo sobre el dispositivo, por ejemplo, un "número de secuencia de mensaje", que es parte de los datos sobre los que se calcula el MAC, y se incrementa para cada mensaje) .

Sí. Sí.

B interactúa con A y el retador de la siguiente manera: B reenvía todas las consultas de A al retador,
y da el mismo resultado que A. Para cada respuesta del retador, B trunca la respuesta
y envía la respuesta truncada a la vista de A. A en esa interacción es idéntica a la vista de A en
la interacción para su escenario con la misma clave, así que si A encuentra la clave secreta, entonces también lo hace B.

B es una reducción constructiva de encontrar la clave secreta para HMAC a encontrar la clave secreta
para HMAC truncado. Por lo tanto, si "un atacante no puede encontrar la clave secreta" para HMAC
entonces "un atacante no puede encontrar la clave secreta a pesar de que el hash está" truncado ".

Tenga en cuenta que necesitará algo para defenderse contra la reutilización de los antiguos pares de etiquetas de equilibrio.

"Truncar un criptográfico bien diseñado" PRF "no debe provocar ninguna debilidad de seguridad que no sea
una reducción en el tamaño de " codomain ". Como "PRFs, por definición , son pseudoaleatorios en su dominio.

"Todas las demás cosas son iguales, utilizando un algoritmo hash más moderno"
(SHA-256) "es más seguro que usar uno más antiguo" (SHA-1).


"Diga que desea 2 ^ 16 en lugar de 2 ^ 256. Esto es una caída fenomenal en el tamaño del espacio de" etiqueta ". En 2 ^ 16 o 2 ^ 32"
una etiqueta aleatoria tendrá una probabilidad de 1 / (2 ^ 16) o 1 / (2 ^ 32) respectivamente de ser aceptada. "Mientras que los códigos QR
son menos receptivos en tamaños más grandes, "hay un compromiso entre la longitud de la etiqueta y la probabilidad de falsificación.