problema de autenticación de 4 bytes

Question

problema de autenticación de 4 bytes

#1 de Tom Leek (5 votos)

5

Tengo un problema de seguridad clásico en el que Alice debe demostrar su identidad a Bob pero con requisitos y restricciones bastante inusuales debido a un contexto M2M .

EDIT en negrita

El canal de comunicación utilizado entre Alice y Bob tiene las siguientes características:

solo Alice puede enviar mensajes a Bob (Bob no puede hablar con Alice)
los mensajes de Alicia tienen 4 bytes de longitud
Bob deja de escuchar durante 10 minutos después de recibir 10 mensajes
Alicia debe demostrar su identidad usando solo un mensaje, si es posible

Otros requisitos específicos son:

Alice tiene bajo CPU & recursos de memoria , Bob tiene una alta CPU & memoria recursos
El mensaje debe incluir la identidad de Alicia, pero sin la necesidad de ocultarlo
Hay un número ilimitado de entidades Bob
Hay < 4000 entidades como Alice que pueden autenticarse en cualquier Bob
Los ataques de repetición deben prevenirse razonablemente (una repetición puede ser posible durante unos minutos después de la emisión pero no más)
Está bien que Bob sea engañado por la fuerza bruta siempre que el adversario tarde en hacerlo (es decir, varios días de cómputo o de reintento del mensaje)

Esto es lo que se me ocurrió para el mensaje de Alice de 4 bytes:

bits 1-20 = truncate(HMAC(date.format(dd/MM/yy hh:mm)),20) 
bits 21-32 = Alice ID (12bits = 4096 IDs)

Cuando Bob recibe el mensaje, si permitimos una desviación de X minutos entre el reloj de Alice y Bob, Bob calcula

truncate(HMAC(date.format(dd/MM/yy hh:mm)),20)

para X / 2 minutos después y antes de la recepción. Así que por ejemplo X = 10 minutos, Bob calcula 10 valores. Si uno de estos valores coincide con la emisión de Alicia, se autentica Alicia.

El adversario tiene X / 2 ^ 20 posibilidades de generar aleatoriamente el mensaje bueno. Ya que Bob solo escucha 10 mensajes cada 10 minutos, esto tomaría ~ 73 días en promedio si mis cálculos son correctos (para X = 10 minutos), lo cual está bien.

El ataque de repetición es posible durante X / 2 minutos.

La mayor probabilidad de colisión introducida al truncar el HMAC a 20 bits no compromete la clave privada ni reduce el nivel de seguridad del proceso AFAIK.

Soy un desarrollador, no un tipo de seguridad, ¿mi solución es razonable y mi análisis es correcto? ¿Ves uno mejor?

authentication hmac

pregunta Rémy DAVID 29.07.2014 - 11:45

fuente

1 respuesta

Lea otras preguntas en las etiquetas authentication hmac

¿Por qué Firefox eliminó la inyección de Javascript en la barra de direcciones? Wifi piña "Karma"

score 5 · Accepted Answer

Lo que importa son las habilidades respectivas de Alice y Bob con respecto al almacenamiento . En tu caso, asumes que ni Alice ni Bob tienen memoria; comparten un valor secreto (para HMAC), pero no tienen una ranura de lectura / escritura para actualizar. Por otro lado, también asumes que Alice y Bob tienen relojes que son razonablemente precisos (a pocos minutos de diferencia).

Si Alice y Bob tienen relojes pero no tienen memoria, entonces su solución es razonable. Tu matemática está un poco fuera de lugar:

Si Bob permite una desviación de X minutos, calculará los valores de 2X + 1 , no solo X .
Los ataques de repetición son posibles hasta 2X o menos, si el reloj de Alice es demasiado temprano para X minutos.

Si Bob tiene algo de memoria transitoria (RAM ...), además, puede protegerse contra los ataques de repetición recordando los mensajes recibidos en los últimos 2X minutos: de esa manera, Bob puede detectar la repetición de mensajes que no son demasiado antiguos (y los mensajes antiguos serían rechazados debido a su edad).

Si Alice y Bob tienen una memoria permanente de lectura y escritura, pueden usar un contador en lugar de un reloj. Esto puede hacer que la implementación del hardware sea mucho más fácil (los relojes necesitan un suministro constante de energía, los contadores no).

Su error principal , sin embargo, es que está tratando de definir su propio protocolo. Esto, en términos generales, no es una buena idea. En su lugar, debe confiar en los protocolos existentes revisados por pares. Por lo tanto, desea utilizar HOTP (para la solución basada en el contador) o TOTP (que reutiliza internamente los mecanismos de HOTP). Le recomendamos encarecidamente que lea su respectivo RFC ( RFC 4226 y 6238 , respectivamente), que están bien escritos.

(No estabas muy lejos, sin embargo. Tu propuesta está bastante cerca de TOTP. Pero la criptografía es sutil, por lo que usar los estándares existentes siempre es mejor.)