Specifiche dell'accessorio di rete Find Hub

v1.3

La specifica dell'accessorio Find Hub Network (FHN) definisce un approccio crittografato end-to-end per il monitoraggio dei dispositivi Bluetooth Low Energy (BLE) di beaconing. Questa pagina descrive FHN come estensione della specifica Fast Pair. I fornitori devono attivare questa estensione se dispongono di dispositivi compatibili con FHN e sono disposti ad attivare il monitoraggio della posizione per questi dispositivi.

Specifica GATT

Al servizio Fast Pair deve essere aggiunta un'ulteriore caratteristica degli attributi generici (GATT) con la seguente semantica:

Caratteristica del servizio di accoppiamento rapido	Criptato	Autorizzazioni	UUID
Azioni beacon	No	Lettura, scrittura e notifica	FE2C1238-8366-4814-8EB0-01DE32100BEA

Tabella 1: caratteristiche del servizio di accoppiamento rapido per FHN.

Autenticazione

Le operazioni richieste da questa estensione vengono eseguite come operazione di scrittura, protetta da un meccanismo di challenge-response. Prima di eseguire qualsiasi operazione, il richiedente deve eseguire un'operazione di lettura dalla caratteristica nella tabella 1, che genera un buffer nel seguente formato:

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Numero di versione principale del protocollo	0x01
1 - 8	array di byte	Nonce casuale una tantum	varia

Ogni operazione di lettura deve generare un nonce diverso e un singolo nonce deve essere valido solo per una singola operazione. Il nonce deve essere invalidato anche se l'operazione non è riuscita.

Il richiedente calcola quindi una chiave di autenticazione una tantum da utilizzare in una successiva richiesta di scrittura. La chiave di autenticazione viene calcolata come descritto nelle tabelle da 2 a 5. A seconda dell'operazione richiesta, il richiedente dimostra di conoscere una o più delle seguenti chiavi:

• Chiave account: la chiave account di accoppiamento rapido di 16 byte, come definita nella specifica di accoppiamento rapido.

• Chiave dell'account proprietario: il fornitore sceglie una delle chiavi dell'account esistenti come chiave dell'account proprietario la prima volta che un richiedente accede alla caratteristica Azioni beacon. La chiave dell'account proprietario scelto non può essere modificata finché il fornitore non viene ripristinato ai dati di fabbrica. Il fornitore non deve rimuovere la chiave dell'account proprietario quando esaurisce gli slot senza costi per le chiavi dell'account.

  • I fornitori che supportano già FHN quando vengono accoppiati per la prima volta (o lo supportano quando vengono accoppiati dopo il ripristino dei dati di fabbrica) scelgono la prima chiave dell'account, perché è l'unica chiave dell'account esistente quando il richiedente legge lo stato di provisioning durante l'accoppiamento.

  • I fornitori che ottengono il supporto FHN dopo l'accoppiamento (ad esempio, tramite un aggiornamento firmware) possono scegliere qualsiasi chiave dell'account esistente. È ragionevole scegliere la prima chiave dell'account utilizzata per leggere lo stato di provisioning dalla caratteristica delle azioni del beacon dopo l'aggiornamento del firmware, supponendo che l'utente che ha eseguito l'aggiornamento sia l'attuale proprietario del fornitore.

• Chiave di identità effimera (EIK): una chiave di 32 byte scelta in modo casuale dal richiedente durante l'esecuzione della procedura di provisioning FHN. Questa chiave viene utilizzata per derivare le chiavi crittografiche utilizzate per la crittografia end-to-end dei report sulla posizione. Il seeker non lo rivela mai al backend.

• Chiave di recupero: definita come SHA256(ephemeral identity key || 0x01), troncata ai primi 8 byte. La chiave viene memorizzata nel backend e il Cercatore può utilizzarla per recuperare l'EIK, a condizione che l'utente esprima il proprio consenso premendo un pulsante sul dispositivo.

• Chiave di squillo: definita come SHA256(ephemeral identity key || 0x02), troncata ai primi 8 byte. La chiave è archiviata nel backend e il Cercatore può utilizzarla solo per far squillare il dispositivo.

• Chiave di protezione dal monitoraggio indesiderato: definita come SHA256(ephemeral identity key || 0x03), troncata ai primi 8 byte. La chiave è memorizzata nel backend e il richiedente può utilizzarla solo per attivare la modalità di protezione dal monitoraggio indesiderato.

Operazioni

Il formato dei dati scritti nella caratteristica è riportato nelle tabelle da 2 a 5. Ciascuna operazione viene descritta in modo più dettagliato più avanti in questa sezione.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x00: Leggi i parametri del beacon 0x01: Read provisioning state 0x02: Set ephemeral identity key 0x03: Cancella la chiave di identità effimera
1	uint8	Lunghezza dati	varia
2 - 9	array di byte	Chiave di autenticazione una tantum	I primi 8 byte di HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 - var	array di byte	Dati aggiuntivi	0x00: n/a 0x01: n/a 0x02: 32 byte che sono la chiave di identità temporanea, criptata con AES-ECB-128 con la chiave dell'account. Se il fornitore ha già un set di chiavi di identità effimere, invia anche i primi 8 byte di SHA256(current ephemeral identity key || the last nonce read from the characteristic) 0x03: I primi 8 byte di SHA256(ephemeral identity key || the last nonce read from the characteristic)

Tabella 2: richiesta di provisioning dei beacon.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x04: Read ephemeral identity key with user consent
1	uint8	Lunghezza dati	0x08
2 - 9	array di byte	Chiave di autenticazione una tantum	I primi 8 byte di HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length)

Tabella 3: richiesta di recupero della chiave di provisioning del beacon.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x05: Suoneria 0x06: Read ringing state
1	uint8	Lunghezza dati	varia
2 - 9	array di byte	Chiave di autenticazione una tantum	I primi 8 byte di HMAC-SHA256(ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 - var	array di byte	Dati aggiuntivi	0x05: 4 byte che indicano lo stato di squillo, la durata dello squillo e il volume dello squillo. 0x06: n/a

Tabella 4: richiesta di squillo.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x07: Attiva la modalità di protezione dal tracciamento indesiderato 0x08: Disattiva la modalità di protezione dal monitoraggio indesiderato
1	uint8	Lunghezza dati	varia
2 - 9	array di byte	Chiave di autenticazione una tantum	I primi 8 byte di HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 - var	array di byte	Dati aggiuntivi	0x07: 1 byte di flag di controllo (facoltativo) 0x08: I primi 8 byte di SHA256(ephemeral identity key || the last nonce read from the characteristic)

Tabella 5: richiesta di protezione dal tracciamento indesiderato.

Le scritture riuscite attivano le notifiche elencate nella tabella 6.

Le notifiche con ID dati diverso da 0x05: Modifica stato suoneria devono essere inviate prima del completamento della transazione di scrittura che attiva la notifica, ovvero prima dell'invio di un PDU di risposta per la richiesta di scrittura.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x00: Leggi i parametri del beacon 0x01: Read provisioning state 0x02: Set ephemeral identity key 0x03: Cancella la chiave di identità effimera 0x04: Read ephemeral identity key with user consent 0x05: Modifica dello stato della suoneria 0x06: Read ringing state 0x07: Attiva la modalità di protezione dal tracciamento indesiderato 0x08: Disattiva la modalità di protezione dal monitoraggio indesiderato
1	uint8	Lunghezza dati	varia
2 - 9	array di byte	Autenticazione	Dettagliato per operazione
10 - var	array di byte	Dati aggiuntivi	0x00: 8 byte che indicano la potenza di trasmissione, il valore dell'orologio, il metodo di crittografia e le funzionalità di suoneria, crittografia AES-ECB-128 con la chiave dell'account (con riempimento di zeri) 0x01: 1 byte che indica lo stato di provisioning, seguito dall'ID effimero corrente (20 o 32 byte), se applicabile 0x04: 32 byte che sono la chiave di identità effimera, AES-ECB-128 criptata con la chiave dell'account 0x05: 4 byte che indicano il nuovo stato e il trigger per la modifica 0x06: 3 byte che indicano i componenti che squillano attivamente e il numero di decimi di secondo rimanenti per lo squillo Altri ID dati utilizzano dati aggiuntivi vuoti

Tabella 6: risposta del servizio di beacon.

La tabella 7 elenca i possibili codici di errore GATT restituiti dalle operazioni.

Codice	Descrizione	Note
0x80	Non autenticato	Restituito in risposta a una richiesta di scrittura quando l'autenticazione non va a buon fine (incluso il caso in cui è stato utilizzato un nonce precedente).
0x81	Valore non valido	Restituito quando viene fornito un valore non valido o i dati ricevuti hanno un numero imprevisto di byte.
0x82	Nessun consenso dell'utente	Restituito in risposta a una richiesta di scrittura con ID dati 0x04: Read ephemeral identity key with user consent quando il dispositivo non è in modalità di accoppiamento.

Tabella 7: codici di errore GATT.

Leggi il parametro del beacon

Il richiedente può eseguire query sul fornitore per i parametri del beacon eseguendo un'operazione di scrittura sulla caratteristica costituita da una richiesta della tabella 2 con ID dati 0x00. Il fornitore verifica che la chiave di autenticazione monouso fornita corrisponda a una delle chiavi dell'account memorizzate sul dispositivo.

Se la verifica non va a buon fine, il fornitore restituisce un errore di autenticazione.

In caso di esito positivo, il fornitore invia una notifica con una risposta dalla tabella 6 con ID dati 0x00. Il fornitore crea il segmento di dati nel seguente modo:

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Potenza calibrata	La potenza calibrata ricevuta a 0 m (un valore nell'intervallo [-100, 20]). Rappresentato come numero intero con segno, con una risoluzione di 1 dBm.
1-4	uint32	Valore orologio	Il valore attuale dell'orologio in secondi (big endian).
5	uint8	Selezione della curva	La curva ellittica utilizzata per la crittografia: 0x00 (predefinito): SECP160R1 0x01: SECP256R1 (richiede pubblicità estesa)
6	uint8	Componenti	Il numero di componenti in grado di squillare: 0x00: indica che il dispositivo non è in grado di squillare. 0x01: Indica che solo un singolo componente è in grado di suonare. 0x02: Indica che due componenti, gli auricolari sinistro e destro, sono in grado di squillare in modo indipendente. 0x03: Indica che tre componenti, gli auricolari sinistro e destro e la custodia, sono in grado di squillare in modo indipendente.
7	uint8	Funzionalità di squillo	Le opzioni supportate sono: 0x00: La selezione del volume della suoneria non è disponibile. 0x01: Selezione del volume della suoneria disponibile. Se impostato, il fornitore deve accettare e gestire 3 livelli di volume come indicato in Funzionamento della suoneria.
8-15	array di byte	Spaziatura interna	Riempimento con zeri per la crittografia AES.

I dati devono essere criptati con AES-ECB-128 con la chiave dell'account utilizzata per autenticare la richiesta.

Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data after encryption || 0x01).

Leggere lo stato di provisioning del beacon

Il richiedente può eseguire query sul fornitore per lo stato di provisioning del beacon eseguendo un'operazione di scrittura sulla caratteristica costituita da una richiesta della tabella 2 con ID dati 0x01. Il fornitore verifica che la chiave di autenticazione monouso fornita corrisponda a una delle chiavi dell'account memorizzate sul dispositivo.

Se la verifica non va a buon fine, il provider restituisce un errore di autenticazione.

In caso di esito positivo, il fornitore invia una notifica con una risposta dalla tabella 6 con ID dati 0x01. Il fornitore crea il segmento di dati nel seguente modo:

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Stato di provisioning	Una maschera di bit con i seguenti valori: Bit 1 (0x01): impostato se è impostata una chiave di identità effimera per il dispositivo. Bit 2 (0x02): impostato se la chiave di autenticazione monouso fornita corrisponde alla chiave dell'account proprietario.
1-20 o 32	array di byte	Identificatore effimero attuale	20 o 32 byte (a seconda del metodo di crittografia utilizzato) che indicano l'ID temporaneo attuale pubblicizzato dal beacon, se ne è impostato uno per il dispositivo.

Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Impostare una chiave di identità effimera

Per eseguire il provisioning di un fornitore di servizi non sottoposto a provisioning come beacon FHN o modificare la chiave di identità effimera di un fornitore di servizi di cui è già stato eseguito il provisioning, il richiedente esegue un'operazione di scrittura sulla caratteristica costituita da una richiesta della tabella 2 con ID dati 0x02. Il Fornitore verifica che:

• La chiave di autenticazione una tantum fornita corrisponde alla chiave dell'account proprietario.
• Se è stato fornito un hash di una chiave di identità effimera, l'hash della chiave di identità effimera corrisponde alla chiave di identità effimera corrente.
• Se non è stato fornito un hash di una chiave di identità effimera, verifica che il provider non sia già stato sottoposto a provisioning come beacon FHN.

Se la verifica non va a buon fine, il provider restituisce un errore di autenticazione.

In caso di esito positivo, la chiave di identità effimera viene recuperata tramite la decriptazione AES-ECB-128 utilizzando la chiave dell'account corrispondente. La chiave deve essere salvata sul dispositivo e da quel momento in poi il fornitore deve iniziare a pubblicizzare i frame FHN. La nuova chiave di identità effimera ha effetto immediato dopo la chiusura della connessione BLE. Il fornitore invia una notifica con una risposta dalla tabella 6 con l'ID dati 0x02.

Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Cancella la chiave di identità effimera

Per eseguire il deprovisioning della parte del beacon del fornitore, il richiedente esegue un'operazione di scrittura sulla caratteristica, costituita da una richiesta della tabella 2 con ID dati 0x03. Il Fornitore verifica che:

• La chiave di autenticazione una tantum fornita corrisponde alla chiave dell'account proprietario.
• La chiave di identità effimera con hash corrisponde alla chiave di identità effimera corrente.

Se il fornitore non è stato sottoposto al provisioning come beacon FHN o la verifica non va a buon fine, viene restituito un errore di autenticazione.

In caso di esito positivo, il provider dimentica la chiave e interrompe la pubblicità dei frame FHN. Il fornitore invia una notifica con una risposta dalla tabella 6 con l'ID dati 0x03. Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Leggere la chiave di identità effimera con il consenso dell'utente

Questa opzione è disponibile solo per recuperare una chiave smarrita, poiché la chiave viene memorizzata solo localmente da Seeker. Pertanto, questa funzionalità è disponibile solo quando il dispositivo è in modalità di accoppiamento o per un periodo di tempo limitato dopo la pressione di un tasto fisico sul dispositivo (che costituisce il consenso dell'utente).

Il richiedente deve archiviare la chiave di recupero nel backend per poter recuperare la chiave in testo non crittografato, ma non archivia l'EIK stesso.

Per leggere l'EIK, il richiedente esegue un'operazione di scrittura sulla caratteristica, che consiste in una richiesta dalla tabella 3 con ID dati 0x04. Il fornitore verifica che:

• La chiave di recupero sottoposta ad hashing corrisponde alla chiave di recupero prevista.
• Il dispositivo è in modalità di recupero EIK.

Se la verifica non va a buon fine, il provider restituisce un errore di autenticazione.

Se il dispositivo non è in modalità di accoppiamento, il fornitore restituisce un errore No User Consent.

In caso di esito positivo, il fornitore invia una notifica con una risposta della tabella 6 con ID dati 0x04.

Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Funzionamento di Ring

Il richiedente può chiedere al fornitore di riprodurre un suono eseguendo un'operazione di scrittura sulla caratteristica, che consiste in una richiesta della tabella 4 con ID dati 0x05. Il fornitore crea il segmento di dati nel seguente modo:

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Funzionamento di Ring	Una maschera di bit con i seguenti valori: Bit 1 (0x01): suona a destra Bit 2 (0x02): Fai squillare sinistro Bit 3 (0x04): custodia con anello 0xFF: Suona tutti i componenti 0x00: Interrompi squillo
1 - 2	uint16	Timeout	Il timeout in decimi di secondo. Non deve essere zero e non deve essere superiore all'equivalente di 10 minuti. Il provider utilizza questo valore per determinare per quanto tempo deve squillare prima di disattivarsi. Il timeout sostituisce quello già in vigore se un componente del dispositivo sta già squillando. Se l'operazione di suoneria è impostata su 0x00, il timeout viene ignorato.
3	uint8	Volume	0x00: Predefinito 0x01: Basso 0x02: Medio 0x03: Alto Il significato esatto di questi valori dipende dall'implementazione.

Al ricevimento della richiesta, il fornitore verifica che:

• La chiave di autenticazione una tantum fornita corrisponde alla chiave dell'anello.
• Lo stato richiesto corrisponde ai componenti che possono squillare.

Se il fornitore non è stato sottoposto al provisioning come beacon FHN o la verifica non va a buon fine, viene restituito un errore di autenticazione. Tuttavia, se il fornitore ha attivato la protezione dal monitoraggio indesiderato e la richiesta di attivazione della protezione dal monitoraggio indesiderato aveva il flag di autenticazione con squillo saltato attivato, il fornitore deve saltare il controllo. I dati di autenticazione devono comunque essere forniti dal richiedente, ma possono essere impostati su un valore arbitrario.

Quando la suoneria inizia o termina, viene inviata una notifica come indicato nella tabella 6 con ID dati 0x05. I contenuti della notifica sono definiti come segue:

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Stato di chiamata	0x00: Avviato 0x01: Impossibile avviare o interrompere (tutti i componenti richiesti non rientrano nell'intervallo) 0x02: Interrotto (timeout) 0x03: Arrestato (pressione del pulsante) 0x04: Arrestato (richiesta GATT)
1	uint8	Componenti di squillo	Una maschera di bit dei componenti che squillano attivamente, come definito nella richiesta.
2 - 3	uint16	Timeout	Il tempo rimanente per lo squillo in decimi di secondo. Se il dispositivo ha smesso di squillare, deve essere restituito 0x0000.

Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(ring key, protocol major version number || the nonce used to initiate the ringing command || data ID || data length || additional data || 0x01).

Se il dispositivo è già nello stato di suoneria richiesto quando viene ricevuta una richiesta di suoneria o di interruzione della suoneria, il fornitore deve inviare una notifica con uno stato di suoneria o 0x00: Started o 0x04: Stopped (richiesta GATT), rispettivamente. Questa richiesta esegue l'override dei parametri dello stato esistente, in modo che la durata della suoneria possa essere estesa.

Se il fornitore ha un pulsante fisico (o il rilevamento del tocco è attivato), questo pulsante deve interrompere la funzione di squillo se viene premuto mentre lo squillo è attivo.

Recuperare lo stato di squillo del beacon

Per ottenere lo stato di squillo del beacon, il cercatore esegue un'operazione di scrittura nella caratteristica, che consiste in una richiesta della tabella 4 con ID dati 0x06. Il fornitore verifica che la chiave di autenticazione monouso fornita corrisponda alla chiave dell'anello.

Se il fornitore non è stato sottoposto al provisioning come beacon FHN o se la verifica non riesce, il fornitore restituisce un errore non autenticato.

In caso di esito positivo, il fornitore invia una notifica con una risposta della tabella 6 con ID dati 0x06. Il fornitore crea il segmento di dati nel seguente modo:

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Componenti di squillo	I componenti che squillano attivamente, come definito nella richiesta di squillo.
1 - 2	uint16	Timeout	Il tempo rimanente per lo squillo in decimi di secondo. Tieni presente che se il dispositivo non squilla, deve essere restituito 0x0000.

Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Modalità di protezione dal monitoraggio indesiderato

La modalità di protezione dal tracciamento indesiderato è pensata per consentire a qualsiasi client di identificare dispositivi abusivi senza comunicazione con il server. Per impostazione predefinita, il fornitore deve ruotare tutti gli identificatori come descritto in Rotazione degli ID. Il servizio Find Hub può inoltrare una richiesta di attivazione della modalità di protezione dal monitoraggio indesiderato tramite la rete Find Hub. In questo modo, il servizio fa sì che il fornitore utilizzi temporaneamente un indirizzo MAC fisso, consentendo ai client di rilevare il dispositivo e avvisare l'utente di un possibile tracciamento indesiderato.

Per attivare o disattivare la modalità di protezione dal monitoraggio indesiderato del beacon, il Cercatore esegue un'operazione di scrittura sulla caratteristica, costituita da una richiesta dalla tabella 5 con ID dati 0x07 o 0x08 rispettivamente.

Quando si attiva la modalità di protezione dal tracciamento indesiderato

Il fornitore crea il segmento di dati nel seguente modo:

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Flag di controllo	0x01: Salta l'autenticazione con squillo. Se impostato, le richieste di squillo non vengono autenticate in modalità protezione dal tracciamento indesiderato. Se non viene impostato alcun flag (il byte è composto da tutti zeri), è valido omettere completamente la sezione dei dati e inviare una sezione dei dati vuota. I flag sono attivi solo fino alla disattivazione della modalità di protezione dal monitoraggio indesiderato.

Il fornitore verifica che la chiave di autenticazione monouso fornita corrisponda alla chiave di protezione dal monitoraggio indesiderato. Se il fornitore non è stato sottoposto al provisioning come beacon FHN o la verifica non riesce, viene restituito un errore di autenticazione.

Quando viene attivata la modalità di protezione dal monitoraggio indesiderato, il beacon deve ridurre la frequenza di rotazione dell'indirizzo MAC privato a una volta ogni 24 ore. L'identificatore effimero pubblicizzato dovrebbe continuare a ruotare come di consueto. Il tipo di frame deve essere impostato su 0x41. Lo stato viene visualizzato anche nella sezione flag con hash.

Quando disattivi la modalità di protezione antitracciamento indesiderato

Il Fornitore verifica che:

• La chiave di autenticazione monouso fornita corrisponde alla chiave di protezione dal tracciamento indesiderato.
• La chiave di identità effimera con hash corrisponde alla chiave di identità effimera corrente.

Se il fornitore non è stato sottoposto al provisioning come beacon FHN o la verifica non riesce, il fornitore restituisce un errore di autenticazione non riuscita.

Quando la modalità di protezione dal monitoraggio indesiderato viene disattivata, il beacon dovrebbe iniziare di nuovo a ruotare l'indirizzo MAC a una velocità normale, sincronizzata con la rotazione dell'identificatore effimero. Il tipo di frame deve essere reimpostato su 0x40. Lo stato viene riflesso anche nella sezione Flag con hash.

In caso di esito positivo, il fornitore invia una notifica con una risposta della tabella 6 con ID dati 0x07 o 0x08.

Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Frame pubblicizzati

Dopo il provisioning, il fornitore deve pubblicizzare i frame FHN almeno una volta ogni 2 secondi. Se vengono pubblicizzati frame di accoppiamento rapido, il fornitore deve alternare i frame FHN all'interno delle normali pubblicità di accoppiamento rapido. Ad esempio, ogni due secondi, il fornitore deve pubblicare sette annunci Fast Pair e un annuncio FHN.

La potenza di trasmissione Bluetooth condotta per le pubblicità FHN deve essere impostata su almeno 0 dBm.

Il frame FHN contiene una chiave pubblica utilizzata per criptare i report sulla posizione da qualsiasi client di supporto che contribuisce alla rete di crowdsourcing. Sono disponibili due tipi di chiavi a curva ellittica: una chiave a 160 bit adatta ai frame BLE 4 legacy o una chiave a 256 bit che richiede BLE 5 con funzionalità di pubblicità estese. L'implementazione del fornitore determina quale curva viene utilizzata.

Un frame FHN è strutturato nel seguente modo.

Ottetto	Valore	Descrizione
0	0x02	Lunghezza
1	0x01	Valore del tipo di dati Flag
2	0x06	Dati dei flag
3	0x18 o 0x19	Lunghezza
4	0x16	Valore del tipo di dati dei dati di servizio
5	0xAA	UUID servizio a 16 bit
6	0xFE	…
7	0x40 o 0x41	Tipo di frame FHN con indicazione della modalità di protezione dal tracciamento indesiderato
8..27		Identificatore effimero di 20 byte
28		Flag con hash

Tabella 8: frame FHN che supporta una curva a 160 bit.

La tabella 9 mostra gli offset di byte e i valori per una curva a 256 bit.

Ottetto	Valore	Descrizione
0	0x02	Lunghezza
1	0x01	Valore del tipo di dati Flag
2	0x06	Dati dei flag
3	0x24 o 0x25	Lunghezza
4	0x16	Valore del tipo di dati dei dati di servizio
5	0xAA	UUID servizio a 16 bit
6	0xFE	…
7	0x40 o 0x41	Tipo di frame FHN con indicazione della modalità di protezione dal tracciamento indesiderato
8..39		Identificatore effimero di 32 byte
40		Flag con hash

Tabella 9: frame FHN che supporta una curva a 256 bit.

Calcolo dell'identificatore temporaneo (EID)

Un valore casuale viene generato dalla crittografia AES-ECB-256 della seguente struttura di dati con la chiave di identità effimera:

Ottetto	Campo	Descrizione
0 - 10	Spaziatura interna	Valore = 0xFF
11	K	Esponente del periodo di rotazione
12 - 15	TS[0]...TS[3]	Contatore del tempo del beacon, in formato big-endian a 32 bit. I K bit meno significativi vengono azzerati.
16 - 26	Spaziatura interna	Valore = 0x00
27	K	Esponente del periodo di rotazione
28 - 31	TS[0]...TS[3]	Contatore del tempo del beacon, in formato big-endian a 32 bit. I K bit meno significativi vengono azzerati.

Tabella 10: costruzione di un numero pseudocasuale.

Il risultato di questo calcolo è un numero a 256 bit, indicato con r'.

Per il resto del calcolo, SECP160R1 o SECP256R1 vengono utilizzati per operazioni di crittografia a curva ellittica. Consulta le definizioni delle curve in SEC 2: Recommended Elliptic Curve Domain Parameters, che definisce Fp, n e G a cui viene fatto riferimento di seguito.

Ora r' viene proiettato nel campo finito Fp calcolando r = r' mod n. Infine, calcola R = r * G, che è un punto sulla curva che rappresenta la chiave pubblica utilizzata. Il beacon pubblicizza Rx, ovvero la coordinata x di R, come identificatore effimero.

Flag sottoposti ad hashing

Il campo dei flag con hash viene calcolato come segue (i bit sono indicati dal più significativo al meno significativo):

• Bit 0-4: riservati (impostati su zero).
• I bit 5-6 indicano il livello della batteria del dispositivo come segue:
  • 00: Indicazione del livello di batteria non supportata
  • 01: Livello batteria normale
  • 10: Livello batteria basso
  • 11: Livello batteria quasi esaurito (è necessario sostituire la batteria a breve)
• Il bit 7 è impostato su 1 se il beacon è in modalità di protezione dal monitoraggio indesiderato e su 0 in caso contrario.

Per produrre il valore finale di questo byte, viene eseguito l'operatore XOR con il byte meno significativo di SHA256(r).

Tieni presente che r deve essere allineato alle dimensioni della curva. Aggiungi zeri come bit più significativi se la rappresentazione è più breve di 160 o 256 bit oppure tronca i bit più significativi se la rappresentazione è più lunga di 160 o 256 bit.

Se il beacon non supporta l'indicazione del livello della batteria e non è in modalità di protezione dal tracciamento indesiderato, è consentito omettere completamente questo byte dalla pubblicità.

Crittografia con EID

Per criptare un messaggio m, un osservatore (che ha letto Rx dal beacon) deve fare quanto segue:

1. Scegli un numero casuale s in Fp, come definito nella sezione Calcolo dell'ID evento.
2. Compute S = s * G.
3. Calcola R = (Rx, Ry) per sostituzione nell'equazione della curva e scegliendo un valore Ry arbitrario tra i risultati possibili.
4. Calcola la chiave AES a 256 bit k = HKDF-SHA256((s * R)x), dove (s * R)x è la coordinata x del risultato della moltiplicazione della curva. Il sale non è specificato.
5. Siano URx e LRx gli 80 bit superiori e inferiori di Rx, rispettivamente, in formato big-endian. In modo simile, definisci USx e LSx per S.
6. Compute nonce = LRx || LSx.
7. Compute (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
8. Invia (URx, Sx, m’, tag) al proprietario, possibilmente tramite un servizio remoto non attendibile.

Decrittografia dei valori criptati con EID

Il client del proprietario, in possesso dell'EIK e dell'esponente del periodo di rotazione, decritta il messaggio nel seguente modo:

1. Dato URx, ottieni il valore del contatore del tempo del beacon su cui si basa URx. Ciò può essere fatto dal computer client del proprietario calcolando i valori Rx per i valori del contatore del tempo del beacon per il passato recente e il futuro prossimo.
2. Dato il valore del contatore del tempo del beacon su cui si basa URx, calcola il valore previsto di r come definito nella sezione Calcolo dell'ID evento.
3. Calcola R = r * G e verifica che corrisponda al valore di URx fornito dal segnalatore.
4. Calcola S = (Sx, Sy) per sostituzione nell'equazione della curva e scegliendo un valore Sy arbitrario tra i risultati possibili.
5. Calcola k = HKDF-SHA256((r * S)x), dove (r * S)x è la coordinata x del risultato della moltiplicazione della curva.
6. Compute nonce = LRx || LSx.
7. Compute m = AES-EAX-256-DEC(k, nonce, m’, tag).

Rotazione degli ID

Per la pubblicità dei frame FHN deve essere utilizzato un indirizzo BLE risolvibile (RPA) o non risolvibile (NRPA). L'RPA è obbligatorio per i dispositivi LE Audio (LEA) ed è consigliato per gli altri dispositivi, ad eccezione dei tracker che non utilizzano l'associazione.

La pubblicità di Accoppiamento rapido, la pubblicità FHN e gli indirizzi BLE corrispondenti devono ruotare contemporaneamente. La rotazione deve avvenire in media ogni 1024 secondi. Il punto preciso in cui il beacon inizia a pubblicizzare il nuovo identificatore deve essere randomizzato all'interno della finestra.

L'approccio consigliato per randomizzare l'ora di rotazione è impostarla sull'ora di rotazione successiva prevista (se non è stata applicata alcuna randomizzazione) più un fattore di tempo randomizzato positivo compreso tra 1 e 204 secondi.

Quando il dispositivo è in modalità di protezione dal monitoraggio indesiderato, l'indirizzo BLE della pubblicità FHN deve essere fisso, ma l'RPA per la pubblicità non rilevabile FP (come l'accoppiamento rapido) deve continuare a ruotare. È accettabile utilizzare indirizzi diversi per i diversi protocolli.

Recupero in seguito a interruzione dell'alimentazione

La risoluzione dell'identificatore effimero è strettamente legata al suo valore di clock al momento della pubblicazione dell'annuncio, pertanto è importante che il fornitore possa recuperare il valore di clock in caso di interruzione dell'alimentazione. È consigliabile che il fornitore scriva il valore corrente dell'orologio nella memoria non volatile almeno una volta al giorno e che al momento dell'avvio il fornitore controlli la memoria non volatile per verificare se è presente un valore da cui inizializzare. I resolver dell'identificatore effimero implementerebbero la risoluzione in un intervallo di tempo sufficiente a consentire sia una deriva ragionevole dell'orologio sia questo tipo di recupero in caso di interruzione dell'alimentazione.

I fornitori devono comunque fare ogni sforzo per ridurre al minimo le variazioni di orologio, poiché la finestra temporale di risoluzione è limitata. Deve essere implementato almeno un metodo di sincronizzazione dell'orologio aggiuntivo (frame Fast Pair non rilevabili o implementazione del flusso di messaggi).

Linee guida per l'implementazione dell'accoppiamento rapido

Questa sezione descrive gli aspetti speciali dell'implementazione dell'accoppiamento rapido sui provider che supportano FHN.

Linee guida specifiche per le targhette di localizzazione

• Se il fornitore è stato accoppiato, ma FHN non è stato eseguito il provisioning entro 5 minuti (o se è stato applicato un aggiornamento OTA mentre il dispositivo è accoppiato ma non è stato eseguito il provisioning di FHN), il fornitore deve ripristinare la configurazione di fabbrica e cancellare le chiavi dell'account memorizzate.
• Una volta accoppiato, il fornitore non deve modificare il proprio indirizzo MAC finché non viene eseguito il provisioning di FHN o finché non trascorrono 5 minuti.
• Se la chiave di identità effimera viene cancellata dal dispositivo, quest'ultimo deve eseguire un ripristino dei dati di fabbrica e cancellare anche le chiavi dell'account memorizzate.
• Il fornitore deve rifiutare i normali tentativi di accoppiamento Bluetooth e accettare solo l'accoppiamento rapido.
• Il fornitore deve includere un meccanismo che consenta agli utenti di interrompere temporaneamente la pubblicità senza ripristinare i dati di fabbrica del dispositivo (ad esempio, premendo una combinazione di pulsanti).
• Dopo un'interruzione dell'alimentazione, il dispositivo deve pubblicizzare frame di accoppiamento rapido non rilevabili fino alla successiva chiamata di read beacon parameters. In questo modo, il cercatore può rilevare il dispositivo e sincronizzare l'orologio anche se si è verificato uno scostamento significativo.
• Quando viene pubblicizzato un frame di Accoppiamento rapido non rilevabile, le indicazioni dell'interfaccia utente non devono essere attivate.
• I frame di Accoppiamento Rapido rilevabili non devono essere pubblicizzati mentre il fornitore è sottoposto al provisioning per FHN.
• Il Fornitore non deve esporre informazioni di identificazione in modo non autenticato (ad es. nomi o identificatori).

Linee guida specifiche per i dispositivi Bluetooth Classic

Questa sezione descrive gli aspetti speciali dei dispositivi Bluetooth classici che supportano FHN.

Provisioning FHN di dispositivi già accoppiati

Il fornitore non viene sempre sottoposto al provisioning per FHN durante l'accoppiamento con il richiedente, ma un po' di tempo dopo. In questo caso, il fornitore potrebbe non disporre di un indirizzo MAC BLE aggiornato necessario per stabilire una connessione GATT. Il fornitore deve supportare almeno uno dei seguenti modi per consentire al cercatore di ottenere il proprio indirizzo BLE quando è già accoppiato:

• Il fornitore può pubblicizzare periodicamente i dati dell'account Fast Pair che consentono al richiedente di trovare il proprio indirizzo BLE tramite una scansione BLE.
  Questo approccio è adatto ai fornitori che non implementano il flusso di messaggi.
• Il fornitore può fornire questi dati tramite il flusso di messaggi dell'accoppiamento rapido tramite Bluetooth classico.
  Questo approccio è adatto ai fornitori che non pubblicizzano i frame di Accoppiamento rapido mentre sono connessi al dispositivo di ricerca tramite Bluetooth.

Il supporto di entrambi gli approcci aumenta le probabilità che l'utente possa eseguire il provisioning del dispositivo per FHN.

Stream di messaggi dell'accoppiamento rapido

Il Fornitore può implementare lo stream di messaggi di Fast Pair e utilizzarlo per notificare al Richiedente le informazioni sul dispositivo. L'implementazione del flusso di messaggi attiva determinate funzionalità, come descritto in questa sezione.

Il fornitore deve inviare messaggi con informazioni sul dispositivo una volta ogni volta che viene stabilito il canale RFCOMM del flusso di messaggi.

Versione firmware (codice informazioni dispositivo 0x09) e funzionalità di monitoraggio

Quando un aggiornamento firmware aggiunge il supporto FHN al fornitore, un cercatore connesso può notificare all'utente questa novità e offrire di eseguire il provisioning. In caso contrario, l'utente deve navigare manualmente nell'elenco dei dispositivi Bluetooth per avviare il provisioning di FHN.

Per consentirlo, il fornitore deve utilizzare la proprietà Versione firmware (codice 0x09) per segnalare un valore stringa che rappresenta la versione del firmware. Inoltre, il fornitore deve supportare il protocollo che consente al richiedente di conoscere le modifiche alle funzionalità dovute agli aggiornamenti firmware.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Evento informazioni dispositivo	0x03
1	uint8	Versione firmware	0x09
2 - 3	uint16	Lunghezza dati aggiuntiva	varia
var	array di byte	Stringa di versione	varia

Tabella 11: evento informazioni sul dispositivo: versione del firmware aggiornata.

Al ricevimento di una richiesta di aggiornamento delle funzionalità (0x0601), se il fornitore ha attivato il supporto per il monitoraggio FHN, deve rispondere come mostrato nella tabella 12.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Evento di sincronizzazione delle funzionalità del dispositivo	0x06
1	uint8	Monitoraggio FHN	0x03
2 - 3	uint16	Lunghezza dati aggiuntiva	0x0007
4	uint8	Stato di provisioning FHN	0x00 se non è stato eseguito il provisioning; 0x01 se è stato eseguito il provisioning da qualsiasi account
5 - 10	array di byte	L'indirizzo MAC BLE attuale del dispositivo	varia

Tabella 12: evento di sincronizzazione della funzionalità del dispositivo: è stata aggiunta la funzionalità di monitoraggio.

Identificatore effimero attuale (codice informazioni dispositivo 0x0B)

Il fornitore può utilizzare l'identificatore effimero corrente (codice 0x0B) per segnalare l'EID e il valore dell'orologio correnti quando il fornitore viene sottoposto al provisioning per FHN, per sincronizzare il cercatore in caso di deriva dell'orologio (ad esempio, a causa della batteria scarica). In caso contrario, Seeker avvia una connessione più costosa e meno affidabile per questo scopo.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Evento informazioni dispositivo	0x03
1	uint8	Identificatore effimero attuale	0x0B
2 - 3	uint16	Lunghezza dati aggiuntiva	0x0018 o 0x0024
4 - 7	array di byte	Valore orologio	Esempio: 0x13F9EA80
8 - 19 o 31	array di byte	EID attuale	Esempio: 0x1122334455667788990011223344556677889900

Tabella 13: evento Informazioni sul dispositivo: sincronizzazione dell'orologio

Ripristinare i dati di fabbrica

Per i dispositivi che supportano il ripristino dei dati di fabbrica: se viene eseguito un ripristino dei dati di fabbrica, il provider deve interrompere la trasmissione dei beacon ed eliminare la chiave di identità effimera e tutte le chiavi dell'account memorizzate, inclusa la chiave dell'account del proprietario.

Dopo un ripristino dei dati di fabbrica (manuale o programmatico), il fornitore non deve iniziare subito a pubblicizzare Fast Pair, per evitare che il flusso di accoppiamento inizi immediatamente dopo l'eliminazione del dispositivo da parte dell'utente.

Prevenzione del monitoraggio indesiderato

I dispositivi FHN certificati devono soddisfare anche i requisiti della versione di implementazione della specifica multipiattaforma per il rilevamento dei tracker della posizione indesiderati (DULT).

Linee guida pertinenti specifiche per FHN per essere conformi alla specifica DULT:

• Qualsiasi dispositivo compatibile con FHN deve essere registrato nella console Dispositivi nelle vicinanze e deve avere la funzionalità "Trova Hub" attivata.
• Il dispositivo deve implementare il servizio e la caratteristica di accessorio non proprietario definiti nella versione di implementazione della specifica DULT, incluse le operazioni Informazioni accessorio e Controlli non proprietario.
• Durante il periodo di compatibilità con le versioni precedenti, come definito nella specifica DULT, non vengono apportate modifiche al frame pubblicizzato come definito in questo documento.
• La "modalità di protezione antitracciamento indesiderato" definita in questo documento corrisponde allo "stato separato" definito dalle specifiche DULT.
• Linee guida per l'implementazione dei codici operativi Accessory Information:
  • Get_Product_Data deve restituire l'ID modello fornito dalla console, con zeri iniziali per soddisfare il requisito di 8 byte. Ad esempio, l'ID modello 0xFFFFFF viene restituito come 0x0000000000FFFFFF.
  • Get_Manufacturer_Name e Get_Model_Name devono corrispondere ai valori forniti nella console.
  • Get_Accessory_Category può restituire il valore generico "Tracker di posizione" se nessun'altra categoria si adatta meglio al tipo di dispositivo.
  • Get_Accessory_Capabilities deve indicare il supporto per la suoneria e la ricerca dell'identificatore BLE.
  • Get_Network_ID deve restituire l'identificatore di Google (0x02).
• Linee guida per l'implementazione del codice operativo Get_Identifier:
  • L'operazione deve restituire una risposta valida solo per 5 minuti dopo che l'utente ha attivato la modalità "Identificazione", che richiede una combinazione di pressioni dei tasti. Un segnale visivo o audio deve indicare all'utente che il fornitore è entrato in questa modalità. Le istruzioni specifiche del modello per l'attivazione di questa modalità devono essere fornite a Google come requisito per la certificazione e almeno 10 giorni prima di qualsiasi aggiornamento o modifica delle istruzioni.
  • La risposta è strutturata come segue: i primi 10 byte dell'identificatore effimero corrente, seguiti dai primi 8 byte di HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
• Linee guida per l'implementazione dell'identificatore tramite NFC:
  • Come URL, utilizza find-my.googleapis.com/lookup.
  • Come parametro e, utilizza la stessa risposta creata per Get_Identifier, codificata in esadecimale.
  • Come parametro pid, utilizza la stessa risposta creata per Get_Product_Data, codificata in esadecimale.
• È obbligatorio che il dispositivo includa un emettitore di suoni e supporti la funzione di squillo. In base alle specifiche DULT, il dispositivo sonoro deve emettere un suono con un'intensità di picco minima di 60 fon come definita dalla norma ISO 532-1:2017.
• Linee guida per l'implementazione del codice operativo Sound_Start:
  • Il comando deve attivare la suoneria in tutti i componenti disponibili.
  • Deve essere utilizzato il volume massimo supportato.
  • La durata consigliata per la suoneria è di 12 secondi.
• I tracker devono includere un meccanismo che consenta agli utenti di interrompere temporaneamente la pubblicità senza ripristinare i dati di fabbrica del dispositivo (ad esempio, premendo una combinazione di tasti).
  • Le istruzioni di disattivazione devono essere documentate in un URL disponibile pubblicamente e fornite a Google come requisito per la certificazione e almeno 10 giorni prima di qualsiasi aggiornamento o modifica delle istruzioni.
  • L'URL deve supportare la localizzazione. A seconda del client, la lingua verrà fornita come parametro di query ("hl=en") o utilizzando l'intestazione HTTP "accept-language".

Linee guida per i protocolli commutabili

• Deve essere utilizzato un solo protocollo alla volta. Assicurati che sul dispositivo possa funzionare una sola rete alla volta. Questo requisito è necessario per garantire che non vi sia commistione di dati utente sensibili tra protocolli diversi.
• Ti consigliamo di incorporare un flusso di lavoro di ripristino dei dati di fabbrica nel dispositivo che consente a un utente di configurare nuovamente un dispositivo con una rete diversa.
• La procedura di aggiornamento di un dispositivo a una rete deve essere semplice da usare ed equa tra le reti. Un utente deve poter scegliere la rete che vuole utilizzare senza dare la preferenza a una delle reti. Questo flusso deve essere approvato dal team di Google.

Aggiornamenti firmware

Il processo e la distribuzione degli aggiornamenti OTA devono essere gestiti dal partner utilizzando il proprio flusso di lavoro per app mobile o web.

L'accoppiamento rapido supporta l'invio di notifiche all'utente, informandolo degli aggiornamenti OTA disponibili. Per utilizzare questo meccanismo:

• L'ultima versione del firmware deve essere aggiornata nella console per i dispositivi nelle vicinanze.
• Nell'app complementare deve essere impostata la console Dispositivi nelle vicinanze. Deve supportare l'intent di aggiornamento firmware.
• Il fornitore deve implementare la caratteristica GATT Revisione firmware.

Per impedire il monitoraggio, l'accesso alla caratteristica Revisione firmware deve essere limitato. Il richiedente leggerà prima lo stato di provisioning e fornirà una chiave di autenticazione, come definito in questa specifica, e solo dopo leggerà la revisione del firmware. Questa operazione verrà eseguita tramite la stessa connessione. Se viene effettuato un tentativo di leggere la revisione del firmware e il fornitore non è associato o non è stata completata correttamente un'operazione autenticata sulla stessa connessione, il fornitore deve restituire un errore non autenticato.

Compatibilità

La rete di Find Hub richiede che siano attivi i servizi di localizzazione e il Bluetooth. Richiede un servizio cellulare o una connessione a internet. Funziona su Android 9 e versioni successive e in determinati paesi per gli utenti di età idonea.

Log delle modifiche

Versione FHN	Data	Commento
v1		Versione iniziale della specifica FHN per l'accesso in anteprima.
v1.1	febbraio 2023	È stata aggiunta un'indicazione in testo normale della modalità di protezione dal tracciamento indesiderato. È stata aggiunta un'opzione per ignorare l'autenticazione delle richieste di squillo in modalità di protezione dal tracciamento indesiderato.
v1.2	Aprile 2023	È stata aggiornata la definizione della chiave AK di un proprietario. È stato aggiunto un consiglio per il recupero in caso di interruzione dell'alimentazione nei tag del localizzatore. È stato aggiunto un chiarimento per la randomizzazione dell'indirizzo MAC. È stato aggiunto un chiarimento sulla rotazione dell'indirizzo MAC in modalità di protezione dal monitoraggio indesiderato. È stata aggiunta una linea guida su come disattivare un localizzatore.
v1.3	Dicembre 2023	È stato aggiunto un chiarimento sulle informazioni identificative esposte dai tag di localizzazione. È stato aggiunto un requisito per implementare la specifica di prevenzione del monitoraggio indesiderato. Sono state aggiunte linee guida per i dispositivi con protocollo commutabile.