GlossarHardwareEmbedded

Debug-Schnittstellen (JTAG, SWD, UART)

JTAG, SWD und UART sind die Debug- und Konsolenschnittstellen fast jeder Embedded-Platine. Was sie Angreifern geben, wie du sie sperrst und was wir in Gerätetests finden.

Aktualisiert 7. Oktober 2026Diese Seite als Markdown

Kurz gesagt

Debug-Schnittstellen sind die Hardware-Ports, über die Entwickler einen Mikrocontroller oder SoC programmieren, debuggen und beobachten: JTAG (IEEE 1149.1), Arm SWD, herstellerspezifische Ports wie Infineon DAP und die serielle UART-Konsole. Im ausgelieferten Produkt offen gelassen, geben sie vollen Zugriff auf Speicher, Register und oft eine Root-Shell. Diese Ports zu sperren ist eine Grundanforderung der ETSI EN 303 645 und Standardpunkt in jedem Hardware-Penetrationstest.

Was sind Debug-Schnittstellen?

Debug-Schnittstellen sind die Ports, die ein Chip nach außen führt, damit Entwickler und die Fertigung ihn programmieren, Code schrittweise ausführen und seinen Zustand lesen können. Die gängigen:

JTAG (IEEE 1149.1) ist ein Test Access Port mit vier oder fünf Leitungen (TCK, TMS, TDI, TDO, optional TRST), ursprünglich für Boundary-Scan-Tests entworfen und von jeder großen CPU-Familie zum Debuggen und Flashen genutzt.
SWD (Serial Wire Debug) ist Arms Zweidraht-Variante (SWDIO, SWCLK) auf Cortex-M und vielen Cortex-A-Bausteinen, definiert in der Arm Debug Interface Specification.
Herstellerports wie Infineons DAP auf AURIX, die Debug-Schnittstellen von Renesas oder JTAG über USB beim ESP32 erfüllen denselben Zweck.
UART ist streng genommen keine Debug-Schnittstelle, sondern eine serielle Konsole. Auf Embedded-Linux-Geräten zeigt sie typischerweise den Bootloader-Prompt und ein Login oder eine Root-Shell; auf Mikrocontrollern trägt sie oft einen Kommandointerpreter oder ein Firmware-Update-Protokoll.

Über eine Debug-Schnittstelle hat ein Angreifer, was der Entwickler hatte: vollen Lese- und Schreibzugriff auf Speicher und Peripherie, Kontrolle über die Ausführung und die Möglichkeit, neuen Code zu flashen.

Wo ist es definiert?

JTAG ist in IEEE 1149.1 standardisiert; die Arm-Debug-Architektur in den Spezifikationen ADIv5 und ADIv6 zusammen mit der CoreSight-Dokumentation. Schutzmechanismen sind herstellerspezifisch: Readout-Protection-Level bei STM32, APPROTECT bei Nordic-Chips, eFuse-basiertes JTAG-Disable beim ESP32, passwortgeschütztes Debugging bei AURIX, Lifecycle-Zustände bei NXP-Prozessoren. Die Sicherheitsanforderung kommt aus Normen und Regulierung: ETSI EN 303 645 Provision 5.6-4 verlangt, dass physisch zugängliche Debug-Schnittstellen in Software deaktiviert sind; der OWASP IoT Security Testing Guide behandelt Debug-Schnittstellen als Testkategorie; UN R155 Anhang 5 nennt unautorisierten physischen Zugriff und Manipulation der Fahrzeugsoftware unter den zu behandelnden Bedrohungen.

Was es in der Praxis bedeutet

Offene oder schwach geschützte Debug-Schnittstellen sind das häufigste Einzelfinding in unseren Hardware-Tests, über Haushaltsgeräte, IoT-Module und Steuergeräte hinweg. Typische Muster: eine UART-Konsole, die ohne Passwort in eine Root-Shell fällt; ein SWD-Port, der in der Konfigurationsdatei “deaktiviert” ist, aber nie in den Fuses gesperrt wurde; Readout Protection Level 1 auf einem Mikrocontroller, bei dem ein dokumentierter Downgrade oder ein Spannungs-Glitch trotzdem Zugriff gibt; ein Fertigungstester-Modus, der über eine Diagnoseroutine erreichbar ist und JTAG wieder einschaltet.

In Tests von Haushalts- und Medizingeräten haben wir meist dieselben drei Schritte empfohlen: in der Fertigungslinie die eFuses brennen, die den Debug-Port sperren, die interaktive Konsole aus dem Serien-Image entfernen und eine signierte Debug-Firmware für den Service vorhalten. Beim Steuergerät ist das Äquivalent das HSM-verwaltete Debug-Passwort plus eine dokumentierte, authentifizierte Entsperrprozedur für die Werkstatt. Der Debug-Port ist außerdem der beste Weg zur Firmware-Extraktion, deshalb steht er im Testplan ganz vorn.

Häufige Missverständnisse

Debug-Schnittstellen sind nicht nur ein Problem für Geräte, die ein Angreifer kaufen kann. Ein einziger offener Port auf einem Gerät in Stückzahl gibt dem Angreifer die Firmware aller Geräte, und damit die Schlüssel und Schwachstellen, die für jede Einheit im Feld gelten. Und den Port zu sperren ist nicht dasselbe wie das Risiko zu beseitigen: Fault Injection und Angriffe auf Chipebene existieren, weshalb Schlüssel in einem Hardware-Sicherheitsmodul oder Secure Element liegen sollten statt im normalen Flash.

FAQ

Häufig gestellte Fragen

Muss ich Debug-Schnittstellen aus Seriengeräten entfernen?

Nicht entfernen, aber deaktivieren oder schützen. ETSI EN 303 645 Provision 5.6-4 sagt, dass physisch zugängliche Debug-Schnittstellen in Software deaktiviert sein müssen. Praktisch: den Auslese- und Debug-Schutz des Chips dauerhaft setzen (Fuses oder Option Bytes), Authentifizierung für den Debug-Zugang verlangen, wo der Chip das kann, und die UART-Konsole auf reine Log-Ausgabe reduzieren oder abschalten. Unbestückte Stiftleisten allein helfen nicht; die Pads sind trotzdem da.

Was kann ein Angreifer mit einem offenen JTAG-Port machen?

Die CPU anhalten, den gesamten Speicher inklusive Flash und RAM lesen und schreiben, Schlüssel auslesen, die gerade im RAM liegen, Breakpoints setzen, um Prüfungen wie einen PIN-Vergleich oder eine Signaturverifikation zu umgehen, und veränderte Firmware flashen. Mit offenem JTAG-Port ist die Softwaresicherheit des Geräts bedeutungslos.

Wie findet ihr Debug-Ports, wenn sie nicht beschriftet sind?

Sichtprüfung auf Testpads und Header, Durchgangsmessung zu den Chip-Pins aus dem Datenblatt, ein Logic Analyzer, um UART-Verkehr beim Booten zu erkennen, und ein JTAG-Pinfinder, der Pinkombinationen durchprobiert. Bei Gehäusen wie BGA nutzen wir die Herstellerdokumentation und bei Bedarf Röntgen oder Lageninspektion. Den Port zu finden ist meist eine Sache von Stunden.

Quellen

Passende Seiten

← Glossar