Todas las debilidades en su protocolo pueden resumirse como "usar SSL" o incluso "usar SSL, ¡maldita sea!".

En más detalles:

• Por supuesto, todo el protocolo es vulnerable a la suplantación, específicamente la doble suplantación, también conocida como Man- ataque en el medio .
• Del mismo modo, si alguno de los posibles atacantes que pueden escuchar a escondidas en la línea decide hacer una modificación de los datos en tránsito, entonces él puede, y su cliente y servidor no sabrán nada.
• La experiencia demuestra que decir "encriptar todos los datos con esa clave" y luego hacerlo correctamente es muy complejo. SSL tardó casi 15 años en hacerlo, y muchas implementaciones aún no están a la altura. Oráculos de relleno, IV predecible, tiempo de verificación de MAC, cierre verificado, protección contra la resecuenciación y reproducción de paquetes ...

Como evaluación general: no hagas eso.

No, este protocolo no es seguro.

Como ya se mencionó en los comentarios:

No hagas rodar tu propio criptográfico. Es probable que lo entiendas mal. Especialmente si admites que realmente no sabes lo que estás haciendo.

Primero, parece que tienes problemas estándar para los que ya existen protocolos estándar, que tienen buenas propiedades y pruebas de seguridad . El protocolo para la transmisión de datos debe ser TLS v1.2 (o más reciente). Debe usar una biblioteca (como NSS , GnuTLS o OpenSSL para esto). Para la autenticación de contraseña, la mejor opción que tiene es usar SRP o TLS-SRP . Sin embargo, si realmente no puede pagar SRP (que debería ser su primera opción), aún puede seguir este documento .
Hasta ahora por las mejoras.

Ahora para las fallas de su protocolo:

1. Es vulnerable a Ataques de hombre en el medio . Si un atacante se encuentra entre el dispositivo y el servidor, puede pescar la clave pública y reemplazarla con la suya. En respuesta, conocería la clave AES y podría descifrar todos los datos.
2. No menciona la integridad / autenticidad de los datos. Parece que quieres usar modo ECB para AES (que realmente no quieres usar ), estaría mucho mejor con AES-GCM para el cifrado masivo. Tampoco menciona cómo se utilizará RSA, RSA-OAEP debe ser su elección (y no un libro de texto RSA) . Sin embargo, asumo que habrías hecho esto con tu implementación.
3. Pones una gran carga de trabajo en el dispositivo. El dispositivo debe generar una nueva clave RSA privada con cada conexión, lo que es una tarea altamente informática. Debería considerar utilizar el intercambio de claves ECDH.
4. Para que la verificación de las contraseñas funcione, es necesario que el servidor almacene las contraseñas en texto sin formato o las elimine, lo que puede habilitar los ataques DoS en el servidor. Y en caso de que se produzca un ataque de hombre en el medio, las contraseñas simples se revelarán a un atacante, lo que puede causar un daño grave a sus usuarios (ya que pueden reutilizar sus contraseñas en los sitios ...)

  

1. El dispositivo genera una clave RSA privada y envía la clave pública al servidor.

  

2. El servidor genera una clave AES única para el usuario y utiliza la clave pública RSA para cifrarla y enviarla de vuelta al dispositivo.

  

3. El dispositivo obtiene la clave AES. Lo utiliza para cifrar la contraseña y el nombre de usuario y lo envía al servidor.

  

Intercambio de claves anónimo.

No hay autenticación. Su intercambio de claves está encriptado, pero no autenticado. Esto es malo.

Si hay un Hombre en el Medio activo, entonces no tienes forma de detectar esto. Este MitM activo solo puede pretender al cliente que él es el servidor. Y fingir al servidor, que él es el cliente.

- > No lo hagas @SEJPM tiene razón con su comentario. Utilizar sistemas criptográficos establecidos. Al igual que TLS con certificados o TLS con SRP.

así es como uso la combinación rsa / aes

1. el cliente genera una clave aleatoria aes
2. use la clave aes para cifrar los datos que necesita (rsa toma más tiempo y tiene una limitación de longitud, por lo que es mejor usar aes para cifrar)
3. use la clave pública para cifrar la clave aes
4. pasar los datos cifrados y la clave aes cifrada por rsa public key al servidor
5. cuando el servidor reciba, descifre esa clave aes por una clave privada y luego descifre los datos adjuntos mediante la clave aes desencriptada

Es bastante bueno, pero lo haría de una manera más fácil que creo que es más segura y similar a lo que pensaste.

Dado que la comunicación es cliente-servidor:

1. El cliente móvil genera la clave mediante PRNG
2. El cliente envía la clave del paso 1 mediante la clave pública del servidor (solo el servidor tiene datos privados para descifrar)
3. El cliente cifra el usuario / contraseña con la tecla del paso 1 y los envía al servidor
4. Si se verifican el usuario / la contraseña, el servidor devuelve una nueva clave para el cifrado de datos, cifrada con la clave del paso 1

-. Por favor, haga los pasos 2 a 4 sobre TLS si es posible

-. Cambiar claves cada X iteraciones (aplicar en cliente y servidor)

---. El cliente debe confiar en el certificado del servidor para evitar MITM / suplantación