Domanda:
Le immagini del firmware per l'IoT devono essere crittografate per motivi di sicurezza?
VC_work
2017-09-01 18:28:49 UTC
view on stackexchange narkive permalink

Quando si lavora con dispositivi Internet of Things, è consigliabile offuscare o crittografare le immagini del firmware inviate ai client? Questo per rendere più difficile il reverse engineering.

(Dovrebbero essere firmati ovviamente)

cosa c'entra il "reverse engineering" con la sicurezza?
Rendiamolo semplice: la crittografia è uno strumento per mitigare i rischi: se i rischi che hai nel firmware IoT possono essere mitigati dalla crittografia, allora sì, la crittografia ha senso
Il firmware è un software incorporato in un componente hardware.Se si trasmette utilizzando una rete pubblica, questo trasferimento deve essere crittografato.
@LeonanCarvalho: non è necessario crittografare il firmware per la trasmissione, solo per firmarlo e verificarlo (che non è crittografia.) Non importa se qualcuno sa cosa contiene il firmware, importa solo se qualcuno può manomettere il firmware che ottieneinstallato.
Il firmware deve essere decrittografato per funzionare sul dispositivo?In tal caso, i clienti ottengono le chiavi in un modo che gli utenti malintenzionati (che possono anche essere clienti) non possono?
"Abbiamo apportato alcuni miglioramenti al firmware della tua camera da letto a infrarossi collegata a Internet. Il nuovo firmware è crittografato, ma promettiamo che il suo unico scopo è fare qualcosa di innocuo"
È interessante trovare questa domanda visto che ne stavo parlando in classe di recente.Ecco una fonte che ho usato per prendere posizione nella DQ (Discussion Question): https://www.symantec.com/content/dam/symantec/docs/white-papers/iot-security-reference-architecture-en.PDF
@schroeder, un paio di cose (1) il design stesso potrebbe aver bisogno di essere protetto, ad es.per ragioni di PI (2) potrebbe rientrare nella preoccupazione di sicurezza "scoperta", dove la conoscenza del progetto potrebbe rendere possibili esplosioni reali.
Otto risposte:
#1
+85
Polynomial
2017-09-01 18:38:54 UTC
view on stackexchange narkive permalink

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.

Ancora meglio: offri un (grande) premio per le vulnerabilità della sicurezza, con vulnerabilità più gravi (misurate in _massimo_ danno che possono causare) che guadagnano un premio maggiore.Si spera che questo convincerà alcuni aspiranti cracker a rivelare i dettagli (premio certo) invece di tentare di sfruttarli (premio incerto, _possibilmente_ più grande ma probabilmente più piccolo, più il rischio di essere scoperti).
Vorrei persino incoraggiare a creare il firmware [software gratuito] (https://en.wikipedia.org/wiki/Free_software) o [open source] (https://opensource.org/).
@wizzwizz4 Molte aziende non hanno il capitale per gestire un vero e proprio programma di bug bounty, in particolare le PMI e le startup autofinanziate.In generale, ho visto che queste aziende offrono ricompense alternative, come prodotti gratuiti o fortemente scontati, t-shirt, gadget, ecc. A seconda della natura dell'attività e del marchio.Le taglie di bug non devono necessariamente essere formali e costose.
@Polynomial Molte aziende non hanno il capitale per _non_ gestire un programma di bug bounty.Se viene rilevata una violazione di grandi dimensioni, sicuramente vale la pena di $ x perché non venga trovata quando i tuoi clienti ti fanno causa per danni causati da una violazione.
@wizzwizz4 Dubito che la mancanza di un programma di bug bounty sarebbe mai il fattore di confusione in una violazione.Le taglie sono ottime, ma sono un livello opzionale nel budget della difesa di quasi tutte le aziende, forse ad eccezione delle organizzazioni altamente pubbliche.Se l'obiettivo è evitare una violazione, il costo e il tempo necessari per eseguire un BBP possono essere meglio investiti in misure di difesa più dirette come la formazione del personale e il miglioramento delle capacità della squadra blu.I BBP sono ottimi se hai già coperto tutto il resto e hai un budget di riserva, o se la percezione dei mercati della sicurezza è buona nel tuo verticale.
Il suggerimento di @BasileStarynkevitch's non è così lontano come potrebbe sembrare.Presumibilmente, il firmware è di scarso utilizzo non accademico per qualcuno che non ha il dispositivo in questione.L'azienda si occupa di vendere gadget fisici e forse servizi, ma non proprio software.In tali circostanze, il rilascio del software affinché tutti possano vederlo potrebbe benissimo essere nel peggiore dei casi neutrale e forse dare un impulso alle PR.Punti bonus se in realtà c'è un modo per un utente ordinario (ma tecnicamente competente) di caricare il firmware modificato sul dispositivo.
Presumibilmente il firmware è utile ai loro concorrenti.
Anche questo è il migliore per il mondo in generale, ma non necessariamente per l'azienda che pubblica il firmware.(In entrambi i casi le vulnerabilità verranno trovate e l'azienda ne soffrirà; vogliono soffrire prima perché erano più facili da trovare?)
@immibis Se una vulnerabilità viene scoperta separatamente e non viene loro divulgata in modo responsabile, hanno il privilegio di PR.L'alternativa è ritardare l'inevitabile e renderlo peggiore.
@Polynomial Forse tra le persone attente alla sicurezza.Il grande pubblico vede ancora "prodotto XYZ hackerato".
I ricercatori di sicurezza non daranno un'occhiata a un fornitore locale di IOT che produce un firmware scadente.Perché le persone controllano il firmware?Fama, fortuna?Che tipo di visibilità otterrai trovando un bug in un firmware scritto male da una piccola azienda locale?Quanta taglia dovresti dare?
@Silver Sono un ricercatore di sicurezza e guardo sempre il firmware del fornitore IoT.Non mi aspetto una taglia.Lo faccio per divertimento.
#2
+11
Josh Ross
2017-09-01 18:52:36 UTC
view on stackexchange narkive permalink

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.

L'open source può essere un passo troppo lontano per un prodotto commerciale, e il principio "molti occhi" è generalmente imperfetto (vedi: lo stato di OpenSSL prima di Heartbleed).Detto questo, se il progetto utilizza un codice con licenza GPL senza un accordo speciale da parte dell'autore, il sorgente completo deve essere comunque reso disponibile.
@Polynomial Se il progetto utilizza un codice con licenza GPL, * le parti che toccano direttamente il codice GPL * devono essere rese disponibili come codice sorgente.Non tutto.La mera aggregazione si applica ancora.
Posso vedere come potrebbe essere un problema con completamente Open Source.Inoltre, di solito si tratta di semantica quando si tratta di Open Sourcing su codice GPL.Esaminerò anche la questione OpenSSL, grazie per questo!
Penso davvero che una buona risposta dovrebbe affrontare il problema "se il mio software deve essere proprietario, vale la pena crittografarlo / offuscarlo".Ci possono essere molte ragioni per mantenere il software proprietario che non hanno nulla a che fare con la sicurezza (contratti con i clienti, burocrazia da parte del management, algoritmi preziosi).Credo anche che pubblicare il codice sorgente non sia un buon modo per sistemare un processo di sviluppo software insicuro e non dovrebbe essere enfatizzato eccessivamente dedicando l'intera risposta ad esso.
#3
+6
Mavaddat Javid
2017-09-01 23:33:33 UTC
view on stackexchange narkive permalink

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à.

#4
+5
Silver
2017-09-05 12:50:19 UTC
view on stackexchange narkive permalink

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.

#5
+2
Tom
2017-09-02 10:49:21 UTC
view on stackexchange narkive permalink

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.

Puoi sempre rendere illegale la distribuzione della chiave di decrittazione!Rendere illegali i numeri funziona sicuramente ...
#6
  0
Steve Sether
2017-09-02 00:40:08 UTC
view on stackexchange narkive permalink

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.

#7
  0
Sergio A. Figueroa
2017-09-08 11:53:14 UTC
view on stackexchange narkive permalink

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.

#8
-4
gnasher729
2017-09-02 02:03:46 UTC
view on stackexchange narkive permalink

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.

La crittografia e la firma sono ortogonali.Entrambi possono avere valore, ma risolvono problemi diversi e lo fanno separatamente.
Entrambi sono molto difficili se non usi correttamente alcune librerie crittografiche e facili se lo fai.Se ne fai uno, fare l'altro richiede uno sforzo minimo.Ed entrambi risolvono lo stesso problema: aiutare a mantenere l'hardware al sicuro.
Quello che ti manca è che la crittografia nell'aneddoto che hai menzionato * è solo pertinente * perché il codice è crittografato ovunque ma all'interno dell'unità di esecuzione fidata.Per un normale processore, anche se l'aggiornamento è crittografato in volo o in memoria, dovrà essere decrittografato * da qualcosa memorizzato sul dispositivo * per essere eseguito.È abbastanza difficile fare in modo che qualcuno in possesso di una copia dell'hardware non possa ottenere il codice decrittografato, e solo nelle situazioni insolite in cui ciò viene fatto efficacemente crittografare l'aggiornamento in volo è importante.
@gnasher729 In realtà, più a lungo per il primo hack, peggio.Tre anni dopo, è molto più difficile correggere il bug: il produttore potrebbe anche non essere ancora in giro e chissà se hanno ancora gli strumenti.E tre anni dopo, il dispositivo potrebbe essere dimenticato e non più mantenuto.Tre anni dopo, ci saranno più dispositivi sul campo: prima si individuano i difetti, prima (e più probabile) verranno risolti.(E come fai a sapere che un ragazzo davvero cattivo non sapeva del difetto e aveva tre anni in più per sfruttarlo?)


Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...