¿Cómo "emparejar" una aplicación cliente / servidor de forma segura?

Question

¿Cómo "emparejar" una aplicación cliente / servidor de forma segura?

#1 de Dmitry Grigoryev (3 votos)
#2 de kasperd (1 votos)

3

Por favor, perdóneme si mi pregunta es una reformulación de un problema común, ¡pero no estoy seguro de qué buscar!

Mi caso de uso es un programa cliente-servidor. El servidor se ejecuta en la PC de un usuario y el cliente se ejecuta en sus dispositivos móviles. Los clientes deben vincularse al servidor de forma segura (p. Ej., Ingresar un PIN o contraseña de una sola vez), y una vez que se completa el emparejamiento, debemos asegurarnos de que el cliente pueda verificar de forma segura el servidor, antes de transmitir datos confidenciales desde tiempo en tiempo.

Al principio de mi investigación, pensé que sería posible usar claves RSA, pero este enfoque parecía demasiado novedoso y complejo para implementarlo de manera segura.

Mi idea actual es implementar un esquema como este:

En el emparejamiento inicial, el intercambio de claves Diffie-Hellman entre el cliente y el servidor
El servidor muestra un PIN aleatorio y el cliente lo ingresa para su verificación (evitando mitm). Solo se permiten un par de intentos incorrectos de PIN antes de que se elimine el intento de emparejamiento.
Dado que el servidor y el cliente ahora están de acuerdo con una clave secreta, simplemente podemos cifrar todas las comunicaciones con esta clave. Aunque el servidor puede tener varios clientes conocidos (por ejemplo, hasta diez clientes), el servidor podría simplemente verificar cualquier conexión entrante con las diez claves. Y como el cliente usa la misma clave secreta, si el servidor es un impostor, no será posible descifrarlo.

Ahora, mi pregunta, ¿es un esquema razonable o existe un protocolo estándar claro que pueda lograr objetivos similares?

authentication cryptography encryption

pregunta fabspro 20.10.2015 - 01:30

fuente

2 respuestas

Lea otras preguntas en las etiquetas authentication cryptography encryption

Firma digital: ¿Cómo sé lo que estoy firmando? ¿Cómo se puede ejecutar un código al ingresar una carpeta en Windows?

score 3 · Answer 1

Reinventar la rueda es una mala idea en el desarrollo de software en general, pero especialmente mala cuando se trata de seguridad. Antes de (o en lugar de) diseñar su propio protocolo de autenticación, debe observar los existentes, como TLS o Kerberos, comprender cómo mitigan los posibles ataques e incluso elegir un protocolo existente para usar en su aplicación. Evitará muchas dificultades comunes, ahorrará tiempo de desarrollo y su aplicación tendrá una mejor compatibilidad, en caso de que quiera tenerla. TLS parece específicamente un buen ajuste para su caso de uso.

Por cierto, ¿podría explicar cómo mostrar un pin aleatorio evitaría los ataques MitM? ¿No vería el atacante el mismo pin también?

score 1 · Answer 2

Puede ser seguro, pero el diablo está en los detalles. Hay una serie de cosas que podrían hacerse incorrectamente dejando el protocolo totalmente abierto a los ataques.

Diffie-Hellman prime demasiado pequeño. Si hace un código primo en su protocolo, entonces el primero debe ser más grande de lo que sería si se generara dinámicamente.
Verificación de PIN propensa a ataques mitm. Un ataque de mitm activo contra Diffie-Hellman es trivial. Es por eso que necesitas el PIN en primer lugar. Sin embargo, debe recordar que el propósito del PIN no es verificar el PIN sino verificar la clave. Si, por ejemplo, simplemente envía el PIN tal como está a través del canal cifrado establecido mediante Diffie-Hellman, un adversario puede simplemente mitigar la conexión y enviar el PIN recibido de un lado al otro.
Usar una sola tecla para demasiados datos. Cuantos más datos se envíen cifrados con la misma clave, más fácil será para un adversario atacar dicha clave. Reingreso periódico sería una buena idea. No vuelva a teclear en el claro. Realice el cambio de clave dentro del canal protegido por la clave anterior, pero al mismo tiempo diseñe el protocolo de cambio de clave de modo que sea plausible si no hubiera estado dentro del canal protegido. Eso es defensa en profundidad.
Si encripta los datos en tránsito sin proteger también la integridad usando algún tipo de código de autenticación de mensaje, será vulnerable a una amplia gama de ataques.

Lo anterior no es de ninguna manera una lista exhaustiva de posibles debilidades. Si puede encontrar un protocolo conocido que satisfaga sus necesidades, le recomendaría que lo use.

Lo único que me viene a la mente a partir de su descripción es el protocolo de emparejamiento de Bluetooth. Desafortunadamente, no sé lo suficiente sobre el protocolo Bluetooth para recomendar o en contra de su uso.