Die Verschlüsselung war nie das Problem: Was der Bau von TeslaKee über sicheres Design zeigt

Mit TeslaKee haben wir eine App veröffentlicht, die zwei seit Jahren dokumentierte Schwachstellen des Tesla-Bluetooth-Schlüssels praktisch entschärft. Die vollständigen Details stehen in unserer Pressemitteilung.

Dieser Artikel handelt von etwas anderem: davon, was der Fall über Softwaresicherheit im Allgemeinen zeigt — und was ein Unternehmen mit eigener Software-Entwicklung daraus für sich mitnehmen kann. Denn das Muster dahinter begegnet uns in Sicherheitsprüfungen ständig, meist ohne dass ein Auto im Spiel wäre.

Zwei Klarstellungen vorweg

App-Entwicklung ist nicht unser Geschäft. Wir prüfen Software, wir bauen sie normalerweise nicht. TeslaKee ist für uns deshalb auch eine Übung — und zwar eine sehr lehrreiche. Wer ein Produkt einmal selbst durch Entwurf, Umsetzung, Store-Freigabe, Fehlerberichte und Wartung bringt, versteht danach erheblich besser, unter welchen Zwängen die Entwicklungsteams unserer Kunden arbeiten. Welche Sicherheitsempfehlung sich in einem laufenden Release-Zyklus tatsächlich umsetzen lässt und welche nur auf Folien funktioniert, merkt man am schnellsten, wenn man selbst liefern muss.

Die Forschung dahinter ist aus eigenem Antrieb entstanden. Die Untersuchung des Tesla-Bluetooth-Protokolls kam aus Freude an der Sicherheitsforschung, nicht aus einem Auftrag: Es gab und gibt keine Beauftragung durch Tesla, keine Zusammenarbeit und keine Vergütung. TeslaKee ist ebenso wenig ein offizielles Tesla-Produkt — die Marke Tesla gehört Tesla, Inc.

Der Befund: alles richtig verschlüsselt, trotzdem angreifbar

Der digitale Autoschlüssel von Tesla verwendet solide Kryptografie: Schlüsselaustausch über ECDH, authentifizierte Verschlüsselung mit AES-GCM, ein Zähler gegen Wiedereinspielung. Wer nach einem Fehler in der Verschlüsselung sucht, wird nicht fündig.

Die Schwachstelle liegt eine Ebene darüber, in einer Designentscheidung: Die offizielle App beantwortet jede Authentifizierungsanfrage — bedingungslos, ohne zu prüfen, ob die Situation überhaupt plausibel ist.

Aus dieser einen Entscheidung folgen zwei sehr unterschiedliche Angriffe:

Der Relay-Angriff. Zwei Täter mit zwei Funkmodulen verlängern die Bluetooth-Strecke zwischen Telefon und Auto über beliebige Distanz. Für das Fahrzeug sieht es aus, als stünde die Besitzerin daneben — tatsächlich ist sie im Einkaufszentrum, das Telefon unberührt in der Tasche. Das Auto entriegelt und lässt sich wegfahren. Ohne Einbruchsspuren, was bei der Schadensregulierung regelmäßig zu Problemen führt.

Die BlueBait-Attacke. Die App antwortet auch gefälschten Fahrzeugen. Ein nachgebauter Beacon für wenige Euro am Straßenrand genügt, und jedes vorbeigetragene Telefon eines Tesla-Fahrers meldet sich. Damit lässt sich feststellen: Diese Person war zu dieser Zeit an diesem Ort. Das Auto muss dafür nicht in der Nähe sein. Mehrere solcher Geräte über eine Stadt verteilt ergeben ein Bewegungsprofil — für Stalking, für Nachstellung, für die Vorbereitung eines Diebstahls.

Bemerkenswert ist die Asymmetrie der Gegenmaßnahmen: Gegen den Diebstahl hilft die neuere UWB-Distanzmessung tatsächlich. Gegen die Ortung hilft sie überhaupt nicht — denn die entsteht schon dadurch, dass das Telefon überhaupt antwortet, also eine Stufe bevor die Distanzmessung greift.

Was daran verallgemeinerbar ist

Drei Dinge an diesem Fall sind typisch, und keines davon hat mit Autos zu tun.

Erstens: Die Bausteine waren in Ordnung, die Verkettung nicht. Kryptografische Verfahren sind heute weitgehend gelöste Probleme; wer eine etablierte Bibliothek korrekt einbindet, macht dort selten Fehler. Was übrig bleibt, sind Fragen des Zusammenspiels — wer darf wann was auslösen, unter welchen Bedingungen wird geantwortet, was passiert im Zweifelsfall. Diese Fragen beantwortet kein Werkzeug. Sie werden im Entwurf entschieden oder gar nicht.

Zweitens: Der Fehler war nicht versteckt. Beide Schwachstellen sind seit 2022 öffentlich dokumentiert, vorgestellt auf der Sicherheitskonferenz CanSecWest in Vancouver, samt Demonstrationsvideo frei zugänglich. Mehr als vier Jahre später ist die Lücke in geschätzt sechs Millionen Fahrzeugen unverändert offen. Bekannt heißt eben nicht behoben — eine Beobachtung, die sich mit dem deckt, was wir in Schwachstellen-Scans bei Unternehmen sehen.

Drittens: Ein automatisierter Test hätte das nicht gefunden. Kein Scanner meldet „diese Anwendung antwortet bereitwilliger, als sie sollte". Die Lücke ist nur sichtbar, wenn jemand das System aus der Perspektive eines Angreifers durchdenkt — also im Threat Modeling oder in einem manuellen Penetrationstest.

Wie wir vorgegangen sind: erst der Entwurf, dann der Code

Bevor die erste Zeile der Policy-Engine entstand, stand die Frage, gegen welche Angriffe sie eigentlich schützen soll — und gegen welche ausdrücklich nicht. Genau das leistet eine Bedrohungsmodellierung: Sie zwingt dazu, die Annahmen offenzulegen, auf denen ein System ruht, bevor diese Annahmen in Code gegossen sind.

Der Aufwand dafür ist überschaubar, der Zeitpunkt entscheidend. Im Entwurf kostet eine Korrektur eine Diskussion. Nach der Auslieferung kostet sie ein Release — und im Fall des Bluetooth-Schlüssels offenbar mehr als vier Jahre.

Defense in Depth: warum keine einzelne Regel genügt

Der Kern von TeslaKee ist eine Policy-Engine, die sich zwischen die Anfrage des Fahrzeugs und die Antwort des Telefons schiebt:

Fahrzeug → Authentifizierungsanfrage → [Policy-Engine] → Antwort ODER Schweigen

Geprüft werden Signale, die eine plausible Annäherung an das eigene Auto belegen: Hat sich das Telefon zuletzt bewegt? Ist es in einer definierten Zone? In einem bekannten WLAN? Innerhalb eines sinnvollen Zeitfensters? Passt die barometrische Höhe zu jener beim Abstellen?

Der entscheidende Gedanke — und der ist auf jede Sicherheitsarchitektur übertragbar:

Keine einzelne dieser Regeln ist für sich genommen sicher. Bewegung lässt sich vortäuschen, GPS lässt sich fälschen, ein WLAN lässt sich nachbauen. Die Sicherheit entsteht aus der Gleichzeitigkeit: Ein Angreifer, der aus hundert Metern Entfernung ein Signal weiterleitet, müsste im selben Moment das Telefon des Opfers schütteln, dessen GPS-Position fälschen und einen Access Point mit der richtigen Hardware-Adresse betreiben.

Jede einzelne Fälschung ist machbar. Alle zusammen, zeitgleich, aus der Ferne, sind es praktisch nicht. Genau darin besteht der Unterschied zwischen „unmöglich" und „so teuer, dass es sich nicht lohnt" — und in der Praxis ist das zweite das erreichbare Ziel.

Darunter liegen weitere Schichten: Der private Schlüssel wird im StrongBox-Sicherheitschip erzeugt und verlässt ihn nie; die ECDH-Berechnung findet in der Hardware statt. Selbst wenn die App vollständig kompromittiert würde, ließe sich das Schlüsselmaterial nicht auslesen.

Architektur als Datenschutz

Eine Entwurfsentscheidung, die uns rückblickend am meisten gebracht hat: TeslaKee hat keinen Server. Kein Benutzerkonto, keine Anmeldung, keine Cloud. Die App spricht ausschließlich direkt per Bluetooth mit dem Fahrzeug; Positionen, Zonen und Parkorte werden nur auf dem Gerät ausgewertet.

Das ist bequemer für die Nutzerin — es funktioniert in der Tiefgarage und im Ausland ohne Datenroaming. Vor allem aber verschwindet damit eine ganze Kategorie von Risiken: Wo keine Zugangsdaten auf einem Server liegen, kann keine Datenbank mit Fahrzeugzugängen gestohlen werden. Es gibt kein zentrales Ziel, das sich zu einem Einbruch lohnt, und keine Protokolle, die man später herausgeben oder verlieren könnte.

Datensparsamkeit ist hier keine nachträgliche Compliance-Übung, sondern eine Architekturentscheidung, die die Angriffsoberfläche verkleinert. Genau so ist auch die DSGVO gemeint.

Der Bezug zum Cyber Resilience Act

Was wir bei TeslaKee gemacht haben, ist im Kern das, was der Cyber Resilience Act ab Dezember 2027 von Herstellern verlangt: Sicherheit von der Konzeption an, ein dokumentiertes Bedrohungsmodell, nachvollziehbares Schwachstellen-Management und eine nachvollziehbare Dokumentation der eingesetzten Komponenten.

Ab 11. September 2026 greifen zudem die CRA-Meldepflichten für aktiv ausgenutzte Schwachstellen — Frühwarnung binnen 24 Stunden, Detailmeldung binnen 72 Stunden, Abschlussbericht binnen 14 Tagen. Wer das erfüllen will, muss Schwachstellen im eigenen Produkt erst einmal bemerken.

Was Sie daraus für Ihre Software mitnehmen können

Fünf Punkte, die sich aus diesem Projekt gut verallgemeinern lassen:

1. Prüfen Sie Annahmen, nicht nur Code. Die Frage „unter welchen Umständen antwortet unser System, und sollte es das?" findet Lücken, die keine Bibliotheksaktualisierung schließt.
2. Modellieren Sie Bedrohungen früh. Im Entwurf kostet eine Änderung eine Diskussion, in der Produktion kostet sie ein Release.
3. Verlassen Sie sich nicht auf ein einzelnes Merkmal. Mehrere unabhängige Signale, die gleichzeitig stimmen müssen, sind erheblich schwerer zu überwinden als eine starke Einzelprüfung.
4. Sparen Sie sich Daten, die Sie nicht brauchen. Jeder Datensatz, den Sie nicht speichern, ist einer, der Ihnen nicht gestohlen werden kann.
5. Rechnen Sie damit, dass bekannte Lücken lange offen bleiben — auch Ihre. Der Unterschied liegt nicht darin, ob es Schwachstellen gibt, sondern ob jemand systematisch danach sucht.

Wie wir das für Ihr Unternehmen tun

Was wir hier am eigenen Produkt durchgespielt haben, ist unser Tagesgeschäft für Kunden:

• Threat-Modeling-Prozess — wir verankern die Bedrohungsmodellierung als wiederholbaren Schritt in Ihrem Entwicklungszyklus, mit Pilotanwendung an einem echten Projekt. Das eintägige Training vermittelt zuvor die Methodik.
• Penetrationstest — manuelle Prüfung Ihrer Anwendung aus Angreifer-Sicht, dort wo automatische Werkzeuge nicht hinreichen. Genau die Art Prüfung, die eine Logiklücke wie die beschriebene findet.
• Angriffsoberflächen-Analyse — was ein Angreifer von außen über Ihr Unternehmen sieht, ohne dass er dafür Zugriff braucht.
• Schwachstellen-Scan — die laufende Prüfung, die verhindert, dass eine bekannte Lücke bei Ihnen vier Jahre offen steht.
• CRA-Compliance — technische Vorbereitung auf Security by Design, Schwachstellen-Management und SBOM.

Wie ein solches Projekt abläuft, steht auf der Seite So arbeiten wir.

TeslaKee ausprobieren

Die App ist für Android ab Version 10 verfügbar und benötigt ein Gerät mit StrongBox-Sicherheitschip (verbreitet ab Baujahr 2019) sowie die NFC-Keycard des Fahrzeugs für die einmalige Anmeldung. Kompatibel sind Model 3, Y, S und X mit Bluetooth-PhoneKey. Sie ersetzt die offizielle Tesla-App nicht, sondern läuft parallel dazu — alle Cloud-Funktionen bleiben erhalten.

Manuelles Ver- und Entriegeln, Fahrzeugstatus und Schnellaktionen sind kostenlos; die Policy-Engine und der passive Zugang sind Teil der Premium-Version (2,99 € monatlich oder 29,99 € jährlich). TeslaKee im Play Store

Wer zunächst nur sehen möchte, was das eigene Fahrzeug ungefragt in die Umgebung sendet, kann das mit der kostenlosen App Tesla Radar nachvollziehen. Sie ist ein reines Beobachtungswerkzeug und sendet selbst nichts. Aufschlussreich ist vor allem der Fahrzeugname: Viele Halterinnen und Halter setzen ihn auf den eigenen Namen — und strahlen ihn damit permanent aus.

Sprechen wir über Ihre Software

Wenn Sie eigene Anwendungen entwickeln oder betreiben und wissen wollen, wo bei Ihnen die Annahmen sitzen, die noch nie jemand hinterfragt hat: Das Erstgespräch ist kostenlos und unverbindlich.

Jetzt Erstgespräch vereinbaren