14.3.4. Uwaga o ochronie odczytu pamięci flash¶

Zaraz po wyjęciu z pudełka oprogramowanie układowe na dostarczonej kamerze OpenMV jest możliwe do odczytania przez każdego, kto ma fizyczny dostęp do urządzenia. Atakujący trzymający kamerę w ręku może podłączyć sondę SWD do złącza debugowania, połączyć się z interfejsem debugowania MCU i zrzucić zawartość pamięci flash – co obejmuje każdy zamrożony moduł Pythona oraz zawartość partycji ROMFS. Standardowe oprogramowanie układowe OpenMV nie włącza ochrony odczytu pamięci flash domyślnie.

Ta strona dokumentuje to wprost, aby zespół dostarczający produkt wiedział, gdzie leży odpowiedzialność.

14.3.4.1. Co kamera robi domyślnie¶

Bootloader i środowisko uruchomieniowe kamery nie włączają żadnej funkcji ochrony odczytu w bazowym MCU. Interfejs debugowania pozostaje otwarty, pamięć flash pozostaje możliwa do odczytania, a kompilacja działa tak, jak na stanowisku programisty. Jest to właściwe ustawienie domyślne dla odbiorców tego samouczka – kamera dostarczona z włączoną ochroną odczytu to kamera, której nie da się ponownie zaprogramować przez IDE, nie da się ponownie obrazować po nieudanym wdrożeniu i nie da się uratować przez nikogo poza zespołem budującym oprogramowanie.

Kompromis zmienia się, gdy kamera przechodzi z „urządzenia programistycznego” w „produkt”. Produkt, którego wartość zależy od utrzymania kodu aplikacji w tajemnicy, musi sam włączyć tę ochronę; oprogramowanie układowe OpenMV tego nie robi.

14.3.4.2. Co robi zespół produktowy¶

Każdy producent MCU oferuje mechanizm ochrony odczytu. Szczegóły się różnią – bezpieczniki na poziomie bitów, jednorazowe przejścia cyklu życia, podpisane obrazy flash – ale wspólny schemat jest następujący:

Specyficzny dla producenta bit (lub zestaw bitów) jest zapisywany w krzemie, zwykle za pomocą narzędzia producenta, które po raz ostatni komunikuje się z portem debugowania MCU.
Po zapisie port debugowania odmawia odczytu pamięci flash. Kamera nadal uruchamia się i wykonuje aplikację; po prostu nie udostępnia już swojej zawartości sondzie.
Zapis jest nieodwracalny. Nie ma sposobu, aby przywrócić kamerę do stanu umożliwiającego debugowanie bez jej zniszczenia.

Konfiguracja tego zależy od konkretnego MCU, a kroki zależą od chronionego układu zastosowanego w kamerze. Podręcznik referencyjny producenta jest źródłem prawdy; wsparcie producenta jest kanałem umożliwiającym poprawne wykonanie tego na linii produkcyjnej.

To jest łatwa część.

Trudną częścią jest zamknięcie każdej innej drogi, którą atakujący ma do uruchomienia kodu na kamerze lub odczytania tego, co robi aplikacja. Ochrona odczytu zapobiega jedynie zrzucaniu pamięci flash przez sondę debugującą. Kamera musi nadal zamknąć:

REPL MicroPythona. REPL podłączony przez USB akceptuje dowolny kod Pythona. Ochrona odczytu tego nie zmienia. Sesja REPL może odczytywać pamięć RAM, wywoływać funkcje, eksfiltrować wszystko, co widzi działająca aplikacja – w efekcie dostępny REPL omija wszystko, co daje ochrona odczytu. Wyłączenie dostępu do REPL to zmiana w kompilacji oprogramowania układowego, za którą odpowiada zespół produktowy.
Przesyłanie skryptów z IDE. Ścieżka IDE „uruchom ten skrypt na kamerze” korzysta z tej samej powierzchni protokołu USB co REPL. Zamknięcie REPL zamyka również tę ścieżkę; pozostawienie którejkolwiek otwartej zostawia kanał wykonywania dowolnego kodu w kamerze.
Przejęcie punktu wejścia z systemu plików. Już zamknięte, gdy aplikacja jest dostarczana poprzez Zamrażanie skryptów w oprogramowaniu układowym – środowisko uruchomieniowe rozwiązuje zamrożone boot.py i main.py przed jakąkolwiek kopią z systemu plików, więc nic umieszczonego w pamięci flash ani na karcie SD nie może ich nadpisać. Ta ochrona jest darmowa, gdy aplikacja znajdzie się w kompilacji.
Zewnętrzna pamięć flash w nowszych kamerach. Kamery przechowujące obraz aplikacji w zewnętrznej pamięci flash umieszczają ten obraz w układzie znajdującym się na widoku na PCB; układ można wylutować i odczytać bezpośrednio za pomocą ogólnodostępnych narzędzi lub odczytać w miejscu, sondując magistralę. Ochrona wymaga włączenia sprzętu wbudowanego w układ, który odszyfrowuje zawartość pamięci flash podczas odczytów, wygenerowania klucza szyfrowania, dostarczenia tego klucza do kamery i nieodwracalnego wypalenia go w jednorazowo programowalnej pamięci MCU. Każda z tych czynności jest osobną operacją jednorazową, a wykonanie którejkolwiek z nich błędnie na egzemplarzu produkcyjnym unieruchamia ten egzemplarz.

Każdy element na tej liście to osobny stos prac nad kompilacją oprogramowania układowego, kroków na linii produkcyjnej i nieodwracalnych zapisów. Prawdziwie zabezpieczony produkt to dostosowana kompilacja oprogramowania układowego, dostosowany bootloader, proces produkcyjny dostarczający klucze dla każdego egzemplarza oraz zestaw testów potwierdzających, że blokada jest rzeczywiście zamknięta, zanim egzemplarz opuści linię. To miesiące pracy, a nie dni, a nieodwracalność oznacza, że błędy kosztują egzemplarze.

Dlaczego domyślnie jest otwarte

Ta lista jest również powodem, dla którego standardowe oprogramowanie układowe OpenMV jest dostarczane bez włączonej ochrony odczytu. Kamera z zamkniętym REPL, wyłączonym przesyłaniem skryptów z IDE i zablokowanym oprogramowaniem układowym to kamera, na której w ogóle nie da się programować – przepływ pracy, który w pierwszej kolejności czyni kamery OpenMV użytecznymi, po prostu by zniknął. Ustawienie domyślne pozostawia wszystko otwarte; zespół produktowy wybiera, które elementy zamknąć w drodze do dostarczonego egzemplarza.

14.3.4.3. Co nadal daje fizyczny dostęp¶

Nawet z włączoną ochroną odczytu atakujący trzymający kamerę może zrobić całkiem sporo:

Odtworzyć ruch sieciowy kamery, podsłuchując jej dane wyjściowe.
Obserwować jej widoczne zachowanie i wnioskować, jak reaguje na dane wejściowe.
W niektórych przypadkach odzyskać sekrety za pomocą wstrzykiwania błędów lub ataków kanałami bocznymi wyspecjalizowanych pod chroniony MCU.

Ochrona odczytu podnosi koszt dotarcia do kodu źródłowego aplikacji. Nie eliminuje tego kosztu. „Fizyczny dostęp = kompromitacja” to robocze założenie, od którego powinna zaczynać się analiza bezpieczeństwa; mechanizm ochrony decyduje jedynie o tym, ile ta kompromitacja kosztuje pod względem czasu i sprzętu.

14.3.4.4. Z czym dostarczane jest oprogramowanie układowe OpenMV¶

Podsumowanie, aby było konkretnie:

Brak włączonej ochrony odczytu domyślnie.
Brak flagi kompilacji w standardowym oprogramowaniu układowym, która ją włącza.
Brak API na poziomie aplikacji do wywołania z MicroPythona.

Produkt, który potrzebuje tej ochrony, dostarcza dostosowane oprogramowanie układowe. Ta personalizacja znajduje się w bootloaderze płytki oraz w procesie produkcyjnym i jest poza bazą kodu OpenMV. Zespoły robiące to po raz pierwszy powinny zaplanować to w harmonogramie rozwoju jako odrębny element pracy, a nie coś do dodania na końcu – nieodwracalność sprawia, że „dodanie później” jest kosztowne.