Specifica degli accessori di rete di Trova il mio dispositivo

v1.3

La specifica dell'accessorio Trova il mio dispositivo (FMDN) definisce un approccio criptato end-to-end per il monitoraggio dei dispositivi BLE (Bluetooth Low Energy) di beaconing. In questa pagina viene descritto FMDN come estensione della specifica dell'accoppiamento rapido. I fornitori dovrebbero attivare questa estensione se dispongono di dispositivi compatibili con FMDN e sono disposti ad attivare il monitoraggio della posizione per questi dispositivi.

Nota: se ti interessa integrare le specifiche degli accessori di Trova il mio dispositivo, invia un modulo di proposta per i dispositivi. Ulteriori dettagli sui passaggi di integrazione e sulla certificazione saranno disponibili a breve.

Specifica GATT

È necessario aggiungere al servizio di accoppiamento rapido un'altra caratteristica di attributi generici (GATT) con la seguente semantica:

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

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

Autenticazione

Le operazioni richieste da questa estensione vengono eseguite come operazioni di scrittura, protette da un meccanismo di risposta challenge. Prima di eseguire qualsiasi operazione, il Seeker dovrebbe eseguire un'operazione di lettura dalla caratteristica nella tabella 1, che genera un buffer nel seguente formato:

Ottobre	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 dovrebbe generare un nonce diverso e un singolo nonce dovrebbe essere valido solo per una singola operazione. Il nonce deve essere invalidato anche se l'operazione non è riuscita.

Il Seeker calcola quindi una chiave di autenticazione una tantum da utilizzare in una richiesta di scrittura successiva. 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 di account per l'accoppiamento rapido a 16 byte, come definita nella specifica per l'accoppiamento rapido.

• Chiave account proprietario: il fornitore sceglie una delle chiavi dell'account esistenti come chiave dell'account proprietario la prima volta che un utente accede alla caratteristica Beacon Actions. La chiave dell'account proprietario scelta non può essere modificata finché non vengono ripristinati i dati di fabbrica del provider. Il provider non deve rimuovere la chiave dell'account proprietario quando esaurisce gli slot senza costi delle chiavi dell'account.

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

  • I provider che ottengono il supporto FMDN dopo essere già accoppiati (ad esempio tramite un aggiornamento firmware) possono scegliere qualsiasi chiave account esistente. È ragionevole scegliere la prima chiave dell'account utilizzata per leggere lo stato di provisioning dalle caratteristiche delle azioni beacon dopo l'aggiornamento del firmware, supponendo che l'utente che ha eseguito l'aggiornamento sia l'attuale proprietario del provider.

• Chiave di identità temporanea (EIK): una chiave di 32 byte scelta in modo casuale dal Seeker durante l'esecuzione del processo di provisioning FMDN. Questa chiave viene utilizzata per ricavare le chiavi di crittografia utilizzate per la crittografia end-to-end dei report sulle località. Il Seeker non lo rivela mai al backend.

• Chiave di recupero: definita come SHA256(ephemeral identity key || 0x01), troncata ai primi 8 byte. Il token è memorizzato nel backend e il Seeker può utilizzarlo per recuperare l'EIK, a condizione che l'utente esprima il consenso premendo un pulsante sul dispositivo.

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

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

Suite operativa

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

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x00: lettura dei parametri del beacon 0x01: Lettura dello stato del provisioning 0x02: imposta chiave di identità temporanea 0x03: cancella la chiave di identità temporanea
1	uint8	Lunghezza dei 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	0 x 00: n/d 0 x 01: n/d 0 x 02: 32 byte, ovvero la chiave di identità temporanea, AES-ECB-128, criptata con la chiave dell'account. Se il provider ha già un set di chiavi di identità temporanee, 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 di beacon.

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x04: leggere la chiave di identità temporanea con il consenso dell'utente
1	uint8	Lunghezza dei 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.

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x05: Fai squillare 0x06: Lettura dello stato della suoneria
1	uint8	Lunghezza dei 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 indicanti lo stato della suoneria, la durata e il volume della suoneria. 0 x 06: n/d

Tabella 4: Richiesta di squillo.

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x07: Attiva la modalità di protezione antitracciamento indesiderata 0x08: Disattivare la modalità di protezione dal tracciamento indesiderato
1	uint8	Lunghezza dei 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 monitoraggio indesiderata.

Notifiche di trigger di scrittura riuscita, come elencato nella tabella 6.

Le notifiche con ID dati diverso da 0x05: modifica dello stato della suoneria devono essere inviate prima del completamento della transazione di scrittura che attiva la notifica, ovvero prima che venga inviata una PDU di risposta per la richiesta di scrittura.

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x00: lettura dei parametri del beacon 0x01: Lettura dello stato del provisioning 0x02: imposta chiave di identità temporanea 0x03: cancella la chiave di identità temporanea 0x04: leggere la chiave di identità temporanea con il consenso dell'utente 0x05: modifica dello stato della suoneria 0x06: Lettura dello stato della suoneria 0x07: Attiva la modalità di protezione antitracciamento indesiderata 0x08: Disattivare la modalità di protezione dal tracciamento indesiderato
1	uint8	Lunghezza dei dati	varia
2 - 9	array di byte	Autenticazione	Dettagliato per operazione
10 - VAR	array di byte	Dati aggiuntivi	0 x 00: 8 byte indicanti la potenza di trasmissione, il valore dell'orologio, il metodo di crittografia e le funzionalità di squillo, AES-ECB-128, criptati con la chiave dell'account (nessun riempimento) 0x01: 1 byte indicante lo stato di provisioning, seguito dall'ID temporaneo attuale (20 o 32 byte), se applicabile 0 x 04: 32 byte che sono la chiave di identità temporanea, AES-ECB-128, criptati con la chiave dell'account 0x05: 4 byte che indicano il nuovo stato e attivano la modifica 0 x 06: 3 byte indicanti che i componenti squillano attivamente e il numero di decisecondi rimanenti per farlo Gli 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	Errore 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: lettura della chiave di identità temporanea con il consenso dell'utente quando il dispositivo non è in modalità di accoppiamento.

Tabella 7: codici di errore GATT.

Lettura del parametro del beacon

Il Seeker può interrogare il provider per trovare i parametri del beacon eseguendo un'operazione di scrittura sulla caratteristica che consiste in una richiesta dalla tabella 2 con ID dati 0x00. Il provider verifica che la chiave di autenticazione monouso fornita corrisponda a qualsiasi chiave dell'account archiviata sul dispositivo.

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

Se l'operazione riesce, il provider invia una notifica con una risposta dalla tabella 6 con ID dati 0x00. Il fornitore crea il segmento di dati nel seguente modo:

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

I dati devono essere criptati 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).

Lettura dello stato di provisioning del beacon

Il Seeker può interrogare il provider per conoscere lo stato di provisioning del beacon, eseguendo un'operazione di scrittura sulla caratteristica che consiste in una richiesta dalla tabella 2 con ID dati 0x01. Il provider verifica che la chiave di autenticazione una tantum fornita corrisponda a una qualsiasi delle chiavi dell'account archiviate sul dispositivo.

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

Se l'operazione riesce, il provider invia una notifica con una risposta dalla tabella 6 con ID dati 0x01. Il fornitore crea il segmento di dati nel seguente modo:

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	Stato provisioning	Una maschera di bit con i seguenti valori: Bit 1 (0x01): da impostare se è impostata una chiave di identità temporanea per il dispositivo. Bit 2 (0x02): da impostare se la chiave di autenticazione una tantum fornita corrisponde alla chiave dell'account del proprietario.
1-20 o 32	array di byte	Identificatore temporaneo attuale	20 o 32 byte (a seconda del metodo di crittografia utilizzato) che indicano l'ID temporaneo corrente pubblicizzato dal beacon, se impostato 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).

Imposta una chiave di identità temporanea

Per eseguire il provisioning di un provider senza provisioning come beacon FMDN o modificare la chiave di identità temporanea del provider di cui è già stato eseguito il provisioning, il cercatore esegue un'operazione di scrittura sulla caratteristica che consiste in una richiesta dalla tabella 2 con ID dati 0x02. Il Fornitore verifica che:

• La chiave di autenticazione una tantum fornita corrisponde alla chiave dell'account del proprietario.
• Se è stato fornito un hash di una chiave di identità temporanea, la chiave di identità temporanea sottoposta ad hashing corrisponde all'attuale chiave di identità temporanea.
• Se non è stato fornito un hash di una chiave di identità temporanea, verifica che il provider non sia già stato sottoposto a provisioning come beacon FMDN.

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

Se l'operazione riesce, la chiave di identità temporanea viene recuperata mediante AES-ECB-128 decriptandola utilizzando la chiave dell'account corrispondente. La chiave deve essere persistente sul dispositivo e da quel momento il provider dovrebbe iniziare a pubblicizzare frame FMDN. La nuova chiave di identità temporanea ha effetto subito dopo il termine della connessione BLE. Il provider invia una notifica con una risposta dalla tabella 6 con 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à temporanea

Per eseguire l'annullamento del provisioning della parte di beacon del provider, il richiedente esegue un'operazione di scrittura sulla caratteristica, composta da una richiesta dalla tabella 2 con ID dati 0x03. Il Fornitore verifica che:

• La chiave di autenticazione una tantum fornita corrisponde alla chiave dell'account del proprietario.
• La chiave di identità temporanea sottoposta ad hashing corrisponde all'attuale chiave di identità temporanea.

Se il provider non è stato sottoposto a provisioning come beacon FMDN o se la verifica non va a buon fine, viene restituito un errore non autenticato.

Se l'operazione riesce, il provider dimentica la chiave e interrompe la pubblicità dei frame FMDN. Il provider invia una notifica con una risposta dalla tabella 6 con 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à temporanea con il consenso dell'utente

Questa opzione è disponibile solo per recuperare una chiave persa, poiché la chiave viene archiviata solo localmente dal 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 pulsante fisico sul dispositivo (presa del consenso dell'utente).

Il Seeker deve archiviare la chiave di recupero sul backend per poter recuperare la chiave in chiaro, ma non memorizza l'EIK stesso.

Per leggere l'EIK, il Seeker esegue un'operazione di scrittura sulla caratteristica, costituita da 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 ripristino EIK.

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

Se il dispositivo non è in modalità di accoppiamento, il provider restituisce un errore di nessun consenso dell'utente.

Se l'operazione riesce, il provider invia una notifica con una risposta dalla 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).

Squillo

Il Seeker può chiedere al provider di riprodurre un suono eseguendo un'operazione di scrittura sulla caratteristica, costituita da una richiesta dalla tabella 4 con ID dati 0x05. Il fornitore crea il segmento di dati nel seguente modo:

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	Squillo	Una maschera di bit con i seguenti valori: Bit 1 (0x01): anello a destra Bit 2 (0x02): anello a sinistra Bit 3 (0x04): custodia ad anello 0xFF: fai squillare tutti i componenti 0x00: Interrompi lo squillo
1 - 2	uint16	Timeout	Il timeout in decisecondi. Non deve essere zero e non deve essere superiore all'equivalente di 10 minuti. Il provider utilizza questo valore per determinare la durata dello squillo prima di silenziare se stesso. Se qualche componente del dispositivo sta già squillando, il timeout sostituisce quello già attivo. Se squillo è impostato su 0x00, il timeout viene ignorato.
3	uint8	Volume	0 x 00: predefinito 0x01: Basso 0 x 02: Medio 0x03: Alta Il significato esatto di questi valori dipende dall'implementazione.

Alla ricezione della richiesta, il Fornitore verifica quanto segue:

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

Se il provider non è stato sottoposto a provisioning come beacon FMDN o se la verifica non va a buon fine, viene restituito un errore non autenticato. Tuttavia, se per il provider è attiva una protezione antitracciamento indesiderata e se per l'attivazione della richiesta di protezione antitracciamento indesiderata è stato attivato il flag di autenticazione per ignorare il campanello, il provider dovrebbe saltare questo controllo. I dati di autenticazione dovrebbero comunque essere forniti dal Seeker, ma potrebbero essere impostati su un valore arbitrario.

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

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	Stato squillo	0x00: Iniziato 0x01: Avvio o arresto non riuscito (tutti i componenti richiesti sono fuori intervallo) 0x02: Interrotto (timeout) 0x03: Interruzione (pressione del pulsante) 0x04: Interrotta (richiesta GATT)
1	uint8	Componenti dello squillo	Maschera di bit dei componenti che suonano attivamente, come definita nella richiesta.
2 - 3	uint16	Timeout	Il tempo rimanente per lo squillo in decisecondi. Se il dispositivo ha smesso di squillare, deve essere restituito il valore 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 si trova già nello stato di squillo richiesto quando viene ricevuta una richiesta di squillo o per interrompere lo squillo, il provider deve inviare una notifica con uno stato di squillo oppure 0x00: Avviata o 0x04: Arrestata (richiesta GATT). Questa richiesta sostituisce i parametri dello stato esistente, in modo che la durata della suoneria possa essere estesa.

Se il provider dispone di un pulsante fisico (o di rilevamento tattile abilitato), tale pulsante deve interrompere la funzione di squillo se viene premuto mentre la suoneria è attiva.

Nota: per i fornitori che prevedono il rilevamento "on-head", valuta la possibilità di verificare che il dispositivo non sia collegato alla testa prima di far squillare il dispositivo al massimo volume. Se il rilevamento sulla testa non è supportato o non è affidabile, aumenta il volume gradualmente (in modo che l'utente abbia il tempo di smettere di suonare o di rimuovere gli auricolari).

Nota: il provider deve continuare a suonare indipendentemente dallo stato della connessione del Cercatore che ha richiesto lo squillo. In questo modo si evita che il dispositivo smetta di squillare perché la connessione si interrompe perché il client si allontana troppo dal dispositivo. Impossibile trovare il dispositivo perché ha smesso di suonare ed è troppo lontano dal client per richiedere di nuovo lo squillo.

Visualizza lo stato di suoneria del beacon

Per ottenere lo stato di squillo del beacon, il Seeker esegue un'operazione di scrittura sulla caratteristica, composta da una richiesta dalla tabella 4 con ID dati 0x06. Il provider verifica che la chiave di autenticazione una tantum fornita corrisponda alla chiave di chiamata.

Se il provider non è stato sottoposto a provisioning come beacon FMDN o se la verifica non va a buon fine, il provider restituisce un errore non autenticato.

Se l'operazione riesce, il provider invia una notifica con una risposta dalla tabella 6 con ID dati 0x06. Il fornitore crea il segmento di dati nel seguente modo:

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	Componenti dello squillo	I componenti squillano attivamente, come definito nella richiesta di squillo.
1 - 2	uint16	Timeout	Il tempo rimanente per lo squillo in decisecondi. Tieni presente che se il dispositivo non squilla, deve essere restituito il valore 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 tracciamento indesiderato

La modalità di protezione dal tracciamento indesiderato consente a qualsiasi client di identificare i dispositivi illeciti senza comunicazione con il server. Per impostazione predefinita, il provider deve ruotare tutti gli identificatori come descritto in Rotazione ID. Il servizio Trova il mio dispositivo può inoltrare una richiesta di attivazione della modalità di protezione dal tracciamento indesiderata tramite la rete Trova il mio dispositivo. In questo modo, il servizio fa sì che il provider 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 tracciamento indesiderato del beacon, il Seeker esegue un'operazione di scrittura sulla caratteristica, composta da una richiesta dalla tabella 5 con ID dati rispettivamente 0x07 o 0x08.

Quando si attiva la modalità di protezione dal tracciamento indesiderato

Il fornitore crea il segmento di dati nel seguente modo:

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	Flag di controllo	0x01: Salta l'autenticazione tramite squillo. Se questa opzione è impostata, le richieste di squillo non vengono autenticate in modalità di protezione dal tracciamento indesiderato. Se non è stato impostato alcun flag (il byte è tutti zeri), è valido omettere completamente la sezione dei dati e inviare una sezione di dati vuota. I flag hanno effetto solo fino alla disattivazione della modalità di protezione dal tracciamento indesiderato.

Il provider verifica che la chiave di autenticazione una tantum fornita corrisponda alla chiave di protezione antitracciamento indesiderata. Se il provider non è stato sottoposto a provisioning come beacon FMDN o se la verifica non va a buon fine, viene restituito un errore non autenticato.

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

Quando si disattiva la modalità di protezione dal tracciamento indesiderato

Il Fornitore verifica che:

• La chiave di autenticazione una tantum fornita corrisponde alla chiave di protezione dal monitoraggio indesiderata.
• La chiave di identità temporanea sottoposta ad hashing corrisponde all'attuale chiave di identità temporanea.

Se il provider non è stato sottoposto a provisioning come beacon FMDN o se la verifica non va a buon fine, il provider restituisce un errore non autenticato.

Quando la modalità di protezione dal tracciamento indesiderato è disattivata, il beacon dovrebbe iniziare a ruotare di nuovo l'indirizzo MAC a una velocità normale, sincronizzata con la rotazione dell'identificatore temporaneo. Il tipo di frame deve essere impostato nuovamente su 0x40. Lo stato viene riportato anche nella sezione dei flag sottoposti ad hashing.

Se l'operazione riesce, il provider 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).

Fotogrammi pubblicizzati

Dopo il provisioning, il provider dovrà pubblicizzare i frame FMDN almeno una volta ogni 2 secondi. Se vengono pubblicizzati frame per l'accoppiamento rapido, il provider deve interlacciare i frame FMDN all'interno dei normali annunci per l'accoppiamento rapido. Ad esempio, ogni due secondi, il fornitore deve pubblicizzare sette annunci pubblicitari ad accoppiamento rapido e un annuncio FMDN.

Nota: ti consigliamo di pubblicizzare i frame FMDN anche quando il dispositivo è in modalità a basso consumo, in quanto ciò consente di ritrovarlo in caso di smarrimento. Per alcuni dispositivi potrebbe non essere possibile fare pubblicità quando sono spenti a causa delle implicazioni relative alla durata della batteria. In questi casi, ti consigliamo vivamente di riattivare periodicamente il dispositivo e fare pubblicità per un breve periodo di tempo (ad es. svegliarti ogni 10 minuti e fare pubblicità per 10 secondi).

Il frame FMDN contiene una chiave pubblica utilizzata per criptare i report sulle località da parte di qualsiasi client di supporto che contribuisce alla rete di crowdsourcing. Sono disponibili due tipi di chiavi a curva ellittica: una chiave a 160 bit compatibile con i frame BLE 4 legacy o una chiave a 256 bit che richiede BLE 5 con funzionalità pubblicitarie estese. L'implementazione del provider determina quale curva viene utilizzata.

Nota: se utilizzi chiavi a 256 bit, i telefoni meno recenti che non supportano la tecnologia BLE 5 non possono eseguire scansioni e creare report per i dispositivi pubblicitari, riducendo così le dimensioni della rete.

Un frame FMDN è strutturato come segue.

Ottobre	Valore	Descrizione
0	0x02	Lunghezza
1	0x01	Segnala il valore del tipo di dati
2	0x06	Dati sulle segnalazioni
3	0x18 o 0x19	Lunghezza
4	0x16	Valore del tipo di dati dei dati di servizio
5	0xAA	UUID del servizio a 16 bit
6	0xFE	...
7	0x40 o 0x41	Tipo di frame FMDN con indicazione della modalità di protezione antitracciamento indesiderata
8...27		Identificatore temporaneo da 20 byte
28		Flag sottoposti ad hashing

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

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

Ottobre	Valore	Descrizione
0	0x02	Lunghezza
1	0x01	Segnala il valore del tipo di dati
2	0x06	Dati sulle segnalazioni
3	0x24 o 0x25	Lunghezza
4	0x16	Valore del tipo di dati dei dati di servizio
5	0xAA	UUID del servizio a 16 bit
6	0xFE	...
7	0x40 o 0x41	Tipo di frame FMDN con indicazione della modalità di protezione antitracciamento indesiderata
8...39		Identificatore temporaneo da 32 byte
40		Flag sottoposti ad hashing

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

Calcolo dell'identificatore temporaneo (EID)

Un casuale viene generato dall'algoritmo AES-ECB-256 criptando la seguente struttura di dati con la chiave di identità temporanea:

Ottobre	Tecnico	Descrizione
0 - 10	Spaziatura interna	Valore = 0xFF
11	K	Esponente periodo di rotazione
12 - 15	TS[0]...TS[3]	Contatore del tempo di beaconing in formato big-endian a 32 bit. I bit K più bassi vengono cancellati.
16 - 26	Spaziatura interna	Valore = 0x00
27	K	Esponente periodo di rotazione
28 - 31	TS[0]...TS[3]	Contatore del tempo di beaconing in formato big-endian a 32 bit. I bit K più bassi vengono cancellati.

Tabella 10: 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 a 256 bit, indicato con r'.

Per il resto del calcolo, per le operazioni crittografiche basate su curva ellittica vengono utilizzati SECP160R1 o SECP256R1. Vedi le definizioni delle curve in SEC 2: parametri di dominio della curva ellittica consigliata, che definisce Fp, n e G a cui si fa riferimento successivamente.

La proiezione di r' nel campo limitato Fp è ora prevista per il calcolo di r = r' mod n. Infine, calcola R = r * G, che è un punto sulla curva che rappresenta la chiave pubblica in uso. Il beacon pubblicizza Rx, che è la coordinata x di R, come identificatore temporaneo.

Flag sottoposti ad hashing

Il campo dei flag sottoposti ad hashing viene calcolato come segue (viene fatto riferimento ai bit dai più significativi a quelli meno significativi):

• Bit 0-4: riservati (impostati su zero).
• I bit da 5 a 6 indicano il livello della batteria del dispositivo nel seguente modo:
  • 00: indicazione del livello della batteria non supportata
  • 01: Livello batteria normale
  • 10: Livello della batteria basso
  • 11: Livello della batteria molto basso (è necessario sostituire la batteria a breve)
• Il bit 7 è impostato su 1 se il beacon è in modalità di protezione dal tracciamento indesiderato e su 0 negli altri casi.

Per produrre il valore finale di questo byte, viene usato xor-ed con il byte meno significativo di SHA256(r).

Tieni presente che r deve essere allineato alla dimensione della curva. Aggiungi gli zeri come bit più significativi se la sua rappresentazione è più breve di 160 o 256 bit oppure i bit più significativi dovrebbero essere troncati se la rappresentazione è superiore a 160 o 256 bit.

Se il beacon non supporta le indicazioni del livello della batteria e non si trova in una 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 EID sono inclusi solo per la completezza della specifica. Solo il Cercante le implementa, non il Fornitore.

Per criptare un messaggio m, un visualizzatore (dopo aver letto Rx dal beacon) deve procedere come segue:

1. Scegli un numero casuale s in Fp, come definito nella sezione Calcolo EID.
2. Calcola S = s * G.
3. Calcola R = (Rx, Ry) effettuando una sostituzione nell'equazione della curva e scegliendo un valore Ry arbitrario dai possibili risultati.
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 delle curve. Il sale non è specificato.
5. Consenti a URx e LRx di essere rispettivamente gli 80 bit superiore e inferiore di Rx nel formato big-endian. In modo simile, definisci USx e LSx per S.
6. Calcola nonce = LRx || LSx.
7. Calcola (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, che è in possesso dell'EIK e dell'esponente del periodo di rotazione, decripta il messaggio come segue:

1. Dati URx, ottieni il valore del contatore del tempo di beacon su cui si basa URx. Ciò può essere fatto dal cliente del proprietario che elabora i valori Rx per i valori del contatore del tempo di beacon per il passato recente e quello prossimo.
2. Dato il valore del contatore del tempo di beacon su cui si basa URx, calcola il valore previsto di r come definito nella sezione relativa al calcolo EID.
3. Calcola R = r * G e verifica una corrispondenza con il valore di URx fornito dal turista.
4. Calcola S = (Sx, Sy) effettuando una sostituzione nell'equazione della curva e scegliendo un valore Sy arbitrario dai possibili risultati.
5. Calcola k = HKDF-SHA256((r * S)x), dove (r * S)x è la coordinata x del risultato della moltiplicazione della curva.
6. Calcola nonce = LRx || LSx.
7. Calcola m = AES-EAX-256-DEC(k, nonce, m’, tag).

Rotazione ID

Per pubblicizzare frame FMDN è necessario utilizzare un indirizzo BLE risolvibile (RPA) o non risolvibile (NRPA). Il protocollo RPA è obbligatorio per i dispositivi LE Audio (LEA) ed è consigliato per altri dispositivi, ad eccezione dei tag di localizzazione che non utilizzano il collegamento.

L'annuncio ad accoppiamento rapido, l'annuncio FMDN e gli indirizzi BLE corrispondenti devono ruotare contemporaneamente. La rotazione dovrebbe avvenire in media ogni 1024 secondi. Il punto esatto in cui il beacon inizia a pubblicizzare il nuovo identificatore deve essere casuale all'interno della finestra.

L'approccio consigliato per randomizzare il tempo di rotazione è di impostarlo sul tempo di rotazione previsto successivo (se non è stata applicata la randomizzazione) più un fattore di tempo randomizzato positivo compreso tra 1 e 204 secondi.

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

Ripristino dopo la perdita di alimentazione

La risoluzione dell'identificatore temporaneo è strettamente legata al valore dell'orologio al momento della pubblicità, pertanto è importante che il provider possa recuperare il valore dell'orologio in caso di interruzione dell'alimentazione. È consigliabile che il provider scriva il valore di clock attuale nella memoria non volatile almeno una volta al giorno e che, al momento dell'avvio, il provider controlli l'NVM per verificare se esiste un valore da cui inizializzare. I resolver dell'identificatore temporaneo implementerebbero la risoluzione in una finestra temporale sufficiente a consentire sia una deriva di orologio ragionevole che questo tipo di recupero dalla perdita di potenza.

I provider devono comunque fare il possibile per ridurre al minimo le deviazioni dell'orologio, poiché la finestra temporale di risoluzione è limitata. È necessario implementare almeno un metodo di sincronizzazione dell'orologio aggiuntivo (pubblicità frame ad accoppiamento rapido non rilevabili o implementazione dello stream 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 FMDN.

Linee guida specifiche per i tag di localizzazione

• Se il provider è stato accoppiato, ma non è stato eseguito il provisioning di FMDN entro 5 minuti (o se è stato applicato un aggiornamento OTA mentre il dispositivo è associato, ma non è stato eseguito il provisioning FMDN), il provider dovrebbe ripristinare la configurazione di fabbrica e cancellare le chiavi account memorizzate.
• Una volta accoppiato il provider, non dovrebbe cambiare l'indirizzo MAC fino a quando non viene eseguito il provisioning di FMDN o prima che siano trascorsi 5 minuti.
• Se la chiave di identità temporanea viene cancellata dal dispositivo, questo dovrebbe eseguire un ripristino dei dati di fabbrica e cancellare anche le chiavi degli account memorizzate.
• Il provider dovrebbe 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 la pressione di una combinazione di pulsanti).
• Dopo una perdita di alimentazione, il dispositivo dovrebbe pubblicizzare frame ad accoppiamento rapido non rilevabili fino alla chiamata successiva dei parametri di beaconing di lettura. In questo modo, Seeker può rilevare il dispositivo e sincronizzare l'orologio anche in caso di una significativa deviazione dell'orologio.
• Quando pubblicizzi frame ad accoppiamento rapido non rilevabili, le indicazioni dell'interfaccia utente non devono essere attivate.
• I frame ad accoppiamento rapido rilevabili non devono essere pubblicizzati mentre viene eseguito il provisioning del provider per FMDN.
• Il provider non deve mostrare informazioni identificative in modo non autenticato (ad es. nomi o identificatori).

Linee guida specifiche per il Bluetooth classico

In questa sezione vengono descritti aspetti speciali dei dispositivi Bluetooth classici che supportano FMDN.

Provisioning FMDN dei dispositivi già accoppiati

Il provider non esegue sempre il provisioning per FMDN durante l'accoppiamento con il richiedente, ma qualche tempo dopo. In questo caso, il provider potrebbe non avere un indirizzo MAC BLE aggiornato necessario per stabilire una connessione GATT. Il provider deve supportare almeno uno dei seguenti modi per consentire al richiedente di ottenere l'indirizzo BLE mentre è già accoppiato:

• Il Fornitore può periodicamente pubblicizzare i dati dell'account ad accoppiamento rapido che consentono a Seeker di trovare il proprio indirizzo BLE tramite una scansione BLE.
  Questo approccio è adatto ai provider che non implementano il flusso di messaggi.
• Il provider può fornire questi dati tramite lo stream di messaggi dell'accoppiamento rapido tramite Bluetooth classico.
  Questo approccio è adatto ai fornitori che non pubblicizzano frame ad accoppiamento rapido mentre sono connessi a Seeker tramite Bluetooth.

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

Stream di messaggi ad accoppiamento rapido

Il Fornitore può implementare lo stream di messaggi ad accoppiamento rapido e utilizzarlo per notificare al richiedente le informazioni del dispositivo. L'implementazione del flusso di messaggi abilita determinate funzionalità, come descritto in questa sezione.

Il fornitore dovrebbe inviare messaggi informativi sul dispositivo una volta ogni volta che viene stabilito il canale RFCOMM dello stream di messaggi.

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

Quando un aggiornamento firmware aggiunge il supporto FMDN al provider, un richiedente connesso può informarne l'utente e proporne il provisioning. In caso contrario, l'utente deve accedere manualmente all'elenco dei dispositivi Bluetooth per avviare il provisioning FMDN.

Per consentire questa operazione, il provider deve utilizzare la proprietà Versione firmware (codice 0x09) per segnalare un valore stringa che rappresenta la versione del firmware. Inoltre, il provider deve supportare il protocollo che informa il richiedente delle modifiche alle funzionalità dovute agli aggiornamenti del firmware.

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	Evento informazioni del dispositivo	0x03
1	uint8	Versione firmware	0x09
2 - 3	uint16	Lunghezza dei dati aggiuntivi	varia
var	array di byte	Stringa della versione	varia

Tabella 11: Evento Informazioni del dispositivo: versione del firmware aggiornata.

Dopo aver ricevuto una richiesta di aggiornamento delle funzionalità (0x0601), se il provider ha abilitato il supporto per il monitoraggio FMDN, dovrebbe rispondere come mostrato nella tabella 12.

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

Tabella 12: Evento di sincronizzazione funzionalità dispositivo: aggiunta capacità di monitoraggio.

Identificatore temporaneo attuale (codice informazioni del dispositivo 0x0B)

Il Provider può utilizzare l'identificatore temporaneo corrente (codice 0x0B) per segnalare l'EID e il valore dell'orologio attuali quando viene eseguito il provisioning del Provider per l'FMDN, per sincronizzare il Seeker in caso di deviazione dell'orologio (ad esempio, a causa della batteria scarica). In caso contrario, il Seeker avvia una connessione più costosa e meno affidabile a questo scopo.

Ottobre	Tipo di dati	Descrizione	Valore
0	uint8	Evento informazioni del dispositivo	0x03
1	uint8	Identificatore temporaneo attuale	0 x 0 MLD
2 - 3	uint16	Lunghezza dei dati aggiuntivi	0x0018 o 0x0024
4 - 7	array di byte	Valore quadrante	Esempio: 0x13F9EA80
8 - 19 o 31	array di byte	EID attuale	Esempio: 0x1122334455667788990011223344556677889900

Tabella 13: Evento informazioni dispositivo: sincronizzazione orologio.

Ripristino 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 il beaconing e cancellare la chiave di identità temporanea 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 dovrebbe iniziare subito a pubblicizzare l'accoppiamento rapido per evitare che il flusso di accoppiamento inizi immediatamente dopo l'eliminazione del dispositivo da parte dell'utente.

Prevenzione del monitoraggio indesiderato

I dispositivi FMDN certificati devono inoltre soddisfare i requisiti nella versione di implementazione della specifica multipiattaforma per il rilevamento dei tracker di località indesiderate (DULT).

Linee guida pertinenti specifiche di FMDN per la conformità con le specifiche DULT:

• Tutti i dispositivi compatibili con FMDN devono essere registrati nella console dispositivo nelle vicinanze e avere attivato la funzionalità "Trova il mio dispositivo".
• Il dispositivo deve implementare il servizio Accessorio non proprietario e la caratteristica definiti nella versione di implementazione delle specifiche DULT, incluse le operazioni Informazioni sugli accessori e i Controlli per i non proprietari.
• Durante il periodo di compatibilità con le versioni precedenti, come definito nelle specifiche DULT, non sono state apportate modifiche al frame pubblicizzato come definito in questo documento.
• La "modalità di protezione dal tracciamento indesiderato" definita in questo documento corrisponde allo "stato separato" definito dalla specifica DULT.
• Linee guida per l'implementazione degli opcode delle informazioni sugli accessori:
  • Get_Product_Data deve restituire l'ID modello fornito dalla console, zero padding per soddisfare il requisito degli 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 "Location Tracker" se nessun'altra categoria è più adatta al tipo di dispositivo.
  • Get_Accessory_Capabilities deve indicare il supporto dello squillo e la ricerca degli identificatori BLE.
  • Get_Network_ID deve restituire l'identificatore di Google (0x02).
• Linee guida per l'implementazione del codice operativo Get_Identifier:
  • L'operazione dovrebbe restituire una risposta valida solo per 5 minuti dopo che l'utente ha attivato la modalità di "identificazione", che richiede una combinazione di pressioni dei pulsanti. Un segnale visivo o audio dovrebbe indicare all'utente che il fornitore è passato a quella modalità. Le istruzioni specifiche per modello per l'attivazione di tale 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 viene creata come segue: i primi 10 byte dell'identificatore temporaneo attuale, seguiti dai primi 8 byte di HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
• Linee guida per l'implementazione dell'opcode Sound_Start:
  • Il comando dovrebbe attivare lo squillo in tutti i componenti disponibili.
  • Deve essere utilizzato il volume massimo supportato.
  • La durata consigliata dello squillo è 12 secondi.
• I tag localizzatori devono includere un meccanismo che consenta agli utenti di interrompere temporaneamente la pubblicità senza ripristinare i dati di fabbrica del dispositivo (ad esempio la pressione di una combinazione di pulsanti).
  • Le istruzioni per la 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 relative ai protocolli commutabili

• È possibile usare un solo protocollo alla volta. Assicurati che sul dispositivo non possa essere eseguita più di una rete contemporaneamente. Questo requisito è necessario per garantire che non esista una combinazione di dati utente sensibili tra protocolli diversi.
• È consigliabile incorporare nel dispositivo un flusso di lavoro per il ripristino dei dati di fabbrica, che consenta all'utente di riconfigurare il dispositivo con una rete diversa.
• Il processo di aggiornamento di un dispositivo a una rete deve essere facile da usare ed equo tra le reti. Un utente deve poter scegliere quale rete utilizzare senza dare la preferenza a una delle reti. Questo flusso deve essere approvato dal team di Google.

Aggiornamenti del 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.

Compatibilità

La rete di Trova il mio dispositivo richiede servizi di geolocalizzazione e Bluetooth per l'attivazione. Richiede un servizio cellulare o una connessione a internet. Funziona su Android 9 e versioni successive e in alcuni paesi per gli utenti di età idonea.

Log delle modifiche

Versione FMDN	Data	Commento
v1		Release iniziale della specifica FMDN per l'accesso in anteprima.
v1.1	Feb 2023	Aggiunta un'indicazione in chiaro della modalità Protezione antitracciamento indesiderata. È stata aggiunta un'opzione per saltare l'autenticazione delle richieste di squillo in modalità di protezione dal tracciamento indesiderato.
v1.2	Aprile 2023	È stata aggiornata la definizione dell'AK di un proprietario. È stato aggiunto un suggerimento per il recupero dalla perdita di potenza nei tag di localizzazione. È stato aggiunto un chiarimento per la randomizzazione degli indirizzi MAC. È stato aggiunto un chiarimento sulla rotazione degli indirizzi MAC in modalità di protezione dal monitoraggio indesiderato. È stata aggiunta una linea guida su come disattivare un tag locator.
v1.3	Dicembre 2023	È stato aggiunto un chiarimento sull'identificazione delle informazioni esposte dai tag locator. È stato aggiunto un requisito per implementare la specifica per la prevenzione del monitoraggio indesiderato. Sono state aggiunte linee guida per i dispositivi con protocollo commutabile.