v1.3
La specifica dell'accessorio Trova il mio dispositivo (FMDN) definisce un approccio criptato end-to-end per il monitoraggio dei dispositivi BLE (Bluetooth Low Energy) di beaconing. In questa pagina viene descritto FMDN come estensione della specifica dell'accoppiamento rapido. I fornitori dovrebbero attivare questa estensione se dispongono di dispositivi compatibili con FMDN e sono disposti ad attivare il monitoraggio della posizione per questi dispositivi.
Specifica GATT
È necessario aggiungere al servizio di accoppiamento rapido un'altra caratteristica di attributi generici (GATT) con la seguente semantica:
Caratteristica del servizio di accoppiamento rapido | Criptato | Autorizzazioni | UUID |
---|---|---|---|
Azioni relative ai beaconing | No | Lettura, scrittura e notifica | FE2C1238-8366-4814-8EB0-01DE32100BEA |
Tabella 1: caratteristiche del servizio di accoppiamento rapido per FMDN.
Autenticazione
Le operazioni richieste da questa estensione vengono eseguite come operazioni di scrittura, protette da un meccanismo di risposta challenge. Prima di eseguire qualsiasi operazione, il Seeker dovrebbe eseguire un'operazione di lettura dalla caratteristica nella tabella 1, che genera un buffer nel seguente formato:
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | Numero di versione principale del protocollo | 0x01 |
1 - 8 | array di byte | Nonce casuale una tantum | varia |
Ogni operazione di lettura dovrebbe generare un nonce diverso e un singolo nonce dovrebbe essere valido solo per una singola operazione. Il nonce deve essere invalidato anche se l'operazione non è riuscita.
Il Seeker calcola quindi una chiave di autenticazione una tantum da utilizzare in una richiesta di scrittura successiva. La chiave di autenticazione viene calcolata come descritto nelle tabelle da 2 a 5. A seconda dell'operazione richiesta, il richiedente dimostra di conoscere una o più delle seguenti chiavi:
Chiave account: la chiave di account per l'accoppiamento rapido a 16 byte, come definita nella specifica per l'accoppiamento rapido.
Chiave account proprietario: il fornitore sceglie una delle chiavi dell'account esistenti come chiave dell'account proprietario la prima volta che un utente accede alla caratteristica Beacon Actions. La chiave dell'account proprietario scelta non può essere modificata finché non vengono ripristinati i dati di fabbrica del provider. Il provider non deve rimuovere la chiave dell'account proprietario quando esaurisce gli slot senza costi delle chiavi dell'account.
I provider che supportano già FMDN quando sono accoppiati per la prima volta (o la supportano quando vengono accoppiati dopo il ripristino dei dati di fabbrica) scelgono la prima chiave dell'account, poiché questa è l'unica chiave dell'account esistente quando il Seeker legge lo stato di provisioning durante l'accoppiamento.
I provider che ottengono il supporto FMDN dopo essere già accoppiati (ad esempio tramite un aggiornamento firmware) possono scegliere qualsiasi chiave account esistente. È ragionevole scegliere la prima chiave dell'account utilizzata per leggere lo stato di provisioning dalle caratteristiche delle azioni beacon dopo l'aggiornamento del firmware, supponendo che l'utente che ha eseguito l'aggiornamento sia l'attuale proprietario del provider.
Chiave di identità temporanea (EIK): una chiave di 32 byte scelta in modo casuale dal Seeker durante l'esecuzione del processo di provisioning FMDN. Questa chiave viene utilizzata per ricavare le chiavi di crittografia utilizzate per la crittografia end-to-end dei report sulle località. Il Seeker non lo rivela mai al backend.
Chiave di recupero: definita come
SHA256(ephemeral identity key || 0x01)
, troncata ai primi 8 byte. Il token è memorizzato nel backend e il Seeker può utilizzarlo per recuperare l'EIK, a condizione che l'utente esprima il consenso premendo un pulsante sul dispositivo.Chiave Ring: definita come
SHA256(ephemeral identity key || 0x02)
, troncata ai primi 8 byte. La chiave è archiviata nel backend e la persona cercatrice può utilizzarla solo per far squillare il dispositivo.Chiave di protezione antitracciamento indesiderata: definita come
SHA256(ephemeral identity key || 0x03)
, troncata ai primi 8 byte. La chiave è archiviata nel backend e il richiedente può utilizzarla solo per attivare la modalità di protezione dal monitoraggio indesiderato.
Suite operativa
Il formato dei dati scritti nella caratteristica è indicato nelle tabelle da 2 a 5. Ogni operazione viene discussa in modo più dettagliato più avanti in questa sezione.
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | ID dati |
|
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 |
|
Tabella 2: richiesta di provisioning di beacon.
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | ID dati | 0x04: leggere la chiave di identità temporanea con il consenso dell'utente |
1 | uint8 | Lunghezza dei dati | 0x08 |
2 - 9 | array di byte | Chiave di autenticazione una tantum | I primi 8 byte di HMAC-SHA256(recovery key, protocol major version number || the last nonce
read from the characteristic || data ID || data length) |
Tabella 3: richiesta di recupero della chiave di provisioning del beacon.
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | ID dati |
|
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 |
|
Tabella 4: Richiesta di squillo.
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | ID dati |
|
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 |
|
Tabella 5: Richiesta di protezione dal monitoraggio indesiderata.
Notifiche di trigger di scrittura riuscita, come elencato nella tabella 6.
Le notifiche con ID dati diverso da 0x05: modifica dello stato della suoneria devono essere inviate prima del completamento della transazione di scrittura che attiva la notifica, ovvero prima che venga inviata una PDU di risposta per la richiesta di scrittura.
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | ID dati |
|
1 | uint8 | Lunghezza dei dati | varia |
2 - 9 | array di byte | Autenticazione | Dettagliato per operazione |
10 - VAR | array di byte | Dati aggiuntivi |
|
Tabella 6: risposta del servizio beacon.
La tabella 7 elenca i possibili codici di errore GATT restituiti dalle operazioni.
Codice | Descrizione | Note |
---|---|---|
0x80 | Non autenticato | Restituito in risposta a una richiesta di scrittura quando l'autenticazione non va a buon fine (incluso il caso in cui è stato utilizzato un nonce precedente). |
0x81 | Valore non valido | Errore restituito quando viene fornito un valore non valido o i dati ricevuti hanno un numero imprevisto di byte. |
0x82 | Nessun consenso dell'utente | Restituito in risposta a una richiesta di scrittura con ID dati 0x04: lettura della chiave di identità temporanea con il consenso dell'utente quando il dispositivo non è in modalità di accoppiamento. |
Tabella 7: codici di errore GATT.
Lettura del parametro del beacon
Il Seeker può interrogare il provider per trovare i parametri del beacon eseguendo un'operazione di scrittura sulla caratteristica che consiste in una richiesta dalla tabella 2 con ID dati 0x00. Il provider verifica che la chiave di autenticazione monouso fornita corrisponda a qualsiasi chiave dell'account archiviata sul dispositivo.
Se la verifica non va a buon fine, il provider restituisce un errore non autenticato.
Se l'operazione riesce, il provider invia una notifica con una risposta dalla tabella 6 con ID dati 0x00. Il fornitore crea il segmento di dati nel seguente modo:
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | Potenza calibrata | La potenza calibrata ricevuta a 0 m (un valore nell'intervallo [-100, 20]). Rappresentato come un numero intero firmato, con una risoluzione di 1 dBm. |
1-4 | uint32 | Valore quadrante | Il valore dell'orologio corrente in secondi (big endian). |
5 | uint8 | Selezione curva | La curva ellittica utilizzata per la crittografia:
|
6 | uint8 | Componenti | Il numero di componenti che possono squillare:
|
7 | uint8 | Funzionalità di squillo | Le opzioni supportate sono:
|
8-15 | array di byte | Spaziatura interna | Nessuna spaziatura interna per la crittografia AES. |
I dati devono essere criptati AES-ECB-128 con la chiave dell'account utilizzata per autenticare la richiesta.
Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data after
encryption || 0x01)
.
Lettura dello stato di provisioning del beacon
Il Seeker può interrogare il provider per conoscere lo stato di provisioning del beacon, eseguendo un'operazione di scrittura sulla caratteristica che consiste in una richiesta dalla tabella 2 con ID dati 0x01. Il provider verifica che la chiave di autenticazione una tantum fornita corrisponda a una qualsiasi delle chiavi dell'account archiviate sul dispositivo.
Se la verifica non va a buon fine, il provider restituisce un errore non autenticato.
Se l'operazione riesce, il provider invia una notifica con una risposta dalla tabella 6 con ID dati 0x01. Il fornitore crea il segmento di dati nel seguente modo:
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | Stato provisioning | Una maschera di bit con i seguenti valori:
|
1-20 o 32 | array di byte | Identificatore temporaneo attuale | 20 o 32 byte (a seconda del metodo di crittografia utilizzato) che indicano l'ID temporaneo corrente pubblicizzato dal beacon, se impostato per il dispositivo. |
Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data || 0x01)
.
Imposta una chiave di identità temporanea
Per eseguire il provisioning di un provider senza provisioning come beacon FMDN o modificare la chiave di identità temporanea del provider di cui è già stato eseguito il provisioning, il cercatore esegue un'operazione di scrittura sulla caratteristica che consiste in una richiesta dalla tabella 2 con ID dati 0x02. Il Fornitore verifica che:
- La chiave di autenticazione una tantum fornita corrisponde alla chiave dell'account del proprietario.
- Se è stato fornito un hash di una chiave di identità temporanea, la chiave di identità temporanea sottoposta ad hashing corrisponde all'attuale chiave di identità temporanea.
- Se non è stato fornito un hash di una chiave di identità temporanea, verifica che il provider non sia già stato sottoposto a provisioning come beacon FMDN.
Se la verifica non va a buon fine, il provider restituisce un errore non autenticato.
Se l'operazione riesce, la chiave di identità temporanea viene recuperata mediante AES-ECB-128 decriptandola utilizzando la chiave dell'account corrispondente. La chiave deve essere persistente sul dispositivo e da quel momento il provider dovrebbe iniziare a pubblicizzare frame FMDN. La nuova chiave di identità temporanea ha effetto subito dopo il termine della connessione BLE. Il provider invia una notifica con una risposta dalla tabella 6 con ID dati 0x02.
Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || 0x01)
.
Cancella la chiave di identità temporanea
Per eseguire l'annullamento del provisioning della parte di beacon del provider, il richiedente esegue un'operazione di scrittura sulla caratteristica, composta da una richiesta dalla tabella 2 con ID dati 0x03. Il Fornitore verifica che:
- La chiave di autenticazione una tantum fornita corrisponde alla chiave dell'account del proprietario.
- La chiave di identità temporanea sottoposta ad hashing corrisponde all'attuale chiave di identità temporanea.
Se il provider non è stato sottoposto a provisioning come beacon FMDN o se la verifica non va a buon fine, viene restituito un errore non autenticato.
Se l'operazione riesce, il provider dimentica la chiave e interrompe la pubblicità dei frame FMDN.
Il provider invia una notifica con una risposta dalla tabella 6 con ID dati 0x03.
Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(account key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || 0x01)
.
Leggere la chiave di identità temporanea con il consenso dell'utente
Questa opzione è disponibile solo per recuperare una chiave persa, poiché la chiave viene archiviata solo localmente dal Seeker. Pertanto, questa funzionalità è disponibile solo quando il dispositivo è in modalità di accoppiamento o per un periodo di tempo limitato dopo la pressione di un pulsante fisico sul dispositivo (presa del consenso dell'utente).
Il Seeker deve archiviare la chiave di recupero sul backend per poter recuperare la chiave in chiaro, ma non memorizza l'EIK stesso.
Per leggere l'EIK, il Seeker esegue un'operazione di scrittura sulla caratteristica, costituita da una richiesta dalla tabella 3 con ID dati 0x04. Il Fornitore verifica che:
- La chiave di recupero sottoposta ad hashing corrisponde alla chiave di recupero prevista.
- Il dispositivo è in modalità di ripristino EIK.
Se la verifica non va a buon fine, il provider restituisce un errore non autenticato.
Se il dispositivo non è in modalità di accoppiamento, il provider restituisce un errore di nessun consenso dell'utente.
Se l'operazione riesce, il provider invia una notifica con una risposta dalla tabella 6 con ID dati 0x04.
Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(recovery key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data || 0x01)
.
Squillo
Il Seeker può chiedere al provider di riprodurre un suono eseguendo un'operazione di scrittura sulla caratteristica, costituita da una richiesta dalla tabella 4 con ID dati 0x05. Il fornitore crea il segmento di dati nel seguente modo:
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | Squillo | Una maschera di bit con i seguenti valori:
|
1 - 2 | uint16 | Timeout | Il timeout in decisecondi. Non deve essere zero e non deve essere superiore all'equivalente di 10 minuti. Il provider utilizza questo valore per determinare la durata dello squillo prima di silenziare se stesso. Se qualche componente del dispositivo sta già squillando, il timeout sostituisce quello già attivo. Se squillo è impostato su 0x00, il timeout viene ignorato. |
3 | uint8 | Volume |
|
Alla ricezione della richiesta, il Fornitore verifica quanto segue:
- La chiave di autenticazione una tantum fornita corrisponde alla chiave circolare.
- Lo stato richiesto corrisponde ai componenti che possono squillare.
Se il provider non è stato sottoposto a provisioning come beacon FMDN o se la verifica non va a buon fine, viene restituito un errore non autenticato. Tuttavia, se per il provider è attiva una protezione antitracciamento indesiderata e se per l'attivazione della richiesta di protezione antitracciamento indesiderata è stato attivato il flag di autenticazione per ignorare il campanello, il provider dovrebbe saltare questo controllo. I dati di autenticazione dovrebbero comunque essere forniti dal Seeker, ma potrebbero essere impostati su un valore arbitrario.
Quando lo squillo inizia o termina, viene inviata una notifica come indicato nella tabella 6 con ID dati 0x05. I contenuti della notifica sono definiti come segue:
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | Stato squillo |
|
1 | uint8 | Componenti dello squillo | Maschera di bit dei componenti che suonano attivamente, come definita nella richiesta. |
2 - 3 | uint16 | Timeout | Il tempo rimanente per lo squillo in decisecondi. Se il dispositivo ha smesso di squillare, deve essere restituito il valore 0x0000. |
Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(ring key, protocol major version number || the nonce used to
initiate the ringing command || data ID || data length || additional data ||
0x01)
.
Se il dispositivo si trova già nello stato di squillo richiesto quando viene ricevuta una richiesta di squillo o per interrompere lo squillo, il provider deve inviare una notifica con uno stato di squillo oppure 0x00: Avviata o 0x04: Arrestata (richiesta GATT). Questa richiesta sostituisce i parametri dello stato esistente, in modo che la durata della suoneria possa essere estesa.
Se il provider dispone di un pulsante fisico (o di rilevamento tattile abilitato), tale pulsante deve interrompere la funzione di squillo se viene premuto mentre la suoneria è attiva.
Visualizza lo stato di suoneria del beacon
Per ottenere lo stato di squillo del beacon, il Seeker esegue un'operazione di scrittura sulla caratteristica, composta da una richiesta dalla tabella 4 con ID dati 0x06. Il provider verifica che la chiave di autenticazione una tantum fornita corrisponda alla chiave di chiamata.
Se il provider non è stato sottoposto a provisioning come beacon FMDN o se la verifica non va a buon fine, il provider restituisce un errore non autenticato.
Se l'operazione riesce, il provider invia una notifica con una risposta dalla tabella 6 con ID dati 0x06. Il fornitore crea il segmento di dati nel seguente modo:
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | Componenti dello squillo | I componenti squillano attivamente, come definito nella richiesta di squillo. |
1 - 2 | uint16 | Timeout | Il tempo rimanente per lo squillo in decisecondi. Tieni presente che se il dispositivo non squilla, deve essere restituito il valore 0x0000. |
Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256 (ring key, protocol major version number || the last nonce read
from the characteristic || data ID || data length || additional data || 0x01)
.
Modalità di protezione dal tracciamento indesiderato
La modalità di protezione dal tracciamento indesiderato consente a qualsiasi client di identificare i dispositivi illeciti senza comunicazione con il server. Per impostazione predefinita, il provider deve ruotare tutti gli identificatori come descritto in Rotazione ID. Il servizio Trova il mio dispositivo può inoltrare una richiesta di attivazione della modalità di protezione dal tracciamento indesiderata tramite la rete Trova il mio dispositivo. In questo modo, il servizio fa sì che il provider utilizzi temporaneamente un indirizzo MAC fisso, consentendo ai client di rilevare il dispositivo e avvisare l'utente di un possibile tracciamento indesiderato.
Per attivare o disattivare la modalità di protezione dal tracciamento indesiderato del beacon, il Seeker esegue un'operazione di scrittura sulla caratteristica, composta da una richiesta dalla tabella 5 con ID dati rispettivamente 0x07 o 0x08.
Quando si attiva la modalità di protezione dal tracciamento indesiderato
Il fornitore crea il segmento di dati nel seguente modo:
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | Flag di controllo |
I flag hanno effetto solo fino alla disattivazione della modalità di protezione dal tracciamento indesiderato. |
Il provider verifica che la chiave di autenticazione una tantum fornita corrisponda alla chiave di protezione antitracciamento indesiderata. Se il provider non è stato sottoposto a provisioning come beacon FMDN o se la verifica non va a buon fine, viene restituito un errore non autenticato.
Quando viene attivata la modalità di protezione dal tracciamento indesiderato, il beacon dovrebbe ridurre la frequenza di rotazione dell'indirizzo privato MAC a una volta ogni 24 ore. L'identificatore temporaneo pubblicizzato dovrebbe continuare a ruotare come di consueto. Il tipo di frame deve essere impostato su 0x41. Lo stato viene riportato anche nella sezione dei flag sottoposti ad hashing.
Quando si disattiva la modalità di protezione dal tracciamento indesiderato
Il Fornitore verifica che:
- La chiave di autenticazione una tantum fornita corrisponde alla chiave di protezione dal monitoraggio indesiderata.
- La chiave di identità temporanea sottoposta ad hashing corrisponde all'attuale chiave di identità temporanea.
Se il provider non è stato sottoposto a provisioning come beacon FMDN o se la verifica non va a buon fine, il provider restituisce un errore non autenticato.
Quando la modalità di protezione dal tracciamento indesiderato è disattivata, il beacon dovrebbe iniziare a ruotare di nuovo l'indirizzo MAC a una velocità normale, sincronizzata con la rotazione dell'identificatore temporaneo. Il tipo di frame deve essere impostato nuovamente su 0x40. Lo stato viene riportato anche nella sezione dei flag sottoposti ad hashing.
Se l'operazione riesce, il provider invia una notifica con una risposta dalla tabella 6 con ID dati 0x07 o 0x08.
Il segmento di autenticazione è definito come i primi 8 byte di HMAC-SHA256(unwanted tracking protection key, protocol major version number ||
the last nonce read from the characteristic || data ID || data length ||
0x01)
.
Fotogrammi pubblicizzati
Dopo il provisioning, il provider dovrà pubblicizzare i frame FMDN almeno una volta ogni 2 secondi. Se vengono pubblicizzati frame per l'accoppiamento rapido, il provider deve interlacciare i frame FMDN all'interno dei normali annunci per l'accoppiamento rapido. Ad esempio, ogni due secondi, il fornitore deve pubblicizzare sette annunci pubblicitari ad accoppiamento rapido e un annuncio FMDN.
Il frame FMDN contiene una chiave pubblica utilizzata per criptare i report sulle località da parte di qualsiasi client di supporto che contribuisce alla rete di crowdsourcing. Sono disponibili due tipi di chiavi a curva ellittica: una chiave a 160 bit compatibile con i frame BLE 4 legacy o una chiave a 256 bit che richiede BLE 5 con funzionalità pubblicitarie estese. L'implementazione del provider determina quale curva viene utilizzata.
Un frame FMDN è strutturato come segue.
Ottobre | Valore | Descrizione |
---|---|---|
0 | 0x02 | Lunghezza |
1 | 0x01 | Segnala il valore del tipo di dati |
2 | 0x06 | Dati sulle segnalazioni |
3 | 0x18 o 0x19 | Lunghezza |
4 | 0x16 | Valore del tipo di dati dei dati di servizio |
5 | 0xAA | UUID del servizio a 16 bit |
6 | 0xFE | ... |
7 | 0x40 o 0x41 | Tipo di frame FMDN con indicazione della modalità di protezione antitracciamento indesiderata |
8...27 | Identificatore temporaneo da 20 byte | |
28 | Flag sottoposti ad hashing |
Tabella 8: frame FMDN che supporta una curva a 160 bit.
La tabella 9 mostra gli offset e i valori dei byte per una curva a 256 bit.
Ottobre | Valore | Descrizione |
---|---|---|
0 | 0x02 | Lunghezza |
1 | 0x01 | Segnala il valore del tipo di dati |
2 | 0x06 | Dati sulle segnalazioni |
3 | 0x24 o 0x25 | Lunghezza |
4 | 0x16 | Valore del tipo di dati dei dati di servizio |
5 | 0xAA | UUID del servizio a 16 bit |
6 | 0xFE | ... |
7 | 0x40 o 0x41 | Tipo di frame FMDN con indicazione della modalità di protezione antitracciamento indesiderata |
8...39 | Identificatore temporaneo da 32 byte | |
40 | Flag sottoposti ad hashing |
Tabella 9: frame FMDN che supporta una curva a 256 bit.
Calcolo dell'identificatore temporaneo (EID)
Un casuale viene generato dall'algoritmo AES-ECB-256 criptando la seguente struttura di dati con la chiave di identità temporanea:
Ottobre | Tecnico | Descrizione |
---|---|---|
0 - 10 | Spaziatura interna | Valore = 0xFF |
11 | K | Esponente periodo di rotazione |
12 - 15 | TS[0]...TS[3] | Contatore del tempo di beaconing in formato big-endian a 32 bit. I bit K più bassi vengono cancellati. |
16 - 26 | Spaziatura interna | Valore = 0x00 |
27 | K | Esponente periodo di rotazione |
28 - 31 | TS[0]...TS[3] | Contatore del tempo di beaconing in formato big-endian a 32 bit. I bit K più bassi vengono cancellati. |
Tabella 10: Costruzione di un numero pseudocasuale.
Il risultato di questo calcolo è un numero a 256 bit, indicato con r'
.
Per il resto del calcolo, per le operazioni crittografiche basate su curva ellittica vengono utilizzati SECP160R1
o SECP256R1
. Vedi le definizioni delle curve in
SEC 2: parametri di dominio della curva ellittica consigliata, che definisce Fp
, n
e G
a cui si fa riferimento successivamente.
La proiezione di r'
nel campo limitato Fp
è ora prevista per il calcolo di r = r' mod n
.
Infine, calcola R = r * G
, che è un punto sulla curva che rappresenta la chiave pubblica in uso. Il beacon pubblicizza Rx
, che è la coordinata x
di R
, come identificatore temporaneo.
Flag sottoposti ad hashing
Il campo dei flag sottoposti ad hashing viene calcolato come segue (viene fatto riferimento ai bit dai più significativi a quelli meno significativi):
- Bit 0-4: riservati (impostati su zero).
- I bit da 5 a 6 indicano il livello della batteria del dispositivo nel seguente modo:
- 00: indicazione del livello della batteria non supportata
- 01: Livello batteria normale
- 10: Livello della batteria basso
- 11: Livello della batteria molto basso (è necessario sostituire la batteria a breve)
- Il bit 7 è impostato su 1 se il beacon è in modalità di protezione dal tracciamento indesiderato e su 0 negli altri casi.
Per produrre il valore finale di questo byte, viene usato xor-ed con il byte meno significativo di SHA256(r)
.
Tieni presente che r deve essere allineato alla dimensione della curva. Aggiungi gli zeri come bit più significativi se la sua rappresentazione è più breve di 160 o 256 bit oppure i bit più significativi dovrebbero essere troncati se la rappresentazione è superiore a 160 o 256 bit.
Se il beacon non supporta le indicazioni del livello della batteria e non si trova in una modalità di protezione dal tracciamento indesiderato, è consentito omettere completamente questo byte dalla pubblicità.
Crittografia con EID
Per criptare un messaggio m
, un visualizzatore (dopo aver letto Rx
dal beacon) deve procedere come segue:
- Scegli un numero casuale
s
inFp
, come definito nella sezione Calcolo EID. - Calcola
S = s * G
. - Calcola
R = (Rx, Ry)
effettuando una sostituzione nell'equazione della curva e scegliendo un valoreRy
arbitrario dai possibili risultati. - Calcola la chiave AES a 256 bit
k = HKDF-SHA256((s * R)x)
, dove(s * R)x
è la coordinatax
del risultato della moltiplicazione delle curve. Il sale non è specificato. - Consenti a
URx
eLRx
di essere rispettivamente gli 80 bit superiore e inferiore diRx
nel formato big-endian. In modo simile, definisciUSx
eLSx
perS
. - Calcola
nonce = LRx || LSx
. - Calcola
(m’, tag) = AES-EAX-256-ENC(k, nonce, m)
. - Invia
(URx, Sx, m’, tag)
al proprietario, possibilmente tramite un servizio remoto non attendibile.
Decrittografia dei valori criptati con EID
Il client del proprietario, che è in possesso dell'EIK e dell'esponente del periodo di rotazione, decripta il messaggio come segue:
- Dati
URx
, ottieni il valore del contatore del tempo di beacon su cui si basaURx
. Ciò può essere fatto dal cliente del proprietario che elabora i valoriRx
per i valori del contatore del tempo di beacon per il passato recente e quello prossimo. - Dato il valore del contatore del tempo di beacon su cui si basa
URx
, calcola il valore previsto dir
come definito nella sezione relativa al calcolo EID. - Calcola
R = r * G
e verifica una corrispondenza con il valore diURx
fornito dal turista. - Calcola
S = (Sx, Sy)
effettuando una sostituzione nell'equazione della curva e scegliendo un valoreSy
arbitrario dai possibili risultati. - Calcola
k = HKDF-SHA256((r * S)x)
, dove(r * S)x
è la coordinatax
del risultato della moltiplicazione della curva. - Calcola
nonce = LRx || LSx
. - Calcola
m = AES-EAX-256-DEC(k, nonce, m’, tag)
.
Rotazione ID
Per pubblicizzare frame FMDN è necessario utilizzare un indirizzo BLE risolvibile (RPA) o non risolvibile (NRPA). Il protocollo RPA è obbligatorio per i dispositivi LE Audio (LEA) ed è consigliato per altri dispositivi, ad eccezione dei tag di localizzazione che non utilizzano il collegamento.
L'annuncio ad accoppiamento rapido, l'annuncio FMDN e gli indirizzi BLE corrispondenti devono ruotare contemporaneamente. La rotazione dovrebbe avvenire in media ogni 1024 secondi. Il punto esatto in cui il beacon inizia a pubblicizzare il nuovo identificatore deve essere casuale all'interno della finestra.
L'approccio consigliato per randomizzare il tempo di rotazione è di impostarlo sul tempo di rotazione previsto successivo (se non è stata applicata la randomizzazione) più un fattore di tempo randomizzato positivo compreso tra 1 e 204 secondi.
Quando il dispositivo è in modalità di protezione dal tracciamento indesiderato, l'indirizzo BLE dell'annuncio FMDN deve essere fisso, ma l'RPA per la pubblicità non rilevabile FP (ad esempio l'accoppiamento rapido) deve continuare a ruotare. È accettabile utilizzare indirizzi diversi per i diversi protocolli.
Ripristino dopo la perdita di alimentazione
La risoluzione dell'identificatore temporaneo è strettamente legata al valore dell'orologio al momento della pubblicità, pertanto è importante che il provider possa recuperare il valore dell'orologio in caso di interruzione dell'alimentazione. È consigliabile che il provider scriva il valore di clock attuale nella memoria non volatile almeno una volta al giorno e che, al momento dell'avvio, il provider controlli l'NVM per verificare se esiste un valore da cui inizializzare. I resolver dell'identificatore temporaneo implementerebbero la risoluzione in una finestra temporale sufficiente a consentire sia una deriva di orologio ragionevole che questo tipo di recupero dalla perdita di potenza.
I provider devono comunque fare il possibile per ridurre al minimo le deviazioni dell'orologio, poiché la finestra temporale di risoluzione è limitata. È necessario implementare almeno un metodo di sincronizzazione dell'orologio aggiuntivo (pubblicità frame ad accoppiamento rapido non rilevabili o implementazione dello stream di messaggi).
Linee guida per l'implementazione dell'accoppiamento rapido
Questa sezione descrive gli aspetti speciali dell'implementazione dell'accoppiamento rapido sui provider che supportano FMDN.
Linee guida specifiche per i tag di localizzazione
- Se il provider è stato accoppiato, ma non è stato eseguito il provisioning di FMDN entro 5 minuti (o se è stato applicato un aggiornamento OTA mentre il dispositivo è associato, ma non è stato eseguito il provisioning FMDN), il provider dovrebbe ripristinare la configurazione di fabbrica e cancellare le chiavi account memorizzate.
- Una volta accoppiato il provider, non dovrebbe cambiare l'indirizzo MAC fino a quando non viene eseguito il provisioning di FMDN o prima che siano trascorsi 5 minuti.
- Se la chiave di identità temporanea viene cancellata dal dispositivo, questo dovrebbe eseguire un ripristino dei dati di fabbrica e cancellare anche le chiavi degli account memorizzate.
- Il provider dovrebbe rifiutare i normali tentativi di accoppiamento Bluetooth e accettare solo l'accoppiamento rapido.
- Il Fornitore deve includere un meccanismo che consenta agli utenti di interrompere temporaneamente la pubblicità senza ripristinare i dati di fabbrica del dispositivo (ad esempio la pressione di una combinazione di pulsanti).
- Dopo una perdita di alimentazione, il dispositivo dovrebbe pubblicizzare frame ad accoppiamento rapido non rilevabili fino alla chiamata successiva dei parametri di beaconing di lettura. In questo modo, Seeker può rilevare il dispositivo e sincronizzare l'orologio anche in caso di una significativa deviazione dell'orologio.
- Quando pubblicizzi frame ad accoppiamento rapido non rilevabili, le indicazioni dell'interfaccia utente non devono essere attivate.
- I frame ad accoppiamento rapido rilevabili non devono essere pubblicizzati mentre viene eseguito il provisioning del provider per FMDN.
- Il provider non deve mostrare informazioni identificative in modo non autenticato (ad es. nomi o identificatori).
Linee guida specifiche per il Bluetooth classico
In questa sezione vengono descritti aspetti speciali dei dispositivi Bluetooth classici che supportano FMDN.
Provisioning FMDN dei dispositivi già accoppiati
Il provider non esegue sempre il provisioning per FMDN durante l'accoppiamento con il richiedente, ma qualche tempo dopo. In questo caso, il provider potrebbe non avere un indirizzo MAC BLE aggiornato necessario per stabilire una connessione GATT. Il provider deve supportare almeno uno dei seguenti modi per consentire al richiedente di ottenere l'indirizzo BLE mentre è già accoppiato:
- Il Fornitore può periodicamente pubblicizzare i dati dell'account ad accoppiamento rapido che consentono a Seeker di trovare il proprio indirizzo BLE tramite una scansione BLE.
Questo approccio è adatto ai provider che non implementano il flusso di messaggi. - Il provider può fornire questi dati tramite lo stream di messaggi dell'accoppiamento rapido tramite Bluetooth classico.
Questo approccio è adatto ai fornitori che non pubblicizzano frame ad accoppiamento rapido mentre sono connessi a Seeker tramite Bluetooth.
Il supporto di entrambi gli approcci aumenta le possibilità che l'utente possa eseguire il provisioning del dispositivo per FMDN.
Stream di messaggi ad accoppiamento rapido
Il Fornitore può implementare lo stream di messaggi ad accoppiamento rapido e utilizzarlo per notificare al richiedente le informazioni del dispositivo. L'implementazione del flusso di messaggi abilita determinate funzionalità, come descritto in questa sezione.
Il fornitore dovrebbe inviare messaggi informativi sul dispositivo una volta ogni volta che viene stabilito il canale RFCOMM dello stream di messaggi.
Versione firmware (codice informazioni dispositivo 0x09) e funzionalità di monitoraggio
Quando un aggiornamento firmware aggiunge il supporto FMDN al provider, un richiedente connesso può informarne l'utente e proporne il provisioning. In caso contrario, l'utente deve accedere manualmente all'elenco dei dispositivi Bluetooth per avviare il provisioning FMDN.
Per consentire questa operazione, il provider deve utilizzare la proprietà Versione firmware (codice 0x09) per segnalare un valore stringa che rappresenta la versione del firmware. Inoltre, il provider deve supportare il protocollo che informa il richiedente delle modifiche alle funzionalità dovute agli aggiornamenti del firmware.
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | Evento informazioni del dispositivo | 0x03 |
1 | uint8 | Versione firmware | 0x09 |
2 - 3 | uint16 | Lunghezza dei dati aggiuntivi | varia |
var | array di byte | Stringa della versione | varia |
Tabella 11: Evento Informazioni del dispositivo: versione del firmware aggiornata.
Dopo aver ricevuto una richiesta di aggiornamento delle funzionalità (0x0601), se il provider ha abilitato il supporto per il monitoraggio FMDN, dovrebbe rispondere come mostrato nella tabella 12.
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | Evento di sincronizzazione delle funzionalità del dispositivo | 0x06 |
1 | uint8 | Monitoraggio FMDN | 0x03 |
2 - 3 | uint16 | Lunghezza dei dati aggiuntivi | 0x0007 |
4 | uint8 | Stato del provisioning FMDN | 0x00 se non è stato eseguito il provisioning; 0x01 se è stato eseguito il provisioning da un account |
5 - 10 | array di byte | L'indirizzo MAC BLE attuale del dispositivo | varia |
Tabella 12: Evento di sincronizzazione funzionalità dispositivo: aggiunta capacità di monitoraggio.
Identificatore temporaneo attuale (codice informazioni del dispositivo 0x0B)
Il Provider può utilizzare l'identificatore temporaneo corrente (codice 0x0B) per segnalare l'EID e il valore dell'orologio attuali quando viene eseguito il provisioning del Provider per l'FMDN, per sincronizzare il Seeker in caso di deviazione dell'orologio (ad esempio, a causa della batteria scarica). In caso contrario, il Seeker avvia una connessione più costosa e meno affidabile a questo scopo.
Ottobre | Tipo di dati | Descrizione | Valore |
---|---|---|---|
0 | uint8 | Evento informazioni del dispositivo | 0x03 |
1 | uint8 | Identificatore temporaneo attuale | 0 x 0 MLD |
2 - 3 | uint16 | Lunghezza dei dati aggiuntivi | 0x0018 o 0x0024 |
4 - 7 | array di byte | Valore quadrante | Esempio: 0x13F9EA80 |
8 - 19 o 31 | array di byte | EID attuale | Esempio: 0x1122334455667788990011223344556677889900 |
Tabella 13: Evento informazioni dispositivo: sincronizzazione orologio.
Ripristino dati di fabbrica
Per i dispositivi che supportano il ripristino dei dati di fabbrica: se viene eseguito un ripristino dei dati di fabbrica, il provider deve interrompere il beaconing e cancellare la chiave di identità temporanea e tutte le chiavi dell'account memorizzate, inclusa la chiave dell'account del proprietario.
Dopo un ripristino dei dati di fabbrica (manuale o programmatico), il fornitore non dovrebbe iniziare subito a pubblicizzare l'accoppiamento rapido per evitare che il flusso di accoppiamento inizi immediatamente dopo l'eliminazione del dispositivo da parte dell'utente.
Prevenzione del monitoraggio indesiderato
I dispositivi FMDN certificati devono inoltre soddisfare i requisiti nella versione di implementazione della specifica multipiattaforma per il rilevamento dei tracker di località indesiderate (DULT).
Linee guida pertinenti specifiche di FMDN per la conformità con le specifiche DULT:
- Tutti i dispositivi compatibili con FMDN devono essere registrati nella console dispositivo nelle vicinanze e avere attivato la funzionalità "Trova il mio dispositivo".
- Il dispositivo deve implementare il servizio Accessorio non proprietario e la caratteristica definiti nella versione di implementazione delle specifiche DULT, incluse le operazioni Informazioni sugli accessori e i Controlli per i non proprietari.
- Durante il periodo di compatibilità con le versioni precedenti, come definito nelle specifiche DULT, non sono state apportate modifiche al frame pubblicizzato come definito in questo documento.
- La "modalità di protezione dal tracciamento indesiderato" definita in questo documento corrisponde allo "stato separato" definito dalla specifica DULT.
- Linee guida per l'implementazione degli opcode delle informazioni sugli accessori:
- Get_Product_Data deve restituire l'ID modello fornito dalla console, zero padding per soddisfare il requisito degli 8 byte. Ad esempio, l'ID modello 0xFFFFFF viene restituito come 0x0000000000FFFFFF.
- Get_Manufacturer_Name e Get_Model_Name devono corrispondere ai valori forniti nella console.
- Get_Accessory_Category può restituire il valore generico "Location Tracker" se nessun'altra categoria è più adatta al tipo di dispositivo.
- Get_Accessory_Capabilities deve indicare il supporto dello squillo e la ricerca degli identificatori BLE.
- Get_Network_ID deve restituire l'identificatore di Google (0x02).
- Linee guida per l'implementazione del codice operativo Get_Identifier:
- L'operazione dovrebbe restituire una risposta valida solo per 5 minuti dopo che l'utente ha attivato la modalità di "identificazione", che richiede una combinazione di pressioni dei pulsanti. Un segnale visivo o audio dovrebbe indicare all'utente che il fornitore è passato a quella modalità. Le istruzioni specifiche per modello per l'attivazione di tale modalità devono essere fornite a Google come requisito per la certificazione e almeno 10 giorni prima di qualsiasi aggiornamento o modifica delle istruzioni.
- La risposta viene creata come segue: i primi 10 byte dell'identificatore temporaneo attuale, seguiti dai primi 8 byte di
HMAC-SHA256(recovery key, the truncated current ephemeral identifier)
.
- Linee guida per l'implementazione dell'opcode Sound_Start:
- Il comando dovrebbe attivare lo squillo in tutti i componenti disponibili.
- Deve essere utilizzato il volume massimo supportato.
- La durata consigliata dello squillo è 12 secondi.
- I tag localizzatori devono includere un meccanismo che consenta agli utenti di interrompere temporaneamente
la pubblicità senza ripristinare i dati di fabbrica del dispositivo (ad esempio la pressione di una
combinazione di pulsanti).
- Le istruzioni per la disattivazione devono essere documentate in un URL disponibile pubblicamente e fornite a Google come requisito per la certificazione e almeno 10 giorni prima di qualsiasi aggiornamento o modifica delle istruzioni.
- L'URL deve supportare la localizzazione. A seconda del client, la lingua verrà fornita come parametro di query ("hl=en") o utilizzando l'intestazione HTTP "accept-language".
Linee guida relative ai protocolli commutabili
- È possibile usare un solo protocollo alla volta. Assicurati che sul dispositivo non possa essere eseguita più di una rete contemporaneamente. Questo requisito è necessario per garantire che non esista una combinazione di dati utente sensibili tra protocolli diversi.
- È consigliabile incorporare nel dispositivo un flusso di lavoro per il ripristino dei dati di fabbrica, che consenta all'utente di riconfigurare il dispositivo con una rete diversa.
- Il processo di aggiornamento di un dispositivo a una rete deve essere facile da usare ed equo tra le reti. Un utente deve poter scegliere quale rete utilizzare senza dare la preferenza a una delle reti. Questo flusso deve essere approvato dal team di Google.
Aggiornamenti del firmware
Il processo e la distribuzione degli aggiornamenti OTA devono essere gestiti dal partner utilizzando il proprio flusso di lavoro per app mobile o web.
Compatibilità
La rete di Trova il mio dispositivo richiede servizi di geolocalizzazione e Bluetooth per l'attivazione. Richiede un servizio cellulare o una connessione a internet. Funziona su Android 9 e versioni successive e in alcuni paesi per gli utenti di età idonea.
Log delle modifiche
Versione FMDN | Data | Commento |
---|---|---|
v1 | Release iniziale della specifica FMDN per l'accesso in anteprima. | |
v1.1 | Feb 2023 |
|
v1.2 | Aprile 2023 |
|
v1.3 | Dicembre 2023 |
|