¿Vulnerabilidades al usar HMAC de ID aleatorio como secreto compartido?

Navega tus respuestas
3

Supongamos que un servidor tiene un secreto aleatorio key , lo usa para generar <id = random(), secret = hmac(id, key)> de tuplas de credenciales, y entrega estas <id, secret> a los clientes libremente (a través de una conexión segura).

¿Hay algún punto débil en un cliente que usa su secret para cifrar simétricamente los mensajes dirigidos al servidor?

Por ejemplo:

1. Configuración del servidor

  1. El servidor está cargado con un secreto aleatorio key

2. Credencial dada al cliente

  1. El cliente solicita credenciales a través de un canal seguro
  2. El servidor genera un id aleatorio
  3. El servidor genera un secret por HMACing id con su key
  4. El servidor responde (a través de un canal seguro) con <id, secret> tuple

3. El cliente envía un mensaje al servidor

  1. El cliente crea un mensaje M para enviarlo al servidor
  2. El cliente genera M' al cifrar simétricamente M y luego MACing con su secret
  3. El cliente envía <id, M'> tuple al servidor a través de un canal no seguro

4. El servidor recibe el mensaje del cliente

  1. El servidor recibe <id, M'> tuple sobre un canal no seguro
  2. El servidor deriva secret por HMACing id con su key
  3. El servidor autentica y descifra M' usando secret

Para mí, esto proporciona la ventaja de que el servidor no necesita conservar los ID o los secretos, y también es rápido (en comparación con la generación de pares de claves RSA).

¿Pero estoy ansioso por escuchar las desventajas de usar HMAC de esta manera para generar claves secretas?

Traté de buscar en Google este esquema, pero mi Google-fu no debe ser lo suficientemente fuerte ( esta pregunta y respuesta parecen bastante cercanas , pero esto no es "Derivación de clave" propiamente dicho, ¿verdad?). Debe haber una buena razón por la que esto no es más común.

También, ¿hay un nombre para esto?

    
pregunta Matt Thomas 05.04.2017 - 15:12
fuente

1 respuesta

0

HMAC es un buen candidato para generar claves como esa.

Después de investigar un poco, encontré este libro, que llama a la técnica " Generando algoritmos simétricos a partir de One Base Secret ", y que recomienda específicamente el uso de HMAC: enlace

  

[Para crear una clave,] mezcle un secreto base y cualquier información única que tenga disponible, pasándola a través de una función pseudoaleatoria (PRF), como se explica en la siguiente sección.

Más tarde llaman a la "información única" el distintivo . Para nuestros propósitos, esto es equivalente al id generado aleatoriamente.

Continúan enumerando varias opciones diferentes para un PRF, incluidas las funciones hash:

  

[...] un hash unidireccional a menudo es bueno como PRF.

Se expanden un poco sobre la idea de usar una función hash como PRF:

  

[...] puede concatenar una clave base con datos únicos y pasar la cadena a través de SHA1.

La cita anterior es similar en principio a la definición de HMAC . De hecho, los autores citan HMAC específicamente como candidato :

  

La forma más fácil de obtener una solución sólida que resista los ataques potencialmente prácticos es usar HMAC en modo contador.

Esta cita está en el contexto de generar claves más largas que el tamaño de bloque de hash. El modo de contador solo significa agregar un número secuencial al distintivo a medida que genera datos clave. El propósito de un contador es mantener la entrada del HMAC única para que la concatenación de los bloques de salida (con el fin de generar una clave larga) no se repita simplemente.

Para nuestros propósitos, no hay necesidad de usar el modo de contador a menos que el secret tenga que ser más largo que el tamaño del bloque de hash.

En las palabras del autor:

  

Si una clave [generada] está comprometida, debería ser imposible recuperar el secreto base.

También mencionan un beneficio adicional :

  

Varias entidades en el sistema deberían poder calcular la misma clave derivada si tienen el secreto base correcto.

Q.E.D.

    
respondido por el Matt Thomas 07.04.2017 - 14:38
fuente

Lea otras preguntas en las etiquetas

Bloqueo de Facebook en el problema del enrutador Cisco RV042 Cómo corregir un error de manipulación de ruta en java que se genera en Fortify [cerrado]