Le immagini del firmware per IoT devono essere crittografate per motivi di sicurezza?

Alcune persone sostengono che il codice che è open source può essere controllato da molti e quindi contiene pochi bug. D'altra parte, gli aggressori hanno lo stesso facile accesso e cercano anche queste stesse vulnerabilità. C'è sicuramente un compromesso qui che non è correttamente descritto nelle risposte precedenti.

Altri menzionano che il codice dovrebbe essere intrinsecamente sicuro e quindi non richiede alcuna offuscazione / crittografia / occultamento. È vero che un sistema dovrebbe essere progettato per essere sicuro anche se sai come funziona. Questo non significa che questo è sempre il caso E l'implementazione è impeccabile. In pratica, il codice non è mai sicuro al 100%. (Dai un'occhiata alla sicurezza delle app Web: Perché abbiamo bisogno di intestazioni di sicurezza per proteggerci dagli attacchi XSS e CSRF se non ci sono vulnerabilità nell'applicazione web?) Ulteriori misure di sicurezza possono essere adottate cercando di nascondere il codice tramite crittografia e offuscamento . Nel mondo mobile, il reverse engineering è anche visto come un serio rischio: OWASP Mobile Top 10 rischi .

Dato che nessun sistema è sicuro al 100% possiamo solo provare ad aumentare lo sforzo richiesto per romperlo.

Quindi ora, il compromesso tra codice open source / codice facilmente accessibile VS codificato e offuscato. Permettere la revisione pubblica sul tuo codice sorgente può aiutare a ridurre il numero di bug. Tuttavia, se sei una piccola azienda in cui il pubblico ha pochi incentivi a controllare liberamente il tuo codice, non c'è alcun beneficio dalla pubblicazione del tuo codice poiché nessuno lo guarderà con buone intenzioni. Tuttavia, diventa molto più facile per gli aggressori scoprire le vulnerabilità. (Non stiamo parlando della nuova versione iOS che ogni ricercatore di sicurezza sta cercando di risolvere) ..

In questo caso non stiamo nemmeno parlando di open sourcing del codice per la revisione pubblica. Stiamo parlando della crittografia del firmware in transito. I ricercatori di sicurezza probabilmente non acquisteranno il tuo dispositivo per ottenere il codice per scoprire e pubblicare vulnerabilità. Quindi la possibilità di avere i bravi ragazzi a trovare le vulnerabilità VS i cattivi che li trovano diminuiscono.

No. Non devi fare affidamento sull'oscurità del tuo firmware per nascondere potenziali vulnerabilità di sicurezza che esistono a prescindere se crittografate o offuscate il vostro firmware.

Ho una proposta radicale: fai l'esatto opposto. Rendi i file binari del firmware disponibili al pubblico e scaricabili, liberamente accessibili a chiunque li desideri. Aggiungi una pagina sul tuo sito con i dettagli su come contattarti in merito a problemi di sicurezza. Impegnarsi con la comunità di sicurezza per migliorare la sicurezza del tuo prodotto.

Dubbi sarebbe utile. È di gran lunga una scelta migliore per spingerlo open source rispetto a closed source. All'inizio potrebbe sembrare sciocco e persino controverso, ma aprire un progetto al pubblico ha molti vantaggi.

Mentre ci sono persone con intenzioni malevole, ci sono anche persone che vogliono aiutare e rendere Internet un posto migliore. L'open source consente a più occhi di guardare oltre il progetto, non solo di visualizzare informazioni su potenziali funzionalità, bug e problemi, ma anche di aumentare la sicurezza e la stabilità della "cosa"

E per essere d'accordo con la risposta di Polynomial, impegnarsi in una comunità e costruire una base di persone che ti aiuti con sicurezza, aumenterà la base di clienti con un margine significativo.

Un firmware ben progettato dovrebbe fare affidamento sulla forza della sua chiave di accesso piuttosto che basarsi sull'ignoranza dell'attaccante sulla progettazione del sistema. Questo segue il principio di ingegneria di sicurezza fondamentale noto come assioma di Kerckhoffs :

An information system should be secure even if everything about the system, except the system's key, is public knowledge.

Il matematico americano Claude Shannon raccomandato partendo dal presupposto che "il il nemico conosce il sistema ", cioè" uno dovrebbe progettare i sistemi ipotizzando che il nemico acquisisca immediatamente piena familiarità con loro ".

Potresti essere interessato a sapere che prima della fine del XIX secolo, gli ingegneri della sicurezza spesso sostenevano oscurità e segretezza come validi mezzi di protezione delle informazioni. Tuttavia, questi approcci conoscenza-antagonisti sono antitetici rispetto a diversi principi di progettazione dell'ingegneria del software, in particolare la modularità.

Sei sicuro di non confondere due metodi di crittografia?

Dovresti certamente firmare gli aggiornamenti del firmware per motivi di sicurezza. Ciò consente al dispositivo di verificare che proviene da te.

Per crittografarli aggiunge un po 'di oscurità e basta. Poiché il dispositivo di decrittografia non è sotto il tuo controllo, qualcuno prima o poi lo hackerà, estrarrà la chiave di decrittografia e la pubblicherà su Internet.

Devi pormi questa domanda. Qualcuno è abbastanza intelligente e abbastanza interessato da scaricare il tuo firmware e iniziare a cercare vulnerabilità che saranno scoraggiate da un ulteriore livello di crittografia del firmware in cui la chiave deve essere rivelata?

Questo è solo un altro cerchio da attraversare, non diverso da capire in che formato del disco si trova l'immagine del firmware. Questo non è nemmeno un cerchio particolarmente difficile da attraversare. Tieni presente che tutti i metodi FAR più sofisticati di ciò che ammonta a DRM sono stati tutti infranti.

Le probabilità sono che qualcuno determinato abbastanza per hackerare la tua macchina da caffè / lavastoviglie collegata ad Internet non sarà scoraggiato da un ulteriore livello di crittografia.

Nel senso di "la crittografia del firmware impedirà il rilevamento di vulnerabilità nel mio codice?" altre risposte hanno affrontato il nocciolo della questione: sebbene possa scoraggiare alcuni aggressori, la sicurezza attraverso l'oscurità porta a una falsa sensazione di invulnerabilità che è controproducente.

Tuttavia, vorrei aggiungere un tocco in più sulla base della mia esperienza. Ho visto che i pacchetti firmware sono a volte crittografati, ma la motivazione è solo per preservare la proprietà intellettuale di un'azienda, piuttosto che essere un controllo contro gli aggressori.

Naturalmente, gli hacker spesso trovano modi per aggirare questo "controllo", ma questa è una storia diversa.

Diverse persone hanno affermato che non si deve fare affidamento su come nascondere il codice crittografandolo, ma solo per renderlo sicuro. Molto recentemente la crittografia di alcuni software piuttosto critici negli iPhone di Apple è stata violata (il che significa che ora gli hacker possono vedere il codice reale, non di più). Ha impedito a chiunque di esaminare il codice per tre anni, quindi il tempo dal rilascio al primo crack è stato aumentato di tre anni. Sembra un'affermazione molto riuscita.

E la crittografia va molto bene insieme alla firma del codice. Quindi, quando il tuo dispositivo riceve un nuovo firmware, può rifiutare qualsiasi firmware falso. Ora quella parte non è solo raccomandata, è assolutamente essenziale.