Debug-Schnittstellen stecken in jedem Mikrocontroller, weil die Entwicklung sie braucht. JTAG, SWD, UART-Konsolen und Boot-Mode-Pins sind die Engineering-Lifeline eines Produkts, und gleichzeitig der direkteste Weg für einen Angreifer mit physischem Zugriff. Flash-Auslesen, Memory-Modifikation, Code-Injektion und Key-Extraktion werden möglich, wenn der Lockdown unvollständig ist.
Das Problem ist selten ein fehlendes Feature. Chips liefern Readout-Schutz-Stufen, Fuse-Optionen und Lifecycle-Zustände, die Debug-Zugang abschließen. Das Problem ist der Übergang: Development-Einheiten mit offenem Zugang fließen in die Produktion, Test-Fixtures halten ungelockte Geräte, RMA-Prozesse öffnen wieder, was die Produktion geschlossen hat, und Lifecycle-Fuses, die beim finalen Test gebrannt werden sollten, werden übersprungen, wenn die Linie spät läuft.
Und selbst ein korrekt konfigurierter Lockdown hat Grenzen. Voltage-Fault-Injection hat Readout-Schutz auf weit verbreiteten MCU-Familien gebrochen. Ein Lockdown, der Schutz als absolut annimmt, ohne das Werkzeug-Set des physischen Angreifers zu betrachten, ist eine Design-Annahme, die darauf wartet, getestet zu werden.
Die Lockdown-Eigenschaft hängt von mehreren technischen Annahmen ab.
- Schnittstellen-Zustände Welche Debug-Schnittstellen (JTAG, SWD, UART, Trace) sind auf Produktionseinheiten offen, gelockt oder permanent gefust?
- Boot-Modi Welche alternativen Boot-Modi (ROM-Boot, USB-DFU, SD-Boot) existieren, und welche Policy gilt für sie?
- Readout-Schutz Mit welcher RDP-Stufe verschießen Produktionseinheiten, und was verhindert diese Stufe tatsächlich, einschließlich bekannter Glitching-Ergebnisse?
- Lifecycle-Konsistenz Verschießen Development-, Test-, RMA- und Produktionseinheiten mit derselben Lifecycle-Konfiguration, und lassen sich Zustände herunterstufen?
- Konsolen-Exposition Existiert eine UART-Konsole, was leakt sie beim Boot, und bietet sie nach dem Boot eine Shell?
- Debug-Authentisierung Wo Debug-Zugang für Service bleibt: Ist er authentisiert, rate-limited und an eine Rolle gebunden?
RDP-Stufe 2 im Datenblatt, Development-Lifecycle auf dem Gerät.
Das Security-Konzept spezifiziert gelockte Fuses und RDP-Stufe 2. Die Produktionslinie flasht die Firmware, überspringt aber den Fuse-Schritt für eine Charge, die im Rückstand ist. Die Geräte bestehen jeden Funktionstest und verschießen.
Ein Angreifer mit physischem Zugriff verbindet SWD und liest das komplette Firmware-Image, inklusive eingebetteter Keys und Credentials. Das Secure-Boot-Design war korrekt; der Lifecycle-Zustand hat es besiegt.
Den Lockdown so testen, wie ein physischer Angreifer es würde.
Wir inventarisieren die zugänglichen Schnittstellen und Boot-Modi an produktions-repräsentativen Einheiten, verifizieren die effektiven Schutz-Stufen und testen die Pfade von Debug-Zugang zu Memory, Code und Secrets, einschließlich Fault-Injection-Betrachtung, wo das Bedrohungsmodell es umfasst.
- Produkt wechselt von Development zu Produktion
- Neuer MCU oder SoC mit anderer Debug-Architektur
- RMA- oder Service-Prozess re-aktiviert Debug-Zugang
- Produktionslinien-Änderung oder Test-Fixture-Update
- Firmware oder Keys müssen gegen physische Extraktion geschützt werden
- Ein Gerät wurde physisch manipuliert, der Angriffspfad ist unklar