Come posso proteggere le comunicazioni tra l'app e il dispositivo IoT?


18

Attualmente sto lavorando a un progetto che include la comunicazione Bluetooth tra un'applicazione mobile (attualmente utilizzando la piattaforma ionica) e un dispositivo incorporato. Per fare un confronto, il nostro prodotto è simile a un lucchetto intelligente .

La sicurezza è estremamente preoccupante e stiamo cercando dei modi per garantire che il nostro hardware e software non siano hackerabili. Quali misure dovremmo adottare per garantire la sicurezza del nostro sistema?

Modifica: Sì, al momento stiamo crittografando le comunicazioni e utilizzando HTTPS quando il dispositivo comunica con il nostro server.


Usa HTTPS? Stai codificando entrambi i dispositivi? Encryption?
Mawg dice di ripristinare Monica il


2
@Mawg Per quanto ne so, HTTPS non è applicabile al bluetooth (o almeno non in senso normativo / sano).
Riccioli d'oro

1
Sto votando per chiudere questa domanda come off-topic perché questo non riesce a mostrare come questo sia specifico dell'IoT. Garantisce solo la comunicazione tra i dispositivi.
Helmar

4
@Helmar La comunicazione tra dispositivi è una caratteristica piuttosto importante di IoT, anche una funzione di definizione, quindi non riesco a capire perché questa domanda sia fuori tema.
Gilles 'SO- smetti di essere malvagio' il

Risposte:


13

Per garantire che il tuo dispositivo sia abbastanza sicuro, ho diversi suggerimenti:

  1. Aggiungi un po 'di crittografia alla comunicazione Bluetooth. Consiglierei di tenere fuori chiave le chiavi di crittografia. Ad esempio, potresti chiedere all'utente di scansionare un codice QR che si trova sul dispositivo, sulla scatola stampata ecc. Durante la configurazione iniziale dell'app mobile, magari con una chiave AES? Sta a te. Questo per impedire a qualcuno di vedere la password trasmessa via etere con testo in chiaro.
  2. Se puoi, stai lontano dalla modalità ECB (usa CBC) dell'algoritmo di crittografia che scegli, in quanto potrebbe fornire alcune informazioni sui dati trasmessi. Maggiori informazioni su questo possono essere trovate qui .
  3. Sulla trasmissione dei dati bluetooth, assicurati di includere un ID univoco, in modo che il messaggio non possa essere ripetuto (ad esempio, potresti includere un timestamp). Potresti anche implementare un sistema simile a TOTP.
  4. Metti una porta sul dispositivo che gli consenta di eseguire facilmente il flashing, in modo che, nel caso in cui ti rendi conto che il software ha un bug (e per qualche motivo non puoi aggiornarlo OTA), il dispositivo non è un costoso fermacarte, solo un dispositivo che deve essere collegato a un PC e trasferito su un nuovo software.
  5. Extra: per garantire che qualcuno con un certificato root non autorizzato (probabilmente auto-emesso e installato sul dispositivo client) non possa intercettare le comunicazioni del server, verificare il certificato HTTPS. Ecco un SO che lo richiede per Android, devi essere in grado di trovare risorse simili anche per iOS .

Inoltre, se vuoi saperne di più sulla crittografia e la crittografia che utilizzerai per proteggere il tuo dispositivo, controlla questo ebook (gratuito) . Parla molto di buone e cattive implementazioni di algoritmi di crittografia e dovrebbe aiutarti a proteggere il tuo prodotto. (Nota 1: per favore, non creare il tuo algoritmo. Nota 2: non sono affiliato con crypto101 o lvh.)


2
"Se puoi, stai lontano dalla BCE". No, cattivo consiglio. Un consiglio accettabile sarebbe "non usare mai la BCE", ma è ancora incompleto. Una risposta migliore direbbe che se stai digitando le lettere CBC nel tuo codice, stai sbagliando . In particolare AES-CBC non garantisce l'integrità o l'autenticità della comunicazione.
Gilles 'SO- smetti di essere malvagio' il

La BCE di @Gilles è sicuramente migliore di tutti i dispositivi iot oggi disponibili che trasmettono semplicemente cose come testo semplice o semplicemente xor con un valore impostato, ma sì, la BCE non porta quasi il tuo prodotto a "non hackerabile" (tecnicamente nulla lo fa, ma puoi tentare di fare qualcosa che lo mantenga il più sicuro possibile per il più lungo periodo di tempo e che non coinvolga la BCE, ma una corretta implementazione di AES-CBC 256).
Ave

13

Se puoi avere un TCP end-to-end, usa TLS end-to-end (ad es. Con HTTPS).

Non reinventare la ruota, soprattutto quando si tratta di crittografia: la maggior parte delle persone sbaglia. A meno che il dispositivo non sia troppo limitato dalle risorse per supportare TLS, se si scende al livello di AES, lo si sta facendo in modo sbagliato . L'errore n. 1 è di crittografare e dimenticare di autenticarsi: se hai un canale crittografato tra il tuo server e un man-in-the-middle, invece di un canale crittografato tra il tuo server e il tuo dispositivo, la crittografia non ha fornito alcun vantaggio . Se non puoi utilizzare TLS, assicurati che qualunque protocollo tu stia utilizzando, autentica tutto e crittografa ciò che deve essere riservato.

Per utilizzare TLS in modo sicuro, pensa a quali garanzie devi avere, dal punto di vista di ciascun partecipante. Generalmente il dispositivo deve sapere che sta parlando con il server legittimo. Ciò significa che deve controllare il certificato del server. Il dispositivo deve avere il certificato X.509 di un'autorità di certificazione registrato come attendibile; ciò richiede uno spazio di archiviazione che non può essere modificato da un utente malintenzionato, ma non richiede alcuna riservatezza dello spazio di archiviazione. Nota che non dovresti codificare direttamente il certificato del server, perché ciò non ti permetterebbe di sostituire facilmente quel certificato se è compromesso. Al contrario, il dispositivo memorizza l' identità prevista(nome host) del server e il certificato di un'autorità di certificazione che garantisce che una determinata chiave pubblica appartiene al nome host previsto. Ancora una volta, non reinventare la ruota, fare affidamento sul controllo del certificato fornito dalla libreria o dall'applicazione TLS.

Se il server deve sapere che sta parlando con un client legittimo, ogni client deve disporre del proprio certificato client. Ciò richiede l'archiviazione riservata sul client. Passare il certificato client alla funzione di apertura della sessione TLS dalla libreria TLS o impostarlo nella configurazione dell'applicazione.

Ciò si occupa di proteggere la comunicazione tra il server e il dispositivo. Se l'applicazione mobile è in grado di comunicare direttamente con il dispositivo (ad es. Per consentire il funzionamento disconnesso mentre si trova sulla rete Wi-Fi locale), è necessario prima eseguire l'associazione tra lo smart switch e il telefono cellulare. L'associazione significa uno scambio di chiavi, preferibilmente uno scambio di chiavi pubbliche se le risorse lo consentono, altrimenti un accordo di chiavi segrete. L'obiettivo di questa associazione è garantire che ogni dispositivo sappia con chi sta parlando.

Dovrai proteggere anche il canale di controllo, che passi direttamente dal dispositivo mobile allo smart switch o tramite un server. Pensa all'autorizzazione: esistono diversi livelli di accesso allo switch, ad esempio un livello di controllo che consente di effettuare la riconfigurazione e un canale di base che consente solo l'accensione / lo spegnimento? Questo è generalmente gestito da una fase di autenticazione dopo aver stabilito il canale sicuro (se possibile TLS).

Un'altra considerazione sono gli aggiornamenti del firmware. È difficile: da un lato, non esiste una sicurezza assoluta, quindi avrai delle patch di sicurezza da applicare di tanto in tanto. D'altra parte, un meccanismo di aggiornamento del firmware è una cosa complessa e potrebbe avere dei bug. Per lo meno, assicurati che gli aggiornamenti del firmware siano firmati. Fare affidamento esclusivamente sulla sicurezza del canale di comunicazione per gli aggiornamenti è complicato, perché la base attendibile per un canale sicuro è più grande di quella per una verifica statica della sicurezza e talvolta è possibile applicare aggiornamenti del firmware senza una connessione di rete. Oltre a verificare la firma, idealmente dovresti avere una certa protezione contro il rollback, in modo che un avversario possa "

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.