Utilizzo di AES per la sicurezza degli oggetti

5

Sto cercando di creare una soluzione di automazione domestica con il seguente caso d'uso

  1. L'utente si registra sul server con nome utente e password_a
  2. L'utente imposta password_b per dispositivo IoT
  3. La connessione tra utente e server è crittografata con TLS
  4. Il dispositivo IoT si collega al server con una connessione web non protetta
  5. Il server funge da supporto per passare i dati al / dal dispositivo IoT da / per l'utente
  6. I datapacket per i web socket sono crittografati da AES usando password_b per generare la chiave
  7. Solo i dispositivi utente e IoT possono crittografare / decrittografare i dati

È un modo sicuro per comunicare? Ci sono delle insidie con questo approccio?

Sono nuovo della sicurezza.

    
posta Siddharth 24.08.2016 - 03:13
fonte

2 risposte

2

Il problema principale che vedo con questo schema è il cosiddetto Problema di distribuzione delle chiavi : come fai a consegnare in modo sicuro password_b sul dispositivo?

Nel passaggio 2, l'utente immette password_b in un modulo Web. Presumibilmente nel passaggio 5%, ilpassword_b viene inviato al dispositivo tramite una connessione WebSocket non protetta. Da quel momento in poi, il dispositivo crittografa tutti i dati websocket utilizzando AES con una chiave derivata da password_b .

Il mio problema è relativo al passaggio 5: se viene inviato in chiaro, un utente malintenzionato sulla stessa rete del dispositivo potrebbe semplicemente disconnettere la password dal pacchetto. Anche se si utilizza una connessione TLS autenticata dal server standard, il server non avrebbe modo di provare a quale dispositivo sta parlando e un utente malintenzionato potrebbe connettersi e dichiarare di essere il dispositivo e ottenere il server per inviarlo password_b .

Il mio suggerimento è che se puoi permetterti di eseguire una libreria TLS, allora dai a ciascun dispositivo un cliente non affidabile durante la produzione e tenere il server a una tabella di quale chiave pubblica appartiene a quale numero di serie del dispositivo. In questo modo, quando un dispositivo si connette al server tramite TLS, il server sa a quale dispositivo sta parlando solo dalla chiave pubblica / firma.

Di solito dovresti usare una crittografia SSL / TLS che avvolge AES, piuttosto che inventare il tuo protocollo perché, come suggerisce @Rook, ci sono così tanti modi per spararti ai piedi. Comprendo che alcuni dispositivi a bassa potenza possono eseguire AES ma non hanno l'impronta di memoria per una libreria TLS completa. Bene, ma dovrai diventare un esperto di crittografia, o assumerne uno, per essere sicuro che lo stai facendo bene perché stai andando fuori strada qui.

    
risposta data 06.09.2016 - 15:34
fonte
0

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.

    
risposta data 05.07.2017 - 23:47
fonte

Leggi altre domande sui tag