14.3.4. Una nota sulla protezione contro la lettura della flash¶

Di base, il firmware presente su una OpenMV cam spedita è leggibile da chiunque abbia accesso fisico al dispositivo. Un aggressore che ha la cam tra le mani può collegare una sonda SWD all’header di debug, comunicare con l’interfaccia di debug dell’MCU ed estrarre la flash, che include ogni modulo Python congelato e il contenuto della partizione ROMFS. Il firmware OpenMV standard non abilita di default la protezione contro la lettura della flash.

Questa pagina lo documenta esplicitamente, in modo che un team che spedisce un prodotto sappia dove ricade la responsabilità.

14.3.4.1. Cosa fa la cam di default¶

Il bootloader e il runtime della cam non attivano alcuna funzione di protezione contro la lettura dell’MCU sottostante. L’interfaccia di debug resta aperta, la flash resta leggibile e la build funziona esattamente come sul banco di uno sviluppatore. Questo è il default corretto per il pubblico del tutorial: una cam spedita con la protezione contro la lettura attiva è una cam che non può essere riprogrammata tramite l’IDE, non può essere ri-immaginata dopo un deployment andato male e non può essere recuperata da nessuno tranne il team di build.

Il compromesso cambia quando la cam passa da «dispositivo per sviluppatori» a «prodotto». Un prodotto il cui valore dipende dal fatto che il codice applicativo rimanga privato deve abilitare da sé la protezione; il firmware OpenMV non lo fa.

14.3.4.2. Cosa fa il team di prodotto¶

Ogni produttore di MCU offre un meccanismo di protezione contro la lettura. I dettagli differiscono – fusibili a livello di bit, transizioni di ciclo di vita irreversibili, immagini flash firmate – ma la forma comune è:

Un bit specifico del produttore (o un insieme di bit) viene scritto in modo permanente nel silicio, di solito tramite uno strumento del produttore che comunica con la porta di debug dell’MCU un’ultima volta.
Dopo la scrittura, la porta di debug rifiuta di leggere la flash. La cam continua ad avviarsi ed eseguire l’applicazione; semplicemente non espone più il proprio contenuto a una sonda.
La scrittura è irreversibile. Non c’è modo di riportare la cam in uno stato di debug senza distruggerla.

Configurare tutto questo è specifico per l’MCU, e i passaggi dipendono dal componente da proteggere presente sulla cam. Il manuale di riferimento del produttore è la fonte autorevole; il supporto del produttore è il canale per ottenere il risultato corretto su una linea di produzione.

Questa è la parte facile.

La parte difficile è chiudere ogni altro percorso che un aggressore ha per eseguire codice sulla cam o per leggere cosa sta facendo l’applicazione. La protezione contro la lettura impedisce soltanto a una sonda di debug di estrarre la flash. La cam deve comunque chiudere:

Il REPL di MicroPython. Un REPL collegato via USB accetta codice Python arbitrario. La protezione contro la lettura non cambia questo. Una sessione REPL può leggere la RAM, chiamare funzioni, esfiltrare qualsiasi cosa l’applicazione in esecuzione possa vedere – in pratica, un REPL raggiungibile aggira tutto ciò che la protezione contro la lettura garantisce. Disabilitare l’accesso al REPL è una modifica alla build del firmware di cui è responsabile il team di prodotto.
Il caricamento di script dall’IDE. Il percorso dell’IDE «esegui questo script sulla cam» sfrutta la stessa superficie del protocollo USB del REPL. Chiudere il REPL chiude anche questo; lasciarne aperto uno qualsiasi lascia aperto un canale di esecuzione di codice arbitrario verso la cam.
Dirottamento del punto di ingresso dal filesystem. Già chiuso quando l’applicazione viene spedita tramite Congelare gli script nel firmware – il runtime risolve i file congelati boot.py e main.py prima di qualsiasi copia su filesystem, quindi nulla depositato sulla flash o sulla SD può sovrascriverli. Questa protezione è gratuita una volta che l’applicazione è nella build.
Flash esterna sulle cam più recenti. Le cam che memorizzano l’immagine dell’applicazione nella flash esterna mettono quell’immagine su un chip ben visibile sul PCB; il chip può essere dissaldato e letto direttamente con strumenti comuni, oppure letto in loco sondando il bus. Proteggerlo richiede di attivare l’hardware on-chip che decifra il contenuto della flash durante le letture, generare la chiave di cifratura, eseguire il provisioning di quella chiave sulla cam e bruciarla in modo irreversibile nello storage one-time-programmable dell’MCU. Ognuna di queste è un’operazione irreversibile separata, e se una qualsiasi di esse viene eseguita male su un’unità di produzione, quell’unità viene resa inutilizzabile.

Ogni voce di questo elenco è una propria serie di lavori sulla build del firmware, passaggi sulla linea di produzione e scritture irreversibili. Un vero prodotto blindato è una build di firmware personalizzata, un bootloader personalizzato, un flusso di produzione che esegue il provisioning delle chiavi per unità e un insieme di test che dimostrano che il blocco è davvero chiuso prima che l’unità lasci la linea. Questo è un lavoro di mesi, non di giorni, e l’irreversibilità fa sì che gli errori costino unità.

Perché il default è aperto

Questo elenco è anche il motivo per cui il firmware OpenMV standard viene spedito senza la protezione contro la lettura abilitata. Una cam con il REPL chiuso, il caricamento di script dall’IDE disabilitato e il firmware bloccato è una cam su cui non si può sviluppare affatto – il flusso di lavoro che rende le OpenMV cam utilizzabili in primo luogo semplicemente sparirebbe. Il default lascia tutto aperto; il team di prodotto sceglie quali pezzi chiudere lungo il percorso verso un’unità spedita.

14.3.4.3. Cosa garantisce comunque l’accesso fisico¶

Anche con la protezione contro la lettura attiva, un aggressore che possiede la cam può fare parecchio:

Riprodurre il traffico di rete della cam intercettandone gli output.
Osservare il suo comportamento visibile e dedurre come reagisce agli input.
In alcuni casi, recuperare segreti tramite attacchi di fault-injection o side-channel specializzati contro l’MCU protetto.

La protezione contro la lettura aumenta il costo per accedere al codice sorgente dell’applicazione. Non lo elimina. «Accesso fisico = compromissione» è l’assunto operativo da cui dovrebbe partire una revisione di sicurezza; il meccanismo di protezione decide soltanto quanto costa quella compromissione in termini di tempo e attrezzatura.

14.3.4.4. Con cosa viene spedito il firmware OpenMV¶

Un riepilogo, per rendere tutto concreto:

Nessuna protezione contro la lettura abilitata di default.
Nessun flag di build nel firmware standard che la attivi.
Nessuna API a livello applicativo da chiamare da MicroPython.

Un prodotto che necessita della protezione spedisce firmware personalizzato. Quella personalizzazione risiede nel bootloader della scheda e nel flusso di produzione, ed è al di fuori del codebase OpenMV. I team che lo fanno per la prima volta dovrebbero pianificarlo all’interno della timeline di sviluppo come un pezzo di lavoro a sé stante, non come qualcosa da aggiungere alla fine – l’irreversibilità rende costoso «aggiungerlo più tardi».