Memorizzazione di una chiave sicura nella memoria di un dispositivo incorporato


10

Sto lavorando su un dispositivo incorporato che invia / riceve dati e li memorizza in modalità testo cifrato (modalità crittografata). Qual è l'approccio migliore per l'archiviazione delle chiavi (ho usato MCU ARM CORTEX serie M)?

1-Memorizzazione delle chiavi nella memoria SRAM e in ciascuna sequenza di avvio, immettere le chiavi nella MCU incorporata e memorizzarle nella memoria SRAM. È il modo migliore secondo me, quindi quando MCU rileva la penetrazione (con sensore antimanomissione o ...) può cancellare SRAM rapidamente e ripristinarsi. Svantaggio: se l'attaccante riesce a superare i tamponi e l'accesso al dispositivo, quanto è sicura la memoria SRAM (contro il mining di codice). Non riesco a trovare alcuna capacità di sicurezza per questa memoria nelle MCU.

2-Genera chiavi e le memorizza nella memoria flash durante la programmazione dell'MCU. Il supporto CRP della memoria flash MCU (protezione dalla lettura del codice) che impedisce il mining del codice e con l'assistenza del suo motore AES interno e del motore RNG (generazione di numeri casuali) possiamo creare una chiave casuale e crittografare la memoria flash e archiviarla nella OTP ( una volta programmabile memoria -una memoria crittografata a 128 bit), quindi nell'esecuzione del codice decodifichiamo la memoria flash con chiave RNG e l'accesso alla chiave e ai codici iniziali. Svantaggio: chiavi archiviate in una memoria non volatile, i manomissioni saranno inutili e gli aggressori avranno molto tempo per estrarre le chiavi.

Chiave 3-memorizzata nella memoria EEPROM, combinazione di 2 approcci precedenti, chiave memorizzata nella memoria non volatile ma quando EEPROM di penetrazione rileva i tamponi è cancellabile.

Considero LPC18S57FBD208 (cortex m3 con 1MB di memoria flash, 180MHZ, SRAM da 136KB, EEPROM da 16KB e un controller LCD TFT di cui ho bisogno per guidare un LCD TFT da 7 "e un motore crittografico AES a 128 bit) perché ci sono altri suggerimenti?

Risposte:


18

Nessuna di queste opzioni è particolarmente migliore o peggiore delle altre, perché sono tutte molto insicure. Vado con l'opzione 4.

  1. SRAM è il posto più sicuro dove conservare le chiavi, ma non devi mai iniettarle dal mondo esterno. Devono SEMPRE essere generati all'interno del processore, durante l'avvio. Fare qualsiasi altra cosa invalida immediatamente il resto: è automaticamente insicuro.

  2. Non conservare le chiavi nella memoria non volatile, hai ragione su questo. Non importa se si protegge la EEPROM o la memoria flash dalla lettura. Il fusibile di protezione dalla lettura del codice è facilmente reversibile. Un aggressore deve solo decapare (rimuovere o incidere chimicamente la confezione epossidica nera per esporre il dado di silicio all'interno). A questo punto, possono coprire la parte del dado che è celle di memoria non volatili (queste sezioni sono molto regolari e mentre le singole celle di memoria sono troppo piccole per essere viste, la struttura più grande può essere) e un piccolo pezzo di qualcosa opaco a UV è mascherato su quella sezione. Quindi l'attaccante può semplicemente illuminare una luce UV sul chip per 5-10 minuti e ripristinare tutti i fusibili, incluso il fusibile CRP. La memoria OTP può ora essere letta da qualsiasi programmatore standard.

Oppure, se sono ben finanziati (diciamo, ottenere quelle chiavi vale più di $ 1000 per qualcuno), possono semplicemente leggere le celle di memoria direttamente con diversi tipi di microscopi elettronici.

Per sicurezza, le chiavi devono essere cancellate, non nascoste.

  1. No, per le stesse ragioni sopra.

Ora, sull'opzione 4:

  1. Usa solo la crittografia. La distribuzione delle chiavi è un problema risolto. Quindi usa quella soluzione prontamente disponibile. Il chip dovrebbe usare il suo RNG e varie altre considerazioni dovrebbero essere fatte per assicurarsi che abbia una scorta sufficiente di entropia disponibile e il boot loader dovrebbe avviarsi direttamente nel programma che genera le chiavi segrete necessarie, che dovrebbero essere di uso generale si registra e si sposta direttamente in SRAM, dove rimarranno fino alla cancellazione.

Tuttavia, esiste un problema, ovvero che nulla tranne la CPU ha idea di quale sia la chiave segreta. Nessun problema: usa la crittografia a chiave pubblica. Ciò che hai memorizzato nella memoria OTP è la tua chiave pubblica. Questa chiave può essere letta da chiunque, puoi pubblicarla sullo scambio di pile, puoi dipingerla sul lato di una petroliera con lettere alte 5 piedi, non importa. La cosa meravigliosa della crittografia a chiave pubblica è che è asimmetrica. La chiave per crittografare qualcosa non può decrittografare, ciò richiede la chiave privata. E viceversa, la chiave per decrittografare qualcosa di crittografato dalla chiave pubblica non può essere utilizzata per crittografare qualcosa. Quindi, la CPU genera le chiavi segrete, utilizza la chiave pubblica memorizzata per ENCRYPT le chiavi segrete e la invia semplicemente tramite USB o RS232 o qualunque cosa tu voglia. La lettura della chiave segreta richiede la tua chiave privata, che non devono essere memorizzati, inviati o mai coinvolti con il chip. Una volta decifrata la chiave segreta con la tua chiave privata (altrove, al di fuori del chip), sei pronto. Hai una chiave segreta trasmessa in modo sicuro che è stata GENERATA interamente all'interno del chip, senza dover archiviare nulla tranne una chiave pubblica - che, come affermato in precedenza, non deve essere affatto protetta dalla lettura.

Questo processo è formalmente chiamato negoziazione chiave e ogni cosa lo utilizza. L'hai usato più volte oggi. Ci sono molte risorse e librerie disponibili per gestirlo. Per favore, non "iniettare" mai le chiavi in ​​nulla.

Un'ultima cosa da menzionare: tutto ciò è discutibile perché la chiave AES può essere facilmente ripristinata usando gli attacchi del canale laterale, che si trovano sull'alimentatore e misurano i piccoli cambiamenti nell'assorbimento di corrente e il tempo tra quei cambiamenti causati dai bit che lanciano nella CPU come registri. Questo, combinato con la conoscenza di come funziona AES (o qualunque sia una delle pochissime serie di possibili algoritmi di crittografia che potrebbero essere utilizzati), rende relativamente semplice ed economico recuperare la chiave. Non consentirà di leggere la chiave, ma può restringere lo spazio della chiave a qualcosa di ridicolmente piccolo, come 255 possibili chiavi. Inoltre, il chip non può rilevarlo, poiché è a monte.

Ciò ha sconfitto i boot loader crittografati AES-256 su processori crittografici "sicuri" e non è nemmeno così difficile. Per quanto ne so, non ci sono veri contromisure hardware per questo attacco. Tuttavia, sono gli algoritmi di crittografia stessi e il modo in cui richiedono una CPU per capovolgere i bit, che sta causando questa vulnerabilità. Sospetto che dovranno essere sviluppati (e si spera lo siano) algoritmi resistenti ai canali laterali o ai canali laterali.

Così com'è adesso, la vera risposta a come archiviare una chiave (o anche solo usare una chiave temporanea) su un dispositivo incorporato in modo sicuro è: non puoi.

Ma almeno se si genera una nuova chiave ogni volta che si utilizza la negoziazione della chiave nell'opzione 4, un attacco del canale laterale può solo compromettere la chiave di un canale in uso e solo se hanno un po 'di tempo per monitorare la potenza mentre crittografa i dati . Se negoziate frequentemente nuove chiavi generate internamente, ciò può offrire utili quantità di sicurezza.

Genera chiavi e conservale il più breve tempo possibile.


Grazie davvero caro Metacollin per avermi chiarito, ma il mio progetto è composto da molti lettori (contengono mcu) e molti MCU target, ogni lettore deve essere in grado di leggere qualsiasi target e qualsiasi target deve poter essere letto da qualsiasi lettore. di questo penso che debbano essere d'accordo con una chiave unica per il trasporto dei dati. e in base alla tua risposta penso che non ci siano così tante differenze tra ad esempio LPC18S57 corteccia sicura m3 e STM32F429 corteccia generale m4 e persino LPC1788 corteccia generale m3 (scelta più economica), non sto facendo un progetto top secret ma voglio fare questo il più sicuro possibile.
Mahmoud Hosseinipour,

2
La tua affermazione che "la chiave AES può essere facilmente recuperata" è almeno discutibile. Comprendo il principio alla base della tecnica per scoprire cosa succede nel processore, in base al suo consumo attuale. Tuttavia, presuppone che la crittografia e la decrittografia siano le uniche cose su cui la cpu sta lavorando. Tuttavia, la maggior parte delle applicazioni ha solo 1 CPU che lavora su un sacco di compiti contemporaneamente. Durante un blocco possono verificarsi decine o centinaia di interruzioni della crittografia AES che rendono impossibile trovare la chiave, in base ai picchi attuali.
Bakcsa83,

2
Se la chiave non deve essere memorizzata in Flash, lo stesso vale per il codice che genera la chiave ... devi solo tradurre i codici op in assembler e quindi hai la chiave, non importa quanto sia intricato il codice.
Lundin,

The wonderful thing about private key cryptography is that it is asymmetric. Anche se dai tuoi post è chiaro che lo sai, lo citerò per altri lettori ... s / privato / pubblico nella citazione sopra.
Radian,

Potresti essere in grado di proteggere un canale tra due dispositivi qualsiasi usando il metodo 4, tuttavia, senza avere una qualche forma di segreto condiviso, non puoi garantire l'autenticità del dispositivo con cui stai comunicando. Se il tuo caso d'uso richiede l'autenticazione, non stai meglio con uno scambio di chiavi di quanto lo sei se stai semplicemente memorizzando un singolo segreto condiviso in flash. Se hai bisogno di una migliore sicurezza, dovrebbe essere usato un chip crittografico.
Greg,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.