Autenticación segura de 2 vías de clave compartida previamente

Navega tus respuestas
2

Tengo la siguiente configuración:
Un servidor y un cliente se conectarán a través de tcp. El servidor y el cliente tienen acceso a la clave secreta previamente compartida. Cuando el cliente se conecta al servidor, tanto el cliente como el servidor necesitan conocer la clave, por lo que necesitan usar la misma clave para autenticarse o fallará.

Se me ocurrió el siguiente proceso y me gustaría saber si hay algo obviamente malo en él que no haya visto. El cifrado real no es Relevante en este caso. Entonces esto es lo que sucede cuando el cliente se conecta:

  1. El servidor genera una sal de 16 bytes (salt1).
  2. El servidor calcula hashServer1 = HASH (key + HASH (key + salt1)).
  3. El servidor envía salt1 al cliente.
  4. Los clientes calculan utilizando el salt1 hashClient1 = HASH recibido (tecla + HASH (tecla + sal1)).
  5. El cliente genera sal de 16 bytes (salt2).
  6. El cliente calcula hashClient2 = HASH (key + HASH (key + salt2)).
  7. El cliente envía (hashClient1 + salt2) al servidor.
  8. El servidor comprueba si hashClient1 == hashServer1 recibido y si no se rompe.
  9. El servidor calcula utilizando el servidor hash sal2 recibido2 = HASH (tecla + HASH (tecla + sal2)).
  10. El servidor envía hashServer2 al cliente.
  11. El cliente comprueba si hashServer2 == hashClient2 recibido y si no se rompe.

Si no me equivoco, esto debería ser bastante seguro cuando se usa un algoritmo hash fuerte. La clave nunca se envía como texto claro y, debido a la sal, los datos son diferentes cada vez.

EDITAR: se modificó la sal utilizada para el hashing de saltX a HASH (clave + saltX).

    
pregunta darkfire000 08.06.2017 - 10:06
fuente

3 respuestas

0

El único problema evidente que veo aquí es que la sal es efectivamente inútil. El objetivo de una sal es hacer que el craqueo sea más difícil agregando un factor desconocido adicional para apoyar la entropía del proceso de hash. Las sales no necesariamente tienen que ser secretos, pero queremos que tengan algunas propiedades cuando se trata de proteger hashes:

  • nunca reutilizar sales
  • no distribuyas sales gratis
  • no uses sales cortas

dar la sal a cada transacción me permitirá observar los patrones en su creación. Por supuesto, esto depende de qué tan aleatorio sea su generación.

En este caso, si soy un atacante que está olfateando este tráfico, siempre tengo la sal. lo que significa que efectivamente he reducido el problema para descifrar el PSK en cada caso, y me proporciona dos hashes y sales para cada conexión, lo que aumenta aún más mi grupo.

Esto sigue siendo un gran problema, todavía tengo que ver si puedo encontrar el valor que conduce al hash que das, pero en este caso, una vez que tengo un hash + sal par, simplemente estoy rompiendo el PSK en ese punto.

Creo que lo más importante aquí es que las sales generalmente se usan para proteger grandes bases de datos de información de búsquedas inversas o tablas de arco iris. Pero en su caso, todo su servidor está sujeto a una contraseña. Saber que la sal es un asunto importante aquí, y apostaría a que eso hace que la sal sea incluso un secreto. Algo que vale la pena proteger. Ya que si realmente quisiera entrar, tomaría un par de sal / hash y generaría hashes hasta que encontrase el PSK.

    
respondido por el Nalaurien 08.06.2017 - 10:20
fuente
0

Este protocolo se llama autenticación de respuesta de desafío , y podría simplificar su proceso:

  1. El servidor envía la cadena timestampFromServer:HASH(PSK + timestampFromServer) .

  2. El cliente valida el hash, confía en el servidor y envía la cadena timestampFromClient:HASH(PSK + timestampFromClient)

  3. El servidor valida el hash y confía en el cliente.

En 2 , el cliente solo procede si el hash es válido, y eso prueba que el servidor conoce la clave. En 3 se comprueba lo contrario, y el servidor sabe que el cliente también conoce la clave.

En 1 , el servidor puede incluso enviar timestampFromServer:HASH(PSK + timestampFromServer):TransientSessionKey . El cliente ahora puede usar el TransientSessionKey y el PSK para derivar una clave simétrica y usarla en cada comunicación con el servidor.

De esta manera, no necesita un almacenamiento de sal, no necesita preocuparse por la reutilización de las sales (según la precisión de la marca de tiempo) y utilizar menos sales. También puede autenticar tanto al cliente como al servidor con menos viajes de ida y vuelta, lo que reduce la latencia, y si usa el TransientSessionKey , reduce la probabilidad de fugas del PSK.

    
respondido por el ThoriumBR 03.07.2018 - 23:28
fuente
0

No hagas rodar tu propia criptografía. Utilice TLS-PSK.

enlace

    
respondido por el StackzOfZtuff 01.11.2018 - 06:42
fuente

Lea otras preguntas en las etiquetas

Resolución de certificados CA dupe en el almacén de claves Error de tiempo de espera de conexión al usar las Comprobaciones de Código de Estado HTTP en un sitio web [cerrado]