Questo non è un modo sicuro per comunicare. Ci sono molte cose che possono andare storte.
Come accennato prima, se possibile, basta usare una connessione TLS. Dovresti essere in grado di utilizzare lo stesso certificato che utilizzi per il tuo server HTTPS. Quindi prendi un server websocket che supporta TLS e il gioco è fatto. Tuttavia, voglio concentrarmi sulla tua domanda sull'utilizzo di AES e su alcuni attacchi di base.
Dando un'occhiata all'handshake websocket, vediamo che alcuni dati sono sempre gli stessi (come "Protocolli di commutazione HTTP / 1.1 101"):
link
Ciò consente attacchi con testo in chiaro noti . Ad esempio, un utente malintenzionato sa che quel testo in chiaro specifico viene convertito nel testo cifrato osservato. Inoltre, lo schema non sembra proteggere dagli attacchi di replay, in cui invio nuovamente alcuni pacchetti osservati.
AES è un codice a blocchi che converte un blocco di dati in chiaro in un blocco di testo cifrato della stessa lunghezza. Ci sono diversi modi per inviare un gruppo di blocchi sulla linea. Vedi:
link
Il più semplice è la BCE. Qui basta inviare un blocco dopo l'altro. Ciò significa che qualsiasi blocco che contiene lo stesso testo in chiaro conterrà lo stesso testo cifrato. Quindi, se conosco il testo in chiaro per un blocco di testo cifrato, e vedo lo stesso testo cifrato da qualche altra parte, so che contiene lo stesso testo in chiaro. Inoltre, con ECB, un utente malintenzionato può anche scambiare un blocco con un altro, che scambierà i blocchi di testo in chiaro dopo la decrittazione.
Un uso più comune della concatenazione di blocchi è CBC. Questo concatenerà i blocchi con una IV, in modo tale che nessun blocco di testo in chiaro (o un gruppo di blocchi) si trasformi negli stessi blocchi di testo cifrato. Tuttavia, questo è anche pieno di pericoli. Se si osserva da vicino lo schema di decrittografia per CBC, è possibile vedere che xor'ing un byte in un blocco di testo cifrato risulterà in un xor dello stesso valore per il blocco di testo in chiaro successivo. Ci sono tutti i tipi di attacchi bitmap e cose che puoi fare. Inoltre, se il server risponde in modo diverso quando il riempimento AES è corretto o meno, parti del testo in chiaro possono essere ripristinate con un oracle riempimento di
.
Gli attacchi di cui sopra funzionano perché non vedo nulla sul controllo dell'integrità (con un HMAC per esempio) che non impedisca a un utente malintenzionato di manomettere il testo cifrato.
Questi sono solo alcuni esempi di cose che possono andare storte. Controlla anche gli attacchi temporali se vuoi entrare e cercare delle letture interessanti. Si prega di non implementare la propria crittografia.
E a parte ottenere la password sul dispositivo come ha detto Mike, vedo grossi problemi nel permettere agli utenti di scegliere una password per la crittografia dei dati. Senza un algoritmo di espansione chiave, potrei semplicemente forzare la password per qualche testo cifrato.