14.3.4. O notă despre protecția la citirea memoriei flash¶

Implicit, firmware-ul de pe o cameră OpenMV livrată este citibil de oricine are acces fizic la dispozitiv. Un atacator care are camera în mână poate atașa o sondă SWD la conectorul de depanare, poate comunica cu interfața de depanare a MCU-ului și poate extrage memoria flash – care include fiecare modul Python înghețat și conținutul partiției ROMFS. Firmware-ul standard OpenMV nu activează implicit protecția la citirea memoriei flash.

Această pagină documentează acest lucru în mod explicit, astfel încât o echipă care livrează un produs să știe unde se află responsabilitatea.

14.3.4.1. Ce face camera în mod implicit¶

Bootloader-ul și mediul de execuție al camerei nu activează nicio funcție de protecție la citire a MCU-ului subiacent. Interfața de depanare rămâne deschisă, memoria flash rămâne citibilă, iar build-ul rulează la fel cum o face pe bancul de lucru al unui dezvoltator. Acesta este comportamentul implicit potrivit pentru publicul tutorialului – o cameră livrată cu protecția la citire activată este o cameră care nu poate fi reprogramată prin IDE, nu poate fi re-imaginată după o implementare eșuată și nu poate fi recuperată de nimeni în afară de echipa de build.

Compromisul se schimbă atunci când camera trece de la statutul de „dispozitiv de dezvoltare” la cel de „produs”. Un produs a cărui valoare depinde de menținerea privată a codului aplicației trebuie să activeze el însuși protecția; firmware-ul OpenMV nu face acest lucru.

14.3.4.2. Ce face echipa de produs¶

Fiecare producător de MCU-uri oferă un mecanism de protecție la citire. Detaliile diferă – siguranțe la nivel de bit, tranziții de ciclu de viață ireversibile, imagini flash semnate – dar forma comună este:

Un bit (sau un set de biți) specific producătorului este înscris în siliciu, de obicei printr-un instrument al producătorului care comunică cu portul de depanare al MCU-ului pentru ultima dată.
După înscriere, portul de depanare refuză să citească memoria flash. Camera încă pornește și rulează aplicația; pur și simplu nu mai expune conținutul său unei sonde.
Înscrierea este ireversibilă. Nu există nicio modalitate de a readuce camera într-o stare depanabilă fără a o distruge.

Configurarea acestui aspect este specifică MCU-ului, iar pașii depind de componenta de pe camera care urmează să fie protejată. Manualul de referință al producătorului este sursa de adevăr; suportul producătorului este canalul prin care se obține o configurare corectă pe o linie de producție.

Aceasta este partea ușoară.

Partea grea este închiderea fiecărei alte căi pe care un atacator o are pentru a rula cod pe cameră sau pentru a citi ce face aplicația. Protecția la citire oprește doar o sondă de depanare să extragă memoria flash. Camera mai trebuie să închidă:

REPL-ul MicroPython. Un REPL conectat prin USB acceptă cod Python arbitrar. Protecția la citire nu schimbă acest lucru. O sesiune REPL poate citi memoria RAM, apela funcții, exfiltra orice poate vedea aplicația care rulează – de fapt, un REPL accesibil ocolește tot ceea ce oferă protecția la citire. Dezactivarea accesului la REPL este o modificare a build-ului firmware-ului de care răspunde echipa de produs.
Încărcarea scripturilor din IDE. Calea „rulează acest script pe cameră” a IDE-ului folosește aceeași suprafață de protocol USB ca și REPL-ul. Închiderea REPL-ului o închide și pe aceasta; lăsarea oricăreia deschise lasă un canal de execuție a codului arbitrar în cameră.
Deturnarea punctului de intrare din sistemul de fișiere. Deja închisă atunci când aplicația este livrată prin Înghețarea scripturilor în firmware – mediul de execuție rezolvă boot.py și main.py înghețate înainte de orice copie din sistemul de fișiere, așa că nimic depus pe memoria flash sau pe cardul SD nu le poate suprascrie. Această protecție este gratuită odată ce aplicația se află în build.
Memoria flash externă pe camerele mai noi. Camerele care stochează imaginea aplicației în memoria flash externă pun acea imagine pe un cip aflat la vedere pe PCB; cipul poate fi dezlipit și citit direct cu instrumente disponibile comercial sau citit pe loc prin sondarea magistralei. Protejarea sa necesită activarea hardware-ului integrat pe cip care decriptează conținutul memoriei flash în timpul citirilor, generarea cheii de criptare, furnizarea acelei chei pe cameră și înscrierea ei ireversibilă în stocarea programabilă o singură dată a MCU-ului. Fiecare dintre acestea este o operațiune separată ireversibilă, iar oricare dintre ele efectuată greșit pe o unitate de producție face acea unitate inutilizabilă.

Fiecare element din această listă reprezintă propriul său set de lucrări de build firmware, pași pe linia de producție și înscrieri ireversibile. Un produs cu adevărat blocat este un build firmware personalizat, un bootloader personalizat, un flux de producție care furnizează chei per unitate și un set de teste care dovedesc că blocarea este efectiv închisă înainte ca unitatea să părăsească linia. Aceasta înseamnă luni de muncă, nu zile, iar ireversibilitatea înseamnă că greșelile costă unități.

De ce comportamentul implicit este deschis

Această listă este și motivul pentru care firmware-ul standard OpenMV este livrat fără protecția la citire activată. O cameră cu REPL-ul închis, încărcarea scripturilor din IDE dezactivată și firmware-ul blocat este o cameră pe care nu se poate dezvolta deloc – fluxul de lucru care face camerele OpenMV utilizabile în primul rând pur și simplu ar dispărea. Comportamentul implicit lasă totul deschis; echipa de produs alege ce componente să închidă pe drumul către o unitate livrată.

14.3.4.3. Ce mai oferă accesul fizic¶

Chiar și cu protecția la citire activată, un atacator care deține camera poate face destul de multe:

Reluarea traficului de rețea al camerei prin interceptarea ieșirilor sale.
Observarea comportamentului vizibil și deducerea modului în care reacționează la intrări.
În unele cazuri, recuperarea secretelor prin injectare de defecte sau atacuri pe canale laterale specializate împotriva MCU-ului protejat.

Protecția la citire crește costul accesării codului sursă al aplicației. Nu elimină acest cost. „Acces fizic = compromitere” este premisa de lucru de la care ar trebui să pornească o evaluare de securitate; mecanismul de protecție decide doar cât de mult costă acea compromitere în timp și echipament.

14.3.4.4. Cu ce este livrat firmware-ul OpenMV¶

Un rezumat, pentru a fi concret:

Nicio protecție la citire activată implicit.
Niciun indicator de build în firmware-ul standard care să o activeze.
Nicio API la nivel de aplicație care să poată fi apelată din MicroPython.

Un produs care are nevoie de protecție este livrat cu firmware personalizat. Acea personalizare se află în bootloader-ul plăcii și în fluxul de producție și este în afara codului OpenMV. Echipele care fac acest lucru pentru prima dată ar trebui să îl planifice în cadrul calendarului de dezvoltare ca o piesă distinctă de lucru, nu ca pe ceva de adăugat la final – ireversibilitatea face ca „adăugarea ulterioară” să fie costisitoare.