BLE-Sicherheit

Was ist BLE-Sicherheit?

BLE-Sicherheit ist die Sammlung der Mechanismen in Bluetooth Low Energy, die eine Verbindung zwischen zwei Geräten und die darüber zugänglichen Daten schützen. Die relevanten Teile sind Pairing (wie zwei Geräte Schlüssel vereinbaren), Bonding (das Speichern dieser Schlüssel für spätere Verbindungen), Verschlüsselung der Verbindung, Authentifizierung der Gegenstelle, Autorisierung des Zugriffs auf einzelne GATT-Characteristics und Privatsphäre über auflösbare private Adressen, die verhindern, dass ein Gerät über seine Bluetooth-Adresse verfolgt wird.

Pairing gibt es in zwei Generationen. LE Legacy Pairing (Bluetooth 4.0 und 4.1) leitet Schlüssel aus einem temporären Schlüssel ab, der bei Just Works null und bei Passkey Entry eine sechsstellige Zahl ist; wer das Pairing mitschneidet, rekonstruiert ihn in Sekunden per Brute Force. LE Secure Connections (ab Bluetooth 4.2) nutzt einen Elliptische-Kurven-Diffie-Hellman-Austausch auf P-256, ein passiver Sniffer erfährt nichts. Das Pairing-Verfahren entscheidet dann, ob die Gegenstelle authentifiziert ist: Numeric Comparison und Passkey Entry schützen gegen einen aktiven Angreifer in der Mitte, Just Works nicht, und Out of Band hängt vom zweiten Kanal ab, etwa NFC.

Wo ist es definiert?

Die Bluetooth Core Specification der Bluetooth SIG definiert Pairing, das Security-Manager-Protokoll, die Verschlüsselung und die LE Security Modes und Levels. Security Mode 1 Level 4 ist der stärkste für eine Datenverbindung: authentifiziertes Pairing mit LE Secure Connections und 128-Bit-Verschlüsselung. NIST SP 800-121 Rev. 2 erklärt die Mechanismen und gibt Konfigurationsempfehlungen; die Tabellen zu Bedrohungen und Gegenmaßnahmen sind eine gute Checkliste für ein Lastenheft. Für Consumer-IoT setzt ETSI EN 303 645 Basisanforderungen wie keine universellen Standardpasswörter und sichere Kommunikation, und in der EU macht die Funkanlagenrichtlinie mit der harmonisierten Reihe EN 18031 die Cybersicherheit der Funkschnittstelle zur Bedingung für die CE-Kennzeichnung.

Was es in der Praxis bedeutet

In unseren IoT-Penetrationstests von BLE-Produkten, von ESP32-basierten Kommunikationsmodulen bis zu Haushalts- und Medizingeräten, ist selten die Spezifikation das Problem. Die Implementierung ist es. Was wir typischerweise finden:

• Keine Sicherheit auf Characteristics. Schreibzugriffe, die das Gerät steuern, vom Entriegeln bis zu Einstellungen, akzeptiert jedes Central, das sich verbindet, ohne Pairing. Der Pairing-Dialog existiert nur in der App, nicht in der Firmware.
• Legacy Pairing weiter aktiv. Der Chip kann LE Secure Connections, aber die Firmware akzeptiert eine Legacy-Pairing-Anfrage, also fragt der Angreifer einfach nach der schwächeren Variante.
• Anwendungsauthentifizierung als Konstante. Die App schickt nach dem Verbinden ein festes Token. Einmal mitgeschnitten, für immer wiederholbar. Ein Challenge-Response, das am Bond hängt, kostet ein paar Zeilen Code.
• Firmware-Updates über BLE ohne Signaturprüfung, womit ein mitlesbares Protokoll zum Pfad für Codeausführung wird.
• Statische Adressen, über die sich ein Gerät und damit sein Besitzer über Orte hinweg verfolgen lassen.

Die Lösung ist meist architektonisch: LE Secure Connections verlangen, Legacy Pairing ablehnen, Autorisierung an den Bond binden, Rechte pro Characteristic in der Attributtabelle setzen, Updates signieren und auflösbare private Adressen nutzen. Um all das zu analysieren, braucht es einen Sniffer, ein steuerbares Central und die Firmware. Deshalb funktionieren BLE-Tests am besten als Greybox mit Hardware-Mustern.

Häufige Missverständnisse

“BLE hat zehn Meter Reichweite, Angreifer müssen also nah dran sein” ignoriert Richtantennen und das Telefon in der Tasche des Angreifers im selben Raum. “Die App verlangt einen Login” bedeutet nichts, wenn das Gerät nicht prüft, wer sich verbindet. Und Verschlüsselung auf der Verbindungsschicht autorisiert nichts: Ein Gerät kann vollständig verschlüsseln und trotzdem jedes gepairte Telefon das Schloss öffnen lassen.