protección MITM, distribución de claves

0

Quiero asegurarme de que cada uno de los usuarios de mis aplicaciones solo obtenga sus propios datos y que nadie los manipule ni los rastree de forma MITM. El cifrado de todo debería ser la solución, ¿verdad? ¿Pero cómo distribuyo las llaves?

Afaik SSL / TLS solo se asegura de que el cliente esté hablando con el servidor correcto, no al revés. Quiero asegurarme de que el cliente es quien dice ser.

Pensé en usar cifrado asimétrico para resolver esto. La clave pública de los servidores podría incluirse en la aplicación y distribuirse a través de la tienda de aplicaciones / google play. Entonces el usuario podrá hablar con el servidor de forma segura desde el principio. Luego, el cliente puede enviar su clave pública de forma segura al servidor, lo que permite una comunicación cifrada de dos maneras y se asegura de que el servidor envíe los datos al cliente correcto. Todo esto se enviaría a través de https.

¿Estoy exagerando esto? ¿Qué agujeros de seguridad me faltan? ¿Hay algo más que necesitaría para asegurar esto? No quiero reinventar la rueda, por lo que sería preferible una solución existente.

    
pregunta Filip Haglund 12.07.2014 - 17:29
fuente

1 respuesta

2

Desea una autenticación mutua entre el cliente y el servidor.

Según el protocolo SSL / TLS , esto es compatible con los certificados de cliente. Tanto el servidor como el cliente tienen un certificado; el servidor muestra su certificado al cliente y, a continuación, solicita al cliente que muestre su propio certificado y demuestre el control de la clave privada correspondiente. Esto funciona, esto es estándar, esto es compatible con las bibliotecas habituales; pero, por supuesto, se requiere que el cliente tenga un certificado instalado

El modelo de certificado doble está bien en los casos en que el cliente no confía realmente en el servidor. En su caso, puede hacer algo más simple, ya que su aplicación confía en su servidor (la aplicación quiere asegurarse de que habla con el servidor original, pero una vez que tiene tal seguridad, habla libremente y sin restricciones): puede usar el El modelo show-the-password que es realmente común en toda la Web. En los detalles completos:

  • Cuando la aplicación se instala o inicia por primera vez, habla con su servidor, identificándola a través de su certificado. El protocolo SSL se asegura de que lo que la aplicación enviará solo vaya a su servidor, y no se pueda modificar ni espiar mientras esté en tránsito.
  • Durante esa primera conexión, la aplicación genera un valor aleatorio K y lo almacena localmente; también le dice a su servidor: "Hola, soy un nuevo cliente y mi clave es K ".
  • Su servidor almacena en su base de datos la información sobre el nuevo cliente, incluyendo h (K) , donde h () es una función criptográfica de hash (por ejemplo, SHA-256 ).
  • Más adelante, cuando la aplicación se vuelve a conectar, abre una nueva conexión SSL, asegurándose nuevamente de que se comunica con el servidor correcto (gracias al certificado del servidor); y luego envía K al servidor. El servidor calcula h (K) (en el valor K del cliente) y lo compara con el valor almacenado; si hay una coincidencia, entonces el servidor sabe que es el mismo cliente que anteriormente.

Cuando K es algo que el usuario humano recuerda y escribe (una "contraseña"), se debe tener mucho cuidado, especialmente con la función hash h () que debería ser algo bastante más complejo que SHA-256. Pero aquí, el valor K es generado y almacenado por una aplicación, que puede usar un PRNG criptográficamente fuerte y manejar un K de 128 bits o más, que será inmune a el tipo de ataques que se aplican a las contraseñas.

Por supuesto, todo esto se trata de proteger la comunicación cliente-servidor de personas externas. El propio cliente (es decir, el usuario de la aplicación) puede aplicar ingeniería inversa a la aplicación a voluntad; no puede asegurarse de que lo que está en el lado del cliente sea "su aplicación", sin modificar. Sin embargo, SSL y el concepto "mostrar la contraseña" le permiten asegurarse de que si los datos caen en las manos equivocadas, entonces el propio cliente es deshonesto (o le robaron su teléfono inteligente).

    
respondido por el Thomas Pornin 13.07.2014 - 16:06
fuente