Bluetooth Low Energy-Gerät (BLE)

Die Implementierung des Google Schnelles Pairing Service (GFPS) für BLE-Geräte ist mit der Bluetooth Core Specification v4.2 oder höher kompatibel.

Mit dem folgenden Nachtrag zur Schnelles Pairing-Spezifikation wird die Unterstützung von Geräten, die nur Low Energy (LE) und Low Energy Audio (LEA) unterstützen, in GFPS ermöglicht.

Konformitätsstufen

Die in der Spezifikation erwähnten Schlüsselwörter „shall“, „must“, „will“, „should“, „may“ und „can“ werden unten erläutert:

Begriff Beschreibung
soll ist erforderlich für: Wird verwendet, um Anforderungen zu definieren.
muss wird verwendet, um Folgendes auszudrücken:
eine natürliche Folge einer zuvor genannten obligatorischen Anforderung
ODER
eine unbestreitbare Tatsachenbehauptung (die unabhängig von den Umständen immer zutrifft).
wird Es ist wahr, dass: Wird nur in Tatsachenbehauptungen verwendet.
sollte wird empfohlen: Wird verwendet, um anzugeben, dass unter mehreren Möglichkeiten eine als besonders geeignet empfohlen wird, aber nicht erforderlich ist.
Mai darf: Wird verwendet, um Optionen zuzulassen.
dir ist in der Lage,: Wird verwendet, um Aussagen kausal in Beziehung zu setzen.

Merkmal für die schlüsselbasierte Kopplung

Nachricht vom Suchenden an den Anbieter

Die Rohanfrage type 0x00 des Merkmals für die schlüsselbasierte Kopplung verwendet Bit 4, um anzugeben, ob der Seeker die BLE-Gerätespezifikation unterstützt, und Bit 5, um anzugeben, ob der Seeker LE Audio unterstützt.

Oktett Datentyp Beschreibung Wert Erforderlich?
0 uint8 Mitteilungsart 0x00 = Schlüsselbasierte Kopplungsanfrage Obligatorisch
1 uint8 Flags
  • Bit 0 (MSB): veraltet und wird von Seeker ignoriert.
  • Bit 1: 1, wenn der Seeker anfordert, dass der Provider die Kopplung initiiert, und diese Anfrage die BR/EDR-Adresse des Seekers enthält. Andernfalls 0.
  • Bit 2: 1, wenn der Suchende verlangt, dass der Anbieter den vorhandenen Namen angibt. Andernfalls 0.
  • Bit 3: 1, wenn dies für das nachträgliche Schreiben des Kontoschlüssels gilt. Andernfalls 0.
  • Bit 4: 1, wenn der Seeker die BLE Device Specification unterstützt. Andernfalls 0.
  • Bit 5: 1, wenn der Seeker LE Audio unterstützt. Andernfalls 0.
  • Die Bits 6 bis 7 sind für die zukünftige Verwendung reserviert und müssen ignoriert werden.
 variiert Obligatorisch
2–7 uint48 Entweder:
  • Aktuelle BLE-Adresse des Anbieters
  • Identitätsadresse des Anbieters
 variiert Obligatorisch
8–13 uint48 Adresse des Antragstellers (BR/EDR) variiert Nur präsentieren, wenn Bit 1 oder 3 für Flags festgelegt ist.
n – 15 Zufälliger Wert (Salt) variiert Obligatorisch

Nachricht vom Dienstleister an den Suchenden

Wenn Bit 4 der Anfrage festgelegt ist, kann die neue Antwortnachricht type 0x02 für das Merkmal „Schlüsselbasierte Kopplung“ verwendet werden, um dem Seeker zusätzliche Optionen für die Kopplung zu bieten.

Oktett Datentyp Beschreibung Wert
0 uint8 Mitteilungsart 0x02 = Key-based Pairing Extended Response
1 uint8 Flags
  • Bit 0 (MSB): 1, wenn der Bereitsteller nur LE unterstützt, 0 andernfalls. Wenn Bit 0 auf 1 gesetzt ist, geht der Seeker davon aus, dass Bit 1 auf 1 gesetzt ist.
  • Bit 1: 1, wenn der Anbieter die LE-Verbindung bevorzugt, andernfalls 0.
  • Bit 2: 1, wenn der Adresstyp der zweiten Adresse „Zufällig“ ist, 0, wenn „Öffentlich“.
  • Bit 3 bis 7 sind für die zukünftige Verwendung reserviert und müssen ignoriert werden.
 variiert
2 uint8 Anzahl der Adressen des Anbieters
(in der aktuellen Version ist die Anzahl 1 oder 2, da wir den Blockchiffriermodus in AES-CTR ändern müssen, wenn die Anzahl >= 3 ist)		 variiert
3–8 oder
3–14
  • Die erste Adresse muss die Identitätsadresse des primären Geräts sein und kann gebunden werden, wenn die BR/EDR-Bindung bevorzugt wird.
  • Die zweite Adresse muss die bindungsfähige Adresse des Sekundärgeräts sein, sofern dieses verfügbar ist.
 variiert
9–15 oder 15 Zufälliger Wert (Salt) variiert

Ein Anbieter, der die BLE Device Specification unterstützt, muss Bit 4 und Bit 5 lesen, um die Funktionen des Suchers zu verstehen.

  • Wenn Bit 4 = 0 ist, muss der Anbieter Bit 5 ignorieren und mit dem type 0x01-Format antworten.
  • Wenn Bit 4 den Wert 1 hat,
    • Bei einem Anbieter, der nur LE unterstützt, muss er mit type 0x02 antworten, um die LE-Verbindungspräferenz anzugeben.
    • Im Dual-Modus kann der Anbieter mit type 0x02 antworten, um entweder BR/EDR oder LE-Bonding zu bevorzugen.
  • Informationen zu LE Audio-Anbietern im Dual-Modus (LEA) finden Sie unter Beispiel: Koppeln mit einem LEA-Anbieter im Dual-Modus.

Message Stream PSM (Protocol Service Multiplexor) Characteristic

Um Nachrichtenstream für BLE-Geräte zu unterstützen, wird durch „Schnelles Pairing“ ein BLE-L2CAP-Channel zum Senden und Empfangen von Nachrichten eingerichtet und aufrechterhalten. Schnelles Pairing Der L2CAP-Server muss die LE-Credit-basierte Ablaufsteuerung implementieren.

Diese Eigenschaft ermöglicht es dem Seeker, den PSM-Wert zu lesen und dann eine sichere L2CAP-Verbindung über den PSM-Wert herzustellen.

Charakteristik des Dienstes „Schnelles Pairing“ Verschlüsselt Berechtigungen UUID
Message Stream PSM Ja Lesen FE2C1239-8366-4814-8EB0-01DE32100BEA
Oktett Datentyp Beschreibung Wert
0 uint8 Bundesland
  • 0x00 = Unbekannt. FP Seeker versucht es mehrmals.
  • 0x01 = Bereit für Verbindung
  • 0x02 = Nicht verfügbar. FP Seeker verwendet diese Komponente dieses Mal nicht für die Verbindung
 variiert
1–2 uint16 Der PSM-Wert muss zwischen 0x80 und 0xFF liegen. variiert

Hinweis:Für TWS gibt es zwei Komponenten: primär und sekundär. Die Rollen für diese Komponenten sind unter bestimmten Bedingungen austauschbar. Angenommen, A ist die primäre Komponente und B die sekundäre Komponente. Wenn sich die Batterie von Komponente A entlädt , muss Komponente B die Rolle der primären Komponente übernehmen. Dieses Szenario wird als role switch bezeichnet.

Nach role switch: Wenn der Anbieter den Fast Pair-Nachrichtenstream nicht verarbeiten kann, muss er die bestehende L2CAP-Verbindung proaktiv trennen. Der Schnelles Pairing-Sucher kann dann die L2CAP-Nachrichtenstreamverbindung mit der neuen primären Komponente wiederherstellen.

Zusätzliches Passkey-Merkmal

Diese Eigenschaft soll die zusätzlichen Komponenten vor Man-in-the-Middle-Angriffen schützen.

CSIS Fake Member MITM Protection

Für die Funktion „Schnelles Pairing“ ist im Rahmen des Pairing-Vorgangs ein Schutz vor Man-in-the-Middle-Angriffen erforderlich. Da CSIS keinen Schutz vor Man-in-the-Middle-Angriffen bietet, muss das aktuelle Design für FP für mehrere Komponenten erweitert werden, um diesen Schutz für die zusätzlichen Komponenten zu bieten.

Definition des Merkmals

Charakteristik des Dienstes „Schnelles Pairing“ Verschlüsselt Berechtigung UUID
Zusätzlicher Passkey Ja Lesen,Schreiben,Benachrichtigen FE2C123A-8366-4814-8EB0-01DE32100BEA

Nachrichten

Das Nachrichtenformat wird auf Lese-, Schreib- und Benachrichtigungsvorgänge angewendet.

Format verschlüsselter Daten

Die verschlüsselten Daten werden über die GATT-Verbindung für das schnelle Pairing gesendet.

Oktett Datentyp Beschreibung Wert
0-15 uint128 Verschlüsselter zusätzlicher Passkey-Block variiert
Rohdatenformat

Nachdem die verschlüsselten Daten mit dem gemeinsamen Secret entschlüsselt wurden, sieht das Format so aus:

Oktett Datentyp Beschreibung Wert
0 uint8 Mitteilungsart eines der folgenden:
  • 0x00 = Passkey des Suchenden
  • 0x01 = Passkey des Anbieters
1-3 uint24 6‑stelliger Passkey variiert
4–9 uint48 Adresse der Zielkomponente für die Bindung variiert
10 uint8 Statuscode, der nur für Lesevorgänge verwendet wird Eine der folgenden Optionen:
  • 0x00 = Erfolgreich
  • 0x01 = Ausstehend. FP Seeker-Wiederholung bis zum Zeitlimit
  • 0x02 = Fehler. FP Seeker-Wiederholungsversuch beenden
11–15 Zufälliger Wert (Salt) variiert

Die primäre (erste gekoppelte Komponente) ist die Brücke zwischen dem Schnellen Pairing-Sucher und den zusätzlichen Kopplungskomponenten. Das Merkmal muss den folgenden Richtlinien entsprechen:

  • Wenn der Bereitsteller eine Schreibanfrage vom Schnelles Pairing Seeker erhält, muss er
    • Adresse der zu verbindenden Komponente festlegen
    • Senden des Passkeys an die zu verbindende Komponente
    • Statuscode auf „Ausstehend“ (0x01) setzen
  • Wenn der Provider eine Leseanfrage erhält, bevor er den Passkey von der zu verbindenden Komponente erhält, muss er eine Nachricht mit
    • Passkey, beliebiger Wert
    • Adresse der zu verbindenden Komponente
    • Statuscode „Ausstehend“, 0x01
  • Bevor der Anbieter eine Benachrichtigung an den Fast Pair-Sucher sendet, legt er das Ergebnis für die Leseanfrage mit
      fest.
    • Passkey der zu verbindenden Komponente
    • Adresse der zu verbindenden Komponente
    • Erfolgsstatuscode, 0x00
  • Wenn auf Anbieterseite ein nicht behebbarer Fehler auftritt, legen Sie das Ergebnis auf
      fest.
    • Passkey, beliebiger Wert
    • Adresse der zu verbindenden Komponente
    • Fehlerstatuscode, 0x02

Weitere Informationen finden Sie im MITM-Diagramm 1 und im MITM-Diagramm 2.

Anforderungen an LE-Geräte

LE Advertising

Im auffindbaren oder nicht auffindbaren Modus muss der Anbieter RPA verwenden, um FastPair-Daten zu bewerben.

Bonding-Funktion

Bei LE-fähigen Geräten muss der Seeker eine Verbindung mit der vorhandenen LE-Verbindung herstellen. Nachdem die Überprüfung des schlüsselbasierten schnellen Pairings bestanden wurde, muss der Anbieter die Bindung mit RPA zulassen und die E/A-Funktion für die Passkey-Überprüfung des schnellen Pairings auf „DisplayYesNo“ festlegen.

Geräteanforderungen für Strafverfolgungsbehörden

LEA Advertising

Für Dual-Mode-Geräte: Im Erkennungsmodus muss der Anbieter Daten für das schnelle Pairing mit der Identitätsadresse bewerben. Im nicht erkennbaren Modus muss der Anbieter Fast Pair-Daten mit RPA bewerben. Es wird dringend empfohlen, die alte Werbung (BT 4.2) zu verwenden, um ältere Geräte für die Abwärtskompatibilität zu unterstützen. Das IRK muss immer dann geändert werden, wenn das Gerät auf die Werkseinstellungen zurückgesetzt wird.

Für Geräte ohne Dual-Modus: Im Erkennungsmodus oder im nicht erkennbaren Modus muss der Anbieter erweiterte Werbung (BT 5.0) mit RPA verwenden, um Fast Pair-Daten zu bewerben.

Die LE-verbindungsfähige Anzeige mit FP-Dienstdaten muss die CAS-UUID gemäß den Anforderungen des Bluetooth Adapter Profile (BAP 1.0.1) und des Common Audio Profile enthalten.

Der Anbieter kann die LEA-Funktion angeben, indem er die CAS-UUID (0x1853) entweder in den Dienstdaten (AD-Typ 0x16) oder in den 16-Bit-Dienstklassen-UUIDs (AD-Typ 0x02 oder 0x03) angibt, unabhängig vom Erkennungsmodus.

Bei nicht auffindbaren Anzeigen, wenn aufgrund der Einbeziehung von Akku- und SASS-Daten nicht genügend Platz in der Legacy-Anzeige vorhanden ist, muss in diesem Fall die CAS-UUID in die Scanantwort aufgenommen werden.

LEA-Bonding-Funktion

Der Seeker muss eine Verbindung mit der vorhandenen LE-Verbindung herstellen. Nachdem die auf dem Fast Pair-Schlüssel basierende Kopplungsüberprüfung bestanden wurde, muss der Dual-Mode-Anbieter die Bindung mit der Identitätsadresse und dem RPA zulassen, während der Non-Dual-Mode-Anbieter die Bindung mit dem RPA zulassen und die E/A-Funktion für die Fast Pair-Passkey-Überprüfung auf „DisplayYesNo“ festlegen muss.

Interner Kommunikationskanal zwischen Komponenten

Die bestehende GATT-Verbindung wird beibehalten, um MITM-Schutz für die zusätzlichen Komponenten zu bieten. Die primäre gekoppelte Komponente muss die Nachrichtenübermittlung zwischen dem Schnelles Pairing-Suchgerät und den verbleibenden Komponenten übernehmen.

Die interne Kommunikation wird für Initial Pair und Subsequent Pair verwendet.

  • Wenn das Verfahren zur schlüsselbasierten Kopplung auf der primären Komponente erfolgreich ist, sendet die primäre Komponente eine Nachricht, um die E/A-Funktionen der verbleibenden Komponenten zu ändern.
  • Wenn das schnelle Pairing abgeschlossen ist, muss die primäre Komponente eine Nachricht senden, um die E/A-Funktionen der verbleibenden Komponenten zurückzusetzen.
  • Wenn das Verfahren für zusätzliche Passkeys ausgeführt wird, muss die primäre Komponente die Passkey-Übermittlung zwischen dem Schnelles Pairing-Sucher und den verbleibenden Komponenten verarbeiten.

IO-Funktion ändern

  • IO-Funktion zu „DisplayYesNo“ ändern, wenn die schlüsselbasierte Kopplung erfolgreich war
    • Wenn das Gerät mehrere Komponenten hat, müssen alle Komponenten auf „DisplayYesNo“ gesetzt werden.
    • Eine Ausnahme, bei der der Anbieter die E/A-Funktion nicht in „DisplayYesNo“ ändern darf, ist Retroactive Pair. Hier ist Bit 3 der schlüsselbasierten Pairing-Anfrage auf 1 gesetzt (siehe Nachricht vom Seeker an den Anbieter).
  • IO-Funktion auf Standardeinstellung zurücksetzen
    • Erstes Koppeln
      • Wenn die LE-Verbindung getrennt wird, beende die Sitzung für das schnelle Pairing.
      • Wenn das primäre Gerät gebunden ist und innerhalb von 15 Sekunden keine zusätzliche Anfrage zum Schreiben eines Passkeys erfolgt, wird die Schnelles Pairing-Sitzung beendet.
      • Wenn eine zusätzliche Anfrage zum Schreiben eines Passkeys empfangen wird und die zu verbindende Komponente nicht innerhalb von 15 Sekunden verbunden wird, wird die Schnelles Pairing-Sitzung beendet.
      • Wenn alle Komponenten verbunden sind und innerhalb von 15 Sekunden keine Schreibanfrage für den Kontoschlüssel erfolgt, wird die Schnelles Pairing-Sitzung beendet.
      • Nachdem eine Schreibanfrage für den Kontoschlüssel empfangen wurde, wird ein Zeitlimit von 15 Sekunden festgelegt, um die Schnelles Pairing-Sitzung zu beenden.
    • Nachfolgende Kopplung
      • Wenn die LE-Verbindung getrennt wird, beende die Sitzung für das schnelle Pairing.
      • Wenn das primäre Gerät gekoppelt ist und innerhalb von 15 Sekunden keine zusätzliche Anfrage zum Schreiben von Passkeys erfolgt, wird die Schnelles Pairing-Sitzung beendet.
      • Wenn eine zusätzliche Anfrage zum Schreiben eines Passkeys empfangen wird und die zu verbindende Komponente nicht innerhalb von 15 Sekunden verbunden wird, wird die Schnelles Pairing-Sitzung beendet.
      • Wenn alle Komponenten verbunden sind, beende die Schnelles Pairing-Sitzung.

UI-Hinweis ausblenden

Wenn das Headset nicht für die Kopplung bereit ist, muss der Anbieter type 0b0010 verwenden, um die Benutzeroberflächenanzeige für Konto-Schlüsseldaten auszublenden. Dadurch wird dem Suchenden mitgeteilt, dass er keine nachfolgende Kopplungs-Benutzeroberfläche anzeigen soll (siehe Werbe-Payload: Fast Pair-Kontodaten).

Anforderungen an LE Audio-Geräte

Bluetooth-Anforderungen

Weitere Informationen finden Sie unter Android, LE Audio-Headset-Empfehlungen.

CTKD-Unterstützung

Bei Dual-Mode-Geräten ist die CTKD von LE zu BR/EDR obligatorisch und muss den BAP-Anforderungen entsprechen.

Zielmitteilung

Ein Peripheriegerät muss Targeted Announcement verwenden, um eine Verbindung von einem gekoppelten zentralen Gerät anzufordern. Gezielte Ankündigungen werden in BAP und CAP für die Verbindungsverwaltung gemäß CAP 1.0, Tabelle 8.4 (S. 48/58) definiert.

GATT EATT Server-Unterstützung

EATT ermöglicht dem zentralen Gerät, mehrere GATT-Transaktionen parallel zu senden, wenn das Gerät gebunden ist. Bei Geräten, die CSIP unterstützen, wird die Leistung der Profilverbindung verbessert und dann bald das CSIP-Bondingverfahren für die anderen Kopfhörer gestartet.

Wenn der Anbieter kein einzelnes Gerät, sondern ein koordiniertes Set mit CSIP-Implementierung ist, sollte er das in Bluetooth 5.1 definierte GATT-Caching implementieren, um die Anzahl der Dienstermittlungen zu reduzieren und die Verbindung zu beschleunigen.

Anforderungen für das schnelle Pairing

LE Advertising

Im erkennbaren oder nicht erkennbaren Modus müssen die Daten für das schnelle Pairing von der primären Komponente beworben werden, wenn das Gerät mehrere Komponenten hat. Wenn das Gerät nicht für das nachfolgende Pairing bereit ist, kann die sekundäre Komponente Daten für erweiterte Funktionen über die Funktion „Schnelles Pairing“ übertragen. Weitere Informationen finden Sie unter UI-Hinweis ausblenden.

GATT-Dienstsichtbarkeit

Die GATT-Datenbank muss für alle GATT-Verbindungen über LE-Transport gleich sein. Der LE Audio-Dienst (0x184E) muss in der GATT-Datenbank der Schnelles Pairing-Verbindung enthalten sein.

Beispiel: Kopplung mit LEA-Dual-Mode-Anbieter

Szenario 1: Der Seeker unterstützt LEA nicht.

Der Anbieter muss abwärtskompatibel mit dem Seeker sein, der LEA nicht unterstützt.

Komponenten
  • Anbieter: A2DP/HFP/LEA
  • Seeker: A2DP/HFP
Erwartetes Verhalten bei der ersten und bei nachfolgenden Kopplungen
  • Der Anbieter bewirbt Fast Pair-Dienstdaten (0xFE2C) mit der Identitätsadresse (anfangs) oder der RPA (später).
    • Alte Werbefunktionen verwenden
  • Der Suchende erhält die Anzeige des Anbieters mit der Identitätsadresse für die erste oder RPA für die nachfolgende Kopplung.
  • Der Suchende sendet eine Anfrage zum schlüsselbasierten Koppeln 
      .
    • Das Flag-Bit 5 der Anfrage zum schlüsselbasierten Koppeln ist auf 0 gesetzt.
  • Der Anbieter sendet die Antwort für die schlüsselbasierte Kopplung mit der öffentlichen Adresse in einem der folgenden Formate:
    • Wenn der Nachrichtentyp 0x01 verwendet wird, muss die Adresse eine öffentliche Adresse sein.
    • Wenn der Nachrichtentyp 0x02 verwendet wird
      • Bit 0 muss 0 sein
      • Bit 1 muss 0 sein
      • Die Adresse muss eine öffentliche Adresse sein.
  • Der Seeker stellt eine Verbindung mit dem BR/EDR-Transport her.
    • Die E/A-Funktion ist für BR/EDR auf „DisplayYesNo“ festgelegt.
  • Der Seeker und der Provider führen das Passkey-Bestätigungsverfahren für „Schnelles Pairing“ durch.

Szenario 2: Der Suchende unterstützt LEA

Komponenten
  • Anbieter
    • Unterstützung von A2DP/HFP/LEA
    • Einzelne Komponente
  • Suchender
    • Unterstützung von A2DP/HFP/LEA
Erwartetes Verhalten bei der ersten und bei nachfolgenden Kopplungen
  • Der Anbieter bewirbt Fast Pair-Dienstdaten (0xFE2C) mit der Identitätsadresse (anfangs) oder der RPA (später).
    • Alte Werbefunktionen verwenden
  • Der Suchende sendet eine Anfrage zum schlüsselbasierten Koppeln 
      .
    • Das Flag-Bit 5 der Anfrage zum schlüsselbasierten Koppeln ist auf 1 gesetzt.
  • Der Anbieter sendet eine Antwort auf die schlüsselbasierte Kopplung mit dem Nachrichtentyp 0x02.
    • Bit 0 muss 0 sein
    • Bit 1 muss 1 sein
    • Die Adresse ist die Identitätsadresse.
  • Der Seeker stellt eine Verbindung mit der vorhandenen LE-Verbindung auf dem LE-Transport her.
    • Die CTKD-Richtung verläuft von LE nach BR/EDR.
    • Die E/A-Funktion ist für LE auf „DisplayYesNo“ festgelegt.
  • Der Seeker und der Provider führen das Passkey-Bestätigungsverfahren für „Schnelles Pairing“ durch.

Szenario 3: Der Suchende unterstützt die Strafverfolgungsbehörde und das CSIP ist beteiligt

Komponenten
  • Anbieter
    • Unterstützung von A2DP/HFP/LEA
    • Mehrere Komponenten
      • Die primäre Komponente ist BR/EDR/LE.
      • Die sekundäre Komponente ist nur für LE verfügbar.
  • Suchender
    • Unterstützung von A2DP/HFP/LEA
Erwartetes Verhalten bei der ersten und bei nachfolgenden Kopplungen
  • Die primäre Komponente bewirbt die Schnelles Pairing-Dienstdaten (0xFE2C) mit der Identitätsadresse (anfänglich) oder der RPA (später).
    • Alte Werbefunktionen verwenden
  • Der Seeker sendet eine Key-based Pairing-Anfrage an die primäre Komponente.
    • Das Flag-Bit 5 der Anfrage zum schlüsselbasierten Koppeln ist auf 1 gesetzt.
  • Die primäre Komponente sendet eine Antwort für die schlüsselbasierte Kopplung mit dem Nachrichtentyp 0x02.
    • Bit 0 muss 0 sein
    • Bit 1 muss 1 sein
    • Die Adressen lauten:
      • Die erste Adresse ist die Identitätsadresse der primären Komponente.
      • Die zweite Adresse ist die bindungsfähige Adresse für die sekundäre Komponente. Die zweite Komponente verwendet diese Adresse auch für die CSIP-Ankündigung.
  • Der Tracker stellt über die vorhandene LE-Verbindung eine Verbindung zur primären Komponente her.
    • Die CTKD-Richtung verläuft von LE nach BR/EDR.
    • Die E/A-Funktion ist für LE auf „DisplayYesNo“ festgelegt.
  • Der Seeker stellt eine Verbindung mit der sekundären Komponente her, deren Adresse aus der erweiterten Antwort für die schlüsselbasierte Kopplung stammt.
    • Die E/A-Funktion muss „DisplayYesNo“ sein. Andernfalls wird die Kopplungsanfrage abgelehnt.
  • Der Seeker und der Provider führen das MITM-Schutzverfahren zum Koppeln der sekundären Komponente durch. Der Provider muss beide Szenarien implementieren.
  • Der Seeker wartet, bis er mit der sekundären Komponente verbunden ist.

Sequenzdiagramm für MITM

In dieser Sitzung wird die Reihenfolge der MITM-Schutzmaßnahmen beschrieben.

Passkey über Benachrichtigung von der zu verbindenden Komponente abrufen

Passkey aus der Komponente abrufen, die durch Lesen gebunden wird

Bekanntes Problem

FP for LEA wurde für Android V(Android 15) optimiert.

Umgekehrt sind uns zahlreiche Probleme mit Headsets aufgefallen, die LEA unterstützen, aber nicht die richtige Schnelles Pairing-Implementierung über LEA haben (d.h. nur Schnelles Pairing über Classic). Das ist beispielsweise der Fall, wenn die RPA des Anbieters nicht mit dem richtigen Identity Resolving Key (IRK) generiert wird und die Adresse nicht aufgelöst werden kann. Wir konnten zwar keine umfassende Liste von Headset-Konfigurationen testen, aber unsere eingeschränkten Tests haben verschiedene Probleme ergeben, darunter das Nichtanzeigen von Benachrichtigungen zum Akkustand der Kopfhörer, das Fehlen der Funktion „Audio Switching“ (SASS), weitverbreitete Probleme beim ersten und nachfolgenden Pairing und mehr.

Daher empfehlen wir Partnern dringend, die Fast Pair-LEA-Spezifikation sowohl für neue Geräte als auch für vorhandene Geräte, die Dual-Modi unterstützen, zu implementieren (über Over-the-Air-Updates).