ECU-Penetrationstests, bedrohungsgeleitet aus der TARA.

1. Ein Penetrationstest ist kein Schwachstellen-Scan

Das Erste, was wir einem neuen Programm sagen, ist zugleich das, was niemand hören will: Der bereits bezahlte Schwachstellen-Scan hat genau die Angriffe nicht getestet, auf die es ankommt. Ein Scanner ist werkzeuggeleitet. Er arbeitet einen Katalog ab — offene Dienste, bekannte CVEs, Standardpasswörter, schwache TLS-Cipher — und meldet Abweichungen davon. Für die IT-artige Angriffsfläche eines Konnektivitäts-Gateways oder eines Infotainment-Linux ist das durchaus nützlich, und solche Scans führen wir ebenfalls durch. Doch ein automotive Steuergerät ist kein Webserver, und die Angriffe, die es kompromittieren, tauchen fast nie in einem CVE-Feed auf.

Nehmen wir ein Seed-Key-Verfahren in UDS SecurityAccess, bei dem der „zufällige“ Seed aus einem frei laufenden Timer abgeleitet wird, der bei jedem Aufwachen zurückgesetzt wird. Kein Scanner schlägt an — der Dienst antwortet korrekt, der Algorithmus ist „proprietär“, die Firmware hat kein öffentliches CVE. Doch ein Angreifer, der einige wenige Seed/Key-Paare aufzeichnet und bemerkt, dass der Seed nach einem Power-Cycle nie weit von null abweicht, erreicht die Programmiersitzung in Minuten. Das ist der interessante Angriff, und er bleibt einem Werkzeug verborgen, das das System nicht aus der Perspektive eines Angreifers durchdenkt.

Penetrationstests sind bedrohungsgeleitet. Wir beginnen bei dem, was ein Angreifer erreichen will — den Motor ohne Schlüssel starten, unsignierte Firmware flashen, eine Momentenanforderung auf dem Bus fälschen, einen Langzeitschlüssel exfiltrieren —, und arbeiten rückwärts zu den konkreten Schritten, die das auf diesem Steuergerät erreichen würden: mit seinen realen Steckern, seinem realen Diagnose-Stack, seiner realen Boot-Kette. Nach unserer Erfahrung würde rund die Hälfte der schwerwiegendsten Findings, die wir berichten, in einem automatisierten Scan nie auftauchen, weil sie in Design-Annahmen stecken, nicht in Software-Versionen.

2. Der Umfang ergibt sich aus der TARA (ISO/SAE 21434 Kapitel 15)

Bedrohungsgeleitet bedeutet nur dann etwas, wenn die Bedrohungen dokumentiert sind — und in der Automobilwelt sind sie das: ISO/SAE 21434 Kapitel 15 definiert die Threat Analysis and Risk Assessment (TARA). Eine gute TARA ist der beste Testplan, den man einem Pentester in die Hand geben kann; eine schwache ist das erste Finding, das wir berichten.

Die Kette aus Kapitel 15 liefert uns genau das, was wir zur Umfangsbestimmung brauchen. Die Asset-Identifikation sagt uns, was schützenswerte Cybersecurity-Eigenschaften besitzt — die Integrität einer Kalibrierungstabelle, die Vertraulichkeit eines Wegfahrsperren-Geheimnisses, die Authentizität eines Sicherheits-Aktuatorbefehls. Threat Scenarios und Damage Scenarios verbinden jedes Asset damit, was schiefgeht, wenn seine Sicherheitseigenschaft verletzt wird, und wie schwerwiegend. Die Attack-Path-Analyse zählt die Wege auf, die ein Angreifer nehmen könnte, und das Attack-Feasibility-Rating — ob über den Attack-Potential-Ansatz (benötigte Zeit, Fachwissen, Wissen über das Item, Gelegenheitsfenster, Ausrüstung), CVSS-basiert oder Attack-Vector-basiert — bewertet, wie realistisch jeder Pfad ist.

Dieses Feasibility-Rating bestimmt, wohin der Aufwand fließt. Ein als hoch durchführbar bewerteter Pfad gegen ein Asset mit hohem Schadenspotenzial erhält unser tiefstes, hartnäckigstes Testen — daran sitzen wir tagelang. Ein als gering durchführbar bewerteter Pfad (entfernt, exotische Ausrüstung, schmales Fenster) erhält dennoch eine Plausibilitätsprüfung, denn Feasibility-Ratings sind Schätzungen, und es gehört zu unserer Aufgabe, sie zu widerlegen. Wenn unser Prüfstandsergebnis der TARA widerspricht — ein als „gering“ bewerteter Pfad, den wir an einem Nachmittag gehen —, ist das eines der wertvollsten Ergebnisse eines Pentests, weil es direkt in die Risikobehandlungsentscheidung zurückfließt.

3. Die reale Angriffsfläche eines modernen Steuergeräts

Bevor wir ein Werkzeug anfassen, kartieren wir die physische und logische Angriffsfläche, denn ein Steuergerät bietet weit mehr davon, als das Datenblatt nahelegt. Wir betrachten:

• Debug- und Trace-Schnittstellen — JTAG, SWD und herstellereigene Debug-Ports. Wir prüfen, ob diese im Serien-Silizium tatsächlich gefust oder gesperrt oder nur per Software „deaktiviert“ sind, ob Testpunkte auf der Leiterplatte verbleiben und ob ein Debug-Authentifizierungsverfahren herabgestuft oder umgangen werden kann. Ein offener Debug-Port bedeutet das Ende jeder Vertraulichkeit.
• UDS-Diagnose über CAN, CAN-FD und Automotive Ethernet (DoIP, ISO 13400). Der Diagnose-Stack ist die reichhaltigste legitime Schnittstelle in ein Steuergerät und damit die reichhaltigste Angriffsfläche — Sitzungen, Security Access, Routinen, Speicherlesen und -schreiben sowie Data Identifier liegen alle hier.
• Bootloader und Secure-Flashing-Pfad — wie das Steuergerät neue Software empfängt, verifiziert und aktiviert, einschließlich primärem Bootloader, etwaigem sekundärem oder Programmier-Bootloader sowie der Signatur- und Versionsprüfungen darum herum.
• Fahrzeuginterne Netze — die Busse, die das Steuergerät mit anderen teilt. Wir bewerten, was ein kompromittierter oder vorgetäuschter Nachbar einspeisen kann, ob Nachrichtenauthentisierung (SecOC) vorhanden und durchgesetzt ist und was an Gateway-Grenzen geschieht.
• Drahtlose und begleitende Schnittstellen — wo vorhanden, BLE, Wi-Fi, UWB, NFC sowie jeder Companion-App- oder Backend-Kanal, samt der dahinterliegenden Provisionierungs- und Pairing-Abläufe.

Sinn der Karte ist nicht Vollständigkeit um ihrer selbst willen; sie dient dazu, die TARA-Angriffspfade auf reale, physische Eintrittspunkte zu legen, damit der Testaufwand dort landet, wo es sowohl das Bedrohungsmodell als auch die Hardware verlangen.

4. Methodik — NIST SP 800-115, angepasst an den Prüfstand

Wir arbeiten nach den vier Phasen von NIST SP 800-115 — Planning, Discovery, Attack und Reporting —, weil die Struktur tragfähig ist und Auditoren sie wiedererkennen. Was sich ändert, ist der embedded-automotive Kontext, der jede Phase füllt.

In der Planning-Phase vereinbaren wir die Rules of Engagement, das Testobjekt (Muster-Steuergeräte, Bench-Harness, Fahrzeug oder HIL-Rig), die erhaltenen Zugangsdaten und Unterlagen (Black-, Grey- oder White-Box) und — entscheidend — übersetzen die TARA-Threat-Scenarios in konkrete Missbrauchsfälle: „Ein Angreifer am Diagnosestecker erreicht die Programmiersitzung und flasht veränderte Kalibrierdaten“ ist auf eine Weise testbar, wie es „Integritätsbedrohung der Kalibrierdaten“ nicht ist.

In der Discovery-Phase enumerieren wir die Angriffsfläche real — welche UDS-Dienste und Sitzungen antworten, welche DIDs und Routinen existieren, wie Boot- und Speicher-Map aussehen, was die Debug-Ports zulassen. Grey- oder White-Box-Zugang (A2L- und ODX-Beschreibungen, Schaltpläne, Quellcode) macht dies schneller und tiefer, weshalb wir ihn für alles empfehlen, was auf eine Typgenehmigung zuläuft.

In der Attack-Phase führen wir die Missbrauchsfälle aus und verketten Primitive so, wie es ein echter Angreifer täte: hier ein Downgrade, dort eine wiedereingespielte Nachricht, ein per Brute Force erratener Seed, um eine Routine freizuschalten, die dann Speicher offenlegt. In der Reporting-Phase wird jedes Finding mit reproduzierbaren Nachweisen und einem Behebungspfad geliefert. Die Phasen sind iterativ, nicht linear — eine Entdeckung in der Attack-Phase schickt uns regelmäßig zurück, um mehr zu enumerieren.

5. Diagnose-Sicherheitstests — UDS

Im UDS-Stack verbringen wir einen großen Teil der Prüfstandszeit, denn er ist die bequemste Vordertür des Angreifers. Unsere Arbeit konzentriert sich auf eine Handvoll Dienste.

SecurityAccess (0x27) ist der Hauptschauplatz. Wir bewerten den gesamten Seed-Key-Lebenszyklus: Entropie — ist der Seed wirklich unvorhersehbar oder aus einem Timer, Zähler oder einer Konstante abgeleitet, die ein Angreifer modellieren kann? Brute-Force-Widerstand — ist der Schlüsselraum groß genug, und erzwingt das Steuergerät eine Verzögerung sowie ein hartes Versuchslimit, sodass eine erschöpfende Suche undurchführbar ist? Replay — entsperrt ein in einer Sitzung erfasster Key eine spätere, ist der Seed also tatsächlich pro Anfrage frisch? Wir haben alle drei scheitern sehen: effektive 16-Bit-Schlüsselräume, kein Versuchszähler, sodass ein Skript ungehindert durchläuft, und Seeds, die sich nach einem Power-Cycle wiederholen. Gutes Seed-Key-Design verwendet einen kryptografisch starken Seed, einen mit einem echten Algorithmus und einem geräteindividuellen Geheimnis (nicht einer flottenweiten Konstante) abgeleiteten Key, eine strikt durchgesetzte Verzögerung und Sperre bei Fehlversuchen, die einen Reset überdauert, sowie Schutzstufen, die sinnvolle Privilegien sinnvollen Sitzungen zuordnen.

Authentication (0x29) — den für stärkere Diagnoseauthentisierung eingeführten Zertifikats- und Challenge-Response-Dienst — prüfen wir auf korrekte Zertifikatsketten-Validierung, Challenge-Frische und darauf, ob er zugunsten eines schwächeren Legacy-0x27-Pfads übersprungen werden kann.

DiagnosticSessionControl (0x10) ist der Türsteher zu den Extended- und Programming-Sitzungen. Wir prüfen, ob diese privilegierten Sitzungen ohne den eigentlich erforderlichen Security Access betreten werden können, ob der Sitzungszustand konsistent durchgesetzt wird und ob Timeouts und die S3-Keep-Alive-Behandlung missbraucht werden können, um eine privilegierte Sitzung offen zu halten.

RoutineControl (0x31) legt die internen Aktionen des Steuergeräts offen — Löschen, Selbsttest, Kalibrierschreibvorgänge, Schlüsseloperationen. Wir suchen nach Routinen, die sensible Operationen hinter unzureichender Sitzungs- oder Sicherheitsprüfung ausführen, ungeprüfte Parameter akzeptieren oder in einem unsicheren Fahrzeugzustand ausgelöst werden können.

6. Secure Boot & SecOC

Sind die Diagnosedienste die Vordertür, so ist die Boot-Kette das Fundament — und SecOC ist die Integrität von allem, was auf dem Bus gesprochen wird. Beides verdient angreiferische Aufmerksamkeit.

Beim Secure Boot verifizieren wir die Vertrauenskette von Anfang bis Ende: Vermisst und authentifiziert die unveränderliche Wurzel tatsächlich die nächste Stufe, authentifiziert jede Stufe die nächste, und ist die Signaturprüfung echt — und nicht ein Rückgabewert, der erzwungen werden kann? Die häufigsten substanziellen Lücken finden wir rund um die Versionierung. Downgrade- und Anti-Rollback-Schwächen erlauben es einem Angreifer, ein älteres, gültig signiertes Image zu installieren, dessen Schwachstellen inzwischen behoben wurden — die Signatur stimmt, aber die Versionsmonotonie nicht, sodass der Fix rückgängig gemacht wird. Wir bestätigen, dass ein Rollback-Schutz existiert, vor der Aktivierung durchgesetzt wird und nicht zurückgesetzt werden kann.

Bei SecOC (Secure Onboard Communication, dem AUTOSAR-Mechanismus) betrachten wir Frische und Schlüsselhandhabung. Der Replay-Schutz beruht auf einem Freshness-Value, auf den sich beide Seiten einigen; wir testen, was passiert, wenn die Frische desynchronisiert ist, wenn eine Nachricht innerhalb des Verifizierungsfensters wiedereingespielt wird und ob verkürzte MACs noch genügend Stärke lassen. Wir untersuchen außerdem, wie SecOC-Schlüssel gespeichert und verteilt werden, denn ein perfektes Protokoll mit einem rückgewinnbaren Schlüssel schützt nichts.

Eine Angriffsklasse gehört hier auf konzeptioneller Ebene her: Fault Injection und Glitching — das Stören von Spannung, Takt oder elektromagnetischer Umgebung, um einen Prozessor eine Instruktion wie einen Signaturvergleich überspringen zu lassen. Wir bewerten, ob ein Ziel dieser Klasse ausgesetzt ist und ob Gegenmaßnahmen (redundante Prüfungen, randomisiertes Timing, Sensoren) vorhanden sind. Wir veröffentlichen keine Glitch-Parameter oder Rezepte; das Ergebnis ist, ob der Schutz hält — nicht eine Anleitung.

7. Schlüsselmanagement & HSM/SHE

Jeder oben genannte Schutz — Secure Boot, SecOC, Diagnoseauthentisierung, Wegfahrsperre — ruht letztlich auf Schlüsseln, also folgen wir den Schlüsseln. Die Fragen zielen bewusst auf Design und Exposition, nicht auf das Extrahieren von Geheimnissen um ihrer selbst willen.

Wo liegen die Schlüssel? Ein Hardware Security Module (HSM) oder SHE (Secure Hardware Extension) existiert genau deshalb, damit Schlüsselmaterial nie im adressierbaren Anwendungsspeicher erscheint. Wir prüfen, ob das tatsächlich der Fall ist — dass Signieren und Verifizieren innerhalb der sicheren Peripherie geschehen, dass Schlüssel nicht im RAM zwischengelagert oder im Trace protokolliert werden und dass die Grenze zwischen Anwendungskern und Sicherheits-Subsystem respektiert wird.

Wie werden Schlüssel provisioniert? Die Provisionierung ist ein wiederkehrender Schwachpunkt: flottenweit geteilte Schlüssel, die ein einziges rückgewonnenes Gerät zum Generalschlüssel für alle machen; Debug- oder Testschlüssel, die in die Serie überdauern; vorhersehbare Schlüsselableitung aus öffentlichen Identifikatoren. Wir untersuchen den Provisionierungs- und Personalisierungsablauf auf diese Muster.

Was setzt die Schlüsselhierarchie voraus? Wir kartieren, welcher Schlüssel welches Asset schützt, ob die Kompromittierung eines Schlüssels eingegrenzt ist oder kaskadiert und ob Schlüsselaktualisierung und -widerruf im Feld überhaupt möglich sind. Durchgängig ist unser Rahmen die Verifikation — wir weisen nach, dass ein Schutz tragfähig oder eine Annahme falsch ist, ohne rückgewonnenes Material zu einer Waffe zu machen.

8. Vom Finding zur Behebung

Ein Finding, mit dem niemand etwas anfangen kann, ist verschwendete Prüfstandszeit, deshalb ist jedes von uns gemeldete Problem so aufbereitet, dass es behoben werden kann. Drei Dinge machen das möglich.

Reproduzierbarer Nachweis. Jedes Finding wird mit den genauen Schritten, den Bus-Traces oder Captures, dem Werkzeug-Zustand und den zur Reproduktion nötigen Bedingungen geliefert. Ein Entwicklungsteam sollte unser Ergebnis ohne uns im Raum nachstellen können — und der Retest ebenso.

Schweregrad, der in zwei Sprachen etwas bedeutet. Wir bewerten jedes Finding mit CVSS für eine vertraute branchenübergreifende Zahl und daneben mit der Attack Feasibility nach ISO/SAE 21434, damit das Ergebnis die Sprache des Cybersecurity Case spricht. Ein Finding kann CVSS-hoch, aber Feasibility-gering sein oder umgekehrt; beides zu berichten verhindert, dass eine einzelne Zahl die Arbeit falsch einordnet.

Ursache, nicht nur Symptom. Weil wir diese Stacks auch selbst bauen — Bootloader, Diagnose- und Sicherheitssoftware, AUTOSAR-Integration —, weisen unsere Findings tendenziell auf die zugrunde liegende Ursache statt auf die Oberfläche. „0x27 ist per Brute Force angreifbar“ ist ein Symptom; „der Verzögerungstimer wird vom selben Aufwachvorgang zurückgesetzt, der neu seedet, sodass die Sperre nie auflaufen kann“ ist eine Ursache, die ein Entwickler einmal beheben kann. Anschließend priorisieren wir die Behebung nach Risiko, und wir testen nach — ein nicht nachgetesteter Fix ist eine Hoffnung, kein Ergebnis. Für die Engineering-Seite dieser Schleife siehe unsere Arbeit zu Software Engineering und funktionaler Sicherheit, da Security- und Safety-Fehler zunehmend dieselben Ursachen teilen.

9. Wie Pentest-Nachweise in die UNECE R155 einfließen

Nichts davon ist Testen um des Testens willen. Unter der UNECE R155 erfordert die Typgenehmigung ein Cybersecurity Management System und, je Fahrzeugtyp, den Nachweis, dass die identifizierten Risiken behandelt und die umgesetzten Maßnahmen verifiziert wurden — nicht bloß entworfen. Penetrationstests sind eine der stärksten Formen dieser Verifikation, weil sie vorführen statt behaupten.

Konkret schließt der Pentest die von der TARA eröffnete Schleife. Die TARA behauptete, bestimmte Angriffspfade seien auf eine akzeptable Durchführbarkeit behandelt; der Pentest liefert den unabhängigen Nachweis, dass die Maßnahmen tatsächlich halten — oder benennt genau, wo nicht, sodass die Lücke vor der Genehmigung geschlossen werden kann statt nach einem Rückruf entdeckt zu werden. Findings, Schweregrade, Behebung und Retest-Ergebnisse werden zu nachverfolgbaren Artefakten im Cybersecurity Case und in der Typgenehmigungs-Nachweisakte, zurückgebunden an genau die Damage- und Threat-Scenarios, die sie umrissen haben. Diese Nachverfolgbarkeit — Threat Scenario zu Attack Path zu Test zu Nachweis zu Fix — verwandelt einen Stapel Testberichte in eine genehmigungsfähige Argumentation.

Genau deshalb führen wir den Pentest bedrohungsgeleitet aus Kapitel 15 durch und nicht als losgelöste Übung: Nachweise, die auf die Risikobewertung abbilden, sind Nachweise, denen ein Prüfer folgen kann — und Nachweise, denen ein Prüfer folgen kann, sind der Unterschied zwischen einer sauberen Typgenehmigungseinreichung und einer Runde von Findings. Wie sich dies in das größere regulatorische Bild fügt, zeigen unsere Cybersecurity-Leistungen und das ECU-Penetrationstesting hinter dieser Methode, neben unserem Begleitbeitrag zu Embedded Cybersecurity unter der UNECE R155.

---

Möchten Sie einen 30-minütigen Walkthrough zu Ihrem Projekt?

Keine NDA nötig. Sagen Sie uns die Norm, das Item bzw. Asset, den Assessor und Ihre Deadline. Innerhalb von 48 Stunden erhalten Sie eine einseitige Diagnose, abgebildet auf die obigen Punkte — Ihre, ob Sie uns beauftragen oder nicht.

Cyber-Walkthrough buchen →

---

Autor: Adrian Valea, Gründer & Geschäftsführer, SafetyTrust Software Technology GmbH. ASPICE Provisional Assessor (intacs / VDA), Functional Safety Engineer (TÜV Rheinland), Automotive Cybersecurity (TÜV NORD). Veröffentlicht 2026-06-04.