Dispositivo Bluetooth Low Energy (BLE)
L'implementazione del servizio Google Fast Pair (GFPS) per i dispositivi BLE è compatibile con la specifica Bluetooth Core v4.2 o versioni successive.
La seguente appendice alla specifica di accoppiamento rapido consentirà il supporto per i dispositivi Low Energy (LE) e Low Energy Audio (LEA) in GFPS.
Livelli di conformità
Le parole chiave "shall", "must", "will", "should", "may" e "can" menzionate nella specifica sono spiegate di seguito:
| Termine | Descrizione |
|---|---|
| shall | is required to (è necessario per): utilizzato per definire i requisiti. |
| must | viene utilizzato per esprimere: una conseguenza naturale di un requisito obbligatorio precedentemente indicato OPPURE una dichiarazione di fatto indiscutibile (che è sempre vera indipendentemente dalle circostanze). |
| will | it is true that (è vero che): utilizzato solo in affermazioni di fatto. |
| should | is recommended that (si consiglia di): utilizzato per indicare che tra diverse possibilità, una è consigliata come particolarmente adatta, ma non obbligatoria. |
| maggio | is permitted to: utilizzato per consentire le opzioni. |
| possiamo | è in grado di: utilizzato per mettere in relazione un'affermazione in modo causale. |
Caratteristica di accoppiamento basato su chiave
Messaggio dal richiedente al fornitore
La richiesta non elaborata type 0x00 della caratteristica di accoppiamento basato su chiavi utilizza il bit 4 per indicare se il Seeker supporta la specifica del dispositivo BLE e il bit 5 per indicare se il Seeker supporta LE Audio.
| Ottetto | Tipo di dati | Descrizione | Valore | Obbligatorio? |
|---|---|---|---|---|
| 0 | uint8 |
Tipo di messaggio | 0x00 = Richiesta di accoppiamento basato su chiave |
Obbligatorio |
| 1 | uint8 |
Flag
|
varies | Obbligatorio |
| 2 - 7 | uint48 |
Una di queste soglie:
|
varies | Obbligatorio |
| 8 - 13 | uint48 |
Indirizzo BR/EDR del Seeker | varies | Presente solo se è impostato il bit 1 o 3 dei flag |
| n - 15 | Valore casuale (salt) | varies | Obbligatorio |
Messaggio dal fornitore al richiedente
Quando il bit 4 della richiesta è impostato, il nuovo messaggio di risposta type 0x02 per la caratteristica Accoppiamento basato su chiave può essere utilizzato per fornire ulteriori opzioni di accoppiamento al Seeker.
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 | uint8 |
Tipo di messaggio | 0x02 = Risposta estesa dell'accoppiamento basato su chiave |
| 1 | uint8 |
Flag
|
varies |
| 2 | uint8 |
Numero di indirizzi del provider (nella versione attuale, il numero è 1 o 2, perché dobbiamo modificare la modalità di crittografia a blocchi in AES-CTR se il numero è >= 3) |
varies |
| 3-8 o 3-14 |
|
varies | |
| 9-15 o 15 | Valore casuale (salt) | varies |
Un Provider che supporta la specifica del dispositivo BLE deve leggere il bit 4 e il bit 5 per comprendere le funzionalità del Seeker
- Quando il bit 4 è 0, il provider deve ignorare il bit 5 e rispondere con il formato
type 0x01 - Quando il bit 4 è 1,
- Per il provider solo LE, deve rispondere con
type 0x02per indicare la preferenza di accoppiamento LE. - Per il Provider in modalità doppia, può rispondere con
type 0x02per indicare la preferenza di accoppiamento BR/EDR o LE.
- Per il provider solo LE, deve rispondere con
- Per i casi di Provider in modalità doppia LE Audio (LEA), consulta Esempio: accoppiamento con Provider in modalità doppia LEA come riferimento
Caratteristica PSM (Protocol Service Multiplexor) del flusso di messaggi
Per supportare il flusso di messaggi per i dispositivi BLE, l'accoppiamento rapido stabilirà e manterrà un canale BLE L2CAP per l'invio e la ricezione di messaggi. Il server L2CAP di accoppiamento rapido deve implementare il controllo di flusso basato su crediti LE.
Questa caratteristica consente al Seeker di leggere il valore PSM e quindi di stabilire una connessione L2CAP sicura in base al valore PSM.
| Caratteristica del servizio di accoppiamento rapido | Criptato | Autorizzazioni | UUID |
|---|---|---|---|
| Flusso di messaggi PSM | Sì | Lettura | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 | uint8 |
Stato
|
varies |
| 1 - 2 | uint16 |
Il valore PSM deve essere compreso tra 0x80 e 0xFF | varies |
Nota: per TWS, esistono due
componenti: principale e secondario. Il ruolo di questi componenti è intercambiabile in determinate condizioni. Supponendo che A sia il componente principale e B il componente secondario, a causa dell'esaurimento della batteria del componente A , il componente B deve assumere il ruolo di componente principale e questo scenario è chiamato role switch.
Dopo role switch, se il provider non è in grado di gestire il flusso di messaggi di Accoppiamento rapido, deve disconnettere in modo proattivo la connessione L2CAP esistente. Il dispositivo di ricerca con accoppiamento rapido può quindi ristabilire la connessione del flusso di messaggi L2CAP con il nuovo componente principale.
Caratteristica aggiuntiva della passkey
Questa caratteristica serve a fornire protezione MITM sui componenti aggiuntivi.
CSIS Fake Member MITM Protection
L'accoppiamento rapido richiede la protezione MITM nell'ambito della procedura di accoppiamento. Poiché CSIS non fornisce protezione MITM, l'attuale progettazione di FP per più componenti deve essere estesa per fornire protezione MITM sui componenti aggiuntivi.
Definizione della caratteristica
| Caratteristica del servizio di accoppiamento rapido | Criptato | Autorizzazione | UUID |
|---|---|---|---|
| Passkey aggiuntiva | No | Lettura,scrittura,notifica | FE2C123A-8366-4814-8EB0-01DE32100BEA |
Messaggi
Il formato del messaggio viene applicato alle operazioni di lettura, scrittura e notifica.
Formato dei dati criptati
I dati criptati vengono inviati utilizzando la connessione GATT di Accoppiamento rapido.
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0-15 | uint128 | Blocco di passkey aggiuntive crittografate | varies |
Formato dei dati non elaborati
Dopo aver decriptato i dati criptati utilizzando il secret condiviso, il formato è il seguente:
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 | uint8 | Tipo di messaggio | uno tra
|
| 1-3 | uint24 | Passkey di 6 cifre | varies |
| 4-9 | uint48 | Indirizzo del componente di bonding di destinazione | varies |
| 10 | uint8 | Codice di stato, utilizzato solo dall'operazione di lettura | Uno tra
|
| 11-15 | Valore casuale (salt) | varies |
Il componente principale (il primo componente accoppiato) funge da ponte tra il Seeker di Accoppiamento rapido e gli altri componenti accoppiati. La caratteristica deve seguire le linee guida:
- Quando riceve una richiesta di scrittura dal Seeker con Accoppiamento rapido, il Provider deve:
- Imposta l'indirizzo del componente che viene associato
- Invia la passkey al componente da accoppiare
- Imposta il codice di stato su In attesa, 0x01
- Quando riceve una richiesta di lettura prima di ricevere la passkey dal componente
da accoppiare, il provider deve restituire un messaggio con
- Passkey, qualsiasi valore
- Indirizzo del componente da collegare
- Codice di stato In attesa, 0x01
- Prima che il provider invii la notifica al seeker di Accoppiamento rapido, imposta il risultato per la richiesta di lettura con
- Passkey del componente da accoppiare
- Indirizzo del componente da collegare
- Codice di stato di esito positivo, 0x00
- In caso di errore irreversibile sul lato del fornitore, imposta il risultato
- Passkey, qualsiasi valore
- Indirizzo del componente da collegare
- Codice di stato di errore, 0x02
Per ulteriori dettagli, consulta il diagramma MITM 1 e il diagramma MITM 2.
Requisiti dei dispositivi LE
LE Advertising
Per la modalità di rilevamento o di non rilevamento, il provider deve utilizzare l'RPA per pubblicizzare i dati di Fast Pair.
Funzionalità di bonding
Per i dispositivi compatibili con LE, il Seeker deve creare un accoppiamento con la connessione LE esistente. Dopo aver superato la verifica dell'accoppiamento basato su chiavi di accoppiamento rapido, il provider deve consentire l'accoppiamento con RPA e impostare la funzionalità IO su DisplayYesNo per la verifica della passkey di accoppiamento rapido.
Requisiti dei dispositivi LEA
Pubblicità LEA
Per i dispositivi dual mode: Per la modalità di rilevamento, il provider deve annunciare i dati di accoppiamento rapido con l'indirizzo identità. Per la modalità non rilevabile, il Provider deve annunciare i dati di Accoppiamento rapido con RPA. È vivamente consigliato utilizzare l'annuncio legacy (BT 4.2) per supportare i dispositivi meno recenti per la compatibilità con le versioni precedenti. È necessario modificare l'IRK ogni volta che vengono ripristinati i dati di fabbrica del dispositivo.
Per i dispositivi non dual mode: per la modalità di rilevamento o non rilevamento, il Provider deve utilizzare l'annuncio esteso (BT 5.0) con RPA per annunciare i dati di accoppiamento rapido.
L'annuncio collegabile LE contenente i dati del servizio FP deve includere l'UUID CAS in conformità ai requisiti del profilo dell'adattatore Bluetooth (BAP 1.0.1) e del profilo audio comune.
Il Provider può indicare la funzionalità LEA includendo l'UUID CAS (0x1853) nei dati del servizio (tipo AD 0x16) o negli UUID della classe di servizio a 16 bit (tipo AD 0x02 o 0x03), indipendentemente dalla modalità di rilevamento.
Per la pubblicità non rilevabile, se non è disponibile spazio sufficiente nella pubblicità precedente a causa dell'inclusione dei dati della batteria e di SASS, in questo caso è obbligatorio includere l'UUID CAS nella risposta alla scansione.
Funzionalità di bonding LEA
Il Seeker deve creare un legame con la connessione LE esistente. Dopo aver superato la verifica dell'accoppiamento basato su chiave di accoppiamento rapido, il provider dual-mode deve consentire l'accoppiamento con l'indirizzo di identità e l'RPA, mentre il provider non dual-mode deve consentire l'accoppiamento con l'RPA e impostare la funzionalità IO su DisplayYesNo per la verifica della passkey di accoppiamento rapido.
Canale di comunicazione interno tra i componenti
La connessione GATT esistente viene mantenuta per eseguire la protezione MITM sui componenti aggiuntivi. Il componente accoppiato principale deve gestire le consegne dei messaggi tra il Seeker di accoppiamento rapido e i componenti rimanenti.
La comunicazione interna viene utilizzata per Initial Pair e Subsequent Pair
- Quando la procedura di accoppiamento basato su chiavi viene superata sul componente principale, quest'ultimo deve inviare un messaggio per modificare la funzionalità di I/O dei componenti rimanenti
- Al termine dell'accoppiamento rapido, il componente principale invia un messaggio per reimpostare la funzionalità di I/O dei componenti rimanenti
- Durante l'esecuzione della procedura di passkey aggiuntiva, il componente principale deve gestire le consegne delle passkey tra il Seeker di accoppiamento rapido e i componenti rimanenti
Tempo per modificare la funzionalità di I/O
- Modifica la funzionalità di I/O in DisplayYesNo quando la procedura di accoppiamento basato su chiave è stata superata
- Se il dispositivo ha più componenti, tutti i componenti devono essere impostati su DisplayYesNo
- Un'eccezione in cui il Provider non deve modificare la funzionalità di I/O in DisplayYesNo è
Retroactive Pair, il cui bit 3 della richiesta di accoppiamento basato su chiave è impostato su 1, consulta Messaggio dal Seeker al Provider
- Modifica la funzionalità di I/O impostandola su quella predefinita
- Accoppiamento iniziale
- Se la connessione LE viene interrotta, termina la sessione di accoppiamento rapido
- Dopo l'accoppiamento del dispositivo principale, se non viene ricevuta un'altra richiesta di scrittura della passkey entro 15 secondi, termina la sessione di accoppiamento rapido
- Dopo aver ricevuto un'ulteriore richiesta di scrittura della passkey, se il componente da accoppiare non viene accoppiato entro 15 secondi, termina la sessione di accoppiamento rapido
- Dopo aver accoppiato tutti i componenti, se non viene ricevuta una richiesta di scrittura della chiave dell'account entro 15 secondi, termina la sessione di accoppiamento rapido
- Dopo aver ricevuto la richiesta di scrittura della chiave dell'account, imposta un timeout di 15 secondi per terminare la sessione di accoppiamento rapido
- Accoppiamento successivo
- Se la connessione LE viene interrotta, termina la sessione di accoppiamento rapido
- Dopo l'accoppiamento del dispositivo principale, se non viene ricevuta un'altra richiesta di scrittura della passkey entro 15 secondi, termina la sessione di accoppiamento rapido
- Dopo aver ricevuto un'ulteriore richiesta di scrittura della passkey, se il componente da accoppiare non viene accoppiato entro 15 secondi, termina la sessione di accoppiamento rapido
- Quando tutti i componenti sono accoppiati, termina la sessione di Accoppiamento rapido
- Accoppiamento iniziale
Nascondi indicazione UI
Quando le cuffie non sono pronte per l'accoppiamento, il Provider deve utilizzare type 0b0010
per impostare l'indicazione di nascondere l'UI per i dati della chiave dell'account per indicare al Seeker di non mostrare
l'UI di accoppiamento successiva (consulta Payload di annuncio: dati dell'account di accoppiamento rapido).
Requisiti dei dispositivi LE Audio
Requisiti Bluetooth
Consulta i consigli per le cuffie LE audio per Android.
Supporto CTKD
Per i dispositivi dual mode, la funzionalità CTKD da LE a BR/EDR è obbligatoria e in linea con i requisiti BAP.
Annuncio target
Un dispositivo periferico deve utilizzare l'annuncio mirato per richiedere una connessione da un dispositivo centrale accoppiato. Targeted Announcements è definito in BAP e CAP per la gestione della connessione in base alla Tabella 8.4 (p48/58) di CAP 1.0.
Supporto del server GATT EATT
EATT consente al dispositivo centrale di inviare più transazioni GATT in parallelo quando il dispositivo è accoppiato. Per il dispositivo che supporta il CSIP, aumenterà le prestazioni della connessione del profilo e poi avvierà subito la procedura di accoppiamento CSIP per gli altri auricolari.
Memorizzazione nella cache robusta GATT (vivamente consigliata)
Se il Provider non è un singolo dispositivo, ma un set coordinato con l'implementazione di CSIP, per ridurre il numero di volte in cui viene eseguito il Service Discovery e velocizzare la connessione, il Provider deve implementare la memorizzazione nella cache GATT definita in Bluetooth 5.1.
Requisiti per l'accoppiamento rapido
LE Advertising
Per la modalità di rilevamento o non rilevamento, se il dispositivo ha più componenti, i dati di accoppiamento rapido devono essere pubblicizzati dal componente principale. Se il dispositivo non è pronto per l'accoppiamento successivo, il componente secondario può annunciare i dati di accoppiamento rapido per le funzionalità estese. Consulta Nascondi indicazione UI.
Visibilità del servizio GATT
Il database GATT deve essere uguale per tutte le connessioni GATT di trasporto LE. Il servizio LE Audio (0x184E) deve essere incluso nel database GATT della connessione con l'accoppiamento rapido.
Esempio: accoppiamento con un provider dual mode LEA
Scenario 1: il Seeker non supporta LEA
Il Provider deve avere la compatibilità con le versioni precedenti del Seeker che non supporta LEA.
Componenti
- Provider: A2DP/HFP/LEA
- Seeker: A2DP/HFP
Comportamento previsto per l'accoppiamento iniziale/successivo
- Il provider annuncia i dati del servizio di accoppiamento rapido (0xFE2C) con l'indirizzo di identità (iniziale) o l'RPA (successivo).
- Utilizza l'annuncio legacy
- Il Seeker riceve l'annuncio del Provider con l'indirizzo di identità per l'accoppiamento iniziale o l'RPA per l'accoppiamento successivo
- Il Seeker invia una richiesta di accoppiamento basato su chiavi
- Il bit 5 del flag della richiesta di accoppiamento basato su chiave è impostato su 0
- Il provider invia la risposta di accoppiamento basato su chiave con l'indirizzo pubblico in uno dei seguenti modi:
- Se viene utilizzato il tipo di messaggio 0x01, l'indirizzo deve essere pubblico
- Se viene utilizzato il tipo di messaggio 0x02
- Il bit 0 deve essere 0
- Il bit 1 deve essere 0
- L'indirizzo deve essere un indirizzo pubblico
- Il Seeker crea un legame con il trasporto BR/EDR
- La funzionalità di I/O è impostata su DisplayYesNo per BR/EDR
- Il Seeker e il Provider eseguono la procedura di verifica della passkey di accoppiamento rapido
Scenario 2: il Seeker supporta LEA
Componenti
- Provider
- Supporto di A2DP/HFP/LEA
- Componente singolo
- Cercatore
- Supporto di A2DP/HFP/LEA
Comportamento previsto per l'accoppiamento iniziale/successivo
- Il provider annuncia i dati del servizio di accoppiamento rapido (0xFE2C) con l'indirizzo di identità (iniziale) o l'RPA (successivo).
- Utilizza l'annuncio legacy
- Il Seeker invia una richiesta di accoppiamento basato su chiavi
- Il bit 5 del flag della richiesta di accoppiamento basato su chiave è impostato su 1
- Il provider invia la risposta di accoppiamento basato su chiavi con il tipo di messaggio 0x02
- Il bit 0 deve essere 0
- Il bit 1 deve essere 1
- L'indirizzo è l'indirizzo di identità
- Il Seeker crea un'associazione con la connessione LE esistente sul trasporto LE
- La direzione CTKD è da LE a BR/EDR
- La funzionalità di I/O è impostata su DisplayYesNo per LE
- Il Seeker e il Provider eseguono la procedura di verifica della passkey di accoppiamento rapido
Scenario 3: il Seeker supporta LEA e CSIP
Componenti
- Provider
- Supporto di A2DP/HFP/LEA
- Più componenti
- Il componente principale è BR/EDR/LE
- Il componente secondario è solo LE
- Cercatore
- Supporto di A2DP/HFP/LEA
Comportamento previsto per l'accoppiamento iniziale/successivo
- Il componente principale annuncia i dati del servizio Accoppiamento rapido (0xFE2C) con l'indirizzo di identità (iniziale) o RPA (successivo).
- Utilizza l'annuncio legacy
- Il Seeker invia una richiesta di accoppiamento basato su chiave al componente principale
- Il bit 5 del flag della richiesta di accoppiamento basato su chiave è impostato su 1
- Il componente principale invia la risposta di accoppiamento basato su chiave con tipo di messaggio 0x02
- Il bit 0 deve essere 0
- Il bit 1 deve essere 1
- L'indirizzo è il seguente:
- Il primo indirizzo è l'indirizzo Identity del componente principale
- Il secondo indirizzo è l'indirizzo accoppiabile per il componente secondario, che utilizza questo indirizzo anche per la pubblicità CSIP
- Il Seeker crea un legame con il componente principale sulla connessione LE esistente
- La direzione CTKD è da LE a BR/EDR
- La funzionalità di I/O è impostata su DisplayYesNo per LE
- Il Seeker crea un'associazione con il componente secondario il cui indirizzo proviene dalla risposta estesa dell'accoppiamento basato su chiave
- La funzionalità di I/O deve essere DisplayYesNo, altrimenti la richiesta di accoppiamento viene rifiutata
- Il Seeker e il Provider eseguono la procedura di protezione MITM per l'accoppiamento del componente secondario. Il Provider deve implementare entrambi gli scenari.
- Il Seeker attende fino a quando non viene accoppiato con il componente secondario
Diagramma sequenziale per MITM
Questa sessione descrive la sequenza della procedura di protezione MITM.
Ricevi la passkey dal componente che viene associato tramite notifica
Ottieni la passkey dal componente che viene associato tramite lettura
Problema noto
L'accoppiamento rapido per LEA è stato ottimizzato per funzionare con Android V (Android 15).
Al contrario, abbiamo riscontrato numerosi problemi con le cuffie che supportano LEA, ma non dispongono della corretta implementazione di Accoppiamento rapido su LEA (ovvero solo Accoppiamento rapido su Classic). In particolare, ad esempio, quando l'RPA del provider non viene generato dalla chiave di risoluzione dell'identità (IRK) corretta e l'indirizzo non può essere risolto. Sebbene non sia stato possibile testare un elenco completo di configurazioni delle cuffie, i nostri test limitati hanno rivelato vari problemi, tra cui la mancata visualizzazione delle notifiche della batteria degli auricolari, la mancanza della funzionalità di cambio audio (SASS), errori diffusi di accoppiamento iniziale e successivo e altro ancora.
Pertanto, consigliamo vivamente ai partner di implementare la specifica Accoppiamento rapido-LEA sia per i nuovi dispositivi sia per quelli esistenti sul campo (tramite aggiornamenti over-the-air) che supportano le modalità duali.