Wir greifen Ihr Steuergerät so an, wie es ein echter Angreifer täte — bevor es einer tut.

Was wir testen

Ein Steuergerät ist nicht eine Angriffsfläche; es ist ein gestufter Satz davon. Wir leiten den Umfang jedes Engagements aus dem Bedrohungsmodell ab statt aus einer festen Checkliste und gehen dort in die Tiefe, wo das Risiko liegt. Über ein Engagement hinweg bearbeiten wir die folgenden Flächen — und die interessanten Befunde liegen fast immer in den Nahtstellen dazwischen.

Diagnose & Authentifizierung (UDS — ISO 14229)

Der häufigste Einstiegspunkt im Serienstand. Das Steuergerät beantwortet jede Anfrage; die Frage ist, wer fragen darf.

• SecurityAccess (0x27) — Seed-Entropie und -Wiederverwendung, Schlüsselstärke und Extrahierbarkeit, Lockout-/Back-off-Durchsetzung über Resets und Sessionwechsel hinweg, Brute-Force-Resistenz.
• Authentication (0x29, ISO 14229-1:2020) — zertifikatsbasierte Abläufe: Geltungsbereich des Trust-Anchors, Nonce-/Freshness-Behandlung, Revocation und stiller Rückfall auf ein schwächeres 0x27-Schema.
• DiagnosticSessionControl (0x10) — ob die entsperrte Ebene die Dienste, die sie beansprucht, tatsächlich absichert, und ob sie bei S3-Timeout / ECUReset / Sessionwechsel wieder sperrt.
• SecOC — Behandlung des Freshness-Werts, MAC-Verkürzung und Replay-Fenster bei geschützten Botschaften und den Routinen, die die Diagnose auslöst.
• Typischer Befund: ein geschützter Dienst, der am Prüfstand über einen unbehandelten Zustandsübergang erreichbar ist — keine gebrochene Chiffre.

Secure Boot & Integrität der Boot-Kette

Ein signierter Bootloader ist noch keine sichere Boot-Kette. Die Kette ist nur so stark wie das Glied, das Sie nicht verifiziert haben.

• Signatur-/Integritätsprüfung in jeder Stufe; Akzeptanz von Teilimages; Signature Confusion; Time-of-Check-/Time-of-Use-Lücken.
• Rollback-/Anti-Downgrade-Schutz, den ein Angreifer nicht abstreifen kann; die Reaktion auf eine fehlgeschlagene Prüfung (Halt, Degradation oder — der Befund, den Sie nicht wollen — Weiterlaufen).
• Signalisierung des Boot-Status und Exfiltration über Seitenkanal; Debug-Wiedereintritt in eine verifizierte Kette.

HSM / SHE & kryptografisches Material

Gute Kryptografie versagt leise an der Grenze, nicht im Algorithmus.

• Sichere Schlüsselspeicherung, Sicherheit von Key-Update / Updater, Trennung von Debug- und Produktiv-Schlüsselmaterial.
• Ob die Applikationsseite die HSM/SHE-Grenze tatsächlich respektiert und ob Schlüsselmaterial nach der Rotation im NVM überlebt.

Secure Flashing, NVM & Anti-Downgrade

• Lösch- und Re-Key-Verhalten des Daten-Flash nach dem Flashen; Atomarität der Nachverarbeitung; Rückstände bei Abbruch mitten im Flashen.
• Monotone Anti-Downgrade-Zähler, Ende-zu-Ende verifiziert (Write-Once / HSM-geschützt), nicht ein Versionsfeld, das niemand durchsetzt.
• NVM-Auslesung und Exfiltration gegen Diagnose- und Debug-Pfade abgesichert (UDS ReadMemoryByAddress, XCP, DAP).

Hardware-Schnittstellen & Debug-Ports

• JTAG/SWD, UART, SPI und Test-Pads, die es in die Serie geschafft haben — ob Debug-Sperren im Produktionszustand tatsächlich gefused und aktiv sind oder nur angenommen werden.
• Versuche der Firmware-Extraktion über exponierte Schnittstellen; Boot-Log- und Shell-Exposition auf der UART.

Bordnetz-Kommunikation

• CAN / CAN-FD und Automotive Ethernet: Botschaftsinjektion, Spoofing, MITM-Positionierung und strukturiertes Fuzzing von Diagnose- und Applikationsverkehr.
• Befunde auf die betroffene Funktion und ihr Sicherheitsziel abgebildet — nicht als rohes Buslärm-Rauschen berichtet.

Sichere Software-Architektur & TEE

• Partitions-/Privileg-Isolation, Trennung sicherheitsrelevanter Partitionen vom Kommunikationsstack, gefährliche APIs, die untrusted Partitionen exponiert werden, MPU-Konfiguration.
• Trusted Execution Environment: Versuche, kryptografische Daten über die Grenze hinweg zu lesen/ersetzen.

Seitenkanal & Fault Injection

• Timing- und MAC-Vergleichs-Seitenkanäle in Software; Leakage der Schlüsselableitung bei der CMAC/AES-Verifikation.
• Voltage-/Clock-Glitching und physische Manipulationsresistenz, bewertet gegen die ausgewiesenen Sicherheitsziele des Steuergeräts.

Lifecycle & ECU-Zustandsmaschine

• Development- vs. Production-Zustand, der Kunden-Umschaltvorgang, der das Teil verriegelt, und die Integrität der Security-Flags über Lifecycle-Übergänge hinweg.
• Ein Gerät, das ausgeliefert wird und noch in einem Development-Zustand erreichbar ist, ist ein Befund — unabhängig davon, wie stark seine Kryptografie ist.

Wie wir ein Engagement durchführen

Risikogetrieben und prozessdiszipliniert, damit das Ergebnis von Ihrem Cybersecurity-Team und Ihrem Assessor prüfbar ist — keine Liste dessen, was wir zufällig ausprobiert haben.

1. Umfang aus dem Bedrohungsmodell. Wir starten von Ihrer TARA (oder erstellen eine fokussierte). Damage-Szenarien, Bedrohungsszenarien und Angriffsmachbarkeits-Bewertungen entscheiden, wohin der Aufwand fließt; jedes Testziel wird auf ein Asset und ein Sicherheitsziel zurückgeführt.
2. Aufwand nach CAL stufen. Testtiefe und der unterstellte Angreifer werden durch das Cybersecurity Assurance Level festgelegt, abgestimmt vor dem Start (siehe Tabelle unten).
3. Ausführung nach NIST SP 800-115. Planung → Discovery → Attack → Reporting. Jeder Befund wird als reproduzierbarer Testvektor festgehalten: Aufbau, Schritte, beobachtetes Ergebnis, Nachweis.
4. In Runden testen. Erst-Test, Ihre Behebung, dann ein Re-Test, der bestätigt, dass die Korrektur den Befund geschlossen und ihn nicht an eine andere Stelle verschoben hat. Regression auf frühere Befunde ist Teil jeder späteren Runde.
5. Reporting in Mitigation-Qualität. Impact, Angriffsmachbarkeit, das zurückverfolgte Asset/Ziel, ein reproduzierbarer Vektor und eine konkrete Behebung mit Verifikationskriterium für den Re-Test.

CAL-gestufter Aufwand

Assurance Level	Unterstellter Angreifer	Zuschnitt des Engagements
CAL2	Begrenzte Zeit & Werkzeuge; benachbarter/lokaler Zugriff	Fokussierter Umfang, eine Runde auf den risikoreichsten Pfaden
CAL3	Versiert, ausgestattet, Zeit am Ziel; Kenntnis des Items	Breiter Umfang, zwei Runden über ein mehrwöchiges Fenster, invasive Techniken im Spiel
CAL4	Experte, gut finanziert, spezialisierte Ausrüstung	Tiefes Mehrrunden-Programm; fortgeschrittene Hardware-Angriffe explizit im Umfang

Das CAL spiegelt die Rigorosität wider, die ISO/SAE 21434 von Cybersecurity-Aktivitäten erwartet; wir nutzen es, um Angreifermodell und Testtiefe zu dimensionieren, im Vorfeld mit Ihnen abgestimmt.

Was Sie erhalten

Einen Bericht, auf den Ihre Ingenieure reagieren können und den Ihr Assessor lesen kann. Pro Befund:

• Das betroffene Asset und Sicherheitsziel sowie das dahinterstehende Damage-Szenario.
• Angriffsmachbarkeits-Bewertung und eine begründete Schwere — ohne Aufblähung.
• Einen reproduzierbaren Testvektor: exakter Aufbau, Schritte, beobachtetes Ergebnis, Nachweis — damit Sie (oder wir, in einer späteren Runde) ihn präzise reproduzieren.
• Eine konkrete Behebung mit Verifikationskriterium für den Re-Test.

Dazu eine Management-Zusammenfassung, die das Restrisiko so formuliert, dass ein Cybersecurity-Manager es in eine Freigabeentscheidung tragen kann, und ein wöchentlicher Status während des Engagements — was getestet wurde, was gefunden wurde, was blockiert ist, was als Nächstes kommt. Der Bericht ist so strukturiert, dass er als Nachweis in Ihrer ISO/SAE-21434-Verifikation und in Ihrer UNECE-R155-Typgenehmigungsakte dienen kann.

Häufig gefragt

Was ändert sich bei einem höheren CAL (z. B. CAL3)?

Ein stärker unterstellter Angreifer — mehr Zeit, Expertise, Ausrüstung und Vorwissen — was die in den Umfang fallenden Angriffspfade erweitert und wie weit jeder getrieben wird, typischerweise über zwei Runden statt eines einzelnen Durchgangs.

Black-, Grey- oder White-Box?

Alle drei. Grey- und White-Box (mit der TARA, den Schnittstellenspezifikationen und idealerweise Quellcode/Design) finden pro Tag deutlich mehr, weil der Aufwand in echte Angriffspfade fließt statt in das Wieder-Entdecken der Architektur.

Können Sie als zugelassenes Labor in einem OEM-Programm tätig sein?

Ja. Wir unterstützen das Lieferanten-Onboarding und den Labor-Freigabeprozess des OEM und stellen das Labor, die Methodik und die Tester-Dokumentation bereit, die eine OEM-Cybersecurity-Stelle zur Freigabe eines Testpartners verlangt.

Was benötigen Sie, um zu starten?

Ein DUT auf einem produktionsnahen Software-Stand, das Bedrohungsmodell / die TARA, Schnittstellen- und Diagnosespezifikationen sowie einen abgestimmten Umfang mit expliziten In- und Out-of-Scope-Punkten.

Warum STS

Wir greifen Steuergeräte von innen heraus an, weil wir die Stacks bauen, die wir angreifen — sichere Diagnosedienste, Secure Boot, HSM/SHE-Integration und Secure Flashing auf produktiven Automotive-MCUs. Diese Sicht des Entwicklers ist der Grund, warum unsere Befunde auf die Grundursache und die Korrektur zeigen, nicht nur auf das Symptom. Und weil wir zuerst Ingenieure sind, endet das Engagement nicht bei einer Liste von Problemen: Sie erhalten die Behebung und den Re-Test, der nachweist, dass sie geschlossen wurde.

Geleitet von Adrian Valea — Automotive Cybersecurity (TÜV NORD), 25 Jahre Automotive-Embedded-Engineering über OEM- und Tier-1-Programme hinweg, mit einer Delivery-Präsenz in Deutschland, Rumänien, Indien und China.