14.3.4. En anmärkning om läsutläsningsskydd för flashminne

Direkt ur lådan är den fasta programvaran på en levererad OpenMV-kamera läsbar för alla med fysisk åtkomst till enheten. En angripare med kameran i handen kan ansluta en SWD-sond till felsökningshuvudet, kommunicera med MCU:ns felsökningsgränssnitt och dumpa flashminnet – vilket inkluderar varje fryst Python-modul och innehållet i ROMFS-partitionen. Standardprogramvaran för OpenMV aktiverar inte läsutläsningsskydd för flashminne som standard.

Den här sidan dokumenterar detta uttryckligen så att ett team som levererar en produkt vet var ansvaret ligger.

14.3.4.1. Vad kameran gör som standard

Kamerans startladdare och körtidsmiljö aktiverar inte någon funktion för läsutläsningsskydd i den underliggande MCU:n. Felsökningsgränssnittet förblir öppet, flashminnet förblir läsbart, och bygget körs på samma sätt som på en utvecklares arbetsbänk. Det är det rätta standardvärdet för handledningens målgrupp – en kamera som levereras med läsutläsningsskydd aktiverat är en kamera som inte kan flashas om via IDE:n, inte kan avbildas på nytt efter en misslyckad distribution och inte kan räddas av någon annan än byggteamet.

Avvägningen ändras när kameran går från ”utvecklarenhet” till ”produkt”. En produkt vars värde beror på att applikationskoden förblir privat måste själv aktivera skyddet; OpenMV-programvaran gör det inte.

14.3.4.2. Vad produktteamet gör

Varje MCU-tillverkare erbjuder en mekanism för läsutläsningsskydd. Detaljerna skiljer sig – säkringar på bitnivå, engångsövergångar i livscykeln, signerade flashavbildningar – men den gemensamma formen är:

  • En tillverkarspecifik bit (eller uppsättning bitar) skrivs in i kislet, vanligtvis genom ett tillverkarverktyg som kommunicerar med MCU:ns felsökningsport en sista gång.

  • Efter inskrivningen vägrar felsökningsporten att läsa flashminnet. Kameran startar och kör fortfarande applikationen; den exponerar bara inte längre sitt innehåll för en sond.

  • Inskrivningen är oåterkallelig. Det finns inget sätt att återställa kameran till ett felsökningsbart tillstånd utan att förstöra den.

Att ställa in detta är MCU-specifikt, och stegen beror på vilken komponent på kameran som skyddas. Tillverkarens referensmanual är den definitiva källan; tillverkarens support är kanalen för att få det rätt på en tillverkningslina.

Det här är den enkla delen.

Den svåra delen är att stänga varenda annan väg en angripare har till att köra kod på kameran eller läsa vad applikationen gör. Läsutläsningsskydd hindrar bara en felsökningssond från att dumpa flashminnet. Kameran måste fortfarande stänga:

  • MicroPython-REPL:en. En USB-ansluten REPL accepterar godtycklig Python. Läsutläsningsskydd ändrar inte detta. En REPL-session kan läsa RAM, anropa funktioner och exfiltrera vad än den körande applikationen kan se – i praktiken kringgår en nåbar REPL allt som läsutläsningsskyddet ger. Att inaktivera REPL-åtkomst är en ändring i programvarubygget som produktteamet ansvarar för.

  • Skriptuppladdning från IDE:n. IDE:ns väg för att ”köra detta skript på kameran” använder samma USB-protokollyta som REPL:en gör. Att stänga REPL:en stänger även denna; att lämna någondera öppen lämnar en kanal för godtycklig kodkörning in i kameran.

  • Kapning av startpunkten från filsystemet. Redan stängd när applikationen levereras genom Frysa skript in i den fasta programvaran – körtidsmiljön löser upp frysta boot.py och main.py före varje filsystemskopia, så ingenting som placeras på flashminnet eller SD-kortet kan åsidosätta dem. Detta skydd är gratis så snart applikationen finns i bygget.

  • Externt flashminne på nyare kameror. Kameror som lagrar applikationsavbildningen i externt flashminne placerar den avbildningen på ett chip som sitter fullt synligt på kretskortet; chippet kan lödas av och läsas direkt med standardverktyg, eller läsas på plats genom att avlyssna bussen. Att skydda det kräver att man aktiverar den inbyggda hårdvaran på chippet som dekrypterar flashinnehållet vid läsning, genererar krypteringsnyckeln, tillhandahåller den nyckeln till kameran och bränner in den oåterkalleligt i MCU:ns engångsprogrammerbara lagring. Var och en av dessa är en separat engångsoperation, och om någon av dem görs fel på en produktionsenhet förstörs den enheten permanent.

Varje punkt på den här listan är sin egen hög av arbete med programvarubygget, steg på tillverkningslinan och oåterkalleliga inskrivningar. En verkligt nedlåst produkt är ett anpassat programvarubygge, en anpassad startladdare, ett tillverkningsflöde som tillhandahåller nycklar per enhet, och en uppsättning tester som bevisar att låset faktiskt är stängt innan enheten lämnar linan. Det är månader av arbete, inte dagar, och oåterkalleligheten gör att misstag kostar enheter.

Varför standardvärdet är öppet

Den här listan är också anledningen till att standardprogramvaran för OpenMV levereras utan läsutläsningsskydd aktiverat. En kamera med stängd REPL, inaktiverad skriptuppladdning från IDE:n och låst programvara är en kamera som inte alls går att utveckla på – arbetsflödet som gör OpenMV-kameror användbara i första hand skulle helt enkelt vara borta. Standardvärdet lämnar allt öppet; produktteamet väljer vilka delar som ska stängas på vägen mot en levererad enhet.

14.3.4.3. Vad fysisk åtkomst fortfarande ger

Även med läsutläsningsskydd aktiverat kan en angripare som har kameran göra ganska mycket:

  • Spela upp kamerans nätverkstrafik igen genom att avlyssna dess utdata.

  • Observera dess synliga beteende och dra slutsatser om hur den reagerar på indata.

  • I vissa fall återställa hemligheter genom felinjektion eller sidokanalsattacker specialiserade mot den skyddade MCU:n.

Läsutläsningsskydd höjer kostnaden för att komma åt applikationens källkod. Det eliminerar inte kostnaden. ”Fysisk åtkomst = komprometterad” är det arbetsantagande som en säkerhetsgranskning bör utgå från; skyddsmekanismen avgör bara hur mycket den komprometteringen kostar i tid och utrustning.

14.3.4.4. Vad OpenMV-programvaran levereras med

En sammanfattning, så att detta blir konkret:

  • Inget läsutläsningsskydd aktiverat som standard.

  • Ingen byggflagga i standardprogramvaran som aktiverar det.

  • Inget API på applikationsnivå att anropa från MicroPython.

En produkt som behöver skyddet levererar anpassad programvara. Den anpassningen finns i kortets startladdare och i tillverkningsflödet, och ligger utanför OpenMV-kodbasen. Team som gör detta för första gången bör planera in det i utvecklingstidslinjen som ett avgränsat arbetsmoment, inte som något att lägga till på slutet – oåterkalleligheten gör att ”lägga till det senare” blir dyrt.