Dispositivo Bluetooth Low Energy (BLE)
L'implementazione del servizio di accoppiamento rapido (GFPS) di Google per i dispositivi BLE è compatibile con Bluetooth Core Specification v4.2 o versioni successive.
Il seguente addendum alla specifica di accoppiamento rapido consentirà il supporto per i dispositivi solo a basso consumo energetico (LE) e audio a basso consumo energetico (LEA) in GFPS.
Livelli di conformità
Le parole chiave "deve", "devono", "farà", "dovrebbe", "potrebbe" e "può" menzionate nella specifica sono spiegate di seguito:
| Termine | Descrizione |
|---|---|
| deve | è obbligatorio: utilizzato per definire i requisiti. |
| deve | viene utilizzato per esprimere: una conseguenza naturale di un requisito obbligatorio precedentemente dichiarato OPPURE una dichiarazione di fatto indiscutibile (che è sempre vera indipendentemente dalle circostanze). |
| che | è vero che - utilizzato solo in affermazioni di fatto. |
| should | È consigliabile: utilizzato per indicare che tra diverse possibilità una è consigliata come particolarmente adatta, ma non obbligatoria. |
| può | è consentito a: utilizzato per consentire opzioni. |
| lattina | è in grado di: utilizzato per mettere in relazione l'affermazione in modo causale. |
Caratteristica di accoppiamento basata su chiave
Messaggio dal cercatore al fornitore
La richiesta non elaborata type 0x00 della caratteristica di accoppiamento basato su chiave utilizza il bit 4
per indicare se il dispositivo supporta la specifica del dispositivo BLE e utilizza il
bit 5 per indicare se il dispositivo supporta LE audio.
| Octet | Tipo di dati | Descrizione | Valore | Obbligatorio? |
|---|---|---|---|---|
| 0 | uint8 |
Tipo di messaggio | 0x00 = Richiesta di accoppiamento basata su chiave |
Obbligatorio |
| 1 | uint8 |
Indicatori
|
varia | Obbligatorio |
| 2 - 7 | uint48 |
Una delle seguenti:
|
varia | Obbligatorio |
| 8 - 13 | uint48 |
Indirizzo BR/EDR del richiedente | varia | Presente solo se è impostato il bit Flags 1 o 3 |
| n - 15 | Valore casuale (salt) | varia | Obbligatorio |
Messaggio dal fornitore al ricercatore
Quando il bit 4 della richiesta è impostato, il nuovo messaggio di risposta type 0x02 per la caratteristica di accoppiamento basato su chiave può essere utilizzato per fornire opzioni di accoppiamento aggiuntive al cercatore.
| Octet | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 | uint8 |
Tipo di messaggio | 0x02 = Risposta estesa di accoppiamento basato su chiave |
| 1 | uint8 |
Flag
|
varia |
| 2 | uint8 |
Numero di indirizzi del fornitore (nella versione corrente, il numero è 1 o 2, perché dobbiamo modificare la modalità di crittografia a blocchi in AES-CTR se il numero è >= 3) |
varia |
| 3-8 o 3-14 |
|
varia | |
| 9-15 o 15 | Valore casuale (sale) | varia |
Un provider che supporta la specifica del dispositivo BLE leggerà Bit 4 e Bit 5 per comprendere le capacità del ricercatore
- Quando il bit 4 è 0, il fornitore deve ignorare il bit 5 e rispondere con il formato
type 0x01 - Quando il bit 4 è 1,
- Per il Fornitore solo LE, dovrà rispondere con
type 0x02per indicare la preferenza per il vincolo LE. - Per il provider in modalità doppia, può rispondere con
type 0x02per indicare preferenza di legame BR/EDR o LE.
- Per il Fornitore solo LE, dovrà rispondere con
- Per i casi dei fornitori dual mode LE Audio (LEA), consulta Esempio: accoppiamento con un fornitore dual mode LEA come riferimento
Caratteristica PSM (Protocol Service Multiplexor) dei flussi di messaggi
Per supportare lo stream di messaggi per i dispositivi BLE, l'accoppiamento rapido stabilirà e manterrà un canale L2CAP BLE per l'invio e la ricezione di messaggi. Il server L2CAP ad accoppiamento rapido implementerà il controllo del flusso basato sul credito LE.
Questa caratteristica consente al cercatore 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 |
|---|---|---|---|
| PSM di stream di messaggi | Sì | Leggi | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 | uint8 |
Stato
|
varia |
| 1 - 2 | uint16 |
Il valore PSM deve essere compreso tra 0x80 e 0xFF | varia |
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 del consumo della batteria del componente A , il componente B deve assumere il ruolo di componente principale e questo scenario è chiamato role switch.
Dopo il giorno role switch, se il provider
non è in grado di gestire il flusso di messaggi di accoppiamento rapido, disconnetterà proattivamente la
connessione L2CAP esistente. Il cercatore dell'accoppiamento rapido può quindi ristabilire la connessione dello stream di messaggi L2CAP con il nuovo componente principale.
Caratteristica passkey aggiuntiva
Questa caratteristica è finalizzata a fornire protezione MITM ai componenti aggiuntivi.
Protezione MITM per membri falsi del CSIS
L'accoppiamento rapido richiede la protezione MITM nell'ambito della procedura di accoppiamento. Poiché CSIS non fornisce protezione MITM, il design attuale per la FP per più componenti deve essere esteso per fornire protezione MITM ai componenti aggiuntivi.
Definizione della caratteristica
| Caratteristiche del servizio di accoppiamento rapido | Criptato | Autorizzazione | UUID |
|---|---|---|---|
| Passkey aggiuntiva | Sì | 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 crittografati
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 criptate | varia |
Formato dei dati non elaborati
Dopo aver decriptato i dati criptati utilizzando la chiave segreta condivisa, il formato è il seguente
| Octet | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 | uint8 | Tipo di messaggio | una di
|
| 1-3 | uint24 | Passkey di 6 cifre | varia |
| 4-9 | uint48 | Indirizzo del componente di unione di destinazione | varia |
| 10 | uint8 | Codice di stato, utilizzato solo dall'operazione di lettura | Uno dei
|
| 11-15 | Valore casuale (salt) | varia |
Il componente principale (primo componente accoppiato) è il ponte tra il cercatore di accoppiamento rapido e i componenti di accoppiamento aggiuntivi. La caratteristica deve rispettare le linee guida:
- Quando riceve una richiesta di scrittura da Fast Pair Seeker, il fornitore deve
- Imposta l'indirizzo del componente da collegare
- Invia la passkey al componente accoppiato
- Imposta il codice stato su In attesa, 0x01
- Quando riceve una richiesta di lettura prima di ricevere la passkey dal componente connesso, il fornitore deve restituire un messaggio con
- Passkey, qualsiasi valore
- Indirizzo del componente da collegare
- Codice di stato in attesa, 0x01
- Prima che il fornitore invii una notifica al cercatore di accoppiamento rapido, imposta il risultato per la richiesta di lettura con
- Passkey del componente a cui è stato eseguito il pairing
- Indirizzo del componente a cui è associato il legame
- Codice di stato operazione riuscita, 0x00
- Se si verifica un errore non recuperabile sul lato del provider, imposta il risultato
- Passkey, qualsiasi valore
- Indirizzo del componente a cui è associato il legame
- Codice di stato dell'errore, 0x02
Per ulteriori dettagli, consulta il diagramma MITM 1 e il diagramma MITM 2.
Requisiti del dispositivo LE
LE Advertising
Per la modalità rilevabile o non rilevabile, il Fornitore deve utilizzare l'RPA per promuovere i dati di Fast Pair.
Capacità di incollaggio
Per i dispositivi compatibili con LE, il cercatore deve creare il legame con la connessione LE esistente. Dopo aver superato la verifica dell'accoppiamento basato su chiavi di accoppiamento rapido, il fornitore 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
LEA Advertising
Per i dispositivi dual mode: Per la modalità rilevabile, il fornitore deve pubblicizzare i dati dell'accoppiamento rapido con l'indirizzo dell'identità. Per la modalità non rilevabile, il Fornitore dovrà pubblicizzare i dati dell'accoppiamento rapido con RPA. Ti consigliamo vivamente di utilizzare gli annunci legacy (BT 4.2) per supportare i dispositivi meno recenti per la compatibilità con le versioni precedenti. È necessario cambiare la modalità IRK ogni volta che viene ripristinato i dati di fabbrica del dispositivo.
Per i dispositivi non dual mode: Per la modalità rilevabile o non rilevabile, il fornitore deve utilizzare la pubblicità obbligatoria (BT 5.0) con RPA per pubblicizzare i dati di Fast Pair.
L'annuncio LE connettibile contenente i dati del servizio FP deve includere CAS UUID in conformità con il profilo dell'adattatore Bluetooth (BAP 1.0.1) e profilo audio comune requisiti. Per gli annunci non rilevabili, se nello spazio annunci precedente non è disponibile spazio sufficiente a causa dell'inclusione dei dati della batteria e SASS, è obbligatorio includere l'UUID CAS nella risposta alla scansione.
Capacità di accoppiamento LEA
Il cercatore deve creare il legame con la connessione LE esistente. Dopo aver superato la verifica di accoppiamento basata su chiave di accoppiamento rapido, il fornitore dual mode deve consentire il legame con l'indirizzo di identità e l'RPA, mentre il fornitore non dual mode deve consentire il legame con l'RPA e impostare la funzionalità IO su DisplayYesNo per la verifica della passkey di accoppiamento rapido.
Canale di comunicazione interna tra i componenti
La connessione GATT esistente viene mantenuta per eseguire la protezione MITM sui componenti aggiuntivi. Il componente accoppiato principale deve gestire l'invio di messaggi tra il cercatore di accoppiamento rapido e i restanti componenti.
La comunicazione interna viene utilizzata per Initial Pair e Subsequent Pair
- Quando la procedura di accoppiamento basata su chiavi passa al componente principale, quest'ultimo deve inviare un messaggio per modificare la funzionalità 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
- Quando viene eseguita la procedura di passkey aggiuntiva, il componente principale deve gestire la trasmissione delle passkey tra il cercatore di accoppiamento rapido e i componenti rimanenti
È ora di modificare la funzionalità IO
- Modifica la funzionalità IO 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
- L'unica eccezione a cui il provider non deve
modificare la capacità IO in DisplayYesNo è
Retroactive Pair, il cui bit 3 di richiesta di accoppiamento basato su chiave è impostato su 1. Consulta Messaggio dal ricercatore al provider
- Modifica la funzionalità di I/O sull'impostazione predefinita
- Accoppiamento iniziale
- Se la connessione LE è disconnessa, termina la sessione di accoppiamento rapido
- Dopo che il dispositivo principale è accoppiato, se non viene richiesta un'ulteriore scrittura della passkey entro 15 secondi, termina la sessione di accoppiamento rapido
- Dopo aver ricevuto una richiesta di scrittura della passkey aggiuntiva, se il componente in fase di accoppiamento non è accoppiato entro 15 secondi, termina la sessione di accoppiamento rapido
- Dopo che tutti i componenti sono accoppiati, se non viene effettuata alcuna 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 il timeout su 15 secondi per terminare la sessione di accoppiamento rapido
- Accoppiamento successivo
- Se la connessione LE è disconnessa, termina la sessione di accoppiamento rapido
- Dopo l'accoppiamento del dispositivo principale, se non viene effettuata alcuna richiesta di scrittura della passkey entro 15 secondi, termina la sessione di accoppiamento rapido
- Dopo aver ricevuto una richiesta di scrittura della passkey aggiuntiva, se il componente in fase di accoppiamento non è 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 gli auricolari non sono pronti per l'accoppiamento, il fornitore deve utilizzare type 0b0010
per impostare l'indicazione di occultamento dell'interfaccia utente per i dati della chiave dell'account per indicare al cercatore di non mostrare
l'interfaccia utente di accoppiamento successiva (vedi Payload della pubblicità: dati dell'account di accoppiamento rapido).
Requisiti dei dispositivi LE Audio
Requisiti Bluetooth
Consulta i consigli per cuffie Android e LE audio.
Assistenza CTKD
Per i dispositivi dual mode, CTKD da LE a BR/EDR è obbligatorio 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. Annunci mirati è definito in BAP e CAP per la gestione delle connessioni in base alla tabella 8.4 del CAP 1.0 (p. 48/58).
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 CSIP, aumenterà le prestazioni della connessione del profilo e a breve inizierà la procedura di CSIP per gli altri auricolari.
Memorizzazione nella cache efficace del GATT (vivamente consigliata)
Se il fornitore non è un singolo dispositivo, ma un insieme coordinato con implementazione di CSIP, per ridurre il numero di volte in cui viene eseguito il rilevamento dei servizi e velocizzare la connessione, il fornitore deve implementare la memorizzazione nella cache GATT definita in Bluetooth 5.1.
Requisiti per l'accoppiamento rapido
Pubblicità LE
Per la modalità rilevabile o non rilevabile, se il dispositivo ha più componenti, i dati dell'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 Nascondere l'indicazione dell'interfaccia utente.
Visibilità del servizio GATT
Il database GATT deve essere lo stesso per tutte le connessioni GATT di trasporto LE. Il servizio LE Audio (0x184E) deve essere incluso nel database GATT della connessione con accoppiamento rapido.
Esempio: accoppiamento con un fornitore LEA dual mode
Scenario 1: quando il ricercatore non supporta l'opzione LEA
Il Fornitore dovrà avere la compatibilità con le versioni precedenti del Cercatore che non supporta l'LEA.
Componenti
- Provider: A2DP/HFP/LEA
- Dispositivo di ricerca: A2DP/HFP
Comportamento previsto per coppia iniziale / coppia successiva
- Il fornitore pubblicizza i dati del servizio di accoppiamento rapido (0xFE2C) con l'indirizzo di identità (iniziale) o RPA (successivo).
- Utilizzare la pubblicità precedente
- Il cercatore riceve l'annuncio del fornitore con l'indirizzo dell'identità per l'accoppiamento iniziale o l'RPA per l'accoppiamento successivo
- Il cercatore invia una richiesta di accoppiamento basata su chiavi
- Il bit 5 del flag della richiesta di accoppiamento basato su chiave è impostato su 0
- Il fornitore invia la risposta all'accoppiamento basato su chiave con l'indirizzo pubblico in uno dei modi seguenti:
- 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
- The Seeker crea legami con il trasporto BR/EDR
- La funzionalità IO è impostata su DisplayYesNo per BR/EDR
- Il cercatore e il fornitore eseguono la procedura di verifica della passkey di Accoppiamento rapido
Scenario 2: quando l'utente supporta il LEA
Componenti
- Fornitore
- Supporto di A2DP/HFP/LEA
- Componente singolo
- Seeker
- SupportA2DP/HFP/LEA
Comportamento previsto per coppia iniziale / coppia successiva
- Il fornitore pubblicizza i dati del servizio di accoppiamento rapido (0xFE2C) con l'indirizzo di identità (iniziale) o RPA (successivo).
- Utilizzare la pubblicità precedente
- Il cercatore invia una richiesta di accoppiamento basata su chiavi
- Il bit 5 del flag della richiesta di accoppiamento basato su chiave è impostato su 1
- Il fornitore invia una 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 è Indirizzo documento di identità
- Il cercatore crea il legame con la connessione LE esistente sul trasporto LE.
- La direzione CTKD è da LE a BR/EDR
- La funzionalità IO è impostata su DisplayYesNo per LE
- Il cercatore e il fornitore eseguono la procedura di verifica della passkey di Accoppiamento rapido
Scenario 3: quando il cercatore supporta le forze dell'ordine e il CSIP coinvolto
Componenti
- Fornitore
- Supporto A2DP/HFP/LEA
- Più componenti
- Il componente principale è BR/EDR/LE
- Il componente secondario è solo LE
- Cercatore
- Supporto A2DP/HFP/LEA
Comportamento previsto per l'accoppiamento iniziale / accoppiamento successivo
- Il componente principale pubblicizza i dati del servizio di accoppiamento rapido (0xFE2C) con indirizzo di identità (iniziale) o RPA (successivo).
- Utilizzare la pubblicità precedente
- Il ricercatore invia una richiesta di accoppiamento basato su chiave al componente principale.
- Il flag bit-5 della richiesta di accoppiamento basato su chiave è impostato su 1.
- Il componente principale invia la risposta di accoppiamento basato su chiave con il 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 dell'identità del componente principale
- Il secondo indirizzo è l'indirizzo associabile per il componente secondario. Anche il secondo componente utilizza questo indirizzo per fare pubblicità CSIP
- Il cercatore crea il legame con il componente principale sulla connessione LE esistente.
- La direzione CTKD va da LE a BR/EDR
- La funzionalità IO è impostata su DisplayYesNo per LE
- Il cercatore crea un legame con il componente secondario il cui indirizzo proviene dalla risposta estesa dell'accoppiamento basato su chiave.
- La funzionalità IO sarà DisplayYesNo, altrimenti rifiuta la richiesta di associazione.
- Il cercatore e il fornitore eseguono la procedura di protezione MITM per l'accoppiamento del componente secondario. Il fornitore deve implementare entrambi gli scenari.
- Il cercatore attende fino al collegamento con il componente secondario
Diagramma sequenziale per MITM
Questa sessione descrive la sequenza della procedura di protezione MITM.
Ricevere la passkey dal componente accoppiato tramite notifica
Ottieni una passkey dal componente da associare tramite lettura
Problema noto
La funzionalità FP per le forze dell'ordine è stata ottimizzata per funzionare con Android V(Android 15).
Al contrario, abbiamo riscontrato numerosi problemi con le cuffie che supportano LEA, ma non dispongono dell'implementazione corretta dell'accoppiamento rapido tramite LEA (ad es. solo accoppiamento rapido tramite Classic). Nello specifico, ad esempio, quando l'RPA del provider non viene generata dalla chiave di risoluzione dell'identità (IRK) corretta e non è possibile risolvere l'indirizzo. Sebbene non sia stato possibile testare un elenco completo di configurazioni degli auricolari, i nostri test limitati hanno rivelato vari problemi, tra cui la mancata visualizzazione delle notifiche relative alla batteria degli auricolari, la mancanza della funzionalità di commutazione audio (SASS), errori di accoppiamento iniziali e successivi diffusi e altro ancora.
Pertanto, consigliamo vivamente ai partner di implementare la specifica di accoppiamento rapido-LEA sia per i nuovi dispositivi sia per quelli esistenti sul campo (tramite aggiornamenti over-the-air) che supportano le modalità duali.