OTA-Update im Auto: Signatur, Abbruch und Rollback verstehen

Was ein Update im Hintergrund wirklich überträgt

Ein Over-the-Air-Update klingt nach einer einzigen Datei, die über das Mobilfunknetz ins Auto fließt. Tatsächlich ist es ein mehrstufiger Prozess, der lange vor dem sichtbaren Fortschrittsbalken beginnt. Das Backend des Herstellers stellt ein Paket zusammen, das genau zur Fahrzeugvariante, zur Hardwarerevision und zum aktuell installierten Softwarestand passt. Nur wenn diese Kombination stimmt, wird das Paket überhaupt zum Download freigegeben. Ein solches Firmware-Update ist damit klar von einer reinen Codierung oder einer neuen Kalibrierung im Steuergerät zu unterscheiden, wie der Beitrag Codierung, Kalibrierung und Firmware im Vergleich einordnet.

Danach kommt die eigentliche Übertragung: Das Paket wird in kleine Blöcke zerlegt, über das Bordnetz oder ein zentrales Gateway an das Ziel-Steuergerät weitergereicht und dort zwischengespeichert. Erst wenn alle Blöcke angekommen sind, beginnt die Prüfung, ob sie unverändert und vollständig sind. Genau hier trennen sich zwei Fragen, die im Alltag oft verwechselt werden: Ist die Datei technisch intakt, und stammt sie wirklich von einer autorisierten Quelle? Die erste Frage beantwortet ein Hashwert, die zweite eine Signatur. Beide Prüfungen laufen getrennt und aus gutem Grund.

Warum ein Hashwert allein nichts über die Herkunft sagt

Ein Hashwert ist im Grunde eine Prüfsumme: Aus den übertragenen Daten wird eine feste Zeichenfolge berechnet, und diese Zeichenfolge wird mit dem erwarteten Wert verglichen. Stimmen beide überein, ist die Übertragung technisch sauber gelaufen – kein Bit ist unterwegs verloren gegangen oder verändert worden. Das ist wichtig, beantwortet aber nur die halbe Frage. Ein Hashwert sagt nichts darüber aus, wer die Datei ursprünglich erzeugt hat. Wer den Algorithmus kennt, kann zu praktisch jeder beliebigen Datei den passenden Hashwert berechnen.

Für ein Fahrzeug ist das ein relevanter Unterschied. Würde ein Steuergerät nur den Hashwert prüfen, könnte theoretisch jedes Paket akzeptiert werden, das rechnerisch zu sich selbst passt – unabhängig davon, wer es gebaut hat. Deshalb reicht die Integritätsprüfung allein nicht aus, um ein sicherheitsrelevantes Steuergerät zu aktualisieren. Es braucht eine zweite, unabhängige Prüfung, die die Quelle bestätigt und nicht nur die Unversehrtheit der Daten.

Signaturprüfung: der öffentliche Schlüssel im Steuergerät

Die Signaturprüfung schließt genau diese Lücke. Der Hersteller signiert ein Update-Paket mit einem geheimen, nur ihm bekannten Schlüssel. Im Steuergerät liegt dazu der passende öffentliche Gegenschlüssel fest hinterlegt, häufig in einem besonders geschützten Speicherbereich, der sich nachträglich nicht mehr ohne Weiteres verändern lässt. Beim Empfang eines Pakets prüft das Steuergerät mit diesem öffentlichen Schlüssel, ob die Signatur tatsächlich zum erwarteten Absender passt. Nur wenn beide Prüfungen erfolgreich sind – Integrität über den Hash, Authentizität über die Signatur –, geht das Update in die nächste Phase.

Diese Zweiteilung erklärt auch, warum ein technisch vollständig heruntergeladenes Paket trotzdem abgelehnt werden kann. Ein manipuliertes oder falsch adressiertes Paket kann bei der Übertragung fehlerfrei ankommen und trotzdem an der Signaturprüfung scheitern. Aus Sicht des Fahrzeugs ist das kein Fehlerfall, sondern die Schutzfunktion, die genau dafür gebaut wurde. Wie ein Steuergerät seinen eigenen Startvorgang gegen unautorisierte Software absichert, erklärt der Beitrag zu Secure Boot im Auto im Detail.

A/B-Partitionen: zwei Softwarestände für ein Steuergerät

Damit ein Update nicht ausgerechnet in dem Moment scheitert, in dem das Fahrzeug es am dringendsten braucht, arbeiten viele moderne Steuergeräte mit zwei getrennten Speicherbereichen, meist Slot A und Slot B genannt. Während das Fahrzeug ganz normal mit dem aktiven Slot läuft, wird das neue Update ausschließlich in den inaktiven Slot geschrieben. Die laufende Software merkt davon zunächst nichts, und ein Fehler während der Übertragung gefährdet den funktionierenden Zustand nicht.

Erst nach einem Neustart prüft das System, ob der neu beschriebene Slot tatsächlich hochfahren kann. Bestimmte Basisfunktionen müssen innerhalb einer festgelegten Zeit erfolgreich anlaufen, bevor der neue Slot als aktiv markiert wird. Scheitert dieser Test, bleibt der alte Slot die Referenz, und das Fahrzeug fährt mit dem bewährten Stand weiter. Diese Architektur ist der eigentliche Grund, warum ein Update-Fehler heute selten ein komplett funktionsunfähiges Steuergerät bedeutet – vorausgesetzt, der alte Slot war vor dem Update selbst intakt.

Warum ein Update nach einem Abbruch weitermachen kann

Bricht die Datenverbindung mitten in der Übertragung ab, muss das Steuergerät nicht zwangsläufig von vorn beginnen. Weil das Paket in einzelne, jeweils selbst geprüfte Blöcke zerlegt ist, kann das System genau dort weitermachen, wo bereits verifizierte Blöcke vorliegen. Diese Fähigkeit wird als Resume-Funktion bezeichnet und spart bei größeren Paketen spürbar Zeit und Datenvolumen. Sie funktioniert allerdings nur, solange der zwischengespeicherte Teilstand selbst nicht beschädigt wurde – in diesem Fall verlangt das System einen sauberen Neustart der Übertragung.

Für den Fahrer ist der Unterschied kaum sichtbar: Sowohl ein fortgesetztes als auch ein neu gestartetes Update zeigt zunächst wieder einen Fortschrittsbalken bei null oder beim zuletzt bestätigten Stand. Entscheidend ist, dass ein Abbruch während der Übertragung nach heutigem Stand der Technik nicht in einem halb beschriebenen, funktionsunfähigen Speicherbereich endet. Genau dafür existiert die Trennung zwischen dem aktiven und dem gerade beschriebenen Slot.

Rollback: die Rückfahrkarte, wenn der neue Stand nicht startet

Rollback ist kein Reparaturtrick, sondern ein fest eingeplanter Bestandteil der Update-Architektur. Besteht der neu beschriebene Slot den Starttest nicht, schaltet das System selbstständig zurück auf den zuletzt funktionierenden Stand. Das Fahrzeug bleibt damit nutzbar, auch wenn das Update selbst gescheitert ist. Diese Rückfallebene unterscheidet ein modernes Update-System deutlich von einem klassischen Werkstatt-Flash, bei dem ein Abbruch früher tatsächlich ein leeres, unbrauchbares Steuergerät zurücklassen konnte.

Wichtig ist dabei die Unterscheidung zwischen den Fehlerarten. Ein Downloadfehler betrifft nur die Übertragung und hat mit dem eigentlichen Softwarestand noch gar nichts zu tun. Ein Verifikationsfehler bedeutet, dass Hash oder Signatur nicht passen. Ein Installationsfehler tritt beim eigentlichen Schreibvorgang auf. Und ein Aktivierungsfehler zeigt sich erst nach dem Neustart, wenn der neue Stand nicht sauber hochfährt. Nur die letzten beiden Fälle lösen überhaupt einen Rollback aus – die ersten beiden verhindern lediglich, dass die Installation jemals beginnt.

Anti-Rollback: warum nicht jede signierte alte Version zurückdarf

Rollback klingt zunächst nach einer einfachen Regel: Geht etwas schief, zurück zum letzten Stand. In der Praxis ist das komplizierter, weil ein Steuergerät nicht beliebig alte Software wieder zulassen darf, selbst wenn diese Datei ursprünglich korrekt signiert war. Der Grund liegt in bekannt gewordenen Sicherheitslücken: Eine ältere Version kann eine Schwachstelle enthalten, die in einer neueren Version bereits geschlossen wurde. Würde das System diese ältere, aber technisch gültig signierte Version wieder zulassen, ließe sich die geschlossene Lücke erneut öffnen.

Deshalb führen viele Steuergeräte einen Versionszähler in einem besonders geschützten Speicherbereich, der sich nur in eine Richtung bewegen lässt. Eine neue Version darf installiert werden, wenn ihr Zählerstand mindestens so hoch ist wie der bereits gespeicherte. Eine ältere Version mit niedrigerem Stand wird abgelehnt, unabhängig von ihrer Signatur. Diese Regel ist der Grund, warum ein Rollback im Fehlerfall zwar auf den vorherigen aktiven Slot zurückgreift, aber nicht bedeutet, dass beliebig alte Softwarestände jederzeit wieder aufgespielt werden dürfen.

Die häufigsten Gründe, warum ein Update wirklich abbricht

In der Praxis liegt ein abgebrochenes Update selten an einem grundsätzlichen Defekt des Steuergeräts. Weit häufiger sind banalere Ursachen, die sich mit etwas Systemverständnis gut einordnen lassen. Eine schwache oder instabile Mobilfunk- beziehungsweise WLAN-Verbindung unterbricht die Übertragung, bevor alle Blöcke vollständig sind. Ein zu niedriger Ladezustand der Bordbatterie kann dazu führen, dass die Installation gar nicht erst startet, weil das System eine stabile Spannungsversorgung während des Schreibvorgangs voraussetzt.

Auch ein nicht erfüllter Fahrzeugzustand verhindert oft den Start: Viele Systeme verlangen, dass das Fahrzeug geparkt ist, die Zündung in einem definierten Zustand steht und keine Fahrt unmittelbar bevorsteht. Kommt zusätzlich Zeitdruck ins Spiel – etwa weil das Fahrzeug kurz nach dem Update-Start bewegt werden soll –, bricht die Installation kontrolliert ab, statt einen riskanten Zustand zu riskieren. Und schließlich kann ein Update schlicht nicht zur aktuellen Fahrzeugkonfiguration passen, etwa weil eine Abhängigkeit zu einem anderen Steuergerät noch nicht erfüllt ist. In all diesen Fällen bricht das System bewusst und kontrolliert ab, nicht chaotisch.

ISO 24089, UN R156 und AUTOSAR UCM: der Rahmen dahinter

Dass Updates heute so strukturiert ablaufen, ist kein Zufall einzelner Hersteller, sondern folgt einem internationalen Normrahmen. Die ISO 24089 aus dem Jahr 2023 beschreibt Softwareupdate-Engineering für Fahrzeuge auf Organisations- und Projektebene: Schon bevor überhaupt ein Byte übertragen wird, müssen Zielsystem, Abhängigkeiten, der freigegebene Softwarestand, die Paketidentität und eine Rückfallstrategie definiert sein. Erst danach folgen Übertragung, Verifikation, Installation, Aktivierung und eine Nachprüfung.

Auf internationaler Regulierungsebene ergänzt die UN-Regelung R156 diesen Rahmen: Sie verlangt für die Typgenehmigung ein dokumentiertes Software-Update-Management-System, das Hersteller nachweisen müssen, bevor Fahrzeuge mit entsprechender Update-Fähigkeit zugelassen werden. Auf der technischen Ebene innerhalb des einzelnen Steuergeräts liefert AUTOSAR mit dem Update and Configuration Management, kurz UCM, konkrete Anforderungen – etwa an Fortschrittsanzeigen sowie an das saubere Unterbrechen und Fortsetzen eines Updates. Diese drei Ebenen greifen ineinander: Prozess, Zulassung und technische Umsetzung im Steuergerät.

Was eine Softwareänderung mit der Betriebserlaubnis zu tun hat

Für Halterinnen und Halter ist an dieser Stelle ein rechtlicher Punkt wichtig, der beim Thema Software leicht übersehen wird. § 19 Absatz 2 StVZO erlischt nicht nur bei mechanischen Umbauten, sondern nennt Softwareänderungen ausdrücklich: Für Änderungen an der Software eines im Verkehr befindlichen Fahrzeugs sind zusätzlich die amtlich bekannt gemachten Vorschriften zur Durchführung sowie der Stand der Technik zu beachten. Ein offizielles Herstellerupdate, das nach dem beschriebenen Signatur- und Freigabeprozess läuft, bewegt sich innerhalb dieses Rahmens. Eine nicht autorisierte Änderung an sicherheits-, emissions- oder zulassungsrelevanter Software tut das nicht zwangsläufig.

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.

Wer prüfen will, ob ein Diagnosezugriff auf ein sicherheitsrelevantes Steuergerät überhaupt eine Freigabe erfordert, findet die Grundlagen im Beitrag zum Secure Gateway im Auto und den dort beschriebenen Freigabestufen.

Was Nachrüstungen für die nächste Update-Runde bedeuten

Ein nachgerüstetes Bauteil kann heute einwandfrei funktionieren und trotzdem beim nächsten Herstellerupdate zum Problem werden. Der Grund liegt in Abhängigkeiten, die auf den ersten Blick nicht sichtbar sind: veränderte Wake-up-Zeiten im Bordnetz, ein zusätzliches Gateway im Kommunikationspfad, ein abweichender Softwarestand an einem beteiligten Steuergerät oder eine zusätzliche elektrische Last. Ein aktueller Chiptuning-Eingriff etwa verändert nicht nur Motorwerte, sondern häufig auch den Softwarestand des Motorsteuergeräts – und genau dieser Stand ist Teil der Prüfung, die ein Update vor der Installation durchläuft.

Deshalb lohnt es sich, jede Nachrüstung als eigenständige Systemänderung zu dokumentieren, nicht nur als eingebautes Bauteil. Welcher Zustand war vorher da, welcher ist es jetzt, und lässt sich die Änderung im Zweifel rückbauen? Diese Dokumentation verhindert später eine unangenehme Überraschung, wenn ein Update aus unklaren Gründen nicht startet oder ein Fahrzeug nach einem Eingriff wie beim Erhöhen des Ladedrucks plötzlich andere Freigabebedingungen meldet als zuvor.

Woran du in der Werkstattdiagnose ansetzen kannst

Ein einzelner Fehlercode erklärt selten, auf welcher Ebene ein Update wirklich gescheitert ist. Aussagekräftiger ist eine kleine Kette aus mehreren Werten, die gemeinsam betrachtet werden: der Status der Hashprüfung, der Status der Signaturprüfung, der aktive Slot, der Fortschritt zum Abbruchzeitpunkt und der protokollierte Abbruchgrund. Keiner dieser Werte für sich allein ist beweiskräftig – erst ihr Zusammenspiel entlang einer gemeinsamen Zeitachse zeigt, was tatsächlich passiert ist.

Genauso wichtig ist der Fahrzeugzustand rund um den Abbruch: Stand die Zündung im richtigen Modus, war die Versorgungsspannung stabil, und lag zeitlich vorher schon ein anderer Fehler im Speicher? Ein Kommunikationsfehler kann Folge eines Schlafzustands sein und nicht dessen Ursache – wer das Notlaufverhalten von Steuergeräten kennt, liest solche Meldungen deutlich entspannter. Wie ein Diagnosewerkzeug diese Werte überhaupt aus dem Fahrzeug ausliest, erklärt der Beitrag zum UDS-Protokoll, und wie diese Daten über den Bus zum Werkzeug gelangen, zeigt der Beitrag zu DoIP und CAN. Liegt der Fehler eher im Netzwerk selbst, hilft der Beitrag zur CAN-Bus-Fehlersuche weiter, und bei Auffälligkeiten im gesamten Datenkanal lohnt ein Blick auf die Authentisierung über SecOC.

Ein einmaliger Screenshot des Displays reicht für eine belastbare Diagnose fast nie aus. Moderne Fahrzeugsoftware kann Fehlerzustände zwischenspeichern, nach einem Neustart Funktionen anders initialisieren oder bei fehlender Freigabe automatisch in eine Ersatzstrategie wechseln. Wo ein Eingriff Schutzmechanismen, Schlüsselmaterial oder sicherheitskritische Funktionen berührt, endet die Eigendiagnose an der Stelle, an der Herstellerfreigabe oder qualifiziertes Fachpersonal gefragt sind.

Häufige Fragen

Einordnung: wo die Regeln stehen

Die technischen Aussagen zu Paketaufbau, Signaturprüfung, A/B-Partitionierung und Rollback folgen dem allgemein anerkannten Stand der Update-Technik in der Fahrzeugindustrie, wie er in den unten genannten Normen und Spezifikationen beschrieben ist. Die Normtitel werden nur bis zu ihrem öffentlich belegbaren Status eingeordnet; laufende Überarbeitungen werden als Entwicklungsstand geführt, nicht als bereits geltende Endfassung. Die Rechtsaussage zu § 19 Absatz 2 StVZO ist am amtlichen Normtext geprüft.