W systemach embedded bezpieczeństwo przez długi czas było traktowane jako coś opcjonalnego. Duży nacisk na ochronę urządzeń producenci kładli jedynie w bardziej wymagających gałęziach, jak przemysł, medycyna czy automotive, gdzie bezpieczeństwo miało kluczowy wpływ na życie ludzkie czy jakość produkcji.
To się jednak w ostatnim czasie dynamicznie zmienia. Coraz więcej urządzeń opartych o mikrokontrolery komunikuje się z siecią, odbiera zdalne aktualizacje i przetwarza dane, które mają realną wartość biznesową. Rozwijający się rynek stawia coraz większe wymagania producentom. Również prawo wprowadza nowe regulacje, między innymi Cyber Resilience Act (CRA), które wymuszają bardziej systemowe podejście do bezpieczeństwa urządzeń m.in. w branży embedded.
Cyber Resilience Act (CRA) to unijne rozporządzenie wprowadzające obowiązkowe wymagania cyberbezpieczeństwa dla produktów zawierających komponenty cyfrowe. Regulacja wymaga między innymi zapewnienia bezpiecznych aktualizacji, zarządzania podatnościami oraz utrzymania bezpieczeństwa produktu przez cały deklarowany okres wsparcia.
Firmware często stanowi istotną część wartości produktu i zawiera know-how budowane przez lata rozwoju. Możliwość odczytania zawartości pamięci mikrokontrolera lub modyfikacji kodu przez nieuprawnioną osobę może prowadzić zarówno do kopiowania urządzeń, jak i naruszenia ich bezpieczeństwa.
Właśnie dlatego producenci mikrokontrolerów od wielu lat rozwijają mechanizmy chroniące pamięć programu przed odczytem. W rodzinie STM32 podstawowym rozwiązaniem przez długi czas był mechanizm Read-Out Protection (RDP), który z biegiem lat ewoluował w bardziej rozbudowane modele bezpieczeństwa, takie jak Product State dostępny w najnowszych rodzinach.
Czym jest Read-Out Protection (RDP)
Interfejsy JTAG i SWD są podstawowym sposobem programowania oraz debugowania mikrokontrolerów STM32. Bez dodatkowych zabezpieczeń umożliwiają również odczyt zawartości pamięci Flash. Oznacza to, że osoba posiadająca fizyczny dostęp do urządzenia może skopiować firmware za pomocą standardowych narzędzi. Aby ograniczyć takie ryzyko, STM32 wykorzystują specjalne bity konfiguracyjne “Option Bytes”, które pozwalają między innymi skonfigurować poziom ochrony pamięci przed odczytem.
Podstawowa wersja RDP
Klasyczne podejście znane z takich rodzin jak F4, L1, L4, G0, G4, czy U0 i C0 wprowadziło mechanizm Read-Out Protection, który jest oparty na kilkustopniowym poziomie zabezpieczeń. Rozróżniamy zwykle trzy poziomy:
- RDP Level 0 to domyślny poziom ochrony oznaczający brak zabezpieczeń przed odczytem. Użytkownik ma pełny dostęp do pamięci oraz funkcji debugowych. Możliwe jest programowanie, kasowanie i odczyt pamięci zarówno przez interfejs SWD/JTAG, jak i za pomocą systemowego bootloadera.
- RDP Level 1 blokuje możliwość odczytu i modyfikacji pamięci Flash przez interfejs debugowy (SWD/JTAG), a także ogranicza dostęp do pamięci SRAM2 w trybach debugowania i bootowania z RAM lub systemowego bootloadera. Próba dostępu do chronionych obszarów skutkuje błędem magistrali. Powrót do RDP Level 0 jest możliwy, jednak wiąże się z całkowitym wymazaniem zawartości pamięci Flash.
- RDP Level 2 zapewnia najwyższy poziom ochrony pamięci, w którym wszystkie zabezpieczenia z Level 1 pozostają aktywne, a mikrokontroler jest całkowicie zablokowany przed debugowaniem i odczytem. Opcje konfiguracyjne (Option Bytes), w tym RDP, zostają trwale zablokowane i nie mogą być już modyfikowane. Oznacza to, że układ nie może zostać przywrócony do niższego poziomu ochrony, co czyni ten stan nieodwracalnym.
Ze względu na całkowity brak ochrony, RDP Level 0 jest przeznaczony przede wszystkim do etapu rozwoju i debugowania oprogramowania, a jego pozostawienie w gotowym produkcie naraża firmware na łatwe skopiowanie lub analizę. RDP Level 1 jest najczęściej stosowany w gotowych produktach, gdzie wymagane jest zabezpieczenie firmware przed odczytem i analizą, ale jednocześnie konieczne może być dalsze serwisowanie urządzenia lub aktualizacja oprogramowania. RDP Level 2 przeznaczony jest dla urządzeń, które po wdrożeniu nie wymagają już żadnej formy debugowania ani serwisowego dostępu przez interfejsy programistyczne. Jest to tryb stosowany w produktach o najwyższych wymaganiach bezpieczeństwa.
Warto wspomnieć, że najstarsza rodzina STM32, czyli seria F1 udostępnia jedynie dwa poziomy ochrony: Level 0 i Level 1.
Rodziny oparte na architekturze Armv8 (czyli rdzeniu Cortex-M33), czyli takie jak L5 oferują również dodatkowo RPD Level 0.5. Został wprowadzony w mikrokontrolerach wyposażonych w mechanizm TrustZone i stanowi pośredni poziom ochrony pomiędzy całkowicie otwartym dostępem a klasycznym RDP Level 1. W tym trybie debugowanie oraz dostęp do pamięci pozostają możliwe dla obszarów oznaczonych jako non-secure, natomiast dostęp do zasobów secure jest całkowicie zablokowany. Poziom 0.5 jest dostępny tylko przy włączonym TrustZone.
RDP Level 0.5 jest szczególnie przydatny podczas rozwoju i testowania aplikacji wykorzystujących TrustZone, gdy konieczne jest debugowanie kodu użytkownika bez ujawniania krytycznych elementów.
RDP możemy skonfigurować zmieniając ustawienia “Option Bytes” w mikrokontrolerze. Można to zrobić z poziomu aplikacji STM32CubeProgrammer lub modyfikując “Option Bytes” z poziomu kodu. Poniżej przykład, jak to wykonać dla mikrokontrolera z serii STM32G4.
Aby zmienić ustawienia za pomocą STM32CubeProgrammer, należy połączyć się z układem i przejść do zakładki OB. Rozwijamy “Read Out Protection” i zmieniamy ustawienia na wymagany poziom. Teraz wystarczy zatwierdzić zmiany przyciskiem “Apply” Ochronę należy włączyć po zaprogramowaniu układu. Pamiętaj, że zmiana na Level 2 jest nieodwracalna!
Rozszerzenie RDP o mechanizm OEMKEY
Opisane dotychczas mechanizmy RDP opierają się wyłącznie na zmianie poziomu ochrony zapisanej w pamięci Option Bytes. W klasycznych rodzinach STM32 przejście do RDP Level 2 oznacza trwałe zamknięcie urządzenia i brak możliwości powrotu do niższych poziomów zabezpieczeń. Takie podejście skutecznie chroni firmware, ale jednocześnie ogranicza elastyczność podczas serwisowania, analizy awarii czy zarządzania cyklem życia produktu. W nowszych rodzinach STM32 wprowadzono dodatkowy mechanizm oparty na kluczach OEM, który pozwala na kontrolowane zarządzanie poziomami ochrony oraz bezpieczną regresję wybranych stanów RDP.
Mikrokontrolery STM32U3 i STM32U5 rozszerzają klasyczny model RDP o dwa klucze producenta: OEM1KEY oraz OEM2KEY. Są one programowane na etapie produkcji i umożliwiają wykonywanie kontrolowanych przejść pomiędzy poziomami zabezpieczeń bez konieczności pozostawania urządzenia w stanie otwartym. Dzięki temu możliwe jest między innymi cofnięcie zabezpieczeń podczas serwisowania przez producenta, przy jednoczesnym zachowaniu wysokiego poziomu ochrony przed nieautoryzowanym dostępem. Mechanizm ten stanowi pomost pomiędzy klasycznym RDP znanym ze starszych rodzin STM32 a bardziej zaawansowanymi modelami zarządzania cyklem życia urządzenia stosowanymi w bardziej rozbudowanych układach.
W przypadku STM32U5 RDP konfigurujemy w zakładce “Option Bytes”, analogicznie jak dla STM32G4. Natomiast klucze możemy skonfigurować w zakładce “Secure Programming” w sekcji “RDP REG”. Tutaj możemy ustawić klucze (jest to możliwe przy nieaktywnej ochronie RDP) oraz je wpisać, aby odblokować RDP.
Najnowsza rodzina STM32C5 również korzysta z mechanizmu RDP, jednak w innej konfiguracji. Model ochrony został uproszczony i opiera się wyłącznie na trzech stanach: RDP Level 0, RDP Level 2 with Boundary Scan oraz RDP Level 2. W stanie RDP Level 0 urządzenie pozostaje całkowicie otwarte, a dodatkowo możliwe jest zaprogramowanie kluczy OEMKEY i BSKEY, które będą wykorzystywane podczas późniejszego blokowania lub odblokowywania układu. Przejście do RDP Level 2 with Boundary Scan blokuje dostęp debugowy, pozostawiając jedynie możliwość korzystania z interfejsu boundary scan podczas resetu, co może być przydatne w procesie produkcyjnym i testowym. RDP Level 2 zapewnia pełne zamknięcie urządzenia, w którym wszystkie interfejsy debugowe są wyłączone, a modyfikacja poziomu RDP nie jest możliwa standardowymi metodami.
Dla rodziny STM32C5 aktywacja RDP odbywa się również w zakładce “Option Bytes”.
Klucze OEM i BSKEY możemy skonfigurować w zakładce “Secure Programming”.
Dlaczego RDP przestało wystarczać
Klasyczny mechanizm RDP w starszych rodzinach STM32, takich jak F1 czy F4, koncentruje się głównie na ochronie przed odczytem pamięci Flash przez interfejs debugowy. W praktyce oznacza to, że skutecznie zabezpiecza firmware przed prostą ekstrakcją, ale nie rozwiązuje wielu problemów związanych z całym cyklem życia urządzenia. Brakuje w nim wyraźnego rozróżnienia etapów takich jak produkcja, provisioning, wdrożenie czy serwis, co w nowoczesnych systemach IoT staje się kluczowe. Dodatkowo RDP jest mało elastyczny w kontekście aktualizacji firmware i procesów serwisowych, ponieważ zmiana poziomu ochrony często wiąże się z kasowaniem pamięci lub trwałą blokadą urządzenia.
Wraz ze wzrostem wymagań bezpieczeństwa i pojawieniem się zaawansowanych zagrożeń sam mechanizm ochrony odczytu przestaje być wystarczający. W nowszych rodzinach STM32 zaczęto więc wprowadzać bardziej elastyczne podejście, oparte na kluczach OEM, które umożliwiają kontrolowane przejścia między stanami zabezpieczeń. Takie rozwiązania stanowią już krok w stronę pełnego zarządzania cyklem życia urządzenia, które zostało rozwinięte w koncepcji Product State w STM32H5 i STM32H7.
STM32H5/H7 – nowa generacja zabezpieczeń
Rodziny STM32H5 i STM32H7 reprezentują nowe podejście do bezpieczeństwa w mikrokontrolerach. Kluczowym elementem tej zmiany jest wprowadzenie technologii TrustZone, która pozwala na fizyczne rozdzielenie świata secure i non-secure w ramach jednego układu. Oprócz tego pojawiają się mechanizmy takie jak Secure Firmware Installation, umożliwiające bezpieczne wdrażanie oprogramowania już na etapie produkcji.
Istotną rolę zaczynają również odgrywać klucze OEM, które wspierają kontrolę nad cyklem życia urządzenia i procesem jego zabezpieczania. Całość uzupełnia koncepcja Product State, która zastępuje proste podejście oparte wyłącznie na poziomach RDP. W tym modelu RDP przestaje być centralnym mechanizmem ochrony, a staje się jedynie jednym z elementów większej architektury bezpieczeństwa.
Czym jest Product State
Product State w rodzinach STM32 H5 i H7 opisuje etap życia urządzenia i stan jego zabezpieczeń w całym cyklu eksploatacji. Zamiast pojedynczego przełącznika typu „RDP level”, system ten wprowadza model oparty na maszynie stanów. Każdy stan definiuje nie tylko poziom ochrony pamięci, ale również zasady dotyczące debugowania, programowania oraz dostępu do kluczy bezpieczeństwa. W praktyce oznacza to, że mikrokontroler przechodzi przez kolejne etapy od całkowicie otwartego urządzenia aż do w pełni zabezpieczonego produktu końcowego.
ST dostarcza mikrokontroler w stanie Open (odpowiednik RDP Level 0), który odpowiada w pełni otwartemu urządzeniu z możliwością swobodnej konfiguracji opcji, w tym aktywacji TrustZone i mechanizmów debug. Kolejnym etapem jest Provisioning, w którym instalowany jest nierozłączny root of trust oraz konfigurowane są mechanizmy bezpieczeństwa i autoryzacji debugowania. W tej fazie możliwe jest jeszcze definiowanie polityk regresji, np. powrotu do Open lub ograniczenia do TZ-Closed w zależności od użytych poświadczeń.
Stan TZ-Closed przeznaczony jest do pracy deweloperskiej w środowisku, gdzie aktywny jest już model TrustZone, a debugowanie ogranicza się wyłącznie do świata non-secure. Natomiast Closed oznacza finalny stan produkcyjny, w którym debug jest wyłączony, a urządzenie działa jako zabezpieczony produkt końcowy, przy czym nadal dopuszczalne są kontrolowane regresje. Najbardziej restrykcyjny stan Locked jest odpowiednikiem dawnego RDP Level 2, gdzie nie ma już możliwości jakiejkolwiek regresji ani zmiany polityki bezpieczeństwa.
W przypadku potrzeby przywrócenia dostępu stosowany jest proces Regression, który pozwala – w zależności od autoryzacji – wrócić do Open lub TZ-Closed, często z konsekwencją kasowania pamięci i unieważnienia kluczy. Warto podkreślić, że nie istnieje bezpośredni odpowiednik RDP Level 1, ponieważ uznano go za niewystarczający zarówno z punktu widzenia rozwoju, jak i ochrony.
W przeciwieństwie do starszych rodzin, stan Product State jest przechowywany w option bytes, ale polityka debugowania jest egzekwowana przez dedykowany blok bezpieczeństwa SBS, co pozwala na bardziej spójne zarządzanie dostępem. Dzięki temu Product State tworzy jednolity model, w którym nawet dostęp do debug i kluczy kryptograficznych jest częścią kontrolowanego cyklu życia urządzenia, a nie tylko prostą blokadą pamięci.
Konfiguracja Product State odbywa się w podobny sposób, jak RDP. Należy w STM32CubeProgrammer przejść do zakładki “Option bytes”. W sekcji “Product State” znajdziemy możliwość zmiany stanu urządzenia.
RDP czy Product State – kierunek rozwoju
Wydaje się, że przyszłość zabezpieczeń STM32 będzie raczej rozwijać się w dwóch równoległych kierunkach niż w stronę jednego, uniwersalnego modelu. W prostszych i tańszych układach klasyczny RDP w połączeniu z mechanizmem kluczy OEM prawdopodobnie pozostanie dominującym podejściem, ponieważ zapewnia wystarczający poziom ochrony firmware przy stosunkowo niewielkiej złożoności implementacyjnej. Co istotne, to właśnie model oparty na kluczach wydaje się naturalnym kierunkiem ewolucji RDP, ponieważ wprowadza możliwość kontrolowanej regresji i lepszego zarządzania dostępem bez konieczności pełnej zmiany architektury bezpieczeństwa.
W bardziej zaawansowanych mikrokontrolerach coraz większe znaczenie będzie miał Product State wraz z podejściem opartym na pełnym zarządzaniu cyklem życia urządzenia. Ten model lepiej odpowiada na złożone wymagania związane z provisioningiem, rolami bezpieczeństwa oraz etapami produkcji i wdrożenia. W efekcie rynek prawdopodobnie utrzyma podział na dwie ścieżki: ewolucję RDP w stronę modeli kluczowych oraz rozwój Product State w bardziej złożonych układach.
Podsumowanie
Mechanizm RDP przez wiele lat stanowił skuteczną i prostą metodę ochrony firmware przed nieautoryzowanym odczytem przez interfejsy debugowe. Wraz z rozwojem systemów embedded i rosnącą złożonością urządzeń IoT jego ograniczenia stały się jednak coraz bardziej widoczne. W nowoczesnych mikrokontrolerach, takich jak STM32H5 i STM32H7, ochrona pamięci jest tylko jednym z elementów znacznie szerszego modelu bezpieczeństwa. Product State rozszerza to podejście, wprowadzając zarządzanie całym cyklem życia urządzenia zamiast pojedynczego poziomu zabezpieczeń. Dzięki temu możliwe jest kontrolowanie nie tylko dostępu do firmware, ale również debugowania, kluczy kryptograficznych i etapów produkcyjnych. W efekcie otrzymujemy spójny model bezpieczeństwa, który lepiej odpowiada współczesnym wymaganiom cyberbezpieczeństwa i regulacjom takim jak CRA.
Autor: Piotr Czaplicki, blog STM32WROBOTYCE
Materiały dodatkowe
- AN5156 Introduction to security for STM32 MCUs [https://www.st.com/resource/en/application_note/an5156-introduction-to-security-for-stm32-mcus-stmicroelectronics.pdf]
- How to enable RDP-like product state flash protection in STM32H5 microcontrollers [https://community.st.com/stm32-mcus-60/how-to-enable-rdp-like-product-state-flash-protection-in-stm32h5-microcontrollers-138097]
- RM0440 Reference Manual STM32G4 series advanced Arm®-based 32-bit MCUs [https://www.st.com/resource/en/reference_manual/dm00355726-stm32g4-series-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf]
- RM0438 Reference Manual STM32L5 series advanced Arm®-based 32-bit MCUs [https://www.st.com/resource/en/reference_manual/dm00346336-stm32l552xx-and-stm32l562xx-advanced-arm-based-32-bit-mcus-stmicroelectronics.pdf]
- RM0522 Reference manual STM32C5 Arm®-based 32-bit MCUs [https://www.st.com/resource/en/reference_manual/rm0522-stm32c5-series-armbased-32bit-mcus-stmicroelectronics.pdf]
- RM0481 Reference manual STM32H523/33xx, STM32H562/63xx, and STM32H573xx Arm®-based 32-bit MCUs [https://www.st.com/resource/en/reference_manual/rm0481-stm32h52333xx-stm32h56263xx-and-stm32h573xx-armbased-32bit-mcus-stmicroelectronics.pdf]