No. Non dovresti fare affidamento sull'oscurità del tuo firmware per nascondere potenziali vulnerabilità di sicurezza esistenti indipendentemente dal fatto che tu crittografi / offuschi o meno il tuo firmware.

Ho un suggerimento radicale : fai l'esatto contrario. Rendi i tuoi file binari del firmware pubblicamente disponibili e scaricabili, liberamente accessibili a chiunque li desideri. Aggiungi una pagina sul tuo sito con i dettagli su come contattarti per problemi di sicurezza. Interagisci con la community della sicurezza per migliorare la sicurezza del tuo prodotto.

Dubito che sarebbe vantaggioso. È di gran lunga un'opzione 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 dannose, ci sono anche persone che vogliono aiutare e rendere Internet un un posto migliore. L'open source consente a più occhi di guardare il progetto, non solo per visualizzare potenziali funzionalità, bug e problemi, ma anche aumentare la sicurezza e la stabilità della "cosa"

E per concordare con la risposta di Polynomial, impegnarsi in una comunità e la creazione di una base di persone che ti aiutano con la sicurezza, aumenterà la base di clienti di un margine significativo.

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

Un sistema informativo dovrebbe essere sicuro anche se tutto ciò che riguarda il sistema, eccetto la chiave del sistema, è di dominio pubblico.

Il matematico americano Claude Shannon raccomandava di partire dal presupposto che "il nemico conosce il sistema", cioè "si dovrebbe progettare sistemi partendo dal presupposto che il nemico acquisirà immediatamente piena familiarità con essi ".

Potrebbe interessarti sapere che prima della fine del XIX secolo, gli ingegneri della sicurezza spesso sostenevano oscurità e segretezza come mezzo valido per proteggere le informazioni. Tuttavia, questi approcci antagonistici alla conoscenza sono antitetici a diversi principi di progettazione dell'ingegneria del software, in particolare la modularità.

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

Altri affermano che il codice dovrebbe essere intrinsecamente sicuro e quindi non richiede offuscamento / crittografia / occultamento. È vero che un sistema dovrebbe essere progettato per essere sicuro anche se sai come funziona. Ciò non significa che sia sempre così E che l'implementazione sia 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?) È possibile adottare misure di sicurezza aggiuntive cercando di nascondere il codice tramite crittografia e offuscamento . Nel mondo mobile, il reverse engineering è persino visto come un serio rischio: OWASP Mobile Top 10 risk.

Poiché nessun sistema è sicuro al 100%, possiamo solo provare ad aumentare lo sforzo richiesto per romperlo.

Quindi ora, il compromesso tra codice open source / facilmente disponibile VS codice crittografato e offuscato. Consentire la revisione pubblica del 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 vantaggio nel pubblicare il tuo codice poiché nessuno lo guarderà con buone intenzioni. Tuttavia, diventa molto più facile per gli aggressori scoprire le vulnerabilità. (Non stiamo parlando della versione iOS più recente che ogni ricercatore di sicurezza sta cercando di decifrare) ..

In questo caso non stiamo nemmeno parlando di open source del codice per la revisione pubblica. Stiamo parlando di crittografare il firmware in transito. I ricercatori di sicurezza probabilmente non acquisteranno il tuo dispositivo per ottenere il codice per scoprire e pubblicare le vulnerabilità. Pertanto la possibilità che i bravi ragazzi trovino le vulnerabilità contro i cattivi che le trovano diminuisce.

Sei sicuro di non confondere due metodi crittografici?

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

Criptarli aggiunge un po 'di oscurità e il gioco è fatto. Poiché il dispositivo di decrittografia non è sotto il tuo controllo, prima o poi qualcuno lo hackererà, estrarrà la chiave di decrittazione e la pubblicherà su Internet.

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

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

È probabile che qualcuno sia abbastanza determinato da hackerare la tua macchina per il caffè / lavastoviglie connessa a 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 ne hanno affrontato il nocciolo: 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ù al base della mia esperienza. Ho visto che i pacchetti firmware a volte sono crittografati, ma la motivazione è solo per preservare la proprietà intellettuale di un'azienda, piuttosto che essere un controllo contro gli aggressori.

Ovviamente, gli hacker spesso trovano il modo di aggirare questo problema " control ", ma questa è una storia diversa.

Diverse persone hanno detto che non dovresti fare affidamento sull'offuscamento del codice crittografandolo, ma solo per renderlo sicuro. Di recente la crittografia di alcuni software piuttosto critici negli iPhone di Apple è stata violata (il che significa che gli hacker ora possono vedere il codice effettivo, non 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 offuscamento di grande successo.

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 consigliata, è assolutamente essenziale.