Während des Verschlüsselungsverfahrens einer BLE-Verbindung führen der Master und der Slave einen 3-Wege-Handshake durch, um die Verschlüsselung zu validieren. Ich bin ein Fall gegenüber dem der Slave, dh die Nachricht LL_START_ENC_RSP die im folgenden Schema dieser Händedruck in Rot ist nicht das letzte Teil dieses Handshake senden:Was könnte dazu führen, dass der Slave LL_START_ENC_RSP während der BLE-Verschlüsselung nicht sendet?
für diese
Gibt es einen bestimmten Grund, passieren ? Mit spezifiziert, meine ich einen Grund, der nicht umsetzungsspezifisch ist.
Die BLE Core-Spec 4.2 sagt dieses:
Wenn der Link Layer des Slave eine LL_START_ENC_RSP PDU empfängt es wird eine LL_START_ENC_RSP PDU übertragen. Dieses Paket soll verschlüsselt gesendet werden.
Aber das gibt keine Bedingung für den Slave, dieses Paket nicht zu senden.
Wäre es zu diesem Zeitpunkt möglich, dass der Slave denkt, dass er den Langzeitschlüssel mit dem aktuellen Master verknüpft hat (denn wenn das nicht der Fall wäre, hätte der Slave den 3-Wege-Handshake nicht gestartet, richtig?), aber seine LTK ist falsch und die Entschlüsselung schlägt fehl? Wenn es passiert wäre, würde es keine Trennungsnachricht geben, statt nichts?
Da ich zu BLE ziemlich neu bin, habe ich keine Idee, wie man dieses Problem analysiert oder interpretiert, also würde jede Hilfe sehr geschätzt werden. Die Anwesenheit und Abwesenheit der Nachrichten wurde mit Hilfe eines BLE-Sniffers beobachtet.
Hinweis: Abbildung 1 ist eine Reproduktion von Abbildung 7-26 des Buches: Bluetooth Low Energy Das Entwicklerhandbuch von Robin Heydon.
Was ist der Bluetooth-Stack/Hardware, die Sie haben? – Emil
Dies ist eine Information, die ich nicht teilen kann (Firmenrichtlinie), deshalb habe ich nach einem Implementierungs-agnostischen Grund gefragt. Ich habe den Anfang einer Antwort, es scheint, dass der erste LL_START_ENC_RSP vom Master nicht vom Slave entschlüsselt werden kann, aber der Grund bleibt vage. – Tim