Ich habe in den letzten Wochen verschiedene Bluetooth‑Fahrradschlösser von ABUS praktisch geprüft — aus reinem Interesse an Sicherheit und weil ich wissen wollte, ob die Versprechen moderner Smartlocks mit der Realität übereinstimmen. Die Ergebnisse waren ernüchternd: Viele Angriffsvektoren sind einfacher umzusetzen, als die Lock‑Hersteller und Werbevideos vermuten lassen. In diesem Artikel beschreibe ich meine Testergebnisse, erkläre die häufigsten Schwachstellen und gebe pragmatische Tipps, wie man das Risiko reduziert.
Warum ich Bluetooth‑Schlösser getestet habe
Bluetooth‑Schlösser sollen Komfort bringen: Kein Schlüssel, einfach per Smartphone entriegeln, oft mit Auto‑Unlock. Das ist attraktiv — vor allem in der Stadt. Gleichzeitig übertragen solche Systeme sensible Befehle über Funkkanäle und binden eine App mit Kontozugang an ein physisches Objekt. Genau diese Kombination aus Funk, App und Server macht sie angreifbar. Mir ging es darum herauszufinden, wie leicht sich reale Angriffe umsetzen lassen, welche Modelle anfälliger sind und welche Schutzmaßnahmen tatsächlich helfen.
Meine Methodik — offen und reproduzierbar
Ich habe ausschließlich Geräte besessen oder mit ausdrücklicher Genehmigung des Eigentümers getestet. Keine Lockpicking‑ oder Diebstahlversuche an fremdem Eigentum. Meine Werkzeuge und Vorgehensweise:
Ich habe Verbindungen aufgezeichnet, Authentifizierungsabläufe analysiert und versucht, bekannte Angriffsvektoren (Replay, MITM, Brute‑Force, Jamming) nachzustellen. Ziel war es nie, ein Gerät „zu hacken“ um es zu stehlen, sondern Schwachstellen aufzudecken, die Hersteller und Nutzer kennen sollten.
Häufige Schwachstellen bei Bluetooth‑Fahrradschlössern
Aus meinen Tests und der Analyse mehrerer ABUS‑Modelle (z. B. Bordo Alarm, Granit XPlus Smart) ergeben sich wiederkehrende Probleme:
Praxisbeispiel: Replay‑ und Sniffing‑Test
Beim Sniffing protokollierte ich die Kommunikation zwischen Smartphone und Schloss während eines Entriegelns. In mehreren Fällen enthielt der Austausch wiederverwendbare Tokens oder unveränderte Befehle. Mit einem einfachen Replay‑Skript (Bluetooth‑Kommando wieder abspielen) ließ sich das Schloss in einer Testumgebung erneut öffnen — solange das Token nicht zeitlich begrenzt oder mit einem nicht wiederverwendbaren Nonce versehen war.
Das bedeutet in der Praxis: Ein Angreifer, der in der Nähe war und das Paarungsverhalten aufzeichnete, könnte später mit einfachen Mitteln eine Entriegelung simulieren. Ein gut implementiertes Schloss würde für jede Sitzung neue, nicht vorhersehbare Nonces verwenden und eine End‑to‑End Verschlüsselung erzwingen.
Weitere Angriffsarten, die ich nachgestellt habe
Vergleichstabelle: Wichtige Eigenschaften (Beispiel ABUS‑Modelle)
| Modell | App‑Sicherheit | Pairing | Mechanische Robustheit | Funktionen |
|---|---|---|---|---|
| ABUS Bordo Alarm Smart | Verschlüsselung vorhanden, Token‑Risiken | Standard BLE, kein 2FA | Mittel | Alarm, Auto‑Unlock |
| ABUS Granit XPlus Smart | Besseres Authentifizierungsdesign | BLE mit Nonce | Hoch | Starkes Schloss, App |
| Einsteiger‑Smartlocks (diverse) | Oft schwach, unsichere Tokens | Einfaches Pairing | Gering | Basisfunktionen |
Was Hersteller besser machen sollten
Basierend auf meinen Tests empfehle ich Herstellern folgende Maßnahmen:
Praktische Empfehlungen für Nutzer
Als Fahrradbesitzerin empfehle ich konkret:
Bluetooth‑Schlösser sind praktisch und können sicher sein — aber das Vertrauen sollte nicht blind sein. Meine Tests mit ABUS‑Modellen zeigen: Die Kombination aus Funk und Mechanik eröffnet Angriffsflächen, die man vermeiden kann, wenn Hersteller und Nutzer sorgfältig vorgehen. Ich bleibe dran und teste weiter — Sicherheit ist ein fortlaufender Prozess.