14.3.4. Een opmerking over uitleesbeveiliging van het flashgeheugen¶

Standaard is de firmware op een geleverde OpenMV-cam leesbaar voor iedereen met fysieke toegang tot het apparaat. Een aanvaller die de cam in handen heeft, kan een SWD-probe op de debugheader aansluiten, communiceren met de debuginterface van de MCU en het flashgeheugen dumpen – inclusief elke ingevroren Python-module en de inhoud van de ROMFS-partitie. De standaard OpenMV-firmware schakelt niet standaard de uitleesbeveiliging van het flashgeheugen in.

Deze pagina documenteert dat expliciet, zodat een team dat een product levert weet waar de verantwoordelijkheid ligt.

14.3.4.1. Wat de cam standaard doet¶

De bootloader en runtime van de cam schakelen geen enkele uitleesbeveiligingsfunctie van de onderliggende MCU in. De debuginterface blijft open, het flashgeheugen blijft leesbaar en de build draait zoals op de werkbank van een ontwikkelaar. Dat is de juiste standaardinstelling voor het tutorialpubliek – een cam die wordt geleverd met uitleesbeveiliging ingeschakeld, is een cam die niet opnieuw via de IDE kan worden geflasht, niet opnieuw kan worden voorzien van een image na een mislukte uitrol en door niemand anders dan het buildteam kan worden gered.

De afweging verandert wanneer de cam van “ontwikkelaarsapparaat” naar “product” gaat. Een product waarvan de waarde afhangt van het privé blijven van de applicatiecode, moet de beveiliging zelf inschakelen; de OpenMV-firmware doet dat niet.

14.3.4.2. Wat het productteam doet¶

Elke MCU-leverancier biedt een uitleesbeveiligingsmechanisme. De details verschillen – fuses op bitniveau, eenmalige levenscyclusovergangen, ondertekende flash-images – maar de gemeenschappelijke vorm is:

Een leverancierspecifieke bit (of set bits) wordt vastgelegd in het silicium, meestal via een leveranciertool die een laatste keer met de debugpoort van de MCU communiceert.
Na het vastleggen weigert de debugpoort het flashgeheugen te lezen. De cam start nog steeds op en draait de applicatie; hij stelt zijn inhoud alleen niet langer bloot aan een probe.
Het vastleggen is onomkeerbaar. Er is geen manier om de cam terug te brengen naar een debugbare staat zonder hem te vernietigen.

Dit instellen is MCU-specifiek, en de stappen hangen af van het te beveiligen onderdeel op de cam. De referentiehandleiding van de leverancier is de bron van waarheid; leveranciersondersteuning is het kanaal om het op een productielijn goed te krijgen.

Dit is het makkelijke deel.

Het moeilijke deel is het afsluiten van elk ander pad dat een aanvaller heeft om code op de cam uit te voeren of om te lezen wat de applicatie doet. Uitleesbeveiliging belet alleen een debug-probe om het flashgeheugen te dumpen. De cam moet nog steeds het volgende afsluiten:

De MicroPython REPL. Een via USB aangesloten REPL accepteert willekeurige Python. Uitleesbeveiliging verandert daar niets aan. Een REPL-sessie kan RAM lezen, functies aanroepen en alles exfiltreren wat de draaiende applicatie kan zien – in feite omzeilt een bereikbare REPL alles wat de uitleesbeveiliging oplevert. Het uitschakelen van REPL-toegang is een wijziging in de firmware-build die het productteam zelf beheert.
Scriptupload via de IDE. Het “voer dit script uit op de cam”-pad van de IDE gebruikt hetzelfde USB-protocoloppervlak als de REPL. Het afsluiten van de REPL sluit dit mee af; als je een van beide openlaat, blijft er een kanaal voor willekeurige code-uitvoering naar de cam bestaan.
Het kapen van het instappunt vanuit het bestandssysteem. Al afgesloten wanneer de applicatie wordt geleverd via Scripts in de firmware bevriezen – de runtime herleidt ingevroren boot.py en main.py voordat er ook maar iets vanuit het bestandssysteem wordt gekopieerd, zodat niets dat op flash of SD wordt geplaatst ze kan overschrijven. Deze bescherming is gratis zodra de applicatie in de build zit.
Extern flashgeheugen op nieuwere cams. Cams die de applicatie-image in extern flashgeheugen opslaan, plaatsen die image op een chip die zichtbaar op de PCB zit; de chip kan worden losgesoldeerd en rechtstreeks met standaardgereedschap worden uitgelezen, of ter plekke worden gelezen door de bus af te tappen. Het beveiligen ervan vereist het inschakelen van de on-chip hardware die de flashinhoud bij het lezen ontsleutelt, het genereren van de versleutelingssleutel, het inrichten van die sleutel op de cam en het onomkeerbaar branden ervan in de eenmalig programmeerbare opslag van de MCU. Elk van die handelingen is een afzonderlijke eenmalige operatie, en als er ook maar een verkeerd wordt uitgevoerd op een productie-eenheid, raakt die eenheid onbruikbaar.

Elk item op deze lijst is een eigen stapel firmware-buildwerk, productielijnstappen en onomkeerbare vastleggingen. Een echt vergrendeld product is een aangepaste firmware-build, een aangepaste bootloader, een productieflow die per eenheid sleutels inricht, en een reeks tests die bewijzen dat het slot daadwerkelijk dicht is voordat de eenheid de lijn verlaat. Dat is maanden werk, geen dagen, en de onomkeerbaarheid betekent dat fouten eenheden kosten.

Waarom de standaard open is

Deze lijst is ook de reden waarom de standaard OpenMV-firmware wordt geleverd zonder ingeschakelde uitleesbeveiliging. Een cam met gesloten REPL, uitgeschakelde IDE-scriptupload en vergrendelde firmware is een cam waarop helemaal niet meer ontwikkeld kan worden – de workflow die OpenMV-cams in de eerste plaats bruikbaar maakt, zou simpelweg verdwenen zijn. De standaard laat alles open; het productteam kiest welke onderdelen het afsluit op weg naar een geleverde eenheid.

14.3.4.3. Wat fysieke toegang nog steeds oplevert¶

Zelfs met ingeschakelde uitleesbeveiliging kan een aanvaller die de cam in handen heeft, behoorlijk veel doen:

Het netwerkverkeer van de cam herhalen door de uitvoer ervan af te luisteren.
Het zichtbare gedrag observeren en afleiden hoe de cam op invoer reageert.
In sommige gevallen geheimen achterhalen via fault-injection- of side-channel-aanvallen die specifiek tegen de beveiligde MCU zijn gericht.

Uitleesbeveiliging verhoogt de kosten om bij de broncode van de applicatie te komen. Het elimineert die kosten niet. “Fysieke toegang = compromittering” is de werkaanname waarmee een beveiligingsbeoordeling zou moeten beginnen; het beveiligingsmechanisme bepaalt alleen hoeveel die compromittering kost in tijd en apparatuur.

14.3.4.4. Waarmee de OpenMV-firmware wordt geleverd¶

Een samenvatting, om dit concreet te maken:

Geen uitleesbeveiliging standaard ingeschakeld.
Geen buildvlag in de standaard firmware die het inschakelt.
Geen API op applicatieniveau om vanuit MicroPython aan te roepen.

Een product dat de beveiliging nodig heeft, wordt geleverd met aangepaste firmware. Die aanpassing zit in de bootloader van het board en in de productieflow, en valt buiten de OpenMV-codebase. Teams die dit voor het eerst doen, zouden het als een afzonderlijk stuk werk in het ontwikkelingstijdschema moeten inplannen, niet als iets om aan het eind toe te voegen – door de onomkeerbaarheid is “later toevoegen” duur.