Bluetooth Low Energy (BLE)-Gerät
Die GFPS-Implementierung (Fast Pair Service) von Google für BLE-Geräte ist mit Bluetooth Core Specification v4.2 oder höher kompatibel.
Der folgende Zusatz zur Spezifikation für schnelles Pairing ermöglicht die Unterstützung nur für Low Energy (LE)- und Low Energy Audio (LEA)-Geräte in GFPS.
Konformitätsstufen
Die in der Spezifikation erwähnten Keywords „sollte“, „muss“, „wird“, „sollten“, „kann“ und „kann“ lauten:
| Laufzeit | Beschreibung |
|---|---|
| soll | is required to – wird zum Definieren von Anforderungen verwendet. |
| muss | wird verwendet, um Folgendes auszudrücken: eine natürliche Folge einer zuvor genannten obligatorischen Anforderung ODER eine nicht anfechtbare Tatsachenbehauptung (eine, die unabhängig von den Umständen immer wahr ist). |
| Aktion | Stimmt es, dass es nur in Tatsachenbehauptungen verwendet wird. |
| sollte | wird empfohlen – wird verwendet, um anzugeben, dass eine Option aus mehreren Gründen als besonders geeignet, aber nicht erforderlich ist, empfohlen wird. |
| Mai | is allowed to – wird verwendet, um Optionen zuzulassen. |
| kann | kann – damit eine Aussage kausal zugeordnet werden. |
Merkmal der schlüsselbasierten Kopplung
Nachricht vom Suchenden an den Anbieter
Für die Rohanfrage type 0x00 des Merkmals „Schlüsselbasierte Kopplung“ wird Bit 4 verwendet
um anzugeben, ob der Seeker die BLE Device Specification unterstützt und
Bit 5, um anzugeben, ob der Seeker LE Audio unterstützt.
| Oktett | Datentyp | Beschreibung | Wert | Obligatorisch? |
|---|---|---|---|---|
| 0 | uint8 |
Nachrichtentyp | 0x00 = Schlüsselbasierte Anfrage zur Kopplung |
Obligatorisch |
| 1 | uint8 |
Markierungen
|
variiert | Obligatorisch |
| 2–7 | uint48 |
Sie haben folgende Möglichkeiten:
|
variiert | Obligatorisch |
| 8–13 | uint48 |
BR/EDR-Adresse des Suchers | variiert | Nur vorhanden, wenn Flags Bit 1 oder 3 festgelegt sind |
| n: 15 | Zufälliger Wert (Salt) | variiert | Obligatorisch |
Nachricht vom Anbieter an den Sucher
Wenn Bit 4 der Anfrage gesetzt ist, wird die neue Antwortnachricht type 0x02 für
Die Eigenschaft schlüsselbasierter Kopplung kann für zusätzliche Bindungen verwendet werden
Optionen für den Seeker.
| Oktett | Datentyp | Beschreibung | Wert |
|---|---|---|---|
| 0 | uint8 |
Nachrichtentyp | 0x02 = Erweiterte Antwort für schlüsselbasiertes Pairing |
| 1 | uint8 |
Markierungen
|
variiert |
| 2 | uint8 |
Anzahl der Adressen des Anbieters (in der aktuellen Version lautet die Zahl 1 oder 2, da wir den Blockverschlüsselungsmodus in AES-CTR ändern müssen, wenn die Zahl größer als 3 ist) |
variiert |
| 3–8 oder 3–14 |
|
variiert | |
| 9–15 oder 15 | Zufälliger Wert (Salt) | variiert |
Ein Anbieter, der die BLE-Gerätespezifikation unterstützt, muss Bit 4 und Bit 5 lesen. um die Fähigkeiten des Seekers
- Wenn Bit 4 0 ist, ignoriert der Provider Bit 5 und antwortet mit dem Format
type 0x01 - Wenn Bit 4 1 ist,
- Bei einem LE-Anbieter muss er mit
type 0x02antworten, um LE anzuzeigen. Bindungsvorlieben. - Beim Dual-Modus-Anbieter kann er mit
type 0x02antworten, um entweder BR/EDR- oder LE-Bindungspräferenz.
- Bei einem LE-Anbieter muss er mit
- Informationen zu LEA-Dual-Modus-Anbietern finden Sie unter Beispiel: Kopplung mit LEA-Dual-Modus-Anbieter
Charakteristik der Nachrichtenstream-PSM (Protocol Service Multiplexor)
Um den Nachrichtenstream für BLE-Geräte zu unterstützen, wird über das schnelle Pairing Sie müssen einen BLE L2CAP-Kanal zum Senden und Empfangen von Nachrichten unterhalten. Schnelles Pairing Der L2CAP-Server muss die Datenflusssteuerung mithilfe von LE-Guthaben implementieren.
Dieses Merkmal ermöglicht es dem Seeker, den PSM-Wert zu lesen und dann sichere L2CAP-Verbindung durch den PSM-Wert.
| Merkmal des Dienstes für schnelles Pairing | Verschlüsselt | Berechtigungen | UUID |
|---|---|---|---|
| Nachrichtenstream – PSM | Ja | Lesen | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Oktett | Datentyp | Beschreibung | Wert |
|---|---|---|---|
| 0 | uint8 |
Bundesland
|
variiert |
| 1–2 | uint16 |
Der PSM-Wert muss im Bereich zwischen 0x80 und 0xFF liegen. | variiert |
Hinweis:Für TWS gibt es zwei
primären und sekundären Komponenten. Die Rolle für diese Komponenten
unter bestimmten Bedingungen austauschbar sind. Angenommen, A ist die Hauptkomponente und B ist
Sekundärkomponente, da sich der Akku von Komponente A entlädt , benötigt Komponente B
, um die Rolle der primären Komponente zu übernehmen. Dieses Szenario heißt role switch.
Nach dem role switch, wenn der Anbieter
den Nachrichtenstream über „Schnelles Pairing“ nicht verarbeiten kann, wird die Verbindung
bestehende L2CAP-Verbindung. Wer auf der Suche nach schnellem Pairing ist, kann anschließend L2CAP neu festlegen.
Message Stream-Verbindung mit der neuen primären Komponente.
Zusätzliche Passkey-Eigenschaft
Diese Eigenschaft soll MITM-Schutz auf den zusätzlichen Komponenten.
MITM-Schutz für gefälschte CSIS-Mitglieder
Die Funktion „Schnelles Pairing“ erfordert im Rahmen des Kopplungsvorgangs einen MITM-Schutz. Als CSIS bietet keinen MITM-Schutz, das aktuelle Design für FP für mehrere Komponenten erweitert werden müssen, um MITM-Schutz auf den zusätzlichen Komponenten.
Charakteristische Definition
| Merkmal des Dienstes für 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.
Verschlüsseltes Datenformat
Die verschlüsselten Daten werden über eine GATT-Verbindung für schnelles Pairing gesendet.
| Oktett | Datentyp | Beschreibung | Wert |
|---|---|---|---|
| 0-15 | uint128 | Verschlüsselter zusätzlicher Passkey blockiert | variiert |
Rohdatenformat
Nachdem die verschlüsselten Daten mit dem gemeinsamen Secret entschlüsselt wurden, gilt folgendes Format:
| Oktett | Datentyp | Beschreibung | Wert |
|---|---|---|---|
| 0 | uint8 | Nachrichtentyp | einer von
|
| 1-3 | uint24 | 6-stelliger Passkey | variiert |
| 4-9 | uint48 | Adresse der Zielbindungskomponente | variiert |
| 10 | uint8 | Statuscode, wird nur vom Lesevorgang verwendet | Eine von
|
| 11–15 | Zufälliger Wert (Salt) | variiert |
Die primäre Verbindung (erste verbundene Komponente) ist die Brücke zwischen schnellem Pairing. Seeker und die zusätzlichen Bindungskomponenten. Das Merkmal sollte Richtlinien befolgen:
- Wenn der Anbieter eine Schreibanfrage vom Fast Pair Seeker erhält, muss er
- Adresse der zu bindenden Komponente festlegen
- Passkey an die zu verknüpfende Komponente senden
- Statuscode auf "Ausstehend, 0x01" setzen
- Wenn eine Leseanfrage empfangen wird, bevor der Passkey von der Komponente empfangen wird
hat der Dienstleister eine Nachricht mit
- Passkey, beliebiger Wert
- Adresse der zu bindenden Komponente
- Statuscode ausstehend, 0x01
- Bevor der Anbieter eine Benachrichtigung an den Sucher von „Schnelles Pairing“ sendet, legt das Ergebnis fest
für die Leseanfrage mit
- Passkey der Komponente, die verbunden wird
- Adresse der zu bindenden Komponente
- Statuscode für Erfolg, 0x00
- Bei einem nicht behebbaren Fehler auf Anbieterseite, Ergebnis festlegen
- Passkey, beliebiger Wert
- Adresse der zu bindenden Komponente
- Fehlerstatuscode, 0x02
Siehe MITM-Diagramm 1 und Weitere Informationen finden Sie in MITM-Diagramm 2.
LE-Geräteanforderungen
LE-Werbung
Für den Modus „Sichtbar“ oder „Nicht sichtbar“ muss der Anbieter RPA verwenden, um FastPair-Daten bewerben
Bonding-Fähigkeit
Bei LE-fähigen Geräten muss der Seeker eine Bindung zum bestehenden LE-Verbindung. Nach erfolgreicher schlüsselbasierter Kopplung über das schnelle Pairing Der Anbieter muss Bindungen mit RPA zulassen und die E/A-Funktion auf DisplayYesNo setzen zur Überprüfung eines Passkeys über die Funktion „Schnelles Pairing“.
LEA-Geräteanforderungen
LEA-Werbung
Für Geräte im Dual-Modus: Im sichtbaren Modus bewirbt der Anbieter Daten über schnelles Pairing mit der Identitäts- Adresse. Im Modus „Nicht auffindbar“ bewirbt der Anbieter Daten über schnelles Pairing mit RPA. Es wird dringend empfohlen, älteres Advertising (BT 4.2) zur Unterstützung älterer für die Abwärtskompatibilität. Der IRK muss bei jedem Zurücksetzen des Geräts auf die Werkseinstellungen geändert werden.
Für Geräte ohne Dual-Modus: Für den Modus „Sichtbar“ oder „Nicht sichtbar“ muss der Anbieter erweiterte Advertising (BT 5.0) mit RPA, um FastPair-Daten zu bewerben.
Die LE-Anzeige, die FP-Dienstdaten enthält, muss Folgendes enthalten: CAS-UUID gemäß das Bluetooth Adapter Profile (BAP 1.0.1) und Gemeinsames Audioprofil Anforderung. Für nicht sichtbare Werbung, wenn nicht genügend Platz verfügbar ist in der alten Werbung berücksichtigt, weil sie Akku- und SASS-Daten enthält, ist in diesem Fall obligatorisch, die CAS-UUID in die Scanantwort aufzunehmen.
LEA-Bindungsfunktion
Der Seeker muss eine Bindung zur vorhandenen LE-Verbindung herstellen. Nach bestandener Prüfung Bestätigung über eine schlüsselbasierte Kopplung (schnelles Pairing) muss der Dual-Modus-Anbieter Verknüpfung mit Identitätsadresse und RPA, während der Anbieter ohne Dual-Modus Verbindung mit RPA und E/A-Funktion für schnelles Pairing auf DisplayYesNo Passkey-Überprüfung
Interner Kommunikationskanal zwischen Komponenten
Die bestehende GATT-Verbindung wird beibehalten, um den MITM-Schutz auf dem zusätzliche Komponenten. Die primär verbundene Komponente soll die Nachricht verarbeiten. Übermittlungen zwischen „Fast Pair Seeker“ und seinen verbleibenden Komponenten.
Die interne Kommunikation wird für Initial Pair und Subsequent Pair verwendet
- Wenn die Prozedur der schlüsselbasierten Kopplung für die Hauptkomponente erfolgreich ist, wird die primäre Komponente sendet eine Nachricht, um die E/A-Kapazität der verbleibenden Komponenten
- Wenn die Funktion „Schnelles Pairing“ abgeschlossen ist, sendet die Hauptkomponente eine Nachricht zum Zurücksetzen. E/A-Kapazität der verbleibenden Komponenten
- Beim Ausführen eines zusätzlichen Passkey-Verfahrens muss die Hauptkomponente Passkey-Übermittlungen zwischen „Fast Pair Seeker“ und seinen verbleibenden Komponenten
Zeit zum Ändern der E/A-Funktion
- E/A-Funktion in DisplayYesNo ändern, wenn die schlüsselbasierte Kopplung erfolgreich abgeschlossen wurde
- Wenn das Gerät über mehrere Komponenten verfügt, müssen alle Komponenten auf DisplayYesNo
- Eine Ausnahme, dass der Dienstleister
die E/A-Funktion nicht in DisplayYesNo ändern, ist
Retroactive Pair, dessen Bit 3 der schlüsselbasierten Kopplungsanfrage auf 1 gesetzt ist, siehe Nachricht vom Sucher an den Anbieter
- E/A-Funktion auf Standardeinstellung ändern
- Erstkopplung
- Wenn die LE-Verbindung getrennt ist, „Schnelles Pairing“ beenden
- Nach der Verknüpfung der primären Instanz, falls kein zusätzlicher Passkey erstellt wurde Anfrage in 15 Sekunden, „Schnelles Pairing“ beenden
- Wenn eine zusätzliche Passkey-Schreibanfrage eingeht und die Komponente wird nicht innerhalb von 15 Sekunden verbunden, „Schnelles Pairing“-Sitzung beenden
- Nachdem alle Komponenten verbunden wurden, wenn kein Kontoschlüssel geschrieben wurde Anfrage innerhalb von 15 Sekunden, Sitzung mit schnellem Pairing beenden
- Nachdem die Anfrage zum Schreiben des Kontoschlüssels eingegangen ist, stellen Sie das Zeitlimit 15 Sekunden ein auf Sitzung mit schnellem Pairing beenden
- Nachfolgende Kopplung
- Wenn die LE-Verbindung getrennt ist, „Schnelles Pairing“ beenden
- Nach der Verknüpfung der primären Instanz, falls kein zusätzlicher Passkey erstellt wurde Anfrage innerhalb von 15 Sekunden, Sitzung mit schnellem Pairing beenden
- Wenn eine zusätzliche Passkey-Schreibanfrage eingeht und die Komponente wird nicht innerhalb von 15 Sekunden verbunden, „Schnelles Pairing“-Sitzung beenden
- Wenn alle Komponenten verbunden sind, Sitzung für schnelles Pairing beenden
- Erstkopplung
UI-Anzeige ausblenden
Wenn das Headset nicht zum Koppeln bereit ist, verwendet der Anbieter type 0b0010
zum Ausblenden von UI-Hinweisen für Kontoschlüsseldaten, um den Sucher anzuweisen,
UI für nachfolgende Kopplung (siehe Werbenutzlast: Kontodaten für schnelles Pairing)
Geräteanforderungen für LE Audio
Bluetooth-Anforderungen
Weitere Informationen zu Headsets für Android und LE Audio
CTKD-Support
Für Geräte im Dual-Modus ist CTKD von LE zu BR/EDR obligatorisch und entspricht den BAP
Zielankündigung
Peripheriegerät muss eine gezielte Mitteilung verwenden, um eine Verbindung herzustellen. über ein gekoppeltes zentrales Gerät. Gezielte Ankündigungen sind in BAP und CAP definiert. für das Verbindungsmanagement gemäß CAP 1.0 Tabelle 8.4 (S. 48/58).
Support für GATT EATT-Server
Mit EATT kann das zentrale Gerät mehrere GATT-Transaktionen parallel senden wenn das Gerät verbunden ist. Für das Gerät, das CSIP unterstützt, wird es erhöht die Leistung der Profilverbindung, um dann bald mit der CSIP-Bindung zu beginnen Verfahren für die anderen Kopfhörer.
Robustes GATT-Caching (dringend empfohlen)
Wenn es sich beim Anbieter nicht um ein einzelnes Gerät handelt, sondern um einen mit der CSIP-Implementierung koordinierten Satz, um die Anzahl der und beschleunigen die Verbindung, sollte der Provider die in Bluetooth 5.1 definierte GATT-Caching implementieren.
Anforderungen für das schnelle Pairing
LE-Werbung
Im Modus „Erkennbar“ oder „Nicht sichtbar“, wenn das Gerät mehrere Komponenten werden von der Hauptkomponente beworben. Wenn die nicht für eine nachfolgende Kopplung bereit ist, kann die Sekundärkomponente Daten über die Funktion „Schnelles Pairing“ für erweiterte Funktionen bewerben. Siehe UI-Anzeige ausblenden
Sichtbarkeit des GATT-Dienstes
GATT-Datenbank muss für alle LE-Transport-GATT-Verbindungen gleich sein. Le Audio (0x184E) muss in der GATT-Datenbank für Verbindungen über schnelles Pairing enthalten sein.
Beispiel: Kopplung mit LEA-Dual-Modus-Anbieter
Szenario 1 – Wenn der Seeker LEA nicht unterstützt
Der Anbieter muss mit dem Seeker abwärtskompatibel sein, unterstützen LEA.
Komponenten
- Anbieter: A2DP/HFP/LEA
- Sucher: A2DP/HFP
Erwartetes Verhalten für erstes und nachfolgendes Paar
- Der Anbieter wirbt für den Dienst „Schnelles Pairing“.
Daten (0xFE2C) mit der Identitätsadresse (Initiale) oder RPA (nachfolgend) hinzu.
- Bisherige Werbung verwenden
- Der Seeker empfängt die Anzeige mit Identitätsadresse für die Anfangs- oder RPA-Angabe für die nachfolgende Kopplung
- Der Seeker sendet eine schlüsselbasierte Kopplungsanfrage
- Flag Bit-5 einer Anfrage für eine schlüsselbasierte Kopplung ist auf 0 gesetzt
- Der Anbieter sendet eine schlüsselbasierte Kopplungsantwort mit einer öffentlichen Adresse in einer der
Folgendes:
- Wenn der Nachrichtentyp 0x01 verwendet wird, muss die Adresse eine öffentliche Adresse sein.
- Wenn der Nachrichtentyp 0x02 verwendet wird
- Bit-0 wird 0 sein.
- Bit-1 muss 0 sein.
- Bei der Adresse muss es sich um eine öffentliche Adresse handeln.
- The Seeker baut eine Bindung zum BR/EDR-Verkehr auf
- E/A-Funktion für BR/EDR auf DisplayYesNo
- Der Sucher und der Anbieter führen einen Passkey für das schnelle Pairing durch.
Szenario 2 – Wenn der Seeker LEA unterstützt
Komponenten
- Anbieter
- Unterstützung von A2DP/HFP/LEA
- Einzelne Komponente
- Suchender
- Unterstützung A2DP/HFP/LEA
Erwartetes Verhalten für erstes und nachfolgendes Paar
- Der Anbieter wirbt für den Dienst „Schnelles Pairing“.
Daten (0xFE2C) mit der Identitätsadresse (Initiale) oder RPA (nachfolgend) hinzu.
- Bisherige Werbung verwenden
- Der Seeker sendet eine schlüsselbasierte Kopplungsanfrage
- Flag Bit-5 einer Anfrage für eine schlüsselbasierte Kopplung ist auf 1 gesetzt
- Der Anbieter sendet eine schlüsselbasierte Kopplungsantwort mit dem Nachrichtentyp 0x02
- Bit-0 wird 0 sein.
- Bit-1 muss 1 sein.
- Die Adresse lautet „Identity Address“.
- Der Seeker schafft eine Bindung zum Vorhandenen
LE-Anschluss in LE Transportation
- CTKD-Richtung ist von LE nach BR/EDR
- E/A-Funktion für LE auf DisplayYesNo eingestellt
- Der Sucher und der Anbieter führen einen Passkey für das schnelle Pairing durch.
Szenario 3 – wenn der Seeker LEA und CSIP unterstützt
Komponenten
- Anbieter
- Unterstützung von A2DP/HFP/LEA
- Mehrere Komponenten
- Hauptkomponente ist BR/EDR/LE
- Sekundäre Komponente ist nur LE
- Suchender
- Unterstützung von A2DP/HFP/LEA
Erwartetes Verhalten für erstes und nachfolgendes Paar
- Die Hauptkomponente bewirbt schnelles Pairing.
Dienstdaten (0xFE2C) mit Identitätsadresse (Initiale) oder RPA (nachfolgend).
- Bisherige Werbung verwenden
- Der Seeker sendet eine schlüsselbasierte Kopplungsanfrage an die Hauptkomponente.
- Flag Bit-5 einer Anfrage für eine schlüsselbasierte Kopplung ist auf 1 gesetzt
- Die Hauptkomponente sendet eine schlüsselbasierte Kopplungsantwort mit dem Nachrichtentyp 0x02
- Bit-0 wird 0 sein.
- Bit-1 muss 1 sein.
- Die Adresse lautet wie folgt :
- Die erste Adresse ist die Identitätsadresse der primären Komponente
- Die zweite Adresse ist die verknüpfbare Adresse für die sekundäre Komponente, Die zweite Komponente verwendet diese Adresse auch für CSIP-Advertising
- Der Seeker schafft eine Bindung zum primären
Komponente für die vorhandene LE-Verbindung
- CTKD-Richtung ist von LE nach BR/EDR
- E/A-Funktion für LE auf DisplayYesNo eingestellt
- Der Seeker schafft eine Bindung zur Sekundarstufe
Komponente, deren Adresse aus der erweiterten Antwort für schlüsselbasierte Kopplung stammt
- E/A-Funktion muss DisplayYesNo lauten. Andernfalls wird die Kopplungsanfrage abgelehnt.
- Der Seeker und der Provider führen ein MITM-Schutzverfahren durch, um das Sekundärkomponente zu nutzen, muss der Anbieter in beiden Szenarien
- Der Seeker wartet, bis er mit der Sekundärkomponente verbunden ist
Sequenzielles Diagramm für MITM
In dieser Sitzung wird die Abfolge der MITM-Schutzverfahren beschrieben.
Passkey von der Komponente abrufen, die per Benachrichtigung verbunden wird
Passkey aus der Komponente abrufen, die durch Lesen verknüpft wird
Bekanntes Problem
FP für LEA wurde für Android V optimiert.
Es gab aber auch Probleme mit Headsets, die LEA unterstützen. aber es fehlt die korrekte Implementierung des schnellen Pairings statt der LEA-Implementierung (d.h. nur schnelles Pairing über Classic). Insbesondere und z. B. wenn die RPA des Anbieters nicht generiert wird. durch den richtigen Identity Resolve Key (IRK) zurückgegeben und die Adresse kann nicht aufgelöst werden. Wir konnten zwar keine umfassende Liste von Headsets testen, haben unsere begrenzten Tests verschiedene Probleme aufgedeckt, darunter zum Anzeigen von Benachrichtigungen zum Akku der Kopfhörer, kein SASS (Audio Switching) Funktionalität, häufige Fehler beim ersten und nachfolgenden Koppeln und mehr.
Daher empfehlen wir Partnern dringend, die LEA-Funktion „Schnelles Pairing“ zu implementieren. Spezifikation sowohl für neue als auch für bereits im Einsatz befindliche Geräte (über Over-the-Air-Updates), die Dual-Modi unterstützen.