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) che trasmettono segnali. 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.

Nota: se ti interessa integrare il tuo localizzatore o dispositivo non udibile con l'accessorio di rete Find Hub, compila un modulo di proposta di dispositivo Find Hub. Se ti interessa aggiungere il supporto di Find Hub a cuffie over-ear o TWS, compila il modulo di proposta di dispositivo per l'accoppiamento rapido.

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 Accoppiamento rapido per FHN.

Autenticazione

Le operazioni richieste da questa estensione vengono eseguite come operazione di scrittura, protetta da un meccanismo di richiesta-risposta. 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 monouso 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 richiedente 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 la 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 viene 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: Read beacon parameters 0x01: Read provisioning state 0x02: Imposta la chiave di identità effimera 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 insieme 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: Read beacon parameters 0x01: Read provisioning state 0x02: Imposta la chiave di identità effimera 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 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ò interrogare il 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 provider 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 della 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 del cronometro	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 suonare: 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 chiamata	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 tre livelli di volume come indicato in Operazione di squillo.
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 effimero corrente 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 non sottoposto a provisioning come beacon FHN o modificare la chiave di identità effimera del fornitore già sottoposto a 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 al 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, in quanto 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 alla caratteristica, costituita da 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 disattivare l'audio. Il timeout sostituisce quello già in vigore se un componente del dispositivo sta già squillando. Se l'operazione di squillo è 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 chiamata saltata 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 squillo	0x00: Avviato 0x01: Impossibile avviare o arrestare (tutti i componenti richiesti non rientrano nell'intervallo) 0x02: Interrotto (timeout) 0x03: Interrotto (pressione del pulsante) 0x04: Interrotto (richiesta GATT)
1	uint8	Componenti di suoneria	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 suoneria se viene premuto mentre la suoneria è attiva.

Nota: per i fornitori che includono il rilevamento sulla testa, verifica che il dispositivo non sia sulla testa prima di suonare al massimo volume. Se il rilevamento sulla testa non è supportato o non è affidabile, aumenta gradualmente il volume (in modo che l'utente abbia il tempo di interrompere la suoneria o rimuovere gli auricolari).

Nota :il fornitore deve continuare a squillare indipendentemente dallo stato della connessione della persona che ha richiesto la suoneria. In questo modo si evita che il dispositivo smetta di squillare perché la connessione è stata interrotta a causa dell'allontanamento eccessivo del cliente dal dispositivo. Il dispositivo non viene trovato perché ha smesso di squillare ed è troppo lontano dal client per richiedere di squillare di nuovo.

Ottenere lo stato di squillo del beacon

Per ottenere lo stato di suoneria del beacon, il cercatore esegue un'operazione di scrittura sulla 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 suoneria	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, 0x0000 deve essere restituito.

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 tracciamento 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 dispositivo di ricerca esegue un'operazione di scrittura sulla caratteristica, costituita da una richiesta della 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 va a buon fine, 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 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 va a buon fine, 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 temporaneo. Il tipo di frame deve essere reimpostato su 0x40. Lo stato viene visualizzato anche nella sezione Flag con hash.

In caso di esito positivo, il fornitore invia una notifica con una risposta dalla 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).

Ricerca di precisione

Questa sezione descrive in dettaglio il flusso e le operazioni aggiuntive necessarie per una ricerca di precisione. Qui si applicano le stesse regole per la caratteristica GATT e l'autenticazione definite nella sezione delle specifiche GATT. La ricerca di precisione è facoltativa.

Il tipo di ricerca di precisione dipende dal tipo di tecnologie di misurazione della distanza supportate sui dispositivi coinvolti nella ricerca di precisione. Le tecnologie di misurazione supportate sono disponibili nella specifica Misurazione: sequenza di messaggi e payload out-of-band. Le sezioni successive esplorano il tipo di esperienza di ricerca di precisione che ci si può aspettare in base alla tecnologia di misurazione della distanza utilizzata.

Flusso di ricerca di precisione

Questa sezione esplora il flusso di messaggi FHNA per la ricerca di precisione. La figura 1 mostra il flusso dei messaggi e i paragrafi spiegano ogni messaggio in modo più dettagliato.

Fig. 1 Flusso tipico dei messaggi di Ricerca di precisione

Il dispositivo Iniziatore è quello su cui è installata l'app Find Hub e da cui è stata attivata la funzionalità di ricerca precisa. L'iniziatore è il dispositivo che sta cercando l'altro dispositivo.

Il dispositivo Risponditore è il dispositivo che il dispositivo Iniziatore sta cercando di trovare.

Il dispositivo Initiator invia un messaggio di richiesta di funzionalità di misurazione al dispositivo Responder, in cui elenca le tecnologie di misurazione di cui è interessato a conoscere dal dispositivo Responder. Il dispositivo di risposta risponderà con la notifica di risposta alla funzionalità di misurazione, contenente informazioni su quali tecnologie di misurazione sono supportate e quali sono le loro funzionalità. Il risponditore includerà solo le informazioni richieste dall'iniziatore. L'elenco delle funzionalità verrà ordinato in base alla priorità della tecnologia di misurazione preferita dal dispositivo di risposta, con la prima della lista che ha la priorità più alta.

Il dispositivo iniziatore invierà quindi un messaggio di configurazione del ranging, in cui definirà la configurazione per ogni tecnologia di ranging con cui vuole eseguire il ranging. Dopo aver ricevuto questo messaggio, il dispositivo Responder deve iniziare a misurare la distanza per le tecnologie applicabili utilizzando le configurazioni fornite. Il dispositivo risponditore invierà una notifica di risposta di configurazione del ranging, che contiene i risultati relativi all'avvio corretto di ogni singola tecnologia di ranging. Alcune tecnologie di misurazione della distanza devono essere avviate sia sul dispositivo Initiator che su quello Responder per una sessione di misurazione della distanza riuscita, mentre per altre è necessario solo che vengano avviate sul dispositivo Initiator. Tuttavia, il dispositivo Responder deve rispondere con un risultato positivo per queste tecnologie. Maggiori informazioni sul comportamento di una tecnologia di misurazione specifica sono disponibili nelle sezioni successive.

Quando il dispositivo Iniziatore è pronto per interrompere la sessione di ricerca di precisione, invia un messaggio di interruzione del rilevamento al dispositivo Risponditore, indicando quali tecnologie di rilevamento devono interrompersi. Il dispositivo Responder risponderà con una notifica di risposta di interruzione del rilevamento della distanza, indicando che ha interrotto correttamente il rilevamento della distanza con le tecnologie di rilevamento della distanza richieste.

Nel caso in cui il canale di comunicazione FHNA BLE GATT si disconnetta a metà della sessione di ricerca di precisione, ma mentre alcune delle tecnologie di misurazione della distanza sono ancora attive, il dispositivo di risposta implementerà un meccanismo di timeout per garantire che la misurazione della distanza non avvenga all'infinito. I dettagli dipenderanno da ogni caso d'uso.

Tieni presente che il dispositivo di risposta non deve presupporre che l'ordine delle operazioni sarà sempre lo stesso. Ad esempio, il dispositivo di risposta deve essere in grado di gestire più operazioni di richiesta della funzionalità di misurazione di distanza di seguito o anche un'operazione di configurazione della misurazione di distanza diretta senza la richiesta di funzionalità precedente.

Operazioni di Posizione precisa

La tabella 8 mostra le operazioni FHNA definite in questo documento necessarie per la ricerca di precisione. Ogni sottosezione definisce il messaggio FHNA per ciascuna delle operazioni, mentre i contenuti del campo Dati aggiuntivi fanno riferimento alla specifica Ranging: sequenza di messaggi fuori banda e payload.

Operazione	ID dati	Descrizione
Richiesta di funzionalità di misurazione della distanza	0x0A	L'operazione di richiesta di funzionalità che verrà inviata dal dispositivo Initiator al dispositivo Responder. I contenuti dei dati di questa operazione elencheranno tutte le tecnologie di misurazione della distanza di cui l'iniziatore vuole conoscere dal dispositivo di risposta.
Ranging Capability Response	0x0A	Questa è la risposta di notifica all'operazione di richiesta della funzionalità di misurazione. Contiene informazioni sulle funzionalità per ogni tecnologia di misurazione della distanza supportata richieste dall'iniziatore.
Configurazione del ranging	0x0B	L'operazione di configurazione del ranging contiene le configurazioni per le tecnologie di ranging con cui il dispositivo iniziatore vuole iniziare il ranging con il dispositivo risponditore.
Risposta di configurazione del ranging	0x0B	Questa è la risposta di notifica all'operazione di configurazione della misurazione della distanza. Contiene dati che indicano se il dispositivo Responder ha avviato correttamente la misurazione con le tecnologie di misurazione richieste in base alla configurazione fornita.
RFU	0x0C	L'operazione con questo ID dati non viene utilizzata ed è riservata per utilizzi futuri.
Stop Ranging	0x0D	L'operazione Stop Ranging inviata dal dispositivo Initiator contiene informazioni sulle tecnologie di ranging con cui il dispositivo Responder deve interrompere il ranging.
Stop Ranging Response	0x0D	Questa è la risposta di notifica all'operazione Stop Ranging. Contiene dati che indicano se l'operazione di arresto per una tecnologia di misurazione specifica è andata a buon fine o meno.

Tabella 8: operazioni di ricerca di precisione.

Operazione di richiesta di funzionalità di misurazione della distanza

La tabella 9 definisce il messaggio di richiesta della funzionalità di misurazione della distanza.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x0A - Operazione di richiesta della funzionalità di misurazione della distanza
1	uint8	Lunghezza dati	varia
2	array di byte	Chiave di autenticazione una tantum	I primi 8 byte di HMAC-SHA256(chiave account, numero di versione principale del protocollo || l'ultimo nonce letto dalla caratteristica || ID dati || Lunghezza dati || Dati aggiuntivi).
10	array di byte	Dati aggiuntivi	Messaggio Ranging Capability Request come definito nella specifica Ranging: Out-of-band message sequence and payload (intestazione e payload)

Tabella 9: richiesta di funzionalità di misurazione della distanza.

Operazione di risposta della funzionalità di misurazione della distanza

La tabella 10 definisce il messaggio di risposta della funzionalità di misurazione della distanza.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x0A: Ranging Capability Response
1	uint8	Lunghezza dati	varia
2	array di byte	Chiave di autenticazione una tantum	I primi 8 byte di HMAC-SHA256(chiave account, numero di versione principale del protocollo || l'ultimo nonce letto dalla caratteristica || ID dati || Lunghezza dati || Dati aggiuntivi || 0x01).
10	array di byte	Dati aggiuntivi	Messaggio Ranging Capability Response come definito nella specifica Ranging: Out-of-band message sequence and payload (intestazione e payload)

Tabella 10: risposta alla funzionalità di misurazione della distanza.

Operazione di configurazione del ranging

La Tabella 11 definisce il messaggio di configurazione del rilevamento della distanza.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x0B - Set Ranging Configuration
1	uint8	Lunghezza dati	varia
2	array di byte	Chiave di autenticazione una tantum	I primi 8 byte di HMAC-SHA256(chiave account, numero di versione principale del protocollo || l'ultimo nonce letto dalla caratteristica || ID dati || Lunghezza dati || Dati aggiuntivi).
10	array di byte	Dati aggiuntivi	Messaggio Ranging Configuration come definito nella specifica Ranging: Out-of-band message sequence and payload (intestazione e payload)

Tabella 11: configurazione della misurazione della distanza.

Operazione di risposta alla configurazione della distanza

La Tabella 12 definisce il messaggio di risposta alla configurazione del rilevamento della distanza.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x0B - Set Ranging Configuration Response
1	uint8	Lunghezza dati	varia
2	array di byte	Chiave di autenticazione una tantum	I primi 8 byte di HMAC-SHA256(chiave account, numero di versione principale del protocollo || l'ultimo nonce letto dalla caratteristica || ID dati || Lunghezza dati || Dati aggiuntivi || 0x01).
10	array di byte	Dati aggiuntivi	Messaggio Ranging Configuration Response come definito nella specifica Ranging: Out-of-band message sequence and payload (intestazione e payload)

Tabella 12: risposta di configurazione della misurazione della distanza.

Interrompi operazione di misurazione

La tabella 13 definisce il messaggio Stop Ranging.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x0D - Ranging Stop
1	uint8	Lunghezza dati	varia
2	array di byte	Chiave di autenticazione una tantum	I primi 8 byte di HMAC-SHA256(chiave account, numero di versione principale del protocollo || ultimo nonce letto dalla caratteristica || ID dati || lunghezza dati).
10	array di byte	Dati aggiuntivi	Messaggio Stop Ranging come definito nella specifica Ranging: Out-of-band message sequence and payload (intestazione e payload)

Tabella 13: Stop Ranging.

Interrompi operazione di risposta di misurazione della distanza

La tabella 14 definisce il messaggio di risposta Stop Ranging.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x0D - Ranging Stop Response
1	uint8	Lunghezza dati	varia
2	array di byte	Chiave di autenticazione una tantum	I primi 8 byte di HMAC-SHA256(chiave account, numero di versione principale del protocollo || l'ultimo nonce letto dalla caratteristica || ID dati || Lunghezza dati || Dati aggiuntivi || 0x01).
10	array di byte	Dati aggiuntivi	Messaggio Stop Ranging Response come definito nella specifica Ranging: Out-of-band message sequence and payload (intestazione e payload)

Tabella 14: Stop Ranging Response.

Protezione dal monitoraggio indesiderato con la ricerca di precisione

Quando viene attivata la modalità di protezione dal tracciamento indesiderato, come descritto nella sezione Protezione dal tracciamento indesiderato, lo stesso flusso che si applica all'omissione dei controlli di autenticazione per i messaggi di chiamata si applica anche a tutti i messaggi di ricerca di precisione definiti in questo documento per i dispositivi che vogliono supportare questa funzionalità.

Specifiche della tecnologia di misurazione per la Posizione precisa

Questa sezione contiene dettagli specifici della tecnologia di misurazione della distanza.

Specifiche della banda ultralarga (UWB)

Dettagli specifici per l'UWB.

Livello di ricerca di precisione

Le sessioni di ricerca di precisione che utilizzano la tecnologia UWB per la misurazione della distanza possono aspettarsi di visualizzare informazioni sia sulla distanza che sulla direzione. L'intervallo di misurazione deve essere di almeno 240 ms, con 96 ms preferiti per una guida ottimale.

ID configurazioni

I dati di configurazione fuori banda scambiati per UWB non contengono un set completo di parametri configurabili disponibili richiesti da UWB per avviare una sessione di misurazione della distanza UWB. Alcuni parametri vengono selezionati implicitamente dall'ID configurazione scelto.

Ogni ID configurazione è un insieme di parametri di configurazione UWB predefiniti che sono documentati pubblicamente. Per lo scenario d'uso della ricerca di precisione, il dispositivo di risposta deve supportare l'ID configurazione 6 e, facoltativamente, l'ID configurazione 3.

Iniziatore e risponditore UWB

Per il caso d'uso della funzionalità Posizione precisa, il dispositivo indicato come dispositivo iniziatore in questo documento sarà il risponditore UWB, mentre il dispositivo indicato come dispositivo risponditore in questo documento sarà l'iniziatore UWB. Questo perché il dispositivo iniziatore UWB consuma meno energia rispetto al dispositivo di risposta UWB e, nella maggior parte dei casi, il dispositivo di risposta sarà una periferica con batteria limitata.

Ciò significa che il dispositivo Responder deve indicare che supporta il ruolo di iniziatore UWB nel messaggio di risposta alla funzionalità di ranging.

Altri parametri correlati all'UWB

• Il canale 9 deve essere supportato
• Per una guida ottimale, è consigliabile un intervallo di misurazione di 96 ms, altrimenti deve essere supportato un intervallo di 240 ms.
• Per risparmiare batteria, è consigliabile una durata dello slot di 1 ms, ma è supportata anche una durata di 2 ms.
• Il chip UWB deve essere conforme almeno a FIRA v1.2 + P-STS.
• BPRF è obbligatorio, HPRF è consigliato ma facoltativo. La modalità supportata o selezionata è determinata dall'indice del preambolo supportato o selezionato.
• Tipo di sicurezza della sessione: P-STS

Specifiche di BLE Channel Sounding (CS)

Dettagli specifici di BLE CS.

Livello di ricerca di precisione

Le sessioni di ricerca di precisione che utilizzano CS come tecnologia di misurazione causeranno misurazioni solo della distanza, la direzionalità non è fornita al momento.

Legame richiesto tra i dispositivi

Le sessioni di ricerca di precisione che utilizzano il rilevamento del canale non funzionano se i dispositivi non sono accoppiati. È necessario un accoppiamento esistente tra il dispositivo iniziatore e quello risponditore. Questa specifica non fornisce un modo per creare un legame tra i dispositivi. Spetta invece allo sviluppatore del caso d'uso stabilire questo legame tra i dispositivi.

Azione richiesta da parte del rispondente per l'assistenza clienti

A differenza di UWB, in cui entrambi i dispositivi devono chiamare esplicitamente l'API di avvio e interruzione del rilevamento della distanza UWB, per CS è necessario solo il dispositivo iniziatore per avviare il rilevamento della distanza CS chiamando lo stack Bluetooth. Il resto dell'inizializzazione sul lato del dispositivo di risposta avviene in banda utilizzando Bluetooth (BT). Ciò significa che, dopo aver ricevuto il messaggio di configurazione del rilevamento della distanza o il messaggio di interruzione del rilevamento della distanza per CS, il lato del risponditore non deve fare nulla se il Bluetooth è attivo, se non rispondere con la notifica del messaggio di risposta alla configurazione del rilevamento della distanza. Il dispositivo di risposta potrebbe potenzialmente utilizzare questi messaggi come trigger per aggiornare l'interfaccia utente in cui è presente uno schermo oppure, indipendentemente dalla presenza di uno schermo, potrebbe essere utilizzato per il feedback visivo sullo stato dei dispositivi, ad esempio per far lampeggiare i LED del dispositivo.

Wi-Fi NAN RTT

Dettagli specifici sull'RTT NAN Wi-Fi.

Livello di ricerca di precisione

Le sessioni di Posizione precisa che utilizzano Wi-Fi NAN RTT come tecnologia di misurazione causeranno misurazioni solo della distanza, la direzionalità non è fornita al momento.

RSSI BLE

Dettagli specifici RSSI BLE.

Livello di ricerca di precisione

Le sessioni di Ricerca di precisione che utilizzano solo BLE RSSI come tecnologia di misurazione non saranno in grado di ottenere informazioni sulla distanza o sulla direzione, poiché BLE RSSI non è una tecnologia di misurazione accurata. L'utente vedrà invece una guida che indica se il dispositivo è vicino o lontano.

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.

Nota: è consigliabile pubblicizzare i frame FHN anche quando il dispositivo è in modalità a basso consumo energetico, in quanto ciò consente di trovare il dispositivo in caso di smarrimento. Per alcuni dispositivi, potrebbe non essere possibile pubblicizzare quando il dispositivo è spento a causa delle implicazioni per la durata della batteria. In questi casi, è consigliabile riattivare periodicamente il dispositivo e pubblicizzare per un breve periodo di tempo (ad es. riattivare ogni 10 minuti e pubblicizzare per 10 secondi).

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.

Nota: l'utilizzo di chiavi a 256 bit significa che gli smartphone meno recenti che non supportano BLE 5 non possono scansionare e segnalare i dispositivi pubblicitari, riducendo così le dimensioni della rete.

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 15: frame FHN che supporta una curva a 160 bit.

La tabella 16 mostra gli offset e i valori dei byte 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 16: 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 17: costruzione di un numero pseudocasuale.

Nota: si presume che il dispositivo abbia un contatore del tempo a 32 bit in secondi.

Nota: l'esponente del periodo di rotazione è fisso e impostato su 10, corrispondente a 1024 secondi.

Il risultato di questo calcolo è un numero di 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 con hash

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 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

Nota: i seguenti dettagli per la crittografia e la decrittografia con gli ID entità sono inclusi solo per completezza della specifica. Solo il Richiedente implementa questi, non il Fornitore.

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 entità.
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 Rx valori per il 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 localizzatori 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 (ad esempio 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 suo 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 per la pubblicità 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é FHN non viene eseguito il provisioning 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 tasti).
• 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 è provisionato 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 Provider 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 richiedente 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.

Flusso 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 18: evento di informazioni sul dispositivo: versione 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 19: 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 del cronometro	Esempio: 0x13F9EA80
8 - 19 o 31	array di byte	EID attuale	Esempio: 0x1122334455667788990011223344556677889900

Tabella 20: evento di 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 di beacon e cancellare 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 da rispettare per la conformità alla specifica DULT:

• Qualsiasi dispositivo compatibile con FHN deve essere registrato nella console per i dispositivi nelle vicinanze e deve avere la funzionalità "Trova Hub" attivata.
• Il dispositivo deve implementare il servizio e la caratteristica Non-Owner dell'accessorio definiti nella versione di implementazione della specifica DULT, incluse le operazioni Accessory Information e Non-owner controls.
• 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 Informazioni sugli accessori:
  • 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 dispositivo di riproduzione del suono 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 definito 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 tag di localizzazione 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

La procedura e la distribuzione degli aggiornamenti OTA devono essere gestite dal partner utilizzando il proprio flusso di lavoro dell'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. Seeker 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 né è stata completata correttamente un'operazione autenticata sulla stessa connessione, il fornitore deve restituire un errore non autenticato.

Compatibilità

La rete 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 monitoraggio indesiderato.
v1.2	Aprile 2023	È stata aggiornata la definizione della chiave dell'account 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.