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. In questa pagina viene descritto 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 vuoi integrare le specifiche degli accessori di Trova il mio dispositivo, invia un modulo di proposta del dispositivo. 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 degli attributi generici (GATT) con la seguente semantica:

Caratteristica del servizio di accoppiamento rapido	Criptato	Autorizzazioni	UUID
Azioni di beaconing	No	Leggi, scrivi e invia notifiche	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 operazione di scrittura, protetta da un meccanismo di risposta challenge. 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 tabelle 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 dell'account per l'accoppiamento rapido a 16 byte, come definita nella specifica per l'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 finché il fornitore non viene reimpostato alle impostazioni di fabbrica. 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), truncated to the first 8 bytes. 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 dell'anello: 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 il cercatore può utilizzarla solo per attivare la modalità di protezione dal monitoraggio indesiderato.

Operazioni

Il formato dei dati scritti nella caratteristica è indicato nelle tabelle da 2 a 5. Ognuna delle operazioni viene descritta in modo più dettagliato più avanti in questa sezione.

Octet	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x00: lettura dei parametri di beaconing 0x01: leggi lo stato del provisioning 0x02: Impostazione della chiave di identità temporanea 0x03: chiave di identità effimera chiara
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 0x02: 32 byte che rappresentano la chiave di identità temporanea, criptata con AES-ECB-128 con la chiave dell'account. Se il provider ha già impostato una chiave di identità temporanea, 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 del beacon.

Ottetto	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x04: lettura della chiave di identità temporanea 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: lettura dello stato dello squillo
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 che indicano lo stato dello squillo, la durata dello squillo e il volume dello squillo. 0x06: n/d

Tabella 4: Richiesta di squillo.

Octet	Tipo di dati	Descrizione	Valore
0	uint8	ID dati	0x07: Attivazione della modalità di protezione antitracciamento indesiderata 0x08: disattiva la modalità di protezione antitracciamento indesiderata
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 antitracciamento indesiderata.

Scrive riuscite per le notifiche di trigger, come elencato 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: lettura dei parametri di beaconing 0x01: leggi lo stato del provisioning 0x02: Impostazione della chiave di identità temporanea 0x03: chiave di identità effimera chiara 0x04: lettura della chiave di identità temporanea con il consenso dell'utente 0x05: modifica dello stato dell'anello 0x06: leggi lo stato di suoneria 0x07: Attivazione della modalità di protezione antitracciamento indesiderata 0x08: disattiva la modalità di protezione antitracciamento indesiderata
1	uint8	Lunghezza dei 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 squillo, AES-ECB-128 criptato con la chiave dell'account (zero riempito) 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 degli utenti	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 ricercatore può interrogare il provider sui parametri del beacon eseguendo un'operazione di scrittura nella caratteristica che consiste in una richiesta dalla tabella 2 con ID dati 0x00. Il provider verifica che la chiave di autenticazione una tantum fornita corrisponda a una qualsiasi delle chiavi dell'account memorizzate nel dispositivo.

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

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:

Octet	Tipo di dati	Descrizione	Valore
0	uint8	Potenza calibrata	La potenza calibrata ricevuta a 0 m (un valore nell'intervallo [-100, 20]). Rappresentato come numero intero con segno, con una risoluzione di 1 dBm.
1-4	uint32	Valore orologio	Il valore dell'orologio attuale 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 può squillare un solo componente. 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 provider deve accettare e gestire 3 livelli di volume come indicato in Operazione squillo.
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).

Lettura dello stato di provisioning del beacon

Il cercatore può eseguire una query sul fornitore per conoscere lo stato del provisioning del beacon eseguendo 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 non autenticato.

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:

Octet	Tipo di dati	Descrizione	Valore
0	uint8	Stato 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 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).

Impostare una chiave di identità temporanea

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

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.

Se l'operazione riesce, il provider dimentica la chiave e smette di pubblicizzare i frame FMDN. Il fornitore invia una notifica con una risposta della 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).

Leggi 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. Di conseguenza, 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 dispositivo di ricerca 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 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.

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

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 nel seguente modo:

Octet	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): Fai squillare sinistro Bit 3 (0x04): cassa anello 0xFF: fai squillare tutti i componenti 0x00: smetti di suonare
1 - 2	uint16	Timeout	Timeout in decisecondi. Non deve essere zero e non deve essere maggiore dell'equivalente di 10 minuti. Il provider utilizza questo valore per determinare la durata della suoneria prima di disattivare l'audio. Il timeout sostituisce quello già in vigore se un componente del dispositivo sta già squillando. Se l'operazione di chiamata è impostata su 0x00, il timeout viene ignorato.
3	uint8	Volume	0 x 00: valore predefinito 0x01: basso 0x02: medio 0 x 03: 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 ring.
• 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 per saltare la suoneria, il fornitore deve saltare questo controllo. I dati di autenticazione dovrebbero comunque essere forniti dall'utente che effettua la ricerca, 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:

Octet	Tipo di dati	Descrizione	Valore
0	uint8	Stato suoneria	0x00: avviato 0x01: impossibile avviare o arrestare (tutti i componenti richiesti sono fuori intervallo) 0x02: Interruzione (timeout) 0x03: Interrotto (pressione del pulsante) 0x04: Interrotta (richiesta GATT)
1	uint8	Componenti squillo	Una maschera di bit dei componenti che squilla attivamente, come definito nella richiesta.
2 - 3	uint16	Timeout	Il tempo rimanente per suonare 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 provider dispone di un pulsante fisico (o il rilevamento del tocco è abilitato), questo pulsante dovrebbe interrompere la funzione di suoneria se viene 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 a volume massimo. Se il rilevamento in uso 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 di 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.

Recupera 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 eseguito il provisioning 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:

Octet	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, dovrebbe 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 nella 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 antitracciamento indesiderata del beacon, il dispositivo di ricerca esegue un'operazione di scrittura sulla caratteristica, che consiste in una richiesta dalla tabella 5 con ID dati rispettivamente 0x07 o 0x08.

Quando si attiva la modalità di protezione antitracciamento indesiderato

Il fornitore crea il segmento di dati nel seguente modo:

Octet	Tipo di dati	Descrizione	Valore
0	uint8	Flag di controllo	0x01: salta l'autenticazione tramite squillo. 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 è indicato anche nella sezione dei flag sottoposti ad hashing.

Quando si disattiva la modalità di protezione antitracciamento indesiderata

Il fornitore verifica che:

• La chiave di autenticazione una tantum fornita corrisponde alla chiave di protezione antitracciamento indesiderata.
• 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 è disattivata, il beacon dovrebbe iniziare nuovamente a ruotare l'indirizzo MAC a una frequenza normale, sincronizzato con la rotazione degli identificatori temporanei. Il tipo di frame deve essere impostato nuovamente su 0x40. Lo stato viene 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 i frame di accoppiamento rapido, il provider deve interlacciare i frame FMDN all'interno dei normali annunci di accoppiamento rapido. Ad esempio, ogni due secondi il fornitore deve pubblicizzare sette annunci di accoppiamento rapido e un annuncio FMDN.

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, consigliamo vivamente di riattivare periodicamente il dispositivo e fare pubblicità per un breve periodo di tempo (ad es. svegliati ogni 10 minuti e fai 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 provider 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 pubblicitari, riducendo così le dimensioni della rete.

Un frame FMDN è strutturato come segue.

Octet	Valore	Descrizione
0	0x02	Lunghezza
1	0x01	Valore del tipo di dati dei flag
2	0x06	Dati delle segnalazioni
3	0x18 o 0x19	Lunghezza
4	0x16	Valore del tipo di dati dei dati di servizio
5	0xAA	UUID di 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 con hash

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.

Octet	Valore	Descrizione
0	0x02	Lunghezza
1	0x01	Valore del tipo di dati dei flag
2	0x06	Dati delle segnalazioni
3	0x24 o 0x25	Lunghezza
4	0x16	Valore del tipo di dati dei dati di servizio
5	0xAA	UUID di 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 da 32 byte
40		Flags sottoposte ad hashing

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

Calcolo dell'identificatore temporaneo (EID)

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

Octet	Campo	Descrizione
0 - 10	Spaziatura interna	Valore = 0xFF
11	K	Esponente del 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 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, corrispondente a 1024 secondi.

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

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

La proiezione di r' ora è verso il 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 con hash

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 allineata alla dimensione 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 le implementa, non il fornitore.

Per criptare un messaggio m, un visualizzatore (che ha letto Rx dal beacon) procede nel seguente modo:

1. Scegli un numero casuale s in Fp, come definito nella sezione Calcolo EID.
2. Esegui il calcolo S = s * G.
3. Calcola R = (Rx, Ry) per sostituzione nell'equazione della curva e scegliendo un valore di Ry arbitrario tra i 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. 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. Calcola 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 nel seguente modo:

1. Dato URx, ottieni il valore del contatore del tempo di beaconing su cui si basa URx. Questa operazione può essere eseguita dal client del proprietario che calcola i valori Rx per i valori del contatore dell'ora di beaconing relativi al passato recente e al prossimo futuro.
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 una corrispondenza con il valore di URx fornito dal visitatore.
4. Calcola S = (Sx, Sy) per sostituzione nell'equazione della curva e scegliendo un valore di Sy arbitrario tra i possibili risultati.
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 gli annunci di frame FMDN deve essere utilizzato 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 localizzatori che non utilizzano bond.

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 dell'intervallo.

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 non rilevabile FP (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 della pubblicazione 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 memoria NVM per verificare se è presente un valore da inizializzare. I resolver dell'identificatore temporaneo implementerebbero la risoluzione in un intervallo di tempo sufficiente a consentire una ragionevole deviazione dell'orologio e questo tipo di ripristino dalla perdita di alimentazione.

I provider dovrebbero comunque fare il possibile per ridurre al minimo le deviazioni dell'orologio, poiché la finestra temporale di risoluzione è limitata. Deve essere implementato 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 localizzatori

• 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.
• Dopo l'accoppiamento, 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 provider dovrebbe rifiutare i normali tentativi di accoppiamento Bluetooth e accettare solo l'accoppiamento rapido.
• Il provider 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 una perdita di alimentazione, il dispositivo deve pubblicizzare frame ad accoppiamento rapido non rilevabili fino alla successiva chiamata dei parametri del beacon di lettura. 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

Non sempre viene eseguito il provisioning del provider per FMDN durante l'accoppiamento con il dispositivo di ricerca, ma dopo un po' di tempo. In questo caso, il provider potrebbe non disporre di un indirizzo MAC BLE aggiornato per stabilire una connessione GATT. Il provider deve supportare almeno uno dei seguenti modi affinché il richiedente possa ottenere l'indirizzo BLE mentre è 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 per l'accoppiamento rapido tramite 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 provider può implementare lo stream di messaggi per l'accoppiamento rapido e utilizzarlo per notificare al ricercatore le informazioni del dispositivo. L'implementazione dello stream di messaggi consente di attivare determinate funzionalità, come descritto in questa sezione.

Il provider deve inviare messaggi con le informazioni sul dispositivo una volta ogni volta che viene stabilito il canale RFCOMM del flusso 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.

Octet	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 della versione	varia

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

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

Octet	Tipo di dati	Descrizione	Valore
0	uint8	Evento di sincronizzazione delle funzionalità del dispositivo	0x06
1	uint8	Monitoraggio FMDN	0x03
2 - 3	uint16	Dati aggiuntivi	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 BLE MAC corrente del dispositivo	varia

Tabella 12: Evento di sincronizzazione funzionalità dispositivo: aggiunta funzionalità di tracciamento.

Identificatore temporaneo corrente (codice informazioni del dispositivo 0x0B)

Il fornitore può utilizzare l'identificatore temporaneo corrente (codice 0x0B) per segnalare l'EID e il valore dell'orologio correnti quando il provisioning del fornitore è stato eseguito per FMDN, per 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.

Octet	Tipo di dati	Descrizione	Valore
0	uint8	Evento relativo alle informazioni del dispositivo	0x03
1	uint8	Identificatore temporaneo corrente	0x0B
2 - 3	uint16	Dati aggiuntivi	0x0018 o 0x0024
4 - 7	array di byte	Valore dell'orologio	Esempio: 0x13F9EA80
8 - 19 o 31	array di byte	EID attuale	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 provider non dovrebbe iniziare subito a pubblicizzare l'accoppiamento rapido per impedire l'avvio del flusso di accoppiamento subito dopo l'eliminazione del dispositivo da parte dell'utente.

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 FMDN per essere conformi alla specifica DULT:

• Tutti i dispositivi compatibili con FMDN devono essere registrati nella console dispositivi nelle vicinanze e avere la funzionalità "Trova il mio dispositivo" attivata.
• Il dispositivo deve implementare il servizio e la caratteristica accessorio non proprietario definiti nella versione di implementazione della specifica DULT, incluse le operazioni Informazioni sugli accessori e i controlli non proprietari.
• Durante il periodo di compatibilità con le versioni precedenti, come definito nelle specifiche DULT, non vengono apportate modifiche al frame pubblicizzato, come definito in questo documento.
• La "modalità di protezione antitracciamento indesiderato" definita in questo documento corrisponde allo "stato separato" definito 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 "Location Tracker" se nessun'altra categoria si adatta meglio al tipo di dispositivo.
  • Get_Accessory_Capabilities deve indicare il supporto per la suoneria e la ricerca dell'identificatore BLE.
  • Get_Network_ID deve restituire l'identificatore di Google (0x02).
• Linee guida per l'implementazione dell'opcode Get_Identifier:
  • L'operazione dovrebbe restituire una risposta valida solo cinque 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 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 è composta dai 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'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, con codifica esadecimale.
• Linee guida per l'implementazione dell'opcode Sound_Start:
  • Il comando dovrebbe attivare la suoneria in tutti i componenti disponibili.
  • Utilizzare il volume massimo supportato.
  • La durata consigliata per lo squillo è di 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 tramite 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 sia possibile operare più di una rete contemporaneamente. Questo requisito è necessario per garantire che i dati utente sensibili non vengano mescolati tra protocolli diversi.
• È consigliabile incorporare nel dispositivo un flusso di lavoro di ripristino dei dati di fabbrica che permetta all'utente di configurare nuovamente un dispositivo con una rete diversa.
• La procedura di aggiornamento di un dispositivo a una rete deve essere facile da usare e equa tra le reti. Un utente deve poter 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 web o mobile.

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	Aprile 2023	È stata aggiornata la definizione di "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 degli indirizzi MAC in modalità di protezione antitracciamento indesiderata. È 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 localizzatore. È stato aggiunto un requisito per l'implementazione della specifica per la prevenzione del monitoraggio indesiderato. Sono state aggiunte le linee guida per i dispositivi con protocollo commutabile.