14.3.4. Megjegyzés a flash kiolvasás elleni védelméről¶

Alapállapotban egy leszállított OpenMV kamera firmware-e kiolvasható bárki számára, aki fizikai hozzáféréssel rendelkezik az eszközhöz. Egy támadó, akinek a kamera a kezében van, csatlakoztathat egy SWD szondát a hibakeresési fejlécre, kommunikálhat az MCU hibakeresési interfészével, és kiolvashatja a flash memóriát – amely tartalmazza az összes befagyasztott Python modult és a ROMFS partíció tartalmát. A gyári OpenMV firmware alapértelmezetten nem engedélyezi a flash kiolvasás elleni védelmét.

Ez az oldal ezt kifejezetten dokumentálja, hogy egy terméket szállító csapat tudja, hol van a felelősség.

14.3.4.1. Mit tesz a kamera alapértelmezetten¶

A kamera rendszerbetöltője és futtatókörnyezete nem kapcsolja be az alapul szolgáló MCU egyetlen kiolvasás elleni védelmi funkcióját sem. A hibakeresési interfész nyitva marad, a flash memória olvasható marad, és a build úgy fut, ahogyan egy fejlesztő munkapadján. Ez a helyes alapértelmezés a tananyag közönsége számára – egy olyan kamera, amelyet bekapcsolt kiolvasás elleni védelemmel szállítanak, olyan kamera, amelyet nem lehet újraflashelni az IDE-n keresztül, nem lehet újra image-elni egy elrontott telepítés után, és senki sem tudja megmenteni a build csapaton kívül.

A kompromisszum megváltozik, amikor a kamera „fejlesztői eszközből” „termékké” válik. Egy olyan terméknek, amelynek értéke az alkalmazáskód titokban tartásától függ, magának kell engedélyeznie a védelmet; az OpenMV firmware ezt nem teszi meg.

14.3.4.2. Mit tesz a termékcsapat¶

Minden MCU gyártó kínál kiolvasás elleni védelmi mechanizmust. A részletek eltérőek – bit szintű biztosítékok, egyszeri életciklus-átmenetek, aláírt flash image-ek –, de a közös forma a következő:

Egy gyártóspecifikus bit (vagy bitek halmaza) véglegesítésre kerül a szilíciumban, általában egy gyártói eszköz révén, amely utoljára kommunikál az MCU hibakeresési portjával.
A véglegesítés után a hibakeresési port megtagadja a flash memória olvasását. A kamera továbbra is elindul és futtatja az alkalmazást; csak már nem teszi elérhetővé a tartalmát egy szonda számára.
A véglegesítés visszafordíthatatlan. Nincs mód arra, hogy a kamerát visszaállítsuk hibakereshető állapotba anélkül, hogy tönkretennénk.

Ennek beállítása MCU-specifikus, és a lépések a védendő kamerán lévő alkatrésztől függenek. A gyártó referencia-kézikönyve a hiteles forrás; a gyártói támogatás a csatorna ahhoz, hogy egy gyártósoron helyesen csináljuk.

Ez a könnyű rész.

A nehéz rész minden egyéb út lezárása, amelyen keresztül egy támadó kódot futtathat a kamerán, vagy kiolvashatja, mit csinál az alkalmazás. A kiolvasás elleni védelem csak azt akadályozza meg, hogy egy hibakeresési szonda kiolvassa a flash memóriát. A kamerának továbbra is le kell zárnia a következőket:

A MicroPython REPL. Egy USB-n keresztül csatlakoztatott REPL tetszőleges Python kódot fogad el. A kiolvasás elleni védelem ezen nem változtat. Egy REPL munkamenet képes RAM-ot olvasni, függvényeket hívni, kiszivárogtatni mindazt, amit a futó alkalmazás lát – valójában egy elérhető REPL megkerül mindent, amit a kiolvasás elleni védelem nyújt. A REPL hozzáférés letiltása egy firmware-build változtatás, amely a termékcsapat felelőssége.
IDE szkriptfeltöltés. Az IDE „futtasd ezt a szkriptet a kamerán” útvonala ugyanazon az USB protokollfelületen halad, mint a REPL. A REPL lezárása ezt is lezárja vele; bármelyik nyitva hagyása tetszőleges kódfuttatási csatornát hagy a kamerába.
A belépési pont eltérítése a fájlrendszerből. Már lezárva, amikor az alkalmazást a Szkriptek befagyasztása a firmware-be segítségével szállítják – a futtatókörnyezet a befagyasztott boot.py és main.py fájlokat oldja fel bármilyen fájlrendszerbeli másolat előtt, így semmi, amit a flash memóriára vagy az SD-kártyára helyeznek, nem írhatja felül őket. Ez a védelem ingyenes, ha az alkalmazás már a buildben van.
Külső flash az újabb kamerákon. Azok a kamerák, amelyek az alkalmazás image-ét külső flash memóriában tárolják, ezt az image-et a NYÁK-on jól láthatóan elhelyezett chipre teszik; a chipet le lehet forrasztani és közvetlenül kiolvasni bolti eszközökkel, vagy a busz figyelésével a helyén kiolvasni. A védelméhez be kell kapcsolni a chipen lévő hardvert, amely olvasáskor visszafejti a flash tartalmat, létre kell hozni a titkosítási kulcsot, fel kell tölteni azt a kamerára, és visszafordíthatatlanul be kell égetni az MCU egyszer programozható tárolójába. Ezek mindegyike különálló egyszeri művelet, és ha bármelyiket rosszul hajtják végre egy gyártási egységen, az tönkreteszi az egységet.

Ezen lista minden eleme önmagában is firmware-build munka, gyártósori lépések és visszafordíthatatlan véglegesítések halmaza. Egy valóban lezárt termék testreszabott firmware-build, testreszabott rendszerbetöltő, egységenként kulcsokat kiosztó gyártási folyamat és olyan tesztek halmaza, amelyek bizonyítják, hogy a zár valóban zárva van, mielőtt az egység elhagyja a sort. Ez hónapok munkája, nem napoké, és a visszafordíthatatlanság miatt a hibák egységekbe kerülnek.

Miért nyitott az alapértelmezés

Ez a lista az oka annak is, hogy a gyári OpenMV firmware kiolvasás elleni védelem engedélyezése nélkül kerül szállításra. Egy olyan kamera, amelynél a REPL le van zárva, az IDE szkriptfeltöltés le van tiltva, és a firmware le van zárva, olyan kamera, amelyen egyáltalán nem lehet fejleszteni – az a munkafolyamat, amely az OpenMV kamerákat egyáltalán használhatóvá teszi, egyszerűen eltűnne. Az alapértelmezés mindent nyitva hagy; a termékcsapat választja meg, hogy mely darabokat zárja le egy leszállított egység felé vezető úton.

14.3.4.3. Mit nyújt még mindig a fizikai hozzáférés¶

Még bekapcsolt kiolvasás elleni védelem mellett is egy támadó, akinek a kamera a kezében van, sok mindent tehet:

Lejátszhatja a kamera hálózati forgalmát a kimeneteinek lehallgatásával.
Megfigyelheti a látható viselkedését, és következtethet arra, hogyan reagál a bemenetekre.
Bizonyos esetekben titkokat nyerhet ki a védett MCU ellen specializált hibainjektálási vagy oldalcsatornás támadásokkal.

A kiolvasás elleni védelem megnöveli az alkalmazás forráskódjához való hozzáférés költségét. Nem szünteti meg a költséget. A „fizikai hozzáférés = kompromittálódás” az a munkahipotézis, amelyből egy biztonsági felülvizsgálatnak ki kell indulnia; a védelmi mechanizmus csak azt dönti el, mennyibe kerül ez a kompromittálódás időben és felszerelésben.

14.3.4.4. Mivel szállítják az OpenMV firmware-t¶

Egy összefoglaló, hogy ez konkrét legyen:

Alapértelmezetten nincs engedélyezve kiolvasás elleni védelem.
A gyári firmware-ben nincs build flag, amely bekapcsolná.
Nincs alkalmazásszintű API, amelyet MicroPythonból lehetne hívni.

Egy olyan termék, amelynek szüksége van a védelemre, testreszabott firmware-t szállít. Ez a testreszabás a kártya rendszerbetöltőjében és a gyártási folyamatban él, és az OpenMV kódbázison kívül esik. Az ezt először végző csapatoknak ezt különálló munkadarabként kell beilleszteniük a fejlesztési ütemtervbe, nem pedig olyasvalamiként, amit a végén kell hozzáadni – a visszafordíthatatlanság drágává teszi a „tegyük hozzá később” megközelítést.