Pairing ist der Moment, in dem ein Produkt entscheidet, wem es vertraut, und meist der am wenigsten untersuchte Moment im Design. „Just Works“-Modi authentisieren nichts: Forschung zeigt, dass die meisten Consumer- und sogar Industrial-IoT-Geräte mit Pairing ausliefern, das keinen Schutz gegen Man-in-the-Middle bietet. Das Gerät authentisiert sich; der Controller nicht.
Die Folge ist nicht theoretisch. Ein Pairing-Prozess, der das Produkt verifiziert, den Controller aber nicht bindet, erlaubt einem Angreifer, sich als neuer Peer zu enrollieren und die Trust-Beziehung zu erben. Von dort regiert die Protokoll-State-Machine, was der Angreifer erreicht, und State Machines, die für Nutzer-Komfort gebaut sind, nicht für Adversaries, exponieren routinemäßig privilegierte Kommandos in frühen oder Recovery-Zuständen.
Selbst korrekt gepaarte Sessions treffen auf Replay und Spoofing: Ein erfasstes, zustandsänderndes Kommando wird erneut gesendet, weil Frische nicht erzwungen wird; eine gefälschte Peer-Identität wird akzeptiert, weil die Trust-Entscheidung Präsenz prüft, nicht Bindung. Verschlüsselung ohne Authentisierungs-Policy ist ein versiegelter Umschlag, der an jeden ausgeliefert wird, der fragt.
Wireless-Vertrauen hängt von mehreren technischen Annahmen ab.
- Discovery-Exposition Ist das Gerät für jeden discoverable, und was leakt der Austausch vor der Authentisierung?
- Pairing-Modus Welcher Modus wird genutzt (Just Works, Passkey, Numeric Comparison, OOB), und authentisiert er tatsächlich beide Peers?
- Peer-Binding Bindet das Protokoll den richtigen Controller, oder wird der nächste Anfrager enrolliert?
- Frische & Replay Werden Sequenznummern, Nonces oder Zähler auf zustandsändernden Kommandos erzwungen?
- Spoofing-Widerstand Kann eine gefälschte Peer-Identität am Trust-Entscheidungspunkt akzeptiert werden?
- State-Machine-Exposition Welche Kommandos sind in jedem Protokoll-Zustand verfügbar, einschließlich früher, Recovery- und Fehler-Zustände?
- Autorisierung nach Pairing Bekommt der vertraute Peer alles, oder ist privilegierte Funktionalität separat autorisiert?
Einmal gepaart, für immer vertraut, gesteuert von jedem Nächsten.
Das Produkt authentisiert sich beim Pairing. Der Controller wird nicht stark gebunden. Ein Angreifer in Funk-Reichweite enrolliert sich im nächsten Pairing-Fenster als neuer Peer, das Protokoll akzeptiert, weil Enrollment genau das ist, was Pairing tut.
Mit etablierter Trust-Beziehung erreicht der Angreifer den autorisierten Kommando-Satz. Die State Machine war auf Komfort gebaut: Frühe Zustände exponieren bereits Konfiguration. Keine kryptografische Prüfung schlägt fehl, die Trust-Entscheidung hat nur die falsche Frage beantwortet.
Die Trust-Beziehung angreifen, nicht nur das Funk.
Wir testen Pairing als das, was es ist: eine Trust-Entscheidung. Enrollment als Angreifer, Replay erfasster Kommandos gegen Frische-Erzwingung, Spoofing von Peer-Identitäten am Entscheidungspunkt, und das Abgehen der Protokoll-State-Machine, um zu finden, welche Zustände privilegiertes Verhalten freigeben.
- Neues Funkprodukt vor dem Release
- Neuer Pairing- oder Onboarding-Prozess
- Mobile-Applikation steuert ein physisches Produkt
- Geräte-zu-Gerät-Kommunikation eingeführt
- Re-Pairing- oder Reset-Verhalten geändert
- Eine gemeldete Schwachstelle betrifft Pairing, Replay oder RF-Verhalten
- Compliance oder Kunden-Assurance verlangt Wireless-Security-Nachweise