Nonostante il crescente numero di attacchi di rete ai dispositivi IoT, la sicurezza del firmware viene spesso posta in una posizione secondaria. Poiché gli aggressori penetrano nello stack di sistema e prendono di mira il processo di avvio e la configurazione hardware sottostante, la scelta dell'architettura di memoria è diventata una decisione chiave per stabilire una catena di fiducia verificabile.
Pertanto, per garantire la sicurezza del firmware è necessario che ciascun componente venga sottoposto a verifica della crittografia prima dell'esecuzione. Questo percorso inizia con un boot loader immutabile, responsabile del caricamento e della verifica del firmware principale. Tuttavia, la tecnologia di memoria utilizzata in ogni passaggio potrebbe comportare la vulnerabilità del firmware a modifiche non autorizzate.
Memoria flash interna ed esterna
La posizione fisica della memoria non volatile utilizzata per archiviare il firmware è uno dei fattori più critici nei modelli di minaccia dei dispositivi. Gli ingegneri del firmware devono scegliere tra flash incorporato su chip (eFlash) e moduli flash esterni collegati tramite interfacce seriali come SPI o QSPI.
La memoria flash incorporata è solitamente integrata direttamente su microcontrollori o chip SoC. Questa architettura fornisce il massimo livello di sicurezza fisica poiché non sono disponibili bus esterni che gli aggressori possano manipolare. Anche l'accesso alla memoria flash interna è controllato da registri dedicati e bit di blocco.
Inoltre, la memoria flash incorporata supporta la protezione da lettura permanente. Cortocircuitando fusibili di sicurezza specializzati, gli sviluppatori possono disabilitare le interfacce di debug JTAG o SWD per impedire agli hacker di modificare le immagini del firmware. Tuttavia, man mano che i SoC si spostano verso nodi più piccoli, questa tecnologia deve affrontare sfide significative in termini di scalabilità.
Al contrario, la memoria flash esterna è posizionata all'esterno del processore principale e comunica attraverso un'interfaccia seriale ad alta velocità. Questa scelta architetturale semplifica la scalabilità della capacità di storage, ma espande anche la superficie di attacco del sistema. Tutti i dati trasmessi tra il processore e la memoria flash esterna sono intrinsecamente vulnerabili a minacce quali intercettazioni, attacchi man in the middle e manomissioni fisiche.
Per affrontare questi rischi, gli ingegneri del firmware devono implementare valide misure di protezione hardware e software. Molti dispositivi di memoria flash NOR esterni sono dotati di un pin fisico di protezione dalla scrittura. Quando il pin viene posizionato a una tensione specifica, la logica interna del chip impedirà l'esecuzione di qualsiasi comando di cancellazione o scrittura.
Figura 1: La memoria flash NOR seriale sicura W77Q32JWSSIR TR di Winbond Electronics è dotata di complesse funzionalità di crittografia del canale di comunicazione. (Fonte immagine: Winbond Electronics)
Tuttavia, se i dati possono essere letti, il semplice blocco della memoria flash non è sufficiente. Durante l'esecuzione, gli aggressori possono comunque accedere all'indirizzo e al bus dati. Questa vulnerabilità ha spinto allo sviluppo di dispositivi flash sicuri specializzati, inclusi meccanismi root of trust basati su hardware, canali di comunicazione crittografati e contatori monotoni per prevenire attacchi di rollback.
Tuttavia, se viene scelta l'architettura di archiviazione sbagliata, il dispositivo lascerà difetti fondamentali che non possono essere completamente risolti dalle patch software. Ad esempio, i progetti che archiviano il firmware su EEPROM esterna senza crittografia o verifica sono sempre vulnerabili agli attacchi hardware. Al contrario, scegliere una memoria con restrizioni eccessive potrebbe pregiudicarne la funzionalità.
Pertanto, gli ingegneri devono comprendere le migliori pratiche e le tecniche di progettazione per massimizzare la sicurezza del firmware attraverso l'architettura della memoria.
Migliori pratiche per la progettazione sicura dell'archiviazione del firmware
Quando si progetta un percorso di archiviazione sicuro del firmware dall'avvio al runtime, gli ingegneri del firmware devono seguire i seguenti principi:
1. Radice di attendibilità basata su hardware
L'esecuzione deve sempre iniziare da aree di memoria immutabili. Ad esempio, la ROM di avvio o il settore flash protetto in modo permanente dovrebbero contenere il codice per verificare tutti gli altri firmware. Ciò garantirà che gli aggressori non possano aggirare la verifica manomettendo la password iniziale.
2. Utilizza firme crittografate
Configura il caricatore di avvio sicuro per eseguire solo immagini firmware firmate con chiavi private attendibili. In questo modo, anche se gli aggressori possono accedere alla memoria e modificare i bit, possono impedire il codice non autorizzato. Se è richiesta la riservatezza, il firmware archiviato può essere crittografato.
3. Utilizzare le funzionalità di sicurezza hardware
Se l'architettura del sistema utilizza storage esterno, gli ingegneri dovrebbero scegliere dispositivi che supportino la sicurezza hardware, come la protezione con password integrata o la semplice crittografia. Anche se questi dispositivi potrebbero non essere robusti quanto componenti di sicurezza completi, aggiungono un ulteriore livello di protezione.
Figura 2: Macronix supporta la memoria flash NOR seriale MX25L3233FM2I-08Q da 32 Mb con interfaccia periferica seriale. (Fonte immagine: Macronix)
4. Isolare firmware e dati
Organizza l'area di memoria e separa il codice più sensibile. Nell'MCU, colloca le istruzioni di routine critiche in un'area di memoria sicura. Anche il firmware, se supportato dall'hardware, può contrassegnare determinati banchi di memoria flash come solo eseguibili o di sola lettura.
5. Piano di aggiornamento del firmware di sicurezza
Assicurarsi che il processo di aggiornamento stesso sia convalidato (ad esempio richiedendo la firma del pacchetto di aggiornamento). Se il progetto utilizza una memoria esterna per aggiornamenti temporanei, dovrebbero essere adottate le stesse misure di sicurezza della memoria principale del firmware.