È una cattiva pratica conservare i certificati nella memoria esterna?

Stiamo lavorando su AWS-IoT utilizzando un microcontrollore STM32.

Fino ad oggi, stavamo scrivendo i certificati sul flash e bloccando il flash dalla lettura esterna. All'aumentare del codice dell'applicazione, stiamo ottenendo meno spazio sul flash, quindi abbiamo pianificato di spostare il certificato esternamente su una scheda SD / EEPROM e di leggere ogni volta che era necessario prima di connetterci ad AWS-IoT.

Appunti:

• La politica scritta per la cosa consentirà solo i dispositivi con nomi particolari di connettersi su quel particolare certificato.

• La cosa è autorizzata a pubblicare solo 2 canali (è il nome e un canale di feed di dati) che è collegato a un elaboratore di dati che ignorerà tutti i pacchetti non autorizzati che vi arrivano.

• Se la cosa pubblica / sottoscrive qualsiasi altro argomento, AWS disconnetterà immediatamente la cosa.

Se rilevo che un dispositivo viene rubato / non autorizzato, disattiviamo la chiave dal server.

Cosa può fare uno sfruttatore con i certificati (RootCA, chiave del server, chiave del client)?

È una cattiva pratica conservare i certificati per tali casi d'uso su una memoria esterna a cui può accedere un exploit?

Citi “certificati”, ma dal contesto, penso che ti riferisci a due cose diverse.

• Il dispositivo ha una chiave privata , unica per questo dispositivo e non nota al di fuori del dispositivo. Questa chiave identifica il tuo dispositivo. Chiunque possa accedere a tale chiave può impersonare il dispositivo. Ciò significa che possono, in particolare:

  • Pubblica dati validi ma non corretti sui canali in cui il tuo dispositivo è legittimamente autorizzato a pubblicare.
  • Pubblica dati non validi che vieteranno il dispositivo legittimo.
  • Forse, a seconda del caso d'uso, esporre alcune informazioni private del proprietario del dispositivo.

  È meglio che questa chiave privata rimanga riservata.

• Il tuo dispositivo probabilmente ha almeno una chiave pubblica , che gli consente di riconoscere con quali server sta parlando. Va bene se qualcuno può leggere questa chiave: è pubblica. Ma un utente malintenzionato non dovrebbe essere in grado di modificare la chiave. Altrimenti, potrebbero comunicare con il dispositivo e impersonare il server. Ciò potrebbe consentire loro di fare cose come:

  • Invia un aggiornamento del firmware al dispositivo.
  • Invia un aggiornamento di configurazione al dispositivo.
  • Fai caricare al dispositivo i suoi dati in una posizione diversa.

La buona notizia è che questa analisi delle minacce non è in realtà molto rilevante. Non è necessario sacrificare alcuna sicurezza ! (Almeno non proprietà di riservatezza e autenticità - se si memorizzano oggetti esternamente, la disponibilità subisce un colpo, perché è un pezzo del sistema che potrebbe andare perso.)

Fintanto che hai almeno 128 bit di memoria su cui puoi scrivere almeno una volta, che hai e altro, puoi implementare una soluzione di archiviazione remota sicura. Utilizzare l'archiviazione sul dispositivo a spazio limitato per memorizzare una chiave segreta. Questa chiave segreta deve essere unica per dispositivo; STM32 ha un RNG hardware, quindi è possibile generarlo sul dispositivo al primo avvio. Se il dispositivo non disponeva di un RNG hardware, è possibile generare la chiave in una posizione off-device sicura e iniettarla nel dispositivo.

Con questa chiave, utilizzare la crittografia autenticata per gli oggetti archiviati dal dispositivo. Quando si desidera leggere alcuni dati dalla memoria esterna, caricarli, decrittografarli e verificarli. Quando si desidera scrivere alcuni dati su memoria esterna, crittografarli e firmarli. Ciò garantisce che i dati siano confidenziali e autentici come i dati nella memoria interna.

La crittografia autenticata è sufficiente per garantire la riservatezza e l' autenticità dei dati, ma non ne garantisce completamente l' integrità .

• Se è presente più di un blocco di dati, quando il dispositivo legge nuovamente un blocco di dati, non è sicuro che si tratti del blocco corretto. Soluzione: includono un identificatore univoco nel contenuto di ogni pezzo (ad esempio iniziare ogni pezzo con una delle "AWS-IoT private key.", "configuration CA certificate.", "publishing server CA certificate.", "user personal data.", ...).
• Se aggiorni i dati a un certo punto, quando li rileggi, non puoi essere sicuro di ricevere l'ultima versione di tali dati. Se qualcuno può modificare la memoria esterna, non può inserire dati falsi perché ciò fallirebbe il controllo di autenticità, ma possono ripristinare i vecchi dati, perché ciò che era autentico era ancora autentico. Soluzione: in ogni blocco di dati archiviato esternamente, includere un contatore che si incrementa ogni volta che si scrive una nuova versione di quel blocco. Quando leggi un pezzo indietro, verifica che sia la versione prevista.

Per evitare di murare un dispositivo nel caso in cui la memoria esterna sia danneggiata o altrimenti persa, nello spazio limitato si ha spazio sulla memoria interna, si dovrebbe dare priorità a tutto ciò che è necessario per ripristinare il dispositivo a uno stato "buono", ad esempio un ripristino delle impostazioni di fabbrica . La seconda priorità saranno le considerazioni sulle prestazioni.

Un po 'di contesto

Poiché stai utilizzando MQTT con AWS IoT, devi utilizzare i certificati X.509 per autenticazione e sicurezza. Amazon ha alcune indicazioni su come proteggere i certificati, quindi citerò qui:

I certificati consentono l'utilizzo di chiavi asimmetriche con i dispositivi. Ciò significa che puoi masterizzare le chiavi private in un archivio sicuro su un dispositivo senza mai lasciare che il materiale crittografico sensibile lasci il dispositivo.

Dal momento che stai utilizzando la protezione da lettura (RDP) dell'STM32, tutti gli aggressori tranne quelli più determinati avranno difficoltà ad accedere ai certificati nel tuo schema attuale:

La protezione globale della lettura consente al codice del firmware incorporato (precaricato nella memoria Flash) di proteggere da reverse engineering, dumping mediante strumenti di debug o altri mezzi di attacco intrusivo.

• Livello 0 - Nessuna protezione (impostazione predefinita)
• Livello 1 - La memoria flash è protetta dalla lettura tramite debug o dumping del codice mediante il codice RAM caricato
• Livello 2: tutte le funzionalità di debug sono disabilitate

Lo storage esterno sarà sicuro?

Probabilmente non è così sicuro . Se la chiave privata del tuo cliente viene rubata, un utente malintenzionato può inviare dati che sembrano provenire dal tuo dispositivo, quando in realtà non lo è. Sebbene non sia chiaro quali dati stai inviando, qualsiasi dato non attendibile può essere un rischio per la sicurezza.

Di quali bit ho bisogno per mantenere privato?

Quando crei un certificato dispositivo su AWS IoT, dovresti vedere un'immagine come questa:

^{Immagine dalla pagina Crea e attiva un certificato dispositivo della documentazione AWS IoT.}

La chiave privata è ciò di cui hai veramente bisogno per mantenere ... privato , e, se possibile, dovrebbe essere sicuramente memorizzato nella memoria protetta da lettura. La chiave pubblica e il certificato sono progettati per essere condivisi, quindi se stai esaurendo lo spazio, puoi spostarli in sicurezza su un archivio esterno. Puoi ottenere un po 'più di contesto nella pagina Come funziona SSL / TLS? su Information Security Stack Exchange e crittografia a chiave pubblica su Wikipedia. Penso che ti farei un disservizio se non includessi questa immagine per spiegare perché la chiave privata deve essere segreta:

.

^{Immagine da Wikipedia , rilasciata nel pubblico dominio.}

La chiave pubblica del dispositivo è ciò che AWS IoT utilizza per firmare i messaggi da inviare al dispositivo (ma non prova chi sta inviando il messaggio ). Quindi, davvero, non è un enorme disastro se qualcuno ruba la chiave pubblica, perché non è pensato per essere un segreto.

La chiave privata è ciò che il tuo dispositivo utilizza per decrittografare i messaggi, quindi è un problema leggermente più grande se un utente malintenzionato lo ruba.

Hai anche chiesto cosa sarebbe successo se l'attaccante avesse rubato il certificato RootCA. Se qualcuno rubasse la chiave privata di AWS IoT , sarebbe disastroso, ma il certificato RootCA sul tuo dispositivo non è quello . Quello RootCA.crtche Amazon ti offre è completamente pubblico e lo scopo è quello di poter verificare che non sei stato attaccato in alcun modo (molto probabilmente un man-in-the-middle che finge di essere server AWS IoT).

Che danno potrebbe fare un dispositivo compromesso?

Il dispositivo rubato può eseguire solo le azioni elencate nella politica . Cerca di seguire il principio del privilegio minimo ; concedi al tuo dispositivo solo i privilegi di cui ha assolutamente bisogno , quindi se succede il peggio, non può causare il caos troppo. Per il tuo caso specifico:

La cosa è autorizzata a pubblicare solo 2 canali (il suo nome e un canale di feed di dati) che è collegato a un elaboratore di dati che ignorerà tutti i pacchetti non autorizzati che vi arrivano.

Quello è buono. Qualsiasi attacco dovrebbe essere isolato solo sui due argomenti MQTT su cui il dispositivo può pubblicare, quindi non causerà danni su larga scala.

Idealmente, vuoi che il tuo sistema generale abbia un design tale che sezionare una singola unità rompe solo quell'unità e non il sistema in generale.

Soprattutto se si memorizzano le chiavi in ​​una memoria distinta in modo tale che attraversino un'interfaccia elettrica standard tra i chip, dovrebbero essere solo chiavi che sono già sicure da pubblicare o uniche per quella particolare istanza fisica del dispositivo.

Se una singola chiave viene estratta da un singolo dispositivo e inizia ad essere maltrattata o visualizzata in un volume di traffico che deve provenire da più cloni non autorizzati, è possibile vietare quella chiave sul lato server.

Le tue chiavi dovrebbero ovviamente avere la proprietà di non essere qualcosa che una parte non autorizzata può indovinare da alcuni esempi estratti o generare le proprie istanze compatibili originali di - cioè, hai bisogno di un record delle chiavi che hai generato dove quelle valide sono solo una parte piccola e imprevedibile di un enorme spazio di possibilità, altrimenti devi firmare le chiavi che generi e far sì che il tuo sistema accetti solo una chiave in combinazione con la sua prova di firma.

Dovresti cercare di mantenere segreta la chiave del client (ma capire le implicazioni della sua perdita (1), come descritto nelle altre risposte). La chiave pubblica del server e il certificato pubblico AWS sono importanti da proteggere all'estremità del dispositivo non perché si desidera mantenere il segreto, ma perché sostituendo il certificato AWS (su un dispositivo compromesso) un utente malintenzionato può convincere il dispositivo a eseguire un scambiare con l'host dell'attaccante o per gestire le comunicazioni con AWS.

In questo modo (2), un utente malintenzionato può eliminare la sicurezza TLS, il che può comportare una riduzione sufficiente della sicurezza da consentire il reverse engineering della chiave client.

Con questo ragionamento, l'unica chiave che è possibile esporre in modo sicuro in un dispositivo di memoria esterno è la chiave pubblica del server. La modifica di questo (3) consentirebbe solo al tuo dispositivo di essere costretto a connettersi a un servizio AWS canaglia, presumibilmente difficile da progettare per l'accesso. Anche perdere solo questa chiave potrebbe consentire a qualcuno di curvare o falsificare alcune trasmissioni (ad esempio se il livello TLS può essere in qualche modo declassato).

Quindi, in sintesi, il rischio non è semplicemente quello di perdere informazioni, esiste il rischio se al firmware (apparentemente attendibile) possano essere fornite informazioni sicure non attendibili.