Sí, si lo estás describiendo con precisión, esto está completamente roto, hasta el punto de ser inútil.
La clave AES inicial se ve comprometida por estar en la aplicación, cualquiera que tenga la aplicación tiene acceso a la clave AES. Si esto es global, entonces está bien y realmente atornillado, si es único para cada aplicación, puede haber un pequeño rayo de esperanza.
El SHA-1 es completamente reproducible. No menciona sal, pero incluso si hay un salt, el atacante puede volver a jugar contra un cliente legítimo como un MitM y luego responder de manera válida para aparecer como el cliente al servidor.
El servidor le proporcionará al atacante la clave pública, en forma encriptada, que no es particularmente útil para el atacante, pero también es la clave pública ... se supone que es pública. Tenerlo en privado no ofrece nada. Si el cliente estuvo comprometido (o cualquier cliente si la clave AES es global), la aplicación filtra la clave AES y la clave pública también está disponible para el atacante.
Además, si la clave AES está comprometida, el atacante puede enviar una clave pública de su elección ya que el cliente no tiene forma de verificar la clave pública RSA.
Una clave AES que se genera en el cliente es una idea bastante decente, pero hasta ahora, no hay nada que impida que el atacante genere su propia clave AES. Además, es probable que puedan proporcionar al cliente su propia clave pública para que también puedan engañar al cliente.
¿Por qué los datos se cifran con la clave RSA? ¿Cuál es el punto de la clave AES temporal entonces? ¿Es realmente completamente sin uso? En general, el cifrado de datos largos con RSA se considera menos seguro que el uso de cifrado simétrico, ya que requiere más trabajo para procesar y puede tener otras implicaciones de seguridad. La norma es simplemente intercambiar una clave simétrica y usarla para el intercambio de datos.
En resumen, el sistema es completamente inútil.
En realidad, sería mucho más útil si simplemente incrustaran la clave pública del servidor en la aplicación y la usaran para que el cliente generara una clave AES y la intercambiara para la comunicación de la sesión. No validaría nada sobre el cliente en sí, pero eso podría hacerse a través de contraseñas u otros tokens después de que la sesión se haya inicializado. Sin embargo, en ese momento está bastante cerca de usar un HTTPS autofirmado, pero podría usarse como una implementación personalizada si el HTTPS no es una opción por algún motivo (como no poder agregar un certificado raíz de confianza en el cliente). dispositivos.)