Scelta della giusta architettura di memoria per la sicurezza del firmware

Nonostante il crescente numero di attacchi informatici sui dispositivi IoT connessi, la sicurezza del firmware è sempre stata considerata secondaria. Poiché gli aggressori penetrano nello stack del sistema, prendendo di mira il processo di avvio e le configurazioni hardware di basso livello, la scelta dell'architettura della memoria è diventata una decisione chiave per stabilire una catena di attendibilità verificabile.

Pertanto, per proteggere il firmware è necessario che ogni componente venga verificato crittograficamente prima dell'esecuzione. Il percorso inizia con un bootloader immutabile che carica e verifica il firmware principale. Tuttavia, le tecnologie di memoria utilizzate in ciascun passaggio determinano la vulnerabilità del firmware alle modifiche non autorizzate.

Flash interna e Flash esterna a confronto

La posizione fisica della memoria non volatile utilizzata per memorizzare il firmware è uno dei fattori più critici nel modello di minaccia di un dispositivo. I tecnici che si occupano del firmware devono scegliere tra una memoria Flash embedded su chip (eFlash) e un modulo Flash esterno collegato tramite un'interfaccia seriale come SPI o QSPI.

La memoria Flash embedded è solitamente integrata direttamente sul microcontroller o sul die del SoC. Questa architettura garantisce il massimo livello di sicurezza fisica, poiché non esiste alcun bus esterno che un pirata informatico possa manipolare. Anche l'accesso alla Flash interna è controllato da registri dedicati e bit di blocco.

Inoltre, la eFlash supporta la protezione permanente dalla lettura. Mettendo in cortocircuito un fusibile di sicurezza dedicato, lo sviluppatore può disabilitare le interfacce di debug JTAG o SWD, impedendo all'hacker di modificare l'immagine del firmware. Tuttavia, la tecnologia deve affrontare problemi significativi di scalabilità man mano che i SoC si spostano su nodi più piccoli.

Una memoria Flash esterna, invece, è posizionata all'esterno del processore host e comunica tramite un'interfaccia seriale ad alta velocità. Questa scelta architettonica semplifica la scalabilità della capacità di storage, ma amplia anche la superficie di attacco del sistema. Tutti i dati che viaggiano tra il processore e la memoria Flash esterna sono intrinsecamente vulnerabili a snooping, attacchi "man-in-the-middle" e manomissioni fisiche.

Per gestire questi rischi, i tecnici del firmware devono implementare solide protezioni hardware e software. Molti dispositivi Flash NOR esterni sono dotati di un pin fisico di protezione dalla scrittura. Quando il pin viene mantenuto a una tensione specifica, la logica interna del chip impedisce l'esecuzione di comandi di cancellazione o scrittura.

Figura 1: La memoria Flash NOR seriale sicura W77Q32JWSSIR TR di Winbond Electronics con sofisticata crittografia del canale di comunicazione. (Immagine per gentile concessione di Winbond Electronics)

Tuttavia, il semplice blocco della memoria Flash non è sufficiente se i dati possono essere comunque letti. Gli hacker possono comunque accedere all'indirizzo e al bus dati durante l'esecuzione. Questa vulnerabilità ha portato allo sviluppo di dispositivi Flash sicuri specializzati che includono meccanismi di radice di attendibilità basati su hardware, canali di comunicazione crittografati e contatori monotonici per prevenire gli attacchi di rollback.

Eppure, se si sceglie un'architettura di memoria sbagliata, il dispositivo può presentare una debolezza fondamentale che nessuna patch software può risolvere completamente. Ad esempio, un progetto nel quale il firmware sia memorizzato su una EEPROM esterna senza crittografia o autenticazione sarà sempre vulnerabile agli attacchi hardware. D'altro canto, scegliere una memoria troppo restrittiva potrebbe comprometterne la funzionalità.

Pertanto, è essenziale che i tecnici comprendano le migliori pratiche e i suggerimenti di progettazione per massimizzare la sicurezza del firmware attraverso l'architettura della memoria.

Buone pratiche per la progettazione di un percorso di memorizzazione sicuro per il firmware

Di seguito sono riportati i principi cui i tecnici del firmware devono attenersi durante la progettazione di un percorso di memorizzazione del firmware sicuro dall'accensione al runtime.

1. Radice di attendibilità basata su hardware

L'esecuzione deve sempre iniziare da una regione di memoria immutabile. Ad esempio, il codice che verifica tutti gli altri firmware deve essere contenuto in una ROM di avvio o in un settore Flash permanentemente protetto. In questo modo si impedisce che un hacker possa eludere la verifica manomettendo il codice iniziale.

2. Utilizzo di firme crittografiche

Implementare un bootloader sicuro che esegua solo immagini firmware firmate con una chiave privata attendibile. Ciò protegge dal codice non autorizzato, anche nell'eventualità un hacker riesca ad accedere alla memoria e a modificarne i bit. Se la riservatezza è un problema, crittografare il firmware nel percorso di memorizzazione.

3. Sfruttare le funzionalità di sicurezza hardware

Se l'architettura del sistema utilizza una memoria esterna, i tecnici dovrebbero scegliere dispositivi che supportino la sicurezza hardware, come la protezione tramite password integrata o la crittografia semplice. Anche se non sono resistenti quanto un elemento di sicurezza completo, aggiungono un ulteriore livello di protezione.

Figura 2: Memoria Flash NOR seriale da 32 Mb MX25L3233FM2I-08Q di Macronix con supporto per interfaccia periferica seriale. (Immagine per gentile concessione di Macronix)

4. Isolare firmware e dati

Organizzare le regioni di memoria in modo da tenere separato il codice più sensibile. Negli MCU inserire le istruzioni di routine critiche in sezioni di memoria sicure. Anche con il firmware, se l'hardware lo supporta, contrassegnare determinati banchi di memoria Flash come di sola esecuzione o di sola lettura.

5. Pianificare gli aggiornamenti del firmware di sicurezza

Assicurarsi che il processo di aggiornamento stesso sia autenticato (es. richiedere pacchetti di aggiornamento firmati). Se il progetto utilizza una memoria esterna per lo staging degli aggiornamenti, trattarla con lo stesso livello di sicurezza dello storage del firmware primario.

Conclusione

La scelta della memoria giusta per il firmware può determinare il successo o il fallimento della sicurezza di qualsiasi dispositivo IoT embedded. La scelta di una memoria non sicura, come uno storage esterno senza protezione, apre le porte agli attacchi informatici. Al contrario, un'architettura scelta con cura che combini la memoria su chip con lo storage esterno sicuro e i controlli crittografici fornisce una solida base per la difesa contro sofisticati attacchi informatici.

In sintesi, ecco i principali suggerimenti per i tecnici del firmware: mantenere la radice di attendibilità nella memoria a prova di manomissione, trattare la memoria non su chip come non attendibile e compensarla di conseguenza, e utilizzare l'intero set di caratteristiche di sicurezza hardware fornite dalle moderne tecnologie di memoria. Allineando la tecnologia della memoria ai requisiti di sicurezza del dispositivo, possiamo proteggere anche il più piccolo sensore IoT dai cyberattacchi a livello di firmware.