14.3.4. Huomautus flash-muistin lukusuojauksesta¶

Oletusarvoisesti toimitetun OpenMV cam -kameran laiteohjelmisto on luettavissa kenelle tahansa, jolla on fyysinen pääsy laitteeseen. Hyökkääjä, jolla on kamera käsissään, voi kytkeä SWD-anturin debug-liittimeen, kommunikoida MCU:n debug-rajapinnan kanssa ja kopioida flash-muistin – joka sisältää jokaisen jäädytetyn Python-moduulin ja ROMFS-osion sisällön. Vakio-OpenMV-laiteohjelmisto ei ota flash-muistin lukusuojausta käyttöön oletusarvoisesti.

Tämä sivu dokumentoi tuon nimenomaisesti, jotta tuotetta toimittava tiimi tietää, missä vastuu on.

14.3.4.1. Mitä kamera tekee oletusarvoisesti¶

Kameran käynnistyslatain ja ajonaikainen ympäristö eivät ota käyttöön mitään taustalla olevan MCU:n lukusuojausominaisuutta. Debug-rajapinta pysyy avoinna, flash-muisti pysyy luettavissa ja koonti toimii samalla tavalla kuin kehittäjän työpöydällä. Se on oikea oletus opetusohjelman kohderyhmälle – kamera, joka toimitetaan lukusuojaus päällä, on kamera, jota ei voi uudelleenflashata IDE:n kautta, jota ei voi imagoida uudelleen epäonnistuneen käyttöönoton jälkeen eikä jota kukaan muu kuin koontitiimi voi pelastaa.

Kompromissi muuttuu, kun kamera siirtyy ”kehittäjälaitteesta” ”tuotteeksi”. Tuotteen, jonka arvo riippuu sovelluskoodin pysymisestä yksityisenä, on otettava suojaus käyttöön itse; OpenMV-laiteohjelmisto ei tee sitä.

14.3.4.2. Mitä tuotetiimi tekee¶

Jokainen MCU-valmistaja tarjoaa lukusuojausmekanismin. Yksityiskohdat vaihtelevat – bittitason sulakkeet, kertaluonteiset elinkaarisiirtymät, allekirjoitetut flash-imaget – mutta yleinen muoto on:

Valmistajakohtainen bitti (tai bittijoukko) kirjoitetaan piihin, yleensä valmistajan työkalulla, joka kommunikoi MCU:n debug-portin kanssa viimeisen kerran.
Kirjoittamisen jälkeen debug-portti kieltäytyy lukemasta flash-muistia. Kamera käynnistyy ja ajaa sovellusta edelleen; se ei vain enää paljasta sisältöään anturille.
Kirjoittaminen on peruuttamatonta. Kameraa ei ole mitään keinoa palauttaa debugattavaan tilaan tuhoamatta sitä.

Tämän asettaminen on MCU-kohtaista, ja vaiheet riippuvat suojattavan kameran komponentista. Valmistajan referenssikäsikirja on totuuden lähde; valmistajan tuki on kanava sen tekemiseen oikein valmistuslinjalla.

Tämä on helppo osuus.

Vaikea osuus on jokaisen muun polun sulkeminen, joka hyökkääjällä on koodin ajamiseen kamerassa tai sen lukemiseen, mitä sovellus tekee. Lukusuojaus estää vain debug-anturia kopioimasta flash-muistia. Kameran on silti suljettava:

MicroPython REPL. USB:hen kytketty REPL hyväksyy mielivaltaista Pythonia. Lukusuojaus ei muuta sitä. REPL-istunto voi lukea RAM-muistia, kutsua funktioita ja vuotaa kaiken, mitä ajossa oleva sovellus näkee – käytännössä saavutettavissa oleva REPL ohittaa kaiken, mitä lukusuojaus tarjoaa. REPL-pääsyn poistaminen käytöstä on laiteohjelmiston koontimuutos, joka kuuluu tuotetiimille.
IDE:n skriptin lataus. IDE:n ”aja tämä skripti kamerassa” -polku käyttää samaa USB-protokollapintaa kuin REPL. REPL:n sulkeminen sulkee tämänkin; jommankumman jättäminen auki jättää mielivaltaisen koodin suorituskanavan kameraan.
Tiedostojärjestelmästä tapahtuva sisääntulokohdan kaappaus. Jo suljettu, kun sovellus toimitetaan kohteen Skriptien jäädyttäminen laiteohjelmistoon kautta – ajonaikainen ympäristö ratkaisee jäädytetyt boot.py ja main.py ennen mitään tiedostojärjestelmäkopiota, joten mikään flash-muistiin tai SD-kortille pudotettu ei voi ohittaa niitä. Tämä suojaus on ilmainen, kun sovellus on koonnissa.
Ulkoinen flash-muisti uudemmissa kameroissa. Kamerat, jotka tallentavat sovelluksen imagen ulkoiseen flash-muistiin, asettavat tuon imagen piirisirulle, joka on selvästi näkyvissä piirilevyllä; sirun voi juottaa irti ja lukea suoraan kaupallisilla työkaluilla tai lukea paikallaan väylää tutkimalla. Sen suojaaminen edellyttää sirulla olevan laitteiston kytkemistä päälle, joka purkaa flash-muistin sisällön lukujen aikana, salausavaimen luomista, kyseisen avaimen provisiointia kameraan ja sen peruuttamatonta polttamista MCU:n kertaohjelmoitavaan muistiin. Jokainen näistä on erillinen kertaluonteinen toimenpide, ja mikä tahansa niistä väärin tehtynä tuotantoyksikössä rikkoo kyseisen yksikön.

Jokainen kohta tällä listalla on oma pinonsa laiteohjelmiston koontityötä, valmistuslinjan vaiheita ja peruuttamattomia kirjoituksia. Aidosti lukittu tuote on räätälöity laiteohjelmiston koonti, räätälöity käynnistyslatain, valmistusvirta, joka provisioi avaimet yksikkökohtaisesti, ja joukko testejä, jotka todistavat lukon olevan todella suljettu ennen kuin yksikkö lähtee linjalta. Se on kuukausien työtä, ei päivien, ja peruuttamattomuus tarkoittaa, että virheet maksavat yksiköitä.

Miksi oletus on avoin

Tämä lista on myös syy siihen, miksi vakio-OpenMV-laiteohjelmisto toimitetaan ilman lukusuojausta käytössä. Kamera, jonka REPL on suljettu, IDE:n skriptin lataus poistettu käytöstä ja laiteohjelmisto lukittu, on kamera, jolla ei voi kehittää lainkaan – työnkulku, joka tekee OpenMV-kameroista ylipäätään käyttökelpoisia, olisi yksinkertaisesti poissa. Oletus jättää kaiken auki; tuotetiimi valitsee, mitkä osat suljetaan matkalla toimitettavaan yksikköön.

14.3.4.3. Mitä fyysinen pääsy yhä tarjoaa¶

Vaikka lukusuojaus on päällä, hyökkääjä, jolla on kamera hallussaan, voi tehdä melko paljon:

Toistaa kameran verkkoliikennettä haistelemalla sen ulostuloja.
Tarkkailla sen näkyvää käyttäytymistä ja päätellä, miten se reagoi syötteisiin.
Joissakin tapauksissa palauttaa salaisuuksia vikainjektio- tai sivukanavahyökkäyksillä, jotka on erikoistettu suojattua MCU:ta vastaan.

Lukusuojaus nostaa sovelluksen lähdekoodiin pääsyn kustannusta. Se ei poista kustannusta. ”Fyysinen pääsy = vaarantuminen” on toimintaolettama, josta turvallisuusarvioinnin tulisi lähteä; suojausmekanismi vain päättää, kuinka paljon tuo vaarantuminen maksaa aikana ja laitteistona.

14.3.4.4. Mitä OpenMV-laiteohjelmisto sisältää toimitettaessa¶

Yhteenveto, jotta tämä on konkreettista:

Lukusuojaus ei ole oletusarvoisesti käytössä.
Vakio-laiteohjelmistossa ei ole koontilippua, joka ottaisi sen käyttöön.
Ei sovellustason API:a, jota kutsua MicroPythonista.

Tuote, joka tarvitsee suojausta, toimittaa räätälöidyn laiteohjelmiston. Tuo räätälöinti sijaitsee piirilevyn käynnistyslataimessa ja valmistusvirrassa, ja on OpenMV-koodikannan ulkopuolella. Tiimien, jotka tekevät tätä ensimmäistä kertaa, tulisi suunnitella se kehitysaikatauluun erillisenä työn osana, ei jonakin loppuun lisättävänä – peruuttamattomuus tekee ”lisätään myöhemmin” -lähestymisestä kallista.