Tutti i punti deboli del tuo protocollo possono essere riassunti come "usa SSL" o anche "usa SSL, dannazione!".

In ulteriori dettagli:

• Tutto il protocollo è ovviamente vulnerabile alla rappresentazione, in particolare la doppia imitazione che è anche conosciuta come Man- attacco in-the-Middle .
• Allo stesso modo, se uno qualsiasi dei potenziali aggressori che possono origliare sulla linea decide di eseguire una modifica dei dati in transito, allora può, e il client e il server non ne saranno più saggi.
• L'esperienza mostra che pronunciare "criptare tutti i dati con quella chiave" e poi eseguirlo correttamente è terribilmente complesso. Lo stesso SSL ha impiegato quasi 15 anni per farlo, e molte implementazioni non sono ancora all'altezza. Oracoli di imbottitura, IV prevedibile, tempi di verifica MAC, chiusura verificata, protezione contro la risequenziazione e riproduzione di pacchetti ...

Come valutazione generale: non farlo.

No, questo protocollo non è sicuro.

Come già menzionato nei commenti:

Non tirare la tua cripta. Probabilmente ti stai sbagliando. Soprattutto se ammetti che non sai davvero cosa stai facendo.

Per prima cosa, sembra che tu abbia problemi standard per i quali esistono già protocolli standard, che hanno proprietà carine e prove di sicurezza . Il protocollo per la trasmissione dei dati dovrebbe essere TLS v1.2 (o più recente). Dovresti utilizzare una libreria (come NSS , GnuTLS o OpenSSL per questo). Per l'autenticazione della password, la scelta migliore è utilizzare SRP o TLS-SRP . Tuttavia, se davvero non ti puoi permettere SRP (che dovrebbe essere la tua prima scelta) puoi comunque seguire questo articolo .
Finora per i miglioramenti.

Ora per i difetti del tuo protocollo:

1. È vulnerabile agli attacchi Man-in-the-middle . Se un utente malintenzionato si trova tra il dispositivo e il server, può pescare la chiave pubblica e sostituirla con la propria. In risposta, conosceva la chiave AES e poteva decifrare tutti i dati.
2. Non menzioni l'integrità / autenticità dei dati. Sembra che tu voglia utilizzare la modalità ECB per AES (che tu davvero non vuoi usare ), starai molto meglio con AES-GCM per la crittografia di massa. Inoltre non menzionerai come utilizzare RSA, RSA-OAEP dovrebbe essere la tua scelta (e non RSA da manuale) . Tuttavia suppongo che avresti fatto questo con la tua implementazione.
3. Hai caricato un carico di lavoro davvero grande sul dispositivo. Il dispositivo ha bisogno di generare una nuova chiave RSA privata con ogni connessione, che è un'attività altamente impegnativa. Dovresti prendere in considerazione la possibilità di utilizzare lo scambio di chiavi ECDH.
4. Affinché la verifica delle password funzioni, è necessario che il server memorizzi le password in testo semplice o le hash da sé, il che potrebbe consentire attacchi DoS sul server. E nel caso in cui si verifichi un attacco man-in-the-middle, le semplici password verranno rivelate a un utente malintenzionato, il che potrebbe causare gravi danni agli utenti (in quanto potrebbero riutilizzare le loro password su siti ...)

1. Device generates private RSA key, and sends the public key to server.

2. Server generates unique to user AES key and uses the RSA public key to encrypt it and send it back to device.

3. Device gets the AES key. Uses it to encrypt password and username and sends it to the server.

Scambio chiavi anonimo.

Non c'è autenticazione. Lo scambio di chiavi è crittografato, ma non autenticato. Questo è male.

Se c'è un Man-in-the-Middle attivo, non hai modo di scoprirlo. Questo MitM attivo può solo far finta che sia il server. E fai finta al server, che è il cliente.

- > Non farlo @SEJPM ha ragione con il suo commento. Utilizzare i sistemi crittografici stabiliti. Come TLS con certificati o TLS con SRP.

questo è il modo in cui utilizzo la combinazione rsa / aes

Il client
1. genera un tasto aes casuale
2. usa la chiave AES per crittografare i dati di cui hai bisogno (rsa impiega più tempo e ha limiti di lunghezza, quindi meglio usare aes per fare cifrare)
3. usa la chiave pubblica per crittografare la chiave AES
4. passare i dati crittografati e la chiave AES crittografata dalla chiave pubblica rsa al server
5. quando il server riceve, decrittografa quella chiave aes con la chiave privata e quindi decrittografa i dati allegati tramite la chiave aes decrittografata

È abbastanza buono, ma lo farei in un modo più semplice che penso sia più sicuro e simile a ciò a cui pensavi.

Poiché la comunicazione è client-server:

1. Il client mobile genera la chiave usando PRNG
2. Il client invia la chiave del passaggio 1 utilizzando la chiave pubblica del server (solo il server ha il diritto di decrittografare)
3. Il client crittografa utente / password con il passaggio 1 e invia al server
4. Se l'utente / password sono verificati - il server restituisce una nuova chiave per la crittografia dei dati, crittografata con il tasto passo 1

-. Si prega di fare il passaggio 2 - 4 su TLS, se possibile

-. Cambia chiavi ogni X iterazioni (applica su client e server)

---. Il cliente deve fidarsi del certificato del server per prevenire MITM / impersonificazione