¿Hay fallas en el intercambio de claves de dos pasos (RSA + AES) y la configuración segura del canal?

Question

¿Hay fallas en el intercambio de claves de dos pasos (RSA + AES) y la configuración segura del canal?

Navega tus respuestas

#1 de mat (1 votos)
#2 de kaidentity (1 votos)

1

Para configurar un canal seguro con el servidor, uso la siguiente configuración en mi aplicación:

1.Generar una clave AES aleatoria y IV aleatorio

2. Encripte la clave AES, IV y las credenciales del cliente con la clave pública RSA

3.Enviar al servidor

4.El servidor se desencripta usando una clave RSA privada

5.Server verifica las credenciales

6.Server responde con [(OK o FAIL) + random salt] cifrado con clave AES

7. El cliente verifica la respuesta

8.El canal de comunicación se designa como auténtico y la sesión como válida

9. Toda la comunicación comercial adicional se realiza a través de la misma clave AES hasta el final de la sesión (Desconexión)

Detalles adicionales:

1.Las claves RSA públicas y privadas están codificadas y son constantes durante el tiempo de vida de la aplicación, es decir, no se obtiene la clave pública de una fuente externa

2.Todos los textos constantes conocidos constantes como OK FAIL, etc. se envían con sal

Creo que esta configuración debería ser bastante infalible a menos que alguien tenga acceso a las operaciones del cliente o servidor (o rompa el RSA)

¿Hay algún posible agujero de bucle en esta configuración que no haya podido realizar o que haya pasado por alto?

cryptography encryption aes rsa decryption

pregunta Allahjane 20.10.2016 - 16:37

fuente

2 respuestas

Lea otras preguntas en las etiquetas cryptography encryption aes rsa decryption

¿Cómo puedo saber si es SDA, DDA o CDA? Descifra el tráfico TLS en la misma máquina (Mac + mitmproxy / otro)

score 1 · Answer 1

Su concepto se ve muy bien, pero veo dos fallas en él:

Autenticación no criptográfica : sugeriría que en el paso 2, en lugar de enviar las credenciales, solo envíe un identificador de usuario y obtenga una clave MAC para el secreto del usuario que utiliza para autenticar los datos restantes. Esto reduciría la posibilidad de que alguien manipule los datos y, además, mejoraría la seguridad al no tener que enviar ningún secreto.
Sin secreto de reenvío : si este es un problema real, depende de su situación, pero como declaró que la clave privada RSA está codificada en su software, supongo que podría ser una (especialmente porque su plan actual es para enviar algunas credenciales secretas en el paso 2 siempre encriptadas con la misma clave). En lugar de enviar una clave AES en el paso 2, puede enviar la mitad de un mensaje de intercambio de claves Diffie-Hellman y devolver el mensaje de intercambio de claves del servidor en el paso 6 junto con la respuesta cifrada.

No es realmente un problema, pero aún así es digno de mención: no veo el punto de crear la IV en el lado del cliente y de transferirla encriptada. Una IV no es una cosa secreta, podría ser creada en el servidor y enviada junto con el mensaje en el paso 6 en texto simple.

score 1 · Answer 2

Una de las cosas contra las que un esquema debería ser inmune es el MITM y la reproducción de token. Y aquí veo un problema. ¿Qué impide que un MITM suprima la respuesta de un servidor y reproduzca un mensaje capturado anteriormente? Dependiendo de la carga útil de la aplicación que envíes, esto puede crear un daño grave.

Para evitar esto, debe incluir un número de secuencia en su comunicación. El cliente envía el número X, comenzando con 1, la respuesta del servidor debe contener el 2 y así sucesivamente. Aún mejor sería verificar cómo TLS resuelve este problema y copiar este mecanismo. Tal vez necesite incluir una marca de tiempo y datos de caché en una sesión para obtener una seguridad de reproducción completa.

Además, no dices lo que significa "fin de sesión". ¿Rotura de la conexión TCP / IP? Creo que sería beneficioso para la seguridad definir claramente cómo manejar la noción de "sesión". Si una sesión está pendiente, ¿el mismo cliente puede abrir una segunda sesión para el mismo usuario? Si la sesión está inactiva durante X minutos, es obligatorio que el servidor reanude una sesión o puede decir "no, establecer una nueva" (con una nueva clave de sesión AES). Cree una posibilidad para cerrar explícitamente la sesión a través de un mensaje correspondiente (que permite a los socios liberar recursos de cómputo).