Clave pública en recursos para evitar al hombre en el ataque central

Lo que está preguntando es básicamente redefinir el "SSL común". Sin embargo, está basando la confianza solo en el servidor, mientras que en SSL la confianza se delega a un tercero. Además, en los certificados SSL están firmados, por lo tanto, puede verificar su autenticidad.

Entonces, sí, el escenario podrá prevenir el ataque MitM (de alguna manera), pero el usuario pierde algo de confianza en el proceso (en comparación con SSL) porque:

• no hay más verificación de la clave
• no hay nadie que respalde su identidad como lo haría una autoridad de certificación

Un escenario que podría idearse para realizar MitM sería que alguien manipulara la APK para cambiar la clave pública para reemplazarla con otra que él tiene el control. Esto probablemente no sea técnicamente fácil pero tampoco imposible.

Finalmente, sería mejor utilizar una versión reciente de la suite SSL / TLS en lugar de desarrollar su propio protocolo.

Lo que estás sugiriendo es completamente compatible con el marco de trabajo de Android TLS.

Cuando crea una conexión a un servidor remoto, puede especificar su propia lista de CA de confianza . Esto significa que, en lugar de utilizar el almacén de CA predeterminado en el que confía el SO, para esta conexión solo confía en los certificados firmados por las CA que especifique, que no es necesario que nadie más conozca.

Del mismo modo, puede enviar certificados de cliente que serán solicitados y verificados por el servidor al conectarse. Todo esto es parte de la especificación, por lo que nada de lo que quiera hacer debe implementarse de manera personalizada. Puede confiar en protocolos y códigos establecidos y probados.

Si las conexiones a su servicio solo las realizarán los clientes que envíe, entonces esta es realmente una buena práctica bien establecida. No hay razón para que sus certificados sean firmados por una CA de confianza global si usted es el único que los confiará, y no hay razón para confiar en las CA comunes si sabe que su certificado no será firmado por ellos.

Nuevamente, usa las cosas incorporadas. La regla número uno de criptografía es no cree su propia . No irá bien si lo haces.

Está complicando las cosas y reduciendo la seguridad sin ninguna razón. Use SSL¹ - ¿por qué demonios no lo usaría? El objetivo principal de SSL es evitar los ataques MitM.

Si entiendo su protocolo correctamente:

1. Cuando se instala la aplicación, configura una clave secreta por dispositivo que comparte con el servidor. No has dicho cómo, ¿vas a usar SSL allí?
   Tenga en cuenta que necesita un secreto compartido por dispositivo , de lo contrario, cualquier persona con una copia de su aplicación puede hacerse pasar por todos los demás usuarios de la aplicación.
2. Cuando la aplicación cliente inicia una conexión con el servidor, envía el secreto compartido al servidor, encriptado con una clave pública para la cual el servidor conoce la clave pública. El servidor autentica el dispositivo cliente al verificar que el secreto es el correcto. El secreto no se usa de hecho como clave aquí, sino como contraseña.
3. El resto de la conexión debe estar cifrada y autenticada, de lo contrario, MitM puede retransmitir los primeros paquetes en la conexión sin modificar y snoop o modificar el resto. Aún debe idear un protocolo para esa parte. Puede usar el secreto compartido como clave de encriptación y autenticación (¡no olvide la autenticación!).

SSL hace todo esto mejor.

1. No hay necesidad de intercambiar claves secretas. El cliente verifica que está hablando con el servidor esperado al verificar el certificado del servidor: o bien la clave pública del servidor está codificada en el paquete de la aplicación (certificado anclado), o el nombre del servidor está codificado en el paquete de la aplicación y la aplicación ( a través de las bibliotecas del sistema operativo) verifica que el servidor presente un certificado válido que vincule su clave pública con ese nombre.
   No es posible un ataque de intermediario porque el protocolo SSL requiere que el servidor demuestre al cliente que posee la clave privada asociada con su certificado. Un MitM no podría responder a este desafío, por lo que el cliente detectaría el ataque.
2. En muchos usos de SSL, al servidor no le importa qué cliente se conecta a él. Si desea que el servidor autentique al cliente, hay una característica opcional en SSL para eso: la autenticación del cliente. Genere un par de claves en el lado del cliente y haga que inscriba la clave pública en el servidor.
3. El resto de la conexión está correctamente cifrada y autenticada. SSL incluso le da la opción de elegir un conjunto de cifrado que garantice el secreto hacia adelante (un adversario no podrá recuperar la clave de la sesión y, por lo tanto, descifrar el tráfico si compromete a cualquiera de los participantes después de que finalice la sesión, a costa de un poco más lento establecimiento de conexión).

¹ _{Por "SSL", me refiero a una versión no obsoleta del protocolo, que es TLS 1.0 o superior. Cualquier versión actual de la biblioteca debería usar TLS 1.0 o superior de forma predeterminada en la actualidad, solo asegúrese de no usarlo en un modo de compatibilidad con versiones anteriores de SSL ≤3.0.}