Standard per mantenere aggiornata la sicurezza dei dispositivi

Con i dispositivi IoT in genere costruiti con margini di profitto bassi e specifiche a bassa potenza, la funzionalità è in genere limitata a quella necessaria. Ma per un dispositivo che dovrebbe durare un certo numero di anni, ci saranno vulnerabilità della sicurezza e problemi che devono essere risolti (vedi la botnet Mirai come esempio)

Come produttore di IoT, come posso abilitare l'applicazione di patch o l'aggiornamento di algoritmi di crittografia o protocolli di sicurezza in remoto o semplicemente garantire che il dispositivo sia protetto? Quali standard devo seguire?

In che modo i produttori di IoT consentono il patching o l'aggiornamento di algoritmi di crittografia o protocolli di sicurezza in remoto o semplicemente per garantire che il dispositivo sia protetto?

Un gran numero di produttori IoT ha una soluzione semplice a questo: "non preoccuparti" . Questi tendono ad essere gli stessi sviluppatori che aggiungono password predefinite (o anche immutabili) ai loro dispositivi, il che ha portato Mirai in primo luogo.

Come menzionato nella risposta di Rory , ci sono costi considerevoli per fornire sia i meccanismi che il tempo di sviluppo effettivo per progettare e implementare le correzioni. Sospetto fortemente che senza la pressione regolamentare (o la domanda dei consumatori, che non sembra essere il caso), non vi sarà alcun incentivo per un produttore ad aumentare i prezzi dei propri prodotti per una maggiore sicurezza. L'Australia sembra fare questo passo considerando un sistema di classificazione della sicurezza obbligatorio per tutti i dispositivi IoT.

Penso che per la maggior parte dei produttori l'idea migliore sia convincere qualcun altro a gestire la sicurezza. Proprio come la maggior parte degli sviluppatori web utilizza framework consolidati come Django e Ruby on Rails per evitare di ripetere gli stessi errori , gli sviluppatori IoT dovrebbero fare lo stesso. Esistono diverse opzioni, a seconda della complessità del dispositivo:

• I dispositivi di fascia alta potrebbero utilizzare sistemi operativi come Ubuntu IoT o Windows 10 IoT Core in cui gli aggiornamenti di sicurezza vengono eseguiti dallo sviluppatore del sistema operativo e inviati automaticamente. Gran parte di questo non è specifico dell'IoT, ma è di gran lunga preferibile a ciascun dispositivo IoT utilizzando un sistema operativo interno personalizzato che difficilmente riceverà manutenzione.

• I dispositivi di fascia bassa come i moduli ESP8266 sono forse più limitati, in quanto non sono in grado di eseguire sistemi operativi così complessi e tendono a eseguire codice sviluppato appositamente per quel dispositivo. Esistono ancora opzioni come Mongoose OS che offrono aggiornamenti firmware over-the-air

I produttori di IoT dovrebbero generalmente trarre vantaggio dalle soluzioni esistenti ove disponibili. Gli sviluppatori Web di solito non ricreano un framework Web per ogni nuovo sito Web, quindi perché l'IoT dovrebbe essere sostanzialmente diverso? La risposta di Rory offre un eccellente elenco di funzionalità che dovrebbero essere implementate da un buon sistema operativo per l'IoT, e il solo utilizzo di un "sistema operativo IoT" non risolverà tutti i tuoi problemi. Come spiega questa guida IoT di Windows , è necessario adottare misure per garantire che l'hardware e il firmware siano protetti, nonché il sistema operativo stesso. Le idee nella risposta di Rory sono piuttosto complete in questo senso.

Ecco alcuni esempi dei sistemi operativi che ho suggerito su quali sistemi utilizzano per aggiornare la sicurezza:

• Windows IoT:

  • Aggiornamenti automatici delle funzionalità e della sicurezza quando connessi a Internet
  • Con Azure IoT Suite, ogni dispositivo ha un certificato X.509 per l'autenticazione nell'hub. Questo assicura anche che se un dispositivo è compromesso, gli altri non ne sono interessati

• Ubuntu Core :

  • Aggiornamenti automatici automatici per la sicurezza
  • "Aggiornamenti over-the-air transazionali - con funzionalità di rollback complete"

Il 30 ottobre 2017 Moran ha pubblicato questa bozza IETF intitolata A Firmware Update Architecture for Internet of Things Devices .

Un riassunto chiave delineato sul computer Bleeping è

• Il meccanismo di aggiornamento deve funzionare allo stesso modo anche se il file binario del firmware viene fornito tramite Bluetooth, WiFi, UART, USB o altri supporti.
• Il meccanismo di aggiornamento deve funzionare in un tipo di distribuzione broadcast, consentendo agli aggiornamenti di raggiungere più utenti contemporaneamente.
• La sicurezza end-to-end (crittografia a chiave pubblica) deve essere utilizzata per verificare e convalidare le immagini del firmware.
• Gli attacchi di rollback devono essere prevenuti.
• Tutte le informazioni necessarie affinché un dispositivo prenda una decisione sull'installazione di un aggiornamento devono adattarsi alla RAM disponibile di un dispositivo IoT vincolato. Questo impedisce l'esaurimento della scrittura flash.
• Un'interruzione di corrente in qualsiasi momento durante il processo di aggiornamento non deve causare un guasto al dispositivo.
• Il meccanismo di aggiornamento del firmware non deve richiedere modifiche ai formati di file del firmware esistenti.
• Il nuovo meccanismo di aggiornamento del firmware deve essere in grado di funzionare con un piccolo bootloader, specifico per la maggior parte dei dispositivi IoT.
• Il meccanismo di aggiornamento deve tenere conto di più autorizzazioni. Ad esempio, un aggiornamento del firmware per le apparecchiature di infrastruttura critiche dovrà essere firmato sia dall'autore del firmware sia dal proprietario / operatore dell'apparecchiatura.
• La nuova architettura di aggiornamento del firmware IoT deve supportare i file manifest.

Questa è una bozza, in quanto si tratta di una nuova area. La mia aspettativa è che sarà guidato più dalla regolamentazione che dalla domanda dei consumatori, in quanto i consumatori non si preoccupano davvero degli aggiornamenti o della sicurezza a meno che non li influenzino direttamente. Eventuali miglioramenti in quest'area influiranno sul costo dei dispositivi.

Se il firmware del dispositivo può essere reso meno complesso del bootloader richiesto per un aggiornamento remoto protetto, non implementare l'aggiornamento remoto .

So che il consenso è quello di avere un bootloader sicuro e robusto, con una forte autenticazione crittografica pubblica, meccanismi di rollover sicuri, forse uno stack di rete di base, e quindi aggiungere un RTOS, con uno stack di rete IP + TLS completo, quindi aggiungere per di più la tua applicazione. Questa è pura follia per un dispositivo a basso consumo a basso costo. IMHO, questo porta a prodotti che vengono aggiornati ogni settimana o giù di lì, che tendono a disturbare gli utenti perché a volte gli aggiornamenti iniziano nel momento sbagliato, falliscono o rompono qualcosa. Anche gli aggiornamenti consumano molta energia, quindi l'utente deve caricare più spesso. E la sicurezza è ancora lontana dall'essere garantita in quanto la superficie di attacco è ampia.

Il dispositivo sta eseguendo il rilevamento / l'attivazione di base, forse qualche trigger / visualizzazione locale ma non molto? Salta tutto ciò.

Scrivi un codice bare metal, usa uno stack molto semplice, controllalo accuratamente, se possibile esegui una verifica formale. E quindi puoi essere relativamente sicuro che il tuo dispositivo non avrà problemi di sicurezza per il prossimo decennio.

Se tutto ciò che hai è un martello, tutto sembra un chiodo. Ed è per questo che la maggior parte dei programmatori tenta di scrivere codice per proteggere il loro codice esistente non protetto. Scrivere meno codice non è sempre naturale.