Engineering

BLE-Pairing-Sicherheit: Verschlüsselung verrät nicht, mit wem Sie reden

„Die Verbindung ist verschlüsselt" beantwortet die kleinere Frage. Die größere: verschlüsselt mit wem? Die vier BLE-Pairing-Methoden im Vergleich, was jede über Vertrauen voraussetzt, was Legacy-Pairing verrät und die Fehler aus Wireless-Assessments.

14.05.2026 · 8 Min. Lesezeit · Dr. Ewan Fleischmann

Cryptography Wireless

Bluetooth-Low-Energy-Geräte beenden ihre Security-Story fast immer gleich: „Die Verbindung ist verschlüsselt." Das ist meist wahr, und es beantwortet die kleinere der zwei Fragen, die eine Funkverbindung aufwirft. Die größere: verschlüsselt mit wem? Pairing ist der Moment, in dem Ihr Gerät entscheidet, wer seine Verschlüsselungs-Keys verdient, und es ist der Moment, den wir in jedem Wireless-Assessment zuerst angreifen, weil Produkte hier Vertrauen mit der geringsten Sorgfalt entscheiden.

Diese Note vergleicht die BLE-Pairing-Methoden, zeigt, was jede voraussetzt, und listet die Fehler, die wir immer wieder in Produkten finden, die „sicher" paaren.

Die Pairing-Methoden, ehrlich verglichen

BLE bietet vier Assoziationsmodelle. Die Unterschiede zählen weniger in der Theorie als in dem, was jede vom Nutzer und von der Hardware verlangt, gehen Sie die Matrix durch und beachten Sie die MITM-Spalte.

PAIRING METHODS WHO IS ON THE OTHER SIDE?

MITM ASSUMES TRUST BECAUSE

NO ... nichts. Bequemlichkeit.

SCHWACH ... der Nutzer die Zahl korrekt überträgt.

YES ... Nutzer vergleicht zwei Zahlen.

YES ... der Zweitkanal nicht selbst angreifbar ist.

↓

Encryption beantwortet: kann jemand mithören? Pairing beantwortet: mit wem rede ich überhaupt? Zwei verschiedene Fragen.

Just Works ist der Default der Bequemlichkeit: keine Interaktion, keine Authentifizierung, kein Schutz gegen einen Angreifer, der beim Pairing dabeisteht. Passkey ergänzt ein sechs-stelliges Geheimnis, nützlich nur, wenn die Zahl wirklich out-of-band reist (Display auf einem Gerät, getippt auf dem anderen) und katastrophal, wenn sie im Handbuch steht. Numeric Comparison lässt unter LE Secure Connections beide Seiten einen Wert zeigen, den der Nutzer vergleicht. MITM-resistent, weil ein Mann in der Mitte nicht beide Displays zur Übereinstimmung bringen kann. Out-of-Band nimmt die Pairing-Daten über einen zweiten Kanal (NFC, QR, Kabel) und ist am stärksten, wenn dieser Kanal das Vertrauen verdient.

Legacy-Pairing vs. LE Secure Connections

Das folgenreichste Detail der BLE-Sicherheit ist die Pairing-Generation des Produkts. Legacy-Pairing (vor Bluetooth 4.2) leitet den Link-Key vom TK ab, ein sechs-stelliger Temporary Key mit rund 20 Bit Entropie. Ein passiver Mitschnitt des Pairing-Austauschs plus Offline-Brute-Force liefert den Link-Key, und damit jede Session, die er geschützt hat. LE Secure Connections (ECDH) schließt exakt dieses Loch: Das Key Agreement ist ein Elliptic-Curve-Austausch, passives Mitschneiden bricht ihn nicht mehr. Produkte mit Legacy-Pairing sind 2026 keine Seltenheit. Wir finden sie, indem wir ein Pairing mitschneiden; das dauert Minuten.

Verschlüsselung beantwortet: Kann jemand mithören? Pairing beantwortet: Mit wem rede ich überhaupt? Ein Produkt, das nur die erste Frage beantwortet, führt ein privates Gespräch mit dem, der zuerst da war.

Was Verschlüsselung nicht schützt

Auch eine perfekt gepairte, ECDH-verschlüsselte Verbindung lässt Arbeit offen:

Identität. Verschlüsselung etabliert einen geteilten Key, keine geprüfte Identität. Ein Gerät, das Pairing von jedem akzeptiert, vertraut weiterhin jedem, die Verschlüsselung macht nur den Verkehr des Hochstaplers privat.
Replay. Verschlüsselte Kommandos lassen sich aufzeichnen und erneut senden. Replay-Schutz ist eine Protokolldesign-Entscheidung. Sequenznummern, Counter, Nonces, unabhängig von der Chiffre.
Autorisierung. Nach dem Pairing behandeln viele Produkte die Gegenseite für immer als vertrauenswürdig. Ein verlorenes Telefon, ein erbeuteter Sensor, ein geflashtes Gerät, alle noch gepairt. Bonding-Lebenszeiten und Re-Authentifizierung für privilegierte Operationen sind die Stelle, an der die echte Zugriffskontrolle liegt.
Key-Speicher. Der LTK liegt am Ende auf beiden Seiten gespeichert. Wo das Gerät ihn hält, lesbarer Flash oder Secure Element, entscheidet, ob physischer Zugriff den Funkkanal wieder öffnet. Siehe Secure Element vs. Secure Storage.

Fehler, die wir in Produkt-Assessments finden

Wiederkehrende Befunde, grob nach Häufigkeit: Just-Works-Pairing für ein Produkt, das danach privilegierte Kommandos akzeptiert; derselbe Passkey, für die ganze Produktlinie im Handbuch abgedruckt; Legacy-Pairing für „Kompatibilität" noch aktiviert, das jede Verbindung mit einem alten Handy herunterstuft; Bonding, das nie abläuft und nie re-authentifiziert; Debug-Services in der Produktions-Firmware, die auf Anfrage zurück in den Pairing-Mode fallen; und Session-Keys, die Reboots überdauern, ein einziger Flash-Zugriff entschlüsselt monatelang aufgezeichneten Verkehr.

Den eigenen Pairing-Flow testen

Für einen Belastungstest der Vertrauensentscheidung braucht es kein Labor. Paaren Sie mit dem Gerät, während Sie den Austausch mitschneiden, erzwingt irgendetwas Legacy-Pairing? Paaren Sie von einem zweiten, unberechtigten Telefon, solange das legitime außer Reichweite ist, was ist das Gerät zu verhandeln bereit? Senden Sie ein aufgezeichnetes privilegiertes Kommando nach dem Neu-Pairing noch einmal, merkt das Protokoll es? Entkoppeln und neu paaren mit modifizierter advertised Identity, bindet irgendetwas die Identität an die Verschlüsselung? Jeder dieser Tests hat echte Produkte geschlossen; jeder dauert unter einer Stunde. Übersteht Ihre Pairing-Story alle vier, ist sie wahrscheinlich ehrlich. Kann in Ihrer Firma niemand beantworten, wie das Gerät entscheidet, wem es vertraut, dann ist genau das der Befund.