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.
Il seguente addendum alla specifica Accoppiamento rapido consentirà il supporto per i dispositivi solo 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 | è obbligatorio per: utilizzato per definire i requisiti. |
| must | viene utilizzato per esprimere: una conseguenza naturale di un requisito obbligatorio precedentemente indicato OPPURE un'affermazione di fatto indiscutibile (sempre vera indipendentemente dalle circostanze). |
| will | è vero che: utilizzato solo nelle affermazioni di fatto. |
| should | è consigliabile: utilizzato per indicare che tra diverse possibilità una è consigliata in quanto particolarmente adatta, ma non obbligatoria. |
| maggio | è autorizzato a: 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 chiave utilizza il bit 4
per indicare se il richiedente supporta la specifica del dispositivo BLE e utilizza il
bit 5 per indicare se il richiedente supporta LE Audio.
| Ottetto | Tipo di dati | Descrizione | Valore | Obbligatorio? |
|---|---|---|---|---|
| 0 | uint8 |
Tipo di messaggio | 0x00 = Richiesta di accoppiamento basata su chiave |
Obbligatorio |
| 1 | uint8 |
Flag
|
varia | Obbligatorio |
| 2 - 7 | uint48 |
Scegli una delle opzioni seguenti:
|
varia | Obbligatorio |
| 8 - 13 | uint48 |
Indirizzo BR/EDR del richiedente | varia | Presente solo se è impostato il bit 1 o 3 dei flag |
| n - 15 | Valore casuale (salt) | varia | Obbligatorio |
Messaggio dal fornitore al richiedente
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 richiedente.
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 | uint8 |
Tipo di messaggio | 0x02 = Key-based Pairing Extended Response |
| 1 | uint8 |
Flag
|
varia |
| 2 | uint8 |
Numero di indirizzi del fornitore (nella versione attuale, il numero è 1 o 2, perché dobbiamo modificare la modalità di cifratura a blocchi in AES-CTR se il numero è >= 3) |
varia |
| 3 - 8 o 3 - 14 |
|
varia | |
| 9 - 15 o 15 | Valore casuale (salt) | varia |
Un fornitore che supporta la specifica del dispositivo BLE deve leggere il bit 4 e il bit 5 per comprendere le funzionalità del cercatore
- 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, deve rispondere con
type 0x02per indicare la preferenza di accoppiamento LE. - Per il fornitore in modalità doppia, può rispondere con
type 0x02per indicare la preferenza di accoppiamento BR/EDR o LE.
- Per il fornitore solo LE, deve rispondere con
- Per i casi di provider in modalità doppia LE Audio (LEA), consulta Esempio: accoppiamento con un provider in modalità doppia LEA come riferimento.
Caratteristica PSM (Protocol Service Multiplexor) del flusso 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. Accoppiamento rapido Il server L2CAP deve implementare il controllo del flusso basato sul credito LE.
Questa caratteristica consente al richiedente di leggere il valore PSM e quindi stabilire una connessione L2CAP sicura in base al valore PSM.
| Caratteristica del servizio di accoppiamento rapido | Criptato | Autorizzazioni | UUID |
|---|---|---|---|
| PSM Message Stream | Sì | Lettura | 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: primario e secondario. Il ruolo di questi componenti è
intercambiabile in determinate condizioni. Supponendo che A sia il componente principale e B sia
il componente secondario, a causa dello scaricamento 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 fornitore
non è in grado di gestire il flusso di messaggi di accoppiamento rapido, disconnette in modo proattivo la
connessione L2CAP esistente. Il richiedente dell'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 | Sì | Read,write,notify | 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 dell'accoppiamento rapido.
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0-15 | uint128 | Blocco passkey aggiuntive criptate | varia |
Formato dei dati non elaborati
Dopo aver decriptato i dati criptati utilizzando il segreto 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 | varia |
| 4-9 | uint48 | Indirizzo del componente di accoppiamento di destinazione | varia |
| 10 | uint8 | Codice di stato, utilizzato solo dall'operazione di lettura | Uno tra
|
| 11-15 | Valore casuale (salt) | varia |
Il componente principale (il primo accoppiato) è il ponte tra il richiedente dell'accoppiamento rapido e i componenti di accoppiamento aggiuntivi. La caratteristica deve seguire le linee guida:
- Quando riceve una richiesta di scrittura da Fast Pair Seeker, il fornitore deve
- Imposta l'indirizzo del componente che viene accoppiato
- Inviare 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 fornitore deve restituire un messaggio con
- Passkey, qualsiasi valore
- L'indirizzo del componente da collegare.
- Codice di stato In attesa, 0x01
- Prima che il fornitore invii la notifica al richiedente dell'accoppiamento rapido, imposta il risultato
per la richiesta di lettura con
- Passkey del componente da accoppiare
- L'indirizzo del componente da collegare.
- Codice di stato riuscito, 0x00
- Se si verifica un errore non recuperabile sul lato del provider, imposta il risultato
- Passkey, qualsiasi valore
- L'indirizzo del componente da collegare.
- Codice di stato di errore, 0x02
Per maggiori dettagli, vedi il diagramma MITM 1 e il diagramma MITM 2.
Requisiti dei dispositivi LE
LE Advertising
Per la modalità rilevabile o non rilevabile, il Fornitore deve utilizzare RPA per pubblicizzare i dati Fast Pair.
Funzionalità di bonding
Per i dispositivi compatibili con LE, il cercatore deve creare un accoppiamento con la connessione LE esistente. Dopo aver superato la verifica dell'accoppiamento basato sulla chiave di accoppiamento rapido, il fornitore deve consentire l'associazione con RPA e impostare la funzionalità di I/O su DisplayYesNo per la verifica del passcode 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 identità. Per la modalità non rilevabile, il fornitore deve pubblicizzare i dati dell'accoppiamento rapido con RPA. È vivamente consigliato di utilizzare la pubblicità 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 a doppia modalità: Per la modalità rilevabile o non rilevabile, il Fornitore deve utilizzare la pubblicità estesa (BT 5.0) con RPA per pubblicizzare i dati Fast Pair.
La pubblicità connettibile LE contenente i dati del servizio FP deve includere l'UUID CAS in conformità con il requisito del profilo dell'adattatore Bluetooth (BAP 1.0.1) e del profilo audio comune.
Il fornitore può indicare la funzionalità LEA includendo l'UUID CAS (0x1853) nei dati di servizio (tipo di annuncio 0x16) o negli UUID della classe di servizio a 16 bit (tipo di annuncio 0x02 o 0x03), indipendentemente dalla modalità rilevabile.
Per la pubblicità non rilevabile, se non è disponibile spazio sufficiente nella pubblicità legacy a causa dell'inclusione di dati della batteria e SASS, è obbligatorio includere l'UUID CAS nella risposta alla scansione.
Funzionalità di associazione LEA
Il dispositivo di ricerca deve creare un accoppiamento con la connessione LE esistente. Dopo aver superato la verifica dell'accoppiamento basato sulla chiave di accoppiamento rapido, il fornitore dual mode deve consentire l'associazione con l'indirizzo dell'identità e l'RPA, mentre il fornitore non dual mode deve consentire l'associazione con l'RPA e impostare la funzionalità di I/O su DisplayYesNo per la verifica del passcode 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 gestisce la distribuzione dei messaggi tra Fast Pair Seeker e i suoi componenti rimanenti.
La comunicazione interna viene utilizzata per Initial Pair e Subsequent Pair
- Quando la procedura di accoppiamento basata su chiave viene eseguita sul componente principale, quest'ultimo invia 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
- Quando viene eseguita la procedura per la passkey aggiuntiva, il componente principale deve gestire le consegne delle passkey tra Fast Pair Seeker e i suoi componenti rimanenti
È ora di modificare la funzionalità di I/O
- Modifica la funzionalità di I/O in DisplayYesNo quando la procedura di accoppiamento basata su chiave è stata superata
- Se il dispositivo ha più componenti, tutti devono essere impostati su DisplayYesNo
- Un'eccezione per cui il Fornitore non deve
modificare la funzionalità IO in DisplayYesNo è
Retroactive Pair, il cui bit 3 della richiesta di accoppiamento basato su chiave è impostato su 1. Vedi Messaggio dal richiedente al fornitore
- Modifica la funzionalità di I/O all'impostazione predefinita
- Accoppiamento iniziale
- Se la connessione LE viene interrotta, termina la sessione di Accoppiamento rapido
- Dopo l'associazione del dispositivo principale, se non viene inviata un'ulteriore 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 che tutti i componenti sono stati accoppiati, se non viene inviata 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 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'associazione della chiave primaria, se non viene inviata un'ulteriore 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 Fornitore deve utilizzare type 0b0010
per impostare l'indicazione dell'interfaccia utente nascosta per i dati della chiave dell'account per comunicare al Richiedente di non mostrare
l'interfaccia utente di accoppiamento successiva (vedi Payload pubblicitario: dati dell'account Fast Pair).
Requisiti dei dispositivi LE Audio
Requisiti Bluetooth
Consulta Android, LE Audio headset recommendations.
Supporto CTKD
Per i dispositivi dual mode, CTKD da LE a BR/EDR è obbligatorio e in linea con i requisiti BAP.
Annuncio del target
Un dispositivo periferico deve utilizzare l'annuncio mirato per richiedere una connessione da un dispositivo centrale accoppiato. Gli annunci mirati sono definiti in BAP e CAP per la gestione delle connessioni in base alla tabella 8.4 (p. 48/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 CSIP, le prestazioni della connessione del profilo aumenteranno e presto inizierà la procedura di bonding CSIP per gli altri auricolari.
Memorizzazione nella cache robusta GATT (vivamente consigliata)
Se il Provider non è un singolo dispositivo, ma un insieme coordinato con implementazione CSIP, per ridurre il numero di volte in cui viene eseguita la Service Discovery e velocizzare la connessione, il Provider deve implementare la memorizzazione nella cache GATT definita in Bluetooth 5.1.
Requisiti dell'accoppiamento rapido
LE Advertising
Per la modalità rilevabile o non rilevabile, 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ò pubblicare dati di Accoppiamento Rapido per funzionalità estese. Vedi Nascondere l'indicazione della 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 di accoppiamento rapido.
Esempio: accoppiamento con un fornitore LEA dual mode
Scenario 1: quando il Seeker non supporta LEA
Il fornitore deve essere compatibile con le versioni precedenti del richiedente che non supporta LEA.
Componenti
- Provider: A2DP/HFP/LEA
- Seeker: A2DP/HFP
Comportamento previsto per l'accoppiamento iniziale / successivo
- Il fornitore pubblicizza i dati del servizio Accoppiamento rapido (0xFE2C) con l'indirizzo di identità (iniziale) o RPA (successivo).
- Utilizzare la pubblicità legacy
- Il richiedente riceve la pubblicità del fornitore con l'indirizzo dell'identità per l'accoppiamento iniziale o RPA per l'accoppiamento successivo
- Il richiedente invia la richiesta di accoppiamento basato su chiave
- Il bit del flag 5 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
seguenti formati:
- 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
- Bit-1 deve essere 0
- L'indirizzo deve essere pubblico
- Il Seeker crea un legame con il trasporto BR/EDR
- La funzionalità IO è impostata su DisplayYesNo per BR/EDR
- Il richiedente e il fornitore eseguono la procedura di verifica della passkey dell'accoppiamento rapido
Scenario 2: quando il tracker supporta LEA
Componenti
- Fornitore
- Supportare A2DP/HFP/LEA
- Singolo componente
- Seeker
- SupportA2DP/HFP/LEA
Comportamento previsto per l'accoppiamento iniziale / successivo
- Il fornitore pubblicizza i dati del servizio Accoppiamento rapido (0xFE2C) con l'indirizzo di identità (iniziale) o RPA (successivo).
- Utilizzare la pubblicità legacy
- Il richiedente invia la richiesta di accoppiamento basato su chiave
- Il bit 5 del flag della richiesta di accoppiamento basato su chiave è impostato su 1
- Il fornitore invia la risposta all'accoppiamento basato su chiavi con il tipo di messaggio 0x02
- Il bit 0 deve essere 0
- Bit-1 deve essere 1
- L'indirizzo è Indirizzo identità
- Il Seeker crea un accoppiamento con la connessione
LE esistente sul trasporto LE
- La direzione CTKD è da LE a BR/EDR
- La funzionalità di input/output è impostata su DisplayYesNo per LE
- Il richiedente e il fornitore eseguono la procedura di verifica della passkey dell'accoppiamento rapido
Scenario 3: quando il richiedente supporta l'LEA e il CSIP è coinvolto
Componenti
- Fornitore
- Supportare A2DP/HFP/LEA
- Componenti multipli
- Il componente principale è BR/EDR/LE
- Il componente secondario è solo LE
- Seeker
- Supportare A2DP/HFP/LEA
Comportamento previsto per l'accoppiamento iniziale / successivo
- Il componente principale annuncia i dati del servizio di accoppiamento rapido (0xFE2C) con l'indirizzo Identity (iniziale) o RPA (successivo).
- Utilizzare la pubblicità legacy
- Il richiedente invia la 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 all'accoppiamento basato su chiave con il tipo di messaggio 0x02
- Il bit 0 deve essere 0
- Bit-1 deve essere 1
- Gli indirizzi sono i seguenti:
- Il primo indirizzo è l'indirizzo identità del componente principale
- Il secondo indirizzo è l'indirizzo associabile per il componente secondario, il secondo componente utilizza anche questo indirizzo per la pubblicità CSIP
- Il cercatore crea un accoppiamento con il componente principale sulla connessione LE esistente
- La direzione CTKD è da LE a BR/EDR
- La funzionalità di input/output è impostata su DisplayYesNo per LE
- Il richiedente crea un legame 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 rifiuta la richiesta di accoppiamento
- Il richiedente e il fornitore eseguono la procedura di protezione MITM per l'accoppiamento del componente secondario. Il fornitore deve implementare entrambi gli scenari
- Il componente Seeker attende di essere accoppiato al componente secondario
Diagramma sequenziale per l'attacco MITM
Questa sessione descrive la sequenza della procedura di protezione MITM.
Ricevere la passkey dal componente in fase di accoppiamento tramite notifica
Ottieni la passkey dal componente associato tramite lettura
Problema noto
FP 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 dell'implementazione corretta di Accoppiamento rapido su LEA (ovvero solo Accoppiamento rapido su Classic). Nello specifico e ad esempio, quando l'RPA del fornitore 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 di 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 di accoppiamento iniziali e successivi diffusi e altro ancora.
Pertanto, consigliamo vivamente ai partner di implementare la specifica Fast Pair-LEA sia per i nuovi dispositivi sia per quelli esistenti sul campo (tramite aggiornamenti over-the-air) che supportano la doppia modalità.