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 "