Mercedes FBS4: Was das Wegfahrsperren-System bedeutet

Frank Abagnale Jr. (Leonardo DiCaprio in Spielbergs “Catch Me If You Can”) perfektioniert in den 1960er Jahren das Fälschen von Pan-Am-Schecks. Seine Methode funktioniert, weil Banken damals dezentral arbeiteten: Ein Scheck wurde lokal geprüft, bestenfalls an die ausstellende Bank per Telex zur Deckungsfrage weitergeleitet – aber die Echtheitsprüfung basierte auf Papier, Tinte, Seriennummer-Format, Unterschrift. Alles lokal verifizierbare Merkmale, alles fälschbar für jemanden mit genügend Werkzeug und Fachwissen. Am Ende des Films endet Abagnales Karriere nicht durch besseres Papier, sondern durch FBI-Datenbanken und Echtzeit-Kommunikation: Sobald die Prüfung gegen einen zentralen Server lief, brachen alle lokalen Fälschungen zusammen.

Die Transition von FBS3 zu FBS4 bei Mercedes folgt exakt diesem Paradigmenwechsel – es ist die Digitalisierung einer Vertrauenskette, die vorher rein lokal funktionierte.

FBS3 (ca. 2006–2014, W204/W212/W221): Das EIS (Elektronische Zündschloss, in W204/W212 verbaut) speichert die Schlüssel-IDs lokal in einem EEPROM. Beim Anlernen eines neuen Schlüssels errechnet XENTRY aus der VIN, der FB-ID des Fahrzeugs und dem Schlüssel-Seed einen kryptographischen Hash (SKC – Secret Key Code), schreibt diesen in den Transponder (Infineon PCF7936 oder ähnliche Hitag-2/Crypto-Variante) und in das EIS-EEPROM. Der gesamte Vorgang läuft auf der K-Line oder CAN-Bus, vollständig lokal. Wer die EIS-Seed-Daten aus dem Steuergerät-EEPROM extrahieren kann (Dumping via Boot-Loader-Modus am MCU, typisch Motorola MCU + externer EEPROM 95P08/95080), kann die SKC-Berechnung offline reproduzieren. Grau-Markt-Tools wie “Abrites” oder “VVDI MB” arbeiten genau auf dieser Basis – sie sind technisch das Äquivalent der Abagnale-Druckerpresse.

FBS4 (ab ca. 2014, W205/W222/W213/W177): Das Systemarchitektur-Update macht den entscheidenden Schnitt – die SKC-Berechnung findet nicht mehr lokal statt. XENTRY sendet bei jedem Schlüssel-Anlernvorgang eine signierte Anfrage an den Mercedes-Backend-Server (mercedesbenz-xentry.com, HTTPS/TLS 1.2+ mit MB-Client-Zertifikat aus dem XENTRY-Werkstatt-Dongle). Der Server prüft: Ist der Werkstattaccount aktiv? Ist die FIN plausibel? Ist der Vorgang mit den gesendeten Eigentumsnachweisen vereinbar? Erst nach positiver Prüfung liefert der Server einen fahrzeug- und vorgangsspezifischen Token zurück – ein kryptographisch signierter Datensatz, gültig für genau diese VIN, genau diesen Schlüsselvorgang, zeitlich eng begrenzt (typisch wenige Stunden Gültigkeit).

Das EIS im Fahrzeug enthält einen eingebetteten Root-Zertifikat-Fingerprint (Public-Key-Hash des Mercedes-CA). Wenn XENTRY dem EIS den Token übergibt, prüft das Steuergerät die Signatur gegen diesen Fingerprint – ohne gültige MB-Signatur verweigert das EIS die EEPROM-Änderung. Ein gedumpter EEPROM-Inhalt ist wertlos, weil der Anlernvorgang nicht mehr im lokalen Datensatz kodiert ist, sondern in einer Server-Response, die an den aktuellen Zeitstempel und die aktuelle Werkstatt-Session gebunden ist.

Die Protokollkette (UDS ISO 14229, Mercedes-spezifische Subfunctions): $10 82 DiagnosticSessionControl (Security-relevante Session), $27 01/02 SecurityAccess mit Challenge-Response (Seed 4 Bytes, Key AES-128-basiert aus Server-Token abgeleitet), $2E WriteDataByIdentifier auf die schlüsselspezifischen DIDs (Mercedes-interne IDs, u.a. die Transponder-Slot-Belegung und der zugehörige Crypto-Key). Fehler-Response $7F 27 35 (InvalidKey) bedeutet: Server-Token war ungültig oder abgelaufen.

Bei Schlüsselverlust eines FBS4-Fahrzeugs kommt zusätzlich die “All-Keys-Lost”-Prozedur zum Tragen. Da der letzte Schlüssel den einzigen Einstiegspunkt zur aktiven EIS-Session darstellt, muss Mercedes bei vollständigem Verlust entweder einen verifizierten Eigentumsnachweis (Kopie Fahrzeugschein Teil II, Ausweis des Halters) an den Server übermitteln – dann wird eine spezielle “recovery unlock”-Response generiert – oder das EIS/ESM (neuere Bezeichnung: ESR = Elektronisches Start-Register) muss getauscht werden. Bei letzterem ist die neue EIS-Hardware vom Server mit neuen Initial-Keys zu versehen (Erstinitialisierung, UDS $31 RoutineControl mit MB-spezifischer Routine-ID).

Die Analogie zu “Catch Me If You Can” ist präzise: FBS3 war die Ära, in der ein geschickter Schlüsseldienst mit EEPROM-Programmer und ausreichend Know-how rein technisch alles anlernen konnte, was ihm unter die Finger kam – auch jenseits legitimer Eigentumsverhältnisse. FBS4 schließt diese Lücke strukturell. Nicht weil die lokale Hardware sicherer wäre (der Transponder selbst ist vergleichbar), sondern weil die Autorisierung nicht mehr lokal auditiert werden kann. Der Server ist nun der einzige gültige Prüfer – und er verlangt Legitimation, die kein Parallelmarkt liefern kann.