Specifica degli accessori di rete di Trova il mio dispositivo

v1.3

La specifica dell'accessorio della rete di Trova il mio dispositivo (FMDN) definisce un approccio criptato end-to-end per il monitoraggio dei dispositivi Bluetooth Low Energy (BLE) con beacon. Questa pagina descrive FMDN come estensione della specifica di accoppiamento rapido. I fornitori devono 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 del dispositivo. A breve saranno disponibili ulteriori dettagli sulla procedura di integrazione e sulla certificazione.

Specifica GATT

Al servizio di accoppiamento rapido deve essere aggiunta un'ulteriore caratteristica di attributi generici (GATT) con la seguente semantica:

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

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

Autenticazione

Le operazioni richieste da questa estensione vengono eseguite come operazioni di scrittura, messe al sicuro da un meccanismo di sfida-risposta. Prima di eseguire qualsiasi operazione, il cercatore deve eseguire un'operazione di lettura dalla caratteristica indicata 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 un'unica operazione. Il nonce deve essere invalidato anche se l'operazione non è riuscita.

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

• Chiave account: la chiave account di accoppiamento rapido di 16 byte, come definito 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 cercatore accede alla caratteristica Azioni beacon. La chiave dell'account proprietario scelta non può essere modificata fino al ripristino dei dati di fabbrica del fornitore. Il fornitore non deve rimuovere la chiave dell'account proprietario quando non ha più slot per le chiavi dell'account disponibili.

  • I fornitori che supportano già l'FMDN quando l'accoppiamento viene eseguito per la prima volta (o lo supportano quando viene accoppiato dopo il ripristino dei dati di fabbrica) scelgono la prima chiave dell'account, poiché è l'unica esistente quando il cercatore legge lo stato del provisioning durante l'accoppiamento.

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

• Chiave di identità effimera (EIK): una chiave di 32 byte scelta in modo casuale dal cercatore durante l'esecuzione della procedura di provisioning dell'FMDN. Questa chiave viene utilizzata per ricavare le chiavi crittografiche utilizzate per i report sulla posizione con crittografia end-to-end. Il browser 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 la persona che cerca il dispositivo può utilizzarla per recuperare l'EIK, a condizione che l'utente esprima il consenso premendo un pulsante sul dispositivo.

• Chiave di anellamento: definita come SHA256(ephemeral identity key || 0x02), troncata ai primi 8 byte. La chiave viene archiviata nel backend e chi cerca 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 archiviata nel backend e l'utente può utilizzarla solo per attivare la modalità di protezione dal monitoraggio indesiderato.

Operazioni

Il formato dei dati scritti nella caratteristica è riportato nelle tabelle 2 e 5. Ognuna delle operazioni viene descritta più dettagliatamente più avanti in questa sezione.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x00: leggi i parametri del beacon 0x01: leggi lo stato del provisioning 0x02: imposta la chiave di identità effimera 0x03: chiave di identità effimera chiara
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 rappresentano la chiave di identità temporanea, con crittografia AES-ECB-128 con la chiave dell'account. Se il fornitore ha già impostato una chiave di identità temporanea, invia anche i primi 8 byte diSHA256(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 del beacon.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x04: leggi la chiave di identità effimera con il consenso dell'utente
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: Anello 0x06: leggi lo stato della suoneria
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 squillamento, la durata e il volume di squillamento. 0x06: n/d

Tabella 4: richiesta di squillamento.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x07: attiva la modalità di protezione dal monitoraggio 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 monitoraggio indesiderato.

Le scritture riuscite attivano le notifiche elencate nella tabella 6.

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

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x00: leggi i parametri del beacon 0x01: leggi lo stato del provisioning 0x02: imposta la chiave di identità effimera 0x03: chiave di identità effimera chiara 0x04: leggi la chiave di identità effimera con il consenso dell'utente 0x05: modifica dello stato dell'anello 0x06: leggi lo stato della suoneria 0x07: attiva la modalità di protezione dal monitoraggio indesiderato 0x08: disattiva la modalità di protezione dal monitoraggio indesiderato
1	uint8	Lunghezza dati	varia
2 - 9	array di byte	Autenticazione	Dettagli 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 squillamento, con crittografia AES-ECB-128 con la chiave dell'account (con spaziatura zero) 0x01: 1 byte che indica lo stato del provisioning, seguito dall'ID temporaneo corrente (20 o 32 byte), se applicabile 0x04: 32 byte che rappresentano la chiave di identità temporanea, criptata con AES-ECB-128 con la chiave dell'account 0x05: 4 byte che indicano il nuovo stato e l'attivatore della modifica 0x06: 3 byte che indicano i componenti che squillano attivamente e il numero di decisecondi 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	Viene restituito in risposta a una richiesta di scrittura quando l'autenticazione non va a buon fine (incluso il caso in cui sia stato utilizzato un nonce precedente).
0x81	Valore non valido	Viene restituito quando viene fornito un valore non valido o se i dati ricevuti hanno un numero di byte imprevisto.
0x82	Nessun consenso dell'utente	Viene restituito in risposta a una richiesta di scrittura con ID dati 0x04: Leggi chiave di identità temporanea con il consenso dell'utente quando il dispositivo non è in modalità di accoppiamento.

Tabella 7: codici di errore GATT.

Leggi il parametro del beacon

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

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

In caso di esito positivo, il fornitore invia una notifica con una risposta della tabella 6 con ID dato 0x00. Il fornitore crea il segmento di dati come segue:

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 dell'orologio	Il valore corrente dell'orologio in secondi (big endian).
5	uint8	Selezione curva	La curva ellittica utilizzata per la crittografia: 0x00 (valore predefinito): SECP160R1 0x01: SECP256R1 (richiede la 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 i due componenti, gli auricolari sinistro e destro, sono in grado di suonare in modo indipendente. 0x03: indica che tre componenti, gli auricolari sinistro e destro e la cover, sono in grado di suonare in modo indipendente.
7	uint8	Funzionalità di squillo	Le opzioni supportate sono: 0x00: la selezione del volume della suoneria non è disponibile. 0x01: è disponibile la selezione del volume della suoneria. Se impostato, il fornitore deve accettare e gestire tre livelli di volume come indicato in Funzionamento della suoneria.
8-15	array di byte	Spaziatura interna	Zero padding 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 del provisioning del beacon

Il cercatore può eseguire una query sul provider per conoscere lo stato del provisioning del beacon tramite un'operazione di scrittura nella 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 mancata autenticazione.

In caso di esito positivo, il fornitore invia una notifica con una risposta della tabella 6 con ID dato 0x01. Il fornitore crea il segmento di dati come segue:

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Stato del provisioning	Una maschera di bit con i seguenti valori: Bit 1 (0x01): impostato se è impostata una chiave di identità temporanea per il dispositivo. Bit 2 (0x02): impostato se la chiave di autenticazione una tantum fornita corrisponde alla chiave dell'account proprietario.
1-20 o 32	array di byte	Identificatore temporaneo corrente	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).

Impostare una chiave di identità effimera

Per eseguire il provisioning di un provider non eseguito come beacon FMDN o modificare la chiave di identità temporanea del provider già eseguito, il cercatore esegue un'operazione di scrittura nella 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à temporanea, la chiave di identità temporanea sottoposta ad hashing corrisponde alla chiave di identità temporanea corrente.
• Se non è stato fornito un hash di una chiave di identità temporanea, verifica che il fornitore non sia già stato eseguito il provisioning come beacon FMDN.

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

In caso di esito positivo, la chiave di identità effimera viene recuperata decriptandola con AES-ECB-128 utilizzando la chiave dell'account corrispondente. La chiave deve essere mantenuta sul dispositivo e da quel momento in poi il fornitore deve iniziare a pubblicizzare i frame FMDN. La nuova chiave di identità temporanea viene applicata immediatamente dopo la terminazione della connessione BLE. Il fornitore invia una notifica con una risposta della 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).

Cancellare la chiave di identità effimera

Per annullare il provisioning della parte del beacon del fornitore, il cercatore 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 sottoposta ad hashing corrisponde alla chiave di identità effimera corrente.

Se il provisioning del fornitore non viene eseguito come beacon FMDN o la verifica non va a buon fine, viene visualizzato un errore di mancata autenticazione.

In caso di esito positivo, il fornitore dimentica la chiave e smette di pubblicizzare i frame FMDN. Il fornitore invia una notifica con una risposta della 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à temporanea con il consenso dell'utente

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

Il cercatore deve memorizzare la chiave di ripristino nel backend per poter recuperare la chiave in testo normale, ma non memorizza la chiave EIK stessa.

Per leggere l'EIK, il cercatore esegue un'operazione di scrittura nella caratteristica, costituita da una richiesta della 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 mancata 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 dato 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 dell'anello

Il cercatore può chiedere al fornitore di riprodurre un suono eseguendo un'operazione di scrittura sulla caratteristica, costituita da una richiesta della tabella 4 con ID dati 0x05. Il fornitore crea il segmento di dati come segue:

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Funzionamento dell'anello	Una maschera di bit con i seguenti valori: Bit 1 (0x01): Fai squillare destro Bit 2 (0x02): suona a sinistra Bit 3 (0x04): cassa dello smartphone 0xFF: fa squillare tutti i componenti 0x00: smetti di squillare
1 - 2	uint16	Timeout	Il timeout in decisecondi. Non deve essere pari a zero e non deve essere superiore all'equivalente di 10 minuti. Il fornitore utilizza questo valore per determinare per quanto tempo deve squillare prima di disattivarsi. Il timeout sostituisce quello già in vigore se un componente del dispositivo sta già squillando. Se l'operazione di squillamento è 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 suonare.

Se il provisioning del fornitore non viene eseguito come beacon FMDN o la verifica non va a buon fine, viene visualizzato un errore di mancata autenticazione. Tuttavia, se il fornitore ha attivato la protezione dal monitoraggio indesiderato e la richiesta di attivazione della protezione dal monitoraggio indesiderato aveva attivato il flag di autenticazione salta suoneria, il fornitore deve saltare questo controllo. I dati di autenticazione dovrebbero comunque essere forniti dall'utente che cerca, ma potrebbero essere impostati su un valore arbitrario.

Quando inizia o termina la suoneria, 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 suoneria	0x00: avviata 0x01: impossibile avviare o interrompere (tutti i componenti richiesti sono fuori intervallo) 0x02: Interrotto (timeout) 0x03: interrotta (pressione del pulsante) 0x04: interrotta (richiesta GATT)
1	uint8	Componenti di squillo	Una maschera di bit dei componenti che suonano attivamente, come definito nella richiesta.
2 - 3	uint16	Timeout	Il tempo rimanente per lo squillo in decisecondi. 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: avviato o 0x04: interrotto (richiesta GATT), rispettivamente. Questa richiesta sostituisce i parametri dello stato esistente, in modo da poter prolungare la durata della suoneria.

Se il fornitore ha un pulsante fisico (o se è attiva la funzionalità Touch Sense), questo pulsante dovrebbe interrompere la funzione di squillamento se premuto mentre la suoneria è attiva.

Nota: per i fornitori che includono il rilevamento di utilizzo, ti consigliamo di verificare che il dispositivo non sia indossato prima che suoni al massimo del volume. Se il rilevamento se indosso 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 del cercatore che ha richiesto la suoneria. In questo modo si evita che il dispositivo smetta di squillare perché la connessione viene persa a causa dell'allontanamento del cliente dal dispositivo. Il dispositivo non può essere trovato perché ha smesso di squillare e si trova troppo lontano dal cliente per richiedere di nuovo lo squillo.

Ottenere lo stato di squillamento del beacon

Per ottenere lo stato di squillamento del beacon, il cercatore esegue un'operazione di scrittura sulla caratteristica, costituita da una richiesta della tabella 4 con ID dati 0x06. Il fornitore verifica che la chiave di autenticazione una tantum fornita corrisponda alla chiave dell'anello.

Se il provider non è stato configurato come beacon FMDN o se la verifica non va a buon fine, il provider restituisce un errore di mancata autenticazione.

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

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

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

Modalità di protezione dal monitoraggio indesiderato

La modalità di protezione dal monitoraggio indesiderato è progettata per consentire a qualsiasi client di identificare i dispositivi con comportamenti illeciti che non comunicano con il server. Per impostazione predefinita, il provider deve ruotare tutti gli identificatori come descritto in Rotazione degli ID. Il servizio Trova il mio dispositivo può inoltrare una richiesta di attivazione della modalità di protezione antitracciamento indesiderata tramite la rete di Trova il mio dispositivo. In questo modo, il servizio fa in modo che il fornitore utilizzi temporaneamente un indirizzo MAC fisso, consentendo ai client di rilevare il dispositivo e di avvisare l'utente di un possibile monitoraggio indesiderato.

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

Quando attivi la modalità di protezione antitracciamento indesiderato

Il fornitore crea il segmento di dati come segue:

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	Flag di controllo	0x01: salta l'autenticazione con suono. Se impostato, le richieste di squillamento non vengono autenticate in modalità di protezione dal monitoraggio indesiderato. Se non viene impostato alcun flag (il byte è composto da zeri), è valido omettere del tutto la sezione di dati e inviare una sezione di dati vuota. I flag sono attivi solo fino a quando la modalità di protezione dal monitoraggio indesiderato non viene disattivata.

Il fornitore verifica che la chiave di autenticazione una tantum fornita corrisponda alla chiave di protezione dal monitoraggio indesiderato. Se il provisioning del fornitore non viene eseguito come beacon FMDN o la verifica non va a buon fine, viene restituito un errore di mancata autenticazione.

Quando è attiva la modalità di protezione dal monitoraggio indesiderato, il beacon dovrebbe ridurre la frequenza di rotazione dell'indirizzo privato MAC a una volta ogni 24 ore. L'identificatore effimero pubblicizzato dovrebbe continuare a ruotare come al solito. Il tipo di frame deve essere impostato su 0x41. Lo stato è riportato anche nella sezione flag sottomessi ad hashing.

Quando disattivi la modalità di protezione dal monitoraggio indesiderato

Il fornitore verifica che:

• La chiave di autenticazione una tantum fornita corrisponde alla chiave di protezione dal monitoraggio indesiderato.
• La chiave di identità effimera sottoposta ad hashing corrisponde alla chiave di identità effimera corrente.

Se il provisioning del fornitore non viene eseguito come beacon FMDN o la verifica non va a buon fine, il fornitore restituisce un errore di mancata autenticazione.

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

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

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

Frame pubblicizzati

Dopo il provisioning, il fornitore deve pubblicizzare i frame FMDN almeno una volta ogni 2 secondi. Se vengono pubblicizzati frame di accoppiamento rapido, il fornitore deve interlacciare i frame FMDN all'interno degli annunci di accoppiamento rapido standard. Ad esempio, ogni due secondi il fornitore deve pubblicizzare sette annunci di accoppiamento rapido e un annuncio FMDN.

La potenza di trasmissione Bluetooth condotta per gli annunci FMDN deve essere impostata su almeno 0 dBm.

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

Il frame FMDN contiene una chiave pubblica utilizzata per criptare i report sulla posizione di qualsiasi client di supporto che contribuisce alla rete di crowdsourcing. Sono disponibili due tipi di chiavi con curve ellittiche: una chiave a 160 bit che si adatta ai frame BLE 4 precedenti 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 eseguire la scansione e generare report per i dispositivi di pubblicità, riducendo così le dimensioni della rete.

Un frame FMDN è strutturato come segue.

Ottetto	Valore	Descrizione
0	0x02	Lunghezza
1	0x01	Valore del tipo di dati dei flag
2	0x06	Dati sui 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 FMDN con indicazione della modalità di protezione dal monitoraggio indesiderato
8..27		Identificatore temporaneo di 20 byte
28		Flag sottomessi ad hashing

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

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

Ottetto	Valore	Descrizione
0	0x02	Lunghezza
1	0x01	Valore del tipo di dati dei flag
2	0x06	Dati sui 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 FMDN con indicazione della modalità di protezione dal monitoraggio indesiderato
8,39		Identificatore temporaneo di 32 byte
40		Flag sottomessi ad hashing

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

Calcolo dell'identificatore effimero (EID)

Viene generato un valore casuale mediante la crittografia AES-ECB-256 della seguente struttura di dati con la chiave di identità temporanea:

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 bit più bassi di K vengono cancellati.
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 bit più bassi di K 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, che corrisponde 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 le operazioni di crittografia con curve ellittiche. Consulta le definizioni delle curve nella SEZIONE 2: Parametri di dominio delle curve ellittiche consigliati, che definisce Fp, n e G a cui si fa riferimento di seguito.

r' viene ora 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 in uso. Il beacon pubblicizza Rx, ovvero la coordinata x di R, come identificatore temporaneo.

Flag sottoposti ad hashing

Il campo degli indicatori sottomessi ad hashing 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 della batteria non supportata
  • 01: livello batteria normale
  • 10: livello batteria basso
  • 11: livello batteria critico (è necessaria la sostituzione della batteria a breve)
• Il bit 7 è impostato su 1 se il beacon è in modalità di protezione dal monitoraggio indesiderato e su 0 altrimenti.

Per produrre il valore finale di questo byte, viene eseguito l'operazione 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 i bit più significativi devono essere troncati 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 monitoraggio indesiderato, è consentito omettere del tutto questo byte dall'annuncio.

Crittografia con EID

Nota: i seguenti dettagli per la crittografia e la decrittografia con gli EID sono inclusi solo per completezza della specifica. Solo il cercatore li implementa, non il fornitore.

Per criptare un messaggio m, un osservatore (dopo aver letto Rx dal beacon) deve eseguire quanto segue:

1. Scegli un numero casuale s in Fp, come definito nella sezione Calcolo dell'EID.
2. Esegui il calcolo S = s * G.
3. Calcola R = (Rx, Ry) sostituendolo 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. Sia 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. Esegui il calcolo nonce = LRx || LSx.
7. Esegui il calcolo (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
8. Invia (URx, Sx, m’, tag) al proprietario, eventualmente 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. Dato URx, ottieni il valore del contatore dell'ora del beacon su cui si basa URx. Questo può essere fatto dal client del proprietario calcolando i valori Rx per i valori del contatore del tempo del beacon per il passato recente e il futuro prossimo.
2. Dato il valore del contatore del tempo del beacon su cui si basa URx, calcola il valore previsto di r come definito nella sezione Calcolo dell'EID.
3. Calcola R = r * G e verifica la corrispondenza con il valore di URx fornito dall'osservatore.
4. Calcola S = (Sx, Sy) sostituendolo 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. Esegui il calcolo nonce = LRx || LSx.
7. Esegui il calcolo m = AES-EAX-256-DEC(k, nonce, m’, tag).

ID rotazione

Per la pubblicità dei frame FMDN deve essere utilizzato un indirizzo BLE risolvibile (RPA) o non risolvibile (NRPA). L'RPA è obbligatoria per i dispositivi LE Audio (LEA) ed è consigliata per altri dispositivi, ad eccezione dei tag locator che non utilizzano il pairing.

L'annuncio di 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 generare in modo casuale l'ora di rotazione è impostarla sull'ora di rotazione prevista successiva (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 dell'annuncio FMDN deve essere fisso, ma l'RPA per l'annuncio FP non rilevabile (ad esempio l'accoppiamento rapido) deve continuare a ruotare. È accettabile utilizzare indirizzi diversi per i diversi protocolli.

Recupero da perdita di alimentazione

La risoluzione dell'identificatore effimero è strettamente legata al suo valore dell'orologio al momento dell'annuncio, pertanto è importante che il fornitore possa recuperare il valore dell'orologio 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, controlli la NVM per verificare se è presente un valore da inizializzare. I risolutori dell'identificatore effimero implementano la risoluzione in un intervallo di tempo sufficiente a consentire sia un'adeguata deriva dell'orologio sia questo tipo di recupero della perdita di alimentazione.

I fornitori devono comunque fare tutto il possibile per ridurre al minimo gli scostamenti dell'orologio, poiché il periodo di tempo per la risoluzione è limitato. È necessario implementare almeno un altro metodo di sincronizzazione dell'orologio (pubblicità di frame di accoppiamento rapido non rilevabili o implementazione dello stream di messaggi).

Linee guida per l'implementazione dell'accoppiamento rapido

Questa sezione descrive aspetti speciali dell'implementazione dell'accoppiamento rapido sui fornitori che supportano FMDN.

Linee guida specifiche per i tag locator

• Se il fornitore è stato accoppiato, ma il provisioning di FMDN non è stato eseguito entro 5 minuti (o se è stato applicato un aggiornamento OTA mentre il dispositivo è accoppiato, ma non è stato eseguito il provisioning di FMDN), 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 fino al provisioning dell'FMDN o fino al trascorrere di 5 minuti.
• Se la chiave di identità effimera viene cancellata dal dispositivo, il dispositivo dovrebbe 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 con la funzionalità Fast Pair.
• Il fornitore deve includere un meccanismo che consenta agli utenti di interrompere temporaneamente la pubblicità senza ripristinare i dati di fabbrica del dispositivo (ad esempio, premendo una combinazione di pulsanti).
• Dopo un'interruzione dell'alimentazione, il dispositivo deve pubblicizzare frame di accoppiamento rapido non rilevabili fino alla successiva chiamata di read beacon parameters. In questo modo, il cercatore può rilevare il dispositivo e sincronizzare lo sfasamento dell'orologio anche se si è verificato un sfasamento significativo.
• Quando pubblicizzi frame di accoppiamento rapido non rilevabili, le indicazioni dell'interfaccia utente non devono essere attivate.
• I frame di accoppiamento rapido rilevabili non devono essere pubblicizzati mentre il fornitore è configurato per FMDN.
• Il Fornitore non deve esporre informazioni che consentono l'identificazione in modo non autenticato (ad es. nomi o identificatori).

Linee guida specifiche per i dispositivi Bluetooth Classic

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

Provisioning FMDN dei dispositivi già accoppiati

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

• Il fornitore può pubblicizzare periodicamente i dati dell'account di accoppiamento rapido che consentono al cercatore di trovare il suo indirizzo BLE tramite una ricerca BLE.
  Questo approccio è adatto ai fornitori che non implementano lo stream di messaggi.
• Il fornitore può fornire questi dati tramite lo stream di messaggi dell'accoppiamento rapido tramite il Bluetooth classico.
  Questo approccio è adatto ai fornitori che non pubblicizzano frame di accoppiamento rapido quando sono collegati al cercatore tramite Bluetooth.

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

Stream di messaggi di accoppiamento rapido

Il fornitore può implementare lo stream di messaggi di accoppiamento rapido e utilizzarlo per notificare al cercatore le informazioni sul dispositivo. L'implementazione dello stream di messaggi consente di attivare determinate funzionalità, come descritto in questa sezione.

Il fornitore deve inviare messaggi di informazioni sul dispositivo ogni volta che viene stabilito il canale RFCOMM per lo stream di messaggi.

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

Quando un aggiornamento del firmware aggiunge il supporto di FMDN al fornitore, un cercatore connesso può informare l'utente e offrirsi di eseguire il provisioning. In caso contrario, l'utente deve accedere manualmente all'elenco dei dispositivi Bluetooth per avviare il provisioning FMDN.

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

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

Tabella 11: evento relativo alle informazioni del dispositivo: versione del firmware aggiornata.

Al ricevimento di una richiesta di aggiornamento delle funzionalità (0x0601), se il fornitore ha attivato il supporto per il monitoraggio FMDN, 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 dei numeri consentiti su rete fissa	0x03
2 - 3	uint16	Lunghezza dati aggiuntiva	0x0007
4	uint8	Stato del provisioning FMDN	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 corrente del dispositivo	varia

Tabella 12: evento di sincronizzazione delle funzionalità del dispositivo: aggiunta funzionalità di monitoraggio.

Identificatore temporaneo corrente (codice informazioni del dispositivo 0x0B)

Il fornitore può utilizzare l'identificatore temporaneo corrente (codice 0x0B) per segnalare il valore corrente dell'EID e dell'orologio quando il provisioning del fornitore è stato eseguito per FMDN, in modo da sincronizzare il cercatore in caso di scostamento dell'orologio (ad esempio a causa di una batteria scarica). In caso contrario, il cercatore avvia una connessione più costosa e meno affidabile per questo scopo.

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

Tabella 13: evento relativo alle informazioni del 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 fornitore deve interrompere i beacon 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 deve iniziare subito a pubblicizzare la funzionalità di accoppiamento rapido per evitare che il flusso di accoppiamento inizi immediatamente dopo che l'utente ha eliminato il dispositivo.

Prevenzione del monitoraggio indesiderato

I dispositivi FMDN certificati devono soddisfare anche i requisiti della versione di implementazione della specifica cross-platform per il rilevamento di tracker della posizione indesiderati (DULT).

Linee guida pertinenti specifiche per i fornitori di servizi di media digitali (FMDN) per essere conformi alla specifica DULT:

• Qualsiasi dispositivo compatibile con FMDN deve essere registrato nella Console dei dispositivi nelle vicinanze e avere attiva la funzionalità "Trova il mio dispositivo".
• Il dispositivo deve implementare il servizio e la caratteristica Accessory Non-Owner definiti nella versione di implementazione della specifica DULT, incluse le operazioni di 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 dal monitoraggio indesiderato" definita in questo documento corrisponde allo "stato separato" definito dalla specifica DULT.
• Linee guida per l'implementazione delle opcode Informazioni sugli accessori:
  • Get_Product_Data deve restituire l'ID modello fornito dalla console, con zeri aggiunti per soddisfare il requisito di 8 byte. Ad esempio, l'ID modello 0xFFFFFF viene visualizzato come 0x0000000000FFFFFF.
  • Get_Manufacturer_Name e Get_Model_Name devono corrispondere ai valori forniti nella console.
  • Get_Accessory_Category può restituire il valore generico "Localizzatore" 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 dovrebbe restituire l'identificatore di Google (0x02).
• Linee guida per l'implementazione dell'opcode Get_Identifier:
  • L'operazione deve 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 deve indicare all'utente che il fornitore ha attivato questa modalità. Le istruzioni specifiche del modello per attivare 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 è costituita dai primi 10 byte dell'identificatore temporaneo corrente, seguiti dai primi 8 byte di HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
• Linee guida per l'implementazione di 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 suono e supporti la funzione di squillamento. In base alle specifiche DULT, il produttore di suoni deve emettere un suono con un livello di pressione sonora di picco minimo di 60 Phon, come definito dalla norma ISO 532-1:2017.
• Linee guida per l'implementazione dell'opcode Sound_Start:
  • Il comando dovrebbe attivare la suoneria in tutti i componenti disponibili.
  • Deve essere utilizzato il volume massimo supportato.
  • La durata consigliata per il suono è di 12 secondi.
• I tag locator 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 pulsanti).
  • 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=it") o utilizzando l'intestazione HTTP "accept-language".

Linee guida per i protocolli commutabili

• È possibile utilizzare un solo protocollo alla volta. Assicurati che sul dispositivo non possa funzionare contemporaneamente più di una rete. Questo requisito è necessario per garantire che non venga miscelata la sensibilità dei dati utente tra protocolli diversi.
• È consigliabile incorporare nel dispositivo un flusso di lavoro di ripristino dei dati di fabbrica che consenta a un utente di configurare nuovamente un dispositivo con una rete diversa.
• La procedura di aggiornamento di un dispositivo su una rete deve essere facile da usare e equa tra le reti. Un utente deve essere in grado di scegliere la rete che vuole utilizzare senza dare la preferenza a una delle emittenti. Questo flusso deve essere approvato dal team di Google.

Aggiornamenti del firmware

La procedura e la distribuzione degli aggiornamenti OTA devono essere gestite dal partner utilizzando il proprio flusso di lavoro per app mobile o web.

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

• La versione più recente del firmware dovrebbe essere aggiornata nella console dei dispositivi nelle vicinanze.
• In Console dei dispositivi nelle vicinanze deve essere impostata un'app complementare. Deve supportare l'intent di aggiornamento del firmware.
• Il fornitore deve implementare la caratteristica GATT Revisione firmware.

Per impedire il monitoraggio, l'accesso alla caratteristica Revisione del firmware deve essere limitato. Il cercatore leggerà prima lo stato del provisioning e fornirà una chiave di autenticazione, come definito in questa specifica, e solo dopo leggerà la revisione del firmware. L'operazione verrà eseguita sulla stessa connessione. Se viene eseguito un tentativo di lettura della revisione del firmware e il fornitore non è accoppiato né un'operazione autenticata è stata completata correttamente sulla stessa connessione, il fornitore deve restituire un errore di mancata autenticazione.

Compatibilità

La rete di Trova il mio dispositivo 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 FMDN	Data	Commento
v1		Versione iniziale della specifica FMDN per l'accesso in anteprima.
v1.1	Feb 2023	È stata aggiunta un'indicazione in testo chiaro della modalità di protezione dal monitoraggio indesiderato. È stata aggiunta un'opzione per saltare l'autenticazione delle richieste di squillamento in modalità di protezione dal monitoraggio indesiderato.
v1.2	Apr 2023	È stata aggiornata la definizione dell'AK di un proprietario. È stato aggiunto un consiglio per il recupero in caso di perdita di alimentazione nei tag locator. È stato aggiunto un chiarimento sulla 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 tag di localizzazione.
v1.3	Dicembre 2023	È stato aggiunto un chiarimento sulle informazioni che consentono l'identificazione esposte dai tag locator. È stato aggiunto un requisito per l'implementazione della specifica per la prevenzione del monitoraggio indesiderato. Sono state aggiunte linee guida per i dispositivi con protocollo commutabile.