Schutz vor Reverse Engineering: STM32 Read-Out Protection (RDP)

Schutz vor Reverse Engineering: STM32 Read-Out Protection (RDP) ist für viele Embedded-Produkte ein wichtiger Baustein, um Firmware, Algorithmen und vertrauliche Daten vor unbefugtem Auslesen zu schützen. In der Praxis sind STM32-Mikrocontroller oft in Geräten verbaut, die physisch zugänglich sind: im Schaltschrank, in Messgeräten, in Fahrzeugkomponenten oder in Consumer-Produkten. Damit steigt das Risiko, dass jemand versucht, den Flash-Inhalt über Debug-Schnittstellen (SWD/JTAG), Bootloader-Interfaces oder durch direkte Speicherzugriffe auszulesen und anschließend zu analysieren. RDP adressiert genau diesen Angriffspfad, indem es – je nach Schutzstufe – das Lesen des Programmspeichers und bestimmter Speicherbereiche blockiert und Debug-Funktionen einschränkt. Wichtig ist jedoch: RDP ist kein „magischer“ Komplettschutz. Es reduziert die Angriffsfläche und erhöht den Aufwand für Reverse Engineering, ersetzt aber kein durchdachtes Sicherheitskonzept aus Secure Boot, signierten Updates, sauberem Schlüsselmanagement und ggf. TrustZone oder zusätzlicher Hardware-Härtung. In diesem Artikel erfahren Sie, wie STM32 Read-Out Protection funktioniert, welche RDP-Level typischerweise existieren, welche Konsequenzen das Setzen und Zurücksetzen hat und wie Sie RDP in Produktion und Feldbetrieb sinnvoll einbinden, ohne sich später selbst auszuschließen.

Was ist Read-Out Protection (RDP) beim STM32?

Read-Out Protection ist eine Schutzfunktion, die über sogenannte Option Bytes konfiguriert wird. Ziel ist es, unbefugtes Auslesen des Flash-Speichers (und je nach Familie auch weiterer Bereiche wie Backup-SRAM oder Backup-Register) zu verhindern. In vielen STM32-Familien werden dafür mehrere Schutzstufen angeboten. Typisch ist eine Staffelung von „keine Einschränkung“ bis hin zu „permanent gesperrt“.

• Schutz vor Debug-Auslesen: Ein externer Debugger soll den Programmspeicher nicht mehr auslesen können.
• Schutz vor Manipulation: Je nach Level werden Programmier- und Debugfunktionen eingeschränkt.
• Schutz von IP und Secrets: Firmware, Protokoll-Stacks, Algorithmen und eingebettete Schlüssel sollen nicht trivial kopierbar sein.

Die Aktivierung erfolgt in der Regel durch Setzen eines RDP-Option-Bytes. Danach ist üblicherweise ein Reset oder Power-Cycle erforderlich, damit die neue Konfiguration wirksam wird. ST beschreibt dieses Prinzip auch in Knowledge-Base-Artikeln zur Änderung der RDP-Stufe. Anleitung zur Änderung der Readout Protection auf STM32F4 bietet hierzu einen gut verständlichen Einstieg.

RDP-Level im Überblick: Level 0, Level 1, Level 2

Die genaue Bedeutung hängt von der STM32-Familie ab, aber als grobe Orientierung gilt häufig:

• RDP Level 0: Keine Readout Protection. Debugger- und Programmierzugriffe sind in der Regel uneingeschränkt möglich.
• RDP Level 1: Readout ist blockiert, Debug-Zugriffe werden stark eingeschränkt. Bestimmte Operationen (z. B. „Unprotect“) sind oft möglich, führen aber typischerweise zu einem vollständigen Löschen (Mass Erase) der Benutzer-Flash-Bereiche.
• RDP Level 2: Maximale, dauerhafte Sperre. Option Bytes werden eingefroren, Debug ist deaktiviert und ein Zurücksetzen ist je nach Familie nicht mehr möglich. ST beschreibt für verschiedene Serien, dass bei Level 2 die Option Bytes nicht mehr modifizierbar sind und das Gerät damit „voll geschützt“ ist. Das wird beispielsweise in der ST Application Note zu proprietärem Code-Readout-Schutz erläutert. AN4758 zu PCROP und RDP auf STM32L4/L4+/G4/WB

Ein entscheidender Punkt für die Praxis: RDP Level 2 kann – abhängig von der konkreten STM32-Variante – faktisch irreversibel sein. Das ist ein starkes Sicherheitsmerkmal, aber auch ein erhebliches Produktionsrisiko, wenn Prozesse und Tests nicht sauber sitzen.

Warum RDP allein Reverse Engineering nicht „unmöglich“ macht

RDP ist eine Hürde, kein mathematischer Beweis der Unknackbarkeit. Gegen den typischen Angreifer, der „nur schnell per ST-LINK auslesen“ möchte, wirkt RDP sehr effektiv. Gegen hochbudgetierte Angriffe mit physikalischen Methoden (z. B. Fault Injection, invasive Analyse) ist RDP jedoch nur ein Teil des Gesamtbilds. In der Security-Forschung und in Blogbeiträgen wird gezeigt, dass bestimmte Angriffsklassen – je nach Device, Revision und Setup – grundsätzlich denkbar sind. Beitrag zu Fault-Injection-Angriffen auf STM32 Readout Protection ordnet diese Angriffsrichtung ein.

Für die Produktplanung ist das entscheidend: Sie wählen RDP-Level nicht, weil es „absolut sicher“ ist, sondern weil es die Kosten, den Aufwand und die Expertise für einen Angriff so stark erhöht, dass er für Ihr Bedrohungsmodell unattraktiv wird.

Option Bytes verstehen: Wo RDP technisch verankert ist

RDP wird in der Regel über Option Bytes konfiguriert, also spezielle Konfigurationsworte im nichtflüchtigen Speicher, die Boot-Verhalten, Schutzfunktionen und teils auch Watchdog- oder Reset-Einstellungen steuern. Die wichtigsten praktischen Konsequenzen:

• Änderung wirkt nicht „live“: Nach dem Setzen der Option Bytes ist typischerweise ein Reset bzw. Power-Cycle nötig.
• RDP beeinflusst Zugriffswege: Debugger, Bootloader-Interfaces und Speicherzugriffe verhalten sich je nach Level anders.
• RDP ist eng mit weiteren Schutzmechanismen gekoppelt: z. B. Write Protection, PCROP, TrustZone-Konfiguration (je nach Serie).

Da Option Bytes produkt- und serienabhängig sind, sollte die finale Umsetzung stets gegen Datenblatt/Reference Manual des konkreten Controllers validiert werden. Für praxisnahe Workflows ist häufig STM32CubeProgrammer das zentrale Werkzeug, weil es Option-Byte-Konfiguration, Programmierung und (wo zulässig) Unprotect-Prozeduren bündelt.

RDP Level 1 in der Praxis: Schutz mit „Notausgang“

RDP Level 1 ist in vielen Produktklassen der pragmatische Standard, weil er einen wirksamen Basisschutz bietet, aber im Notfall noch ein Recovery-Szenario zulässt. Der typische Mechanismus: Wenn Sie von Level 1 zurück auf Level 0 gehen, wird der Flash-Speicher massenweise gelöscht, bevor die Protection aufgehoben wird. Das bedeutet: Der Code ist danach weg – aber das Gerät ist wieder programmierbar.

ST beschreibt dieses Verhalten in mehreren Dokumenten: Das Deaktivieren von RDP Level 1 führt zu einem Mass Erase der Flash-Inhalte und setzt je nach Serie weitere Bereiche zurück, wie in AN4758 ausgeführt. AN4758 – Einführung in PCROP und RDP (inkl. Level-1-Disable mit Mass Erase)

Für Ihre Produktstrategie heißt das: RDP Level 1 ist gut, wenn Sie Servicefähigkeit benötigen (z. B. Austausch-Firmware im Feld), aber dennoch das einfache Auslesen verhindern wollen. Gleichzeitig müssen Sie einplanen, dass ein „Unprotect“ das Gerät in einen leerprogrammierten Zustand versetzt und daher eine sichere Re-Provisionierung (inkl. Keys und Konfiguration) erfordert.

RDP Level 2: Maximaler Schutz mit hohem Produktionsrisiko

RDP Level 2 ist in vielen STM32-Familien als endgültiger Zustand gedacht: Der Controller sperrt Option Bytes und verhindert damit eine spätere Rücknahme. In ST-Dokumenten wird dazu beschrieben, dass bei Level 2 die Option Bytes eingefroren und nicht mehr modifizierbar sind. AN4758 – Beschreibung von RDP Level 2 und eingefrorenen Option Bytes

Die Vorteile sind offensichtlich: Reverse Engineering über Standard-Schnittstellen wird massiv erschwert, Debug wird typischerweise deaktiviert, und die „Rückkehr“ zu einem offenen Zustand ist nicht vorgesehen. Die Kehrseite ist ebenso wichtig: Fehler im Provisioning, falsche BOOT-Konfiguration oder eine unvollständige Produktionsprüfung können ein Gerät dauerhaft in einen Zustand bringen, in dem es nicht mehr nutzbar ist. Das ist weniger ein Security-Problem als ein Prozess- und Qualitätsproblem – aber mit echten Kosten.

RDP und Bootloader: DFU, UART-Boot, System Memory und reale Auswirkungen

Viele STM32 bieten einen ROM-basierten System Bootloader (z. B. für DFU über USB oder Programmierung über UART/SPI/I2C, je nach Serie). RDP beeinflusst häufig, wie sich dieser Bootloader bei Zugriffen verhält. In der Praxis sehen Entwickler dann Meldungen wie „Device is under read out protection“ und müssen verstehen, was das konkret bedeutet.

• Programmierzugriff im Bootloader: kann bei aktivem RDP eingeschränkt sein oder besondere Abläufe erfordern.
• Unprotect-Prozeduren: können (bei Level 1) möglich sein, erfordern aber oft einen Power-Cycle und führen zu Mass Erase.
• Service-Prozess definieren: Sie sollten dokumentieren, wie ein Gerät im Feld wiederhergestellt wird, ohne Sicherheitsziele zu brechen.

Diskussionen und typische Fehlermeldungen im Zusammenhang mit DFU und RDP werden auch in der ST-Community behandelt, etwa bei der Meldung, dass ein Gerät unter Readout Protection steht und ein „Read Unprotect“ eine erneute Spannungszufuhr erfordert. ST-Community-Thread zu DFU und Readout Protection

RDP ergänzen: PCROP, Write Protection und segmentierte Schutzkonzepte

In vielen Fällen ist „alles oder nichts“ nicht optimal. Deshalb existieren ergänzende Mechanismen, um bestimmte Flash-Bereiche selektiv zu schützen oder Schreibzugriffe zu verhindern. Ein prominentes Beispiel ist PCROP (Proprietary Code Read Out Protection), das je nach STM32-Familie genutzt wird, um definierte Codebereiche vor Auslesen zu schützen und damit eine feinere Schutzgranularität zu erreichen.

• PCROP: schützt bestimmte Flash-Regionen vor Readout/Analyse, während andere Bereiche updatefähig bleiben.
• Write Protection: verhindert ungewolltes Überschreiben wichtiger Bereiche (z. B. Bootloader, Konfiguration).
• Kombination mit RDP: je nach Bedrohungsmodell kann RDP Level 1 plus PCROP eine sehr praxisnahe Balance sein.

ST beschreibt PCROP und verwandte Flash-Schutztechniken in Application Notes wie AN4758 (für L4/L4+/G4/WB) und AN4968 (für F72/F73). AN4968 zu PCROP auf STM32F72/F73

Wie RDP in ein Gesamt-Sicherheitskonzept passt

RDP ist vor allem ein Schutz gegen Auslesen. Moderne Angriffe betreffen jedoch auch Manipulation (modifizierte Firmware) und Abuse (z. B. Downgrades auf verwundbare Versionen). Deshalb sollten Sie RDP typischerweise kombinieren mit:

• Secure Boot: Start nur bei gültiger Signatur, damit Manipulation nicht einfach per Reflash möglich ist.
• Signierte Firmware-Updates: OTA oder Service-Updates nur nach kryptografischer Verifikation.
• Schlüsselmanagement: Secrets nicht im Non-Secure RAM/Flash „offen liegen lassen“, ggf. Secure Storage/TrustZone nutzen.
• Attack Surface Reduction: Debug-Ports im Feld deaktivieren, Testpads schützen, Firmware-Interfaces minimal halten.

Für den Secure-Boot-Grundgedanken ist Secure Boot eine nützliche Einstiegserklärung, um die Idee der Vertrauenskette einzuordnen.

Produktions- und Serviceprozesse: RDP sicher einführen, ohne sich auszusperren

Der größte praktische Unterschied zwischen einem Demo-Board und einem Serienprodukt ist der Prozess: Wer setzt RDP, wann wird getestet, wie werden Geräte im RMA-Fall behandelt, und wie verhindern Sie, dass ein falscher Schritt ganze Chargen unbrauchbar macht? Eine belastbare Produktionsstrategie enthält mindestens:

• Stufenplan: Erst programmieren und testen, dann RDP setzen, dann finalen Endtest, dann Versand.
• Seriennummern- und Logging-Konzept: protokollieren, welche RDP-Level und Option Bytes pro Gerät gesetzt wurden.
• Golden Device / Referenzlinie: Vergleichsgeräte für Debug und Fehleranalyse, die nicht auf Level 2 „zugesperrt“ sind.
• Service-Policy: definieren, ob Feldgeräte reprogrammierbar sein müssen (spricht oft für Level 1) oder ob Austausch statt Reflash geplant ist (macht Level 2 eher denkbar).

In der Praxis ist Level 1 häufig die bessere Default-Entscheidung, wenn Sie Debug- und Recovery-Fähigkeiten nicht vollständig verlieren dürfen. Level 2 passt eher zu Produkten, bei denen ein späterer Reflash nicht vorgesehen ist und der Schutzbedarf sehr hoch ist – und bei denen die Produktionsqualität den „Point of no return“ sicher beherrscht.

Häufige Missverständnisse rund um RDP

• „RDP verschlüsselt den Flash“: In der Regel verhindert RDP primär das Auslesen über definierte Zugriffswege; es ist nicht automatisch „Verschlüsselung at rest“.
• „Mit RDP bin ich komplett sicher“: RDP ist ein Baustein gegen Reverse Engineering, aber kein Ersatz für Secure Boot, Update-Sicherheit und Key-Schutz.
• „Level 2 kann man später wieder deaktivieren“: Bei vielen STM32-Familien ist Level 2 als dauerhaft beschrieben; das Risiko muss vorab akzeptiert werden.
• „Wenn Debug aus ist, gibt es keine Angriffe“: Hochbudgetierte Angriffe können über physische Methoden denkbar sein; RDP senkt vor allem die Wahrscheinlichkeit in realistischen Szenarien.

Risikoabschätzung: Wann reicht Level 1, wann ist Level 2 gerechtfertigt?

Eine einfache, praxisnahe Entscheidungslogik ist: Welche Folgen hätte ein Firmware-Diebstahl oder eine Firmware-Manipulation, und wie wahrscheinlich ist ein physischer Zugriff durch einen motivierten Angreifer? Wenn der Hauptgegner „Konkurrenz kopiert das Produkt“ ist, ist RDP Level 1 oft ein sehr wirksamer Basisschutz, insbesondere in Kombination mit PCROP und gesperrtem Debug im Feld. Wenn Sie hingegen hochkritische IP oder regulatorisch relevante Sicherheitsfunktionen schützen müssen und ein Reflash im Feld keine Option ist, kann Level 2 in Betracht kommen – aber nur mit sehr reifen Produktions- und Testprozessen.

Outbound-Ressourcen für die Vertiefung

• STM32CubeProgrammer als Werkzeug für Option Bytes und RDP
• RDP-Level und Vorgehen am Beispiel STM32F4 (ST Knowledge Base)
• AN4758: PCROP und RDP für STM32L4/L4+/G4/WB
• AN4968: PCROP für STM32F72/F73
• Praxisfall: DFU und „Device is under read out protection“
• Secure Boot als Ergänzung zu RDP gegen Firmware-Manipulation

IoT-PCB-Design, Mikrocontroller-Programmierung & Firmware-Entwicklung

PCB Design • Arduino • Embedded Systems • Firmware

Ich biete professionelle Entwicklung von IoT-Hardware, einschließlich PCB-Design, Arduino- und Mikrocontroller-Programmierung sowie Firmware-Entwicklung. Die Lösungen werden zuverlässig, effizient und anwendungsorientiert umgesetzt – von der Konzeptphase bis zum funktionsfähigen Prototyp.

Diese Dienstleistung richtet sich an Unternehmen, Start-ups, Entwickler und Produktteams, die maßgeschneiderte Embedded- und IoT-Lösungen benötigen. Finden Sie mich auf Fiverr.

Leistungsumfang:

• IoT-PCB-Design & Schaltplanerstellung

• Leiterplattenlayout (mehrlagig, produktionstauglich)

• Arduino- & Mikrocontroller-Programmierung (z. B. ESP32, STM32, ATmega)

• Firmware-Entwicklung für Embedded Systems

• Sensor- & Aktor-Integration

• Kommunikation: Wi-Fi, Bluetooth, MQTT, I²C, SPI, UART

• Optimierung für Leistung, Stabilität & Energieeffizienz

Lieferumfang:

• Schaltpläne & PCB-Layouts

• Gerber- & Produktionsdaten

• Quellcode & Firmware

• Dokumentation & Support zur Integration

Arbeitsweise:Strukturiert • Zuverlässig • Hardware-nah • Produktorientiert

CTA:
Planen Sie ein IoT- oder Embedded-System-Projekt?
Kontaktieren Sie mich gerne für eine technische Abstimmung oder ein unverbindliches Angebot. Finden Sie mich auf Fiverr.