Kann mein Auto gehackt werden? Was die Logs im Fahrzeug verraten

Die kurze Antwort: technisch ja, praktisch mit hohen Hürden

Ja, ein modernes Auto lässt sich technisch angreifen. Es besteht aus mehreren Dutzend vernetzten Steuergeräten, mehreren Funkschnittstellen und einer wachsenden Menge an Software, und jede dieser Komponenten ist grundsätzlich eine mögliche Angriffsfläche. Das ist die technische Wahrheit hinter der Frage. Die praktische Wahrheit sieht anders aus: Zwischen einem theoretischen Angriffspunkt und einem tatsächlich erfolgreichen Zugriff liegen mehrere unabhängige Schutzebenen, die alle gleichzeitig überwunden werden müssten.

Genau diese Lücke zwischen „technisch möglich“ und „praktisch wahrscheinlich“ wird in Alltagsgesprächen oft übersprungen. Ein Fahrzeug ist kein einzelner Computer mit einer einzigen Firewall, sondern ein System aus vielen kleinen, teils redundanten Schutzmechanismen. Wie stark dieses System im Einzelfall wirklich ist, hängt vom Fahrzeug, vom Softwarestand und von der jeweiligen Schnittstelle ab. Eine pauschale Antwort „sicher“ oder „unsicher“ wird diesem gestuften Bild nicht gerecht.

Ein hilfreicher Vergleich ist ein modernes Bürogebäude mit mehreren Sicherheitsstufen: ein Empfang, eine Zugangskarte für bestimmte Etagen, ein separater Tresorraum mit eigenem Schloss. Ein Eindringling, der die Eingangstür überwindet, steht damit noch lange nicht im Tresorraum. Bei einem Fahrzeug ist es ähnlich gestaffelt. Ein Zugriff auf eine wenig kritische Komfortfunktion bedeutet nicht automatisch einen Zugriff auf Lenkung, Bremse oder Antrieb, weil diese Funktionen in eigenen, stärker abgeschotteten Bereichen liegen.

Was ein modernes Auto heute überhaupt angreifbar macht

Vor zwanzig Jahren bestand ein Fahrzeug im Wesentlichen aus mechanischen und elektrischen Systemen mit wenig Software. Heute übernimmt Software Funktionen von der Motorsteuerung bis zum Infotainment, und viele dieser Funktionen kommunizieren über gemeinsame Netzwerke miteinander. Genau diese Vernetzung ist der Grund für die Angreifbarkeit: Ein Funkweg, eine Ladebuchse, eine Diagnoseschnittstelle oder eine App-Anbindung sind mögliche Einstiegspunkte, über die im schlechtesten Fall auch andere, eigentlich unbeteiligte Systeme erreichbar würden.

Diese Vernetzung ist kein Konstruktionsfehler, sondern eine bewusste Entscheidung. Sie ermöglicht Funktionen wie Fernzugriff, Software-Updates über die Luftschnittstelle oder eine vorausschauende Fahrassistenz, die ohne Vernetzung gar nicht möglich wären. Der Preis dafür ist eine größere Angriffsfläche als bei einem rein mechanischen Fahrzeug. Hersteller begegnen dem nicht mit einer einzelnen Maßnahme, sondern mit mehreren, voneinander unabhängigen Schutzschichten – genau darum geht es im nächsten Abschnitt. Auch die Netzwerkarchitektur selbst, ob Domäne oder Zone, beeinflusst mit, wie weit ein einzelner Einstiegspunkt im Fahrzeug überhaupt reicht.

Vier Schutzebenen: Secure Gateway, Secure Boot, HSM und SecOC

Ein Secure Gateway entscheidet, welche Zugriffswege und Rollen im Fahrzeugnetzwerk überhaupt erlaubt sind. Es trennt kritische Bereiche von weniger kritischen und verhindert, dass ein Zugriff über eine unkritische Schnittstelle automatisch auch kritische Systeme erreicht. Secure Boot prüft dagegen beim Start eines Steuergeräts eine Vertrauenskette: Nur signierte, unveränderte Software darf überhaupt anlaufen. Ein manipuliertes Programm würde diese Prüfung nicht bestehen und das Steuergerät gar nicht erst starten.

Ein Hardware-Sicherheitsmodul, kurz HSM, ist ein eigener, abgeschotteter Chip-Bereich für kryptografische Operationen und Schlüsselmaterial. Es hält Geheimnisse getrennt vom übrigen Steuergerät, selbst wenn dessen Software kompromittiert wäre. Und SecOC schützt ausgewählte Kommunikationsobjekte auf dem Bus gegen Manipulation und Wiederholung, ohne die gesamte Kommunikation zu verschlüsseln. Vier verschiedene Mechanismen, vier verschiedene Aufgaben – wer sie gleichsetzt, erzeugt Diagnosemythen, denn eine fehlende Autorisierung ist etwas anderes als ein physisch gestörter Bus. Eine UDS-Diagnoseverbindung über DoIP oder CAN läuft dabei durch mehrere dieser Ebenen hindurch, und ein Fehlschlag kann an jeder einzelnen davon entstehen.

Was ein Security-Log tatsächlich mitschreibt

Ein Security-Log im Fahrzeug ist im Kern eine Zeitreihe von Ereignissen. Ein brauchbarer Eintrag enthält mindestens einen Zeitstempel, die Identität des betroffenen Steuergeräts, eine Auffälligkeitsbewertung, den aktuellen Softwarestand und den Betriebszustand des Fahrzeugs. Keines dieser Felder ist für sich allein beweiskräftig. Entscheidend ist die gemeinsame Zeitachse: Ein Softwarestand ohne Zeitpunkt sagt wenig aus, wenn kurz zuvor ein Update oder ein Spannungsabfall stattgefunden hat.

Ein guter Log-Datensatz beantwortet im Kern drei Fragen. Was war vor dem Ereignis stabil? Was änderte sich unmittelbar davor? Und welche unabhängige Gegenprobe trennt Ursache und Folge? Fehlt eine dieser drei Antworten, bleibt der Log-Auszug ein loses Sammelsurium von Zahlen. Erst mit Kontext wird daraus ein Werkzeug, das tatsächlich zwischen einem harmlosen Ereignis und einer echten Auffälligkeit unterscheiden kann. Genau deshalb speichern gut aufgebaute Systeme mehr als nur den auslösenden Wert: Fahrzeugvariante, Steuergeräte-Hardwareindex, verwendetes Diagnosewerkzeug und eine kurze Beschreibung des erwarteten Sollzustands gehören ebenfalls in den Datensatz. Eine zweite Person soll die Reihenfolge der Ereignisse nachvollziehen können, ohne den ursprünglichen Bearbeiter befragen zu müssen – das ist keine Formalität, sondern die Grundlage für eine überhaupt erst überprüfbare Diagnose.

Warum ein einzelner Alarm noch kein Beweis ist

Ein einzelner auffälliger Eintrag kann viele Ursachen haben. Er kann eine echte Auffälligkeit sein, eine Folge eines vorgelagerten Zustands oder schlicht eine legitime Werkstattaktivität, die vom System zunächst als ungewöhnlich eingestuft wird. Ein Diagnosewerkzeug kann beispielsweise einen fehlenden Zugriff melden, obwohl das Ziel-Steuergerät technisch erreichbar ist – die Ursache liegt dann nicht in einem Angriff, sondern in einer fehlenden Freigabe für dieses Werkzeug.

Deshalb wird die sichtbare Meldung nicht als Bauteilbezeichnung gelesen, sondern als Beobachtungspunkt. Erst der Vergleich mit einer zweiten, unabhängigen Messgröße macht aus dieser Beobachtung eine Hypothese. Ohne diesen zweiten Blick bleibt jede Aussage über eine mögliche Ursache spekulativ, so plausibel sie auf den ersten Blick auch wirkt.

Baseline statt Einzelalarm: wie aus einer Auffälligkeit eine Aussage wird

Eine Baseline beschreibt, wie sich ein Fahrzeug im normalen Betrieb typischerweise verhält. Erst vor diesem Hintergrund lässt sich beurteilen, ob eine Beobachtung wirklich außergewöhnlich ist. Ohne Baseline fehlt der Maßstab, und jede Abweichung wirkt gleich dramatisch, egal ob sie harmlos oder ernst ist. Für Retrofit, Codierung oder eine Softwareänderung ist diese Vorher-Baseline besonders wichtig: Ohne sie lässt sich nicht sagen, ob ein Fehler bereits vor der Änderung existierte.

Praktisch bedeutet das: Erst wird der Normalzustand über einen längeren Zeitraum dokumentiert, dann wird eine Auffälligkeit dagegen gehalten. Bleibt ein unabhängiges Signal in dieser Kette stabil, obwohl die Hauptannahme etwas anderes vorhersagt, wird die Hypothese enger gefasst oder verworfen. Diese Rückwärtsprüfung verhindert, dass ein nachgelagerter Effekt fälschlich zum vermeintlichen Ursprung erklärt wird.

Precision, Recall und Fehlalarme: warum Erkennung auch mal falsch liegt

Ein Erkennungssystem für Auffälligkeiten arbeitet nie perfekt. Zwei Werte beschreiben, wie gut es tatsächlich ist: Precision misst, welcher Anteil der gemeldeten Alarme wirklich zutreffend ist. Recall misst, welcher Anteil der tatsächlich vorhandenen Auffälligkeiten überhaupt erkannt wird. Ein System kann viele echte Auffälligkeiten finden und trotzdem viele Fehlalarme produzieren, oder umgekehrt wenige Fehlalarme haben und dafür manche echte Auffälligkeit übersehen.

Diese beiden Werte stehen oft in einem Spannungsverhältnis zueinander. Ein besonders empfindliches System erkennt mehr, meldet aber auch mehr harmlose Ereignisse als vermeintliche Auffälligkeit. Ein besonders zurückhaltendes System meldet seltener falsch, riskiert dafür, eine echte Auffälligkeit zu übersehen. Für die Praxis heißt das: Ein einzelner gemeldeter Alarm ist ein Hinweis, kein Urteil, solange Precision und Recall des jeweiligen Systems nicht bekannt sind.

Typische Denkfehler beim Deuten von Logs

Drei Fehlinterpretationen tauchen besonders häufig auf. Erstens: eine Auffälligkeit wird automatisch mit einem Angriff gleichgesetzt, obwohl dafür weitere Belege fehlen. Zweitens: Logs verschiedener Steuergeräte werden verglichen, ohne vorher zu prüfen, ob ihre Zeitbasen überhaupt synchron sind. Drittens: eine seltene, aber völlig legitime Werkstattaktivität wird als Eindringen gedeutet, weil sie im Alltag selten vorkommt.

Alle drei Fehler haben eine gemeinsame Wurzel: Ein System wird auf einer Ebene gedeutet, auf der die eigentliche Ursache gar nicht liegt. Ein Netzwerklink kann beispielsweise technisch vorhanden sein, während der darüber angebotene Dienst aus organisatorischen Gründen nicht freigegeben ist – das sieht nach einem Kommunikationsproblem aus, ist aber ein Berechtigungsproblem. Wer diese Ebenen sauber trennt, vermeidet die teuersten Fehlschlüsse. Dienste wie SOME/IP und DDS fragen Daten zudem gezielt bei Bedarf an, statt sie dauerhaft zu senden. Ein ausbleibender Dienst kann deshalb bedeuten, dass niemand ihn angefragt hat, nicht, dass er blockiert wurde.

Ein vierter, seltener genannter Denkfehler betrifft die Menge an Daten selbst. Viele Logeinträge wirken allein durch ihre Zahl bedrohlich, obwohl die meisten davon Routinevorgänge dokumentieren: ein Steuergerät, das nach dem Schlafmodus wieder aufwacht, ein Diagnosezugriff während einer geplanten Wartung, ein kurzer Spannungseinbruch beim Motorstart. Wer jede dieser Routinemeldungen einzeln bewertet, verliert schnell den Überblick. Sinnvoller ist es, zuerst nach Häufungen und ungewöhnlichen Mustern zu suchen, statt jede einzelne Zeile isoliert zu interpretieren.

Cybersicherheit als Lebenszyklus, nicht als einmaliger Schutz

Die internationale Ingenieurnorm ISO/SAE 21434 betrachtet Cybersicherheit über den gesamten Lebenszyklus eines Fahrzeugsystems: Entwicklung, Produktion, Betrieb, Wartung und Außerbetriebnahme gehören danach zusammen. Ergänzend regelt die international abgestimmte Regelung R155 der Vereinten Nationen den organisatorischen Rahmen für das Cybersicherheits-Management von Fahrzeugherstellern; sie gilt seit 2021 und wird seither in einzelnen Punkten weiterentwickelt.

Für die Praxis bedeutet das: Ein Fahrzeug ist an einem einzigen Tag nie „fertig geschützt“. Schutzmaßnahmen werden über die gesamte Nutzungsdauer angepasst, etwa wenn neue Schwachstellen bekannt werden oder ein Update erscheint. Diese Sichtweise erklärt auch, warum ein älteres, seltener aktualisiertes Fahrzeug tendenziell verwundbarer ist als ein neueres mit aktivem Update-Pfad – nicht, weil es schlechter gebaut wäre, sondern weil sein Schutzstand länger nicht nachgezogen wurde. Dieselbe Zeitlogik gilt übrigens auch technisch, nicht nur organisatorisch: Wer die Zeitbasis und Latenz im Fahrzeugnetzwerk versteht, erkennt leichter, wann ein zeitlicher Versatz zwischen Steuergeräten eine harmlose technische Ursache hat und wann er tatsächlich weiter untersucht werden sollte.

Was Werkstattbesuch und Nachrüstung dabei verändern

Aftermarket-Komponenten können technisch einwandfrei funktionieren und trotzdem neue Abhängigkeiten erzeugen: andere Aufwachzeiten, zusätzliche Gateways, geänderte Diagnosepfade oder neue Lasten im Bordnetz. Deshalb wird jede Nachrüstung als Systemänderung dokumentiert, nicht nur als eingebautes Bauteil. Eine Codierung, Kalibrierung oder ein Firmware-Eingriff sind dabei drei unterschiedliche Änderungsarten mit unterschiedlicher Tragweite, und diese Unterscheidung gehört in jede Dokumentation.

Auch ein gewöhnlicher Werkstattbesuch hinterlässt Spuren im Log, die auf den ersten Blick wie eine Auffälligkeit aussehen können: ein Diagnosetester öffnet kurzzeitig einen Zugriffsweg, den das System sonst nicht sieht. Vorher-/Nachher-Identifikation, Rückrüstbarkeit und ein klar benannter Verantwortlicher der Änderung gehören deshalb in jede Akte. Das reduziert später die Gefahr, bei einem Update oder einer erneuten Diagnose nicht mehr zu wissen, welcher Zustand ursprünglich serienmäßig war.

Was ein Laie aus einem Log-Auszug wirklich herausliest

Ohne Fachwerkzeug sieht ein Fahrzeughalter meist nur wenig direkt: eine Warnleuchte, eine Meldung im Bordcomputer oder ein Hinweis in der Herstelleranwendung. Der eigentliche Security-Log liegt tiefer im System und ist normalerweise nur über ein Diagnosewerkzeug oder eine Werkstattverbindung zugänglich. Für den Alltag ist das eher beruhigend: Ein einzelnes, unverständliches Fehlerbild ist meistens kein Angriff, sondern eine der vielen Alltagsursachen, die ein System auch ohne Cyberbezug erzeugen kann.

Trotzdem lohnt sich ein Grundverständnis. Wer weiß, dass ein Fehlercode ein Beobachtungspunkt ist und keine fertige Diagnose, stellt in der Werkstatt bessere Fragen und lässt sich nicht von einer einzelnen alarmierenden Zahl verunsichern. Auffällig wird es erst, wenn mehrere unabhängige Anzeichen gleichzeitig auftreten und sich nicht durch eine plausible Alltagsursache erklären lassen – dann ist der Weg in die Fachwerkstatt der richtige nächste Schritt, nicht die Selbstdiagnose per Internetsuche.

Ein Beispiel macht den Unterschied greifbar. Ein einzelner Fehlercode zur Funkschlüssel-Erkennung nach einem kalten Morgen ist meist nur eine Alltagsmeldung, ausgelöst durch eine schwache Batterie im Schlüssel. Treten dagegen am selben Tag zusätzlich ein unerklärter Datenverkehr auf einer sonst stillen Schnittstelle, eine ungeplante Softwareänderung und ein Diagnosezugriff ohne bekannten Grund gemeinsam auf, ist die Häufung selbst schon ein Signal. Nicht der einzelne Fehlercode entscheidet, sondern das gemeinsame Muster mehrerer voneinander unabhängiger Beobachtungen.

Wo die Eigenprüfung endet

Dieser Beitrag ist bewusst informations- und diagnoseorientiert. Wo eine Prüfung Schutzmechanismen, Schlüsselmaterial oder sicherheitskritische Funktionen berühren würde, endet die Erklärung vor dem Eingriff. Es geht darum, zu verstehen, warum ein Zustand entsteht und welche Daten zur Fachdiagnose gehören, nicht darum, wie sich Schutzfunktionen umgehen lassen. Diese Grenze erhöht den praktischen Nutzen, weil sie Fehlinterpretationen reduziert, ohne aus einem Wissensbeitrag eine Anleitung zur Manipulation zu machen.

Ein weiterer Grund für diese Grenze ist praktisch: Ein Steuergerät, das plötzlich nicht mehr kommuniziert, muss dabei nicht kompromittiert sein – häufig liegt die Ursache im Gateway, in der Netzwerktopologie oder schlicht in einer fehlenden Freigabe. Bevor überhaupt über einen möglichen Angriff spekuliert wird, lohnt sich deshalb immer zuerst der Blick auf die einfacheren, weitaus häufigeren technischen Ursachen.

Häufige Fragen

Einordnung: wo die Angaben herkommen

Dieser Beitrag ordnet Grundbegriffe der Fahrzeug-Cybersicherheit und des Security-Loggings ein und benennt seine Quellen im Klartext. Entwürfe oder laufende Revisionsverfahren werden dabei nicht als bereits geltende Endfassung dargestellt.

Umbauten am eigenen Fahrzeug. Ob ein Umbau auf öffentlichen Straßen betrieben werden darf, entscheidet der Genehmigungszustand des Fahrzeugs — die Genehmigung des Teils, der Einbau nach ihren Auflagen und, wo nötig, die Abnahme durch eine dafür zuständige Stelle. Solange diese Kette nicht vollständig ist, gehört der Umbau auf Privatgelände, Testflächen und in nicht öffentliche Bereiche.