Caratteristiche
Servizio di accoppiamento rapido
Il provider di accoppiamento rapido deve avere il seguente servizio GATT.
| Servizio | UUID |
|---|---|
| Servizio di accoppiamento rapido | 0xFE2C |
Questo servizio deve avere le seguenti caratteristiche.
| Caratteristica del servizio di accoppiamento rapido | Criptato | Autorizzazioni | UUID |
|---|---|---|---|
| ID modello | No | Lettura | FE2C1233-8366-4814-8EB0-01DE32100BEA |
| Accoppiamento basato su chiave | No | Scrivi e invia notifica | FE2C1234-8366-4814-8EB0-01DE32100BEA |
| Passkey | No | Scrivere e inviare una notifica | FE2C1235-8366-4814-8EB0-01DE32100BEA |
| Chiave account | No | Scrittura | FE2C1236-8366-4814-8EB0-01DE32100BEA |
Servizio di informazioni sul dispositivo
Il fornitore dell'accoppiamento rapido deve supportare anche il servizio di informazioni sul dispositivo.
| Servizio | UUID |
|---|---|
| Servizio informazioni sul dispositivo | 0x180A |
Il Seeker di accoppiamento rapido utilizza le seguenti caratteristiche.
| Nome | Criptato | Autorizzazioni | UUID |
|---|---|---|---|
| Revisione firmware | No | Lettura | 0x2A26 |
Caratteristica: ID modello
Questa caratteristica consente al richiedente di leggere l'ID modello in base alle necessità, al di fuori di quando il dispositivo pubblicizza in modalità rilevabile. Deve sempre restituire i seguenti dati:
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 - 2 | uint24 |
ID modello | varia |
Caratteristica: accoppiamento basato su chiave
Questa caratteristica controlla la procedura di accoppiamento basato su chiave. In questa procedura, un certo livello di attendibilità viene stabilito verificando che il richiedente e il fornitore siano entrambi in possesso di una chiave precondivisa. La chiave è diversa in ogni caso:
Caso 1: la chiave precondivisa si basa sulla coppia di chiavi pubblica/privata anti-spoofing e sulla coppia di chiavi pubblica/privata del Seeker, che cambierà per ogni tentativo di accoppiamento.
- Il provider è in modalità di accoppiamento.
- Il Seeker verifica che il Provider sia in possesso della chiave privata anti-spoofing.
Tieni presente che, in modalità di accoppiamento, il provider può anche accoppiarsi nel modo consueto, ad esempio con un dispositivo che non supporta l'accoppiamento basato su chiavi di accoppiamento rapido.
Caso 2: la chiave precondivisa è una delle chiavi dell'account.
- Il Provider di solito non è in modalità di accoppiamento. (Tuttavia, questo non è un requisito: il provider deve supportare l'utilizzo di una chiave dell'account anche in modalità di accoppiamento).
- Il Seeker e il Provider verificano ciascuno che l'altro sia in possesso della chiave dell'account.
Poiché entrambi i casi sono estremamente simili, tranne per la chiave precondivisa utilizzata, sono combinati nella procedura.
Formato dei dati
Consulta la procedura per l'utilizzo di ciascun formato.
| Ottetto | Tipo di dati | Descrizione | Valore | Obbligatorio? |
|---|---|---|---|---|
| 0-15 | uint128 |
Richiesta criptata | varies | Obbligatorio |
| 16 - 79 | Chiave pubblica | varies | Facoltativo |
Tabella 1.1: richiesta criptata, scritta nella caratteristica dal richiedente.
| Ottetto | Tipo di dati | Descrizione | Valore | Obbligatorio? |
|---|---|---|---|---|
| 0 | uint8 |
Tipo di messaggio | 0x00 = Richiesta di accoppiamento basata su chiave |
Obbligatorio |
| 1 | uint8 |
Flag
|
varies | Obbligatorio |
| 2 - 7 | uint48 |
Una di queste soglie:
|
varies | Obbligatorio |
| 8 - 13 | uint48 |
Indirizzo BR/EDR del richiedente | varia | Presente solo se è impostato il bit 1 o 3 dei flag |
| n - 15 | Valore casuale (salt) | varie | Obbligatorio |
Tabella 1.2.1: richiesta non elaborata (tipo 0x00). Decriptato dalla richiesta criptata nella Tabella 1.1.
| Ottetto | Tipo di dati | Descrizione | Valore | Obbligatorio? |
|---|---|---|---|---|
| 0 | uint8 |
Tipo di messaggio | 0x10 = Richiesta di azione |
Obbligatorio |
| 1 | uint8 |
Flag
|
varies | Obbligatorio |
| 2 - 7 | uint48 |
Una di queste soglie:
|
varies | Obbligatorio |
| 8 | uint8 |
Invia messaggio al gruppo | varia | Obbligatorio se è impostato il bit 0 dei flag |
| 9 | uint8 |
Codice del messaggio | varia | Obbligatorio se è impostato il bit 0 dei flag |
| 10 | uint8 |
Dipende dai flag:
|
varies | Obbligatorio se è impostato il bit 0 o 1 dei flag |
| 11 - n | Dati aggiuntivi | varies | Facoltativo | |
| n - 15 | Valore casuale (salt) | varie | Obbligatorio |
Tabella 1.2.2: richiesta non elaborata (tipo 0x10). Decrittografato dalla richiesta criptata in Tabella 1.1.
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 | uint8 |
Tipo di messaggio | 0x01 = Key-based Pairing Response |
| 1 - 6 | uint48 |
Indirizzo pubblico (BR/EDR) del provider | varia |
| 7 - 15 | Valore casuale (salt) | varies |
Tabella 1.3: risposta non elaborata. Criptata per produrre la risposta criptata nella Tabella 1.4.
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 -15 | uint128 |
Risposta criptata | varies |
Tabella 1.4: risposta criptata, inviata dal provider al seeker tramite una notifica.
Caratteristica: passkey
Questa caratteristica viene utilizzata durante la procedura di accoppiamento basato su chiavi.
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0-15 | uint128 |
Blocco di passkey criptato | varia |
Tabella 2.1: blocco di passkey criptato. Per l'utilizzo, consulta la procedura di accoppiamento basato su chiavi.
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 | uint8 |
Tipo di messaggio | Un elemento tra:
|
| 1 - 3 | unit32 |
Passkey di 6 cifre | varies |
| 4 - 15 | Valore casuale (salt) | varia |
Tabella 2.2: blocco di passkey non elaborato. Versione decrittografata della Tabella 2.1.
Caratteristica: chiave dell'account
Dopo l'accoppiamento, il Seeker di Accoppiamento rapido scrive una chiave account nel Provider di Accoppiamento rapido.
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0-15 | uint128 |
Chiave dell'account (criptata) | varia |
Quando riceve una richiesta di scrittura, il provider di Accoppiamento rapido deve:
- Decripta la chiave dell'account utilizzando il secret condiviso generato nel passaggio 4 della procedura.
- Per i fornitori che richiedono una cauzione (comune):
- Prima di decriptare, verifica che il secret condiviso sia stato utilizzato per decriptare la richiesta di passkey del passaggio 12. Se questo passaggio non è stato superato utilizzando questo secret, ignora questa scrittura e esci.
- A questo punto, il secret condiviso (K nella procedura) non verrà più utilizzato per questo accoppiamento. Tutte le richieste criptate con questa chiave che arrivano senza riavviare la procedura devono essere rifiutate.
- Per i fornitori che richiedono una cauzione (comune):
- Verifica che il valore decriptato inizi con
0x04o0xFF. In caso contrario, ignora questa scrittura e chiudi.- Se il valore è
0x04:- Controlla se l'elenco delle chiavi dell'account persistente ha spazio per il nuovo valore.
- In caso contrario, elimina dall'elenco il valore utilizzato meno di recente.
- Aggiungi il nuovo valore all'elenco.
- Se il valore è
0xFF:- Considera questa sessione di accoppiamento come temporanea e non eseguire alcuna operazione.
- Questo può accadere con il flusso Scrittura retroattiva della chiave dell'account.
- Non memorizzare la chiave e non utilizzarla nell'elenco delle chiavi account, nella crittografia o nei calcoli MAC.
- La rimozione del bond viene attivata da un evento o un timeout specifico della funzionalità. Per la condivisione audio LE, è vivamente consigliato rimuovere l'accoppiamento BLE e la chiave di collegamento 10 minuti dopo la disconnessione della sessione temporanea.
- Se il valore è
Le chiavi account nell'elenco vengono utilizzate durante l'accoppiamento basato su chiavi.
Caratteristica: revisione firmware
Questa caratteristica consente al richiedente di leggere la revisione del firmware del fornitore in base alle esigenze. Dovrebbe sempre restituire i seguenti dati:
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 - var | utf8s |
Codice di revisione del firmware | varies |
Deve essere incapsulato in una singola stringa UTF-8 anche se è presente più di un firmware (ad es. 3 firmware per l'auricolare sinistro, l'auricolare destro e la custodia) sul fornitore. Il fornitore può anche restituire le stringhe specifiche per casi speciali:
status-updating: se il Provider è in fase di aggiornamento a un nuovo firmware. In alternativa, il Provider potrebbe restituire la versione del firmware di gestione temporanea.
status-abnormal: se il provider è in uno stato anomalo. Ad esempio, si è verificato un malfunzionamento perché l'aggiornamento del firmware non è riuscito. Questo valore farà sì che il Seeker mostri un messaggio per informare l'utente che deve essere aggiornato ora.
Il fornitore deve limitare l'accesso alla caratteristica Revisione firmware per impedire il monitoraggio del dispositivo. Limitazioni suggerite:
- i dispositivi accoppiati devono avere accesso in qualsiasi momento
- qualsiasi dispositivo deve avere accesso quando il Provider è rilevabile
Se il Provider supporta Find Hub, è necessaria un'implementazione aggiuntiva. Per maggiori dettagli, consulta la sezione Aggiornamenti firmware di Find Hub.
Caratteristica: dati aggiuntivi
Questo servizio deve avere la seguente caratteristica.
| Caratteristica del servizio di accoppiamento rapido | Criptato | Autorizzazioni | UUID |
|---|---|---|---|
| Dati | No | Scrivere e inviare una notifica | FE2C1237-8366-4814-8EB0-01DE32100BEA |
| Vecchia caratteristica del servizio Accoppiamento rapido (da ritirare il 1° gennaio 2021) | Criptato | Autorizzazioni | UUID |
|---|---|---|---|
| Dati | No | Scrivere e inviare una notifica | 0x1237 |
Prima di scrivere o inviare una notifica a questa caratteristica, deve essere
eseguito un handshake tramite la caratteristica FE2C1234-8366-4814-8EB0-01DE32100BEA per avere
un segreto condiviso. AES-CTR verrà utilizzato per criptare i dati che passano attraverso questa caratteristica, il cui algoritmo è definito di seguito. Questa modalità è più sicura per i dati che si estendono oltre un singolo blocco di 16 byte. HMAC-SHA256 verrà utilizzato per garantire l'integrità dei dati, definita anche di seguito.
| Ottetto | Descrizione | Valore |
|---|---|---|
| abbastanza | I primi 8 byte di HMAC-SHA256. | varies |
| 8 - 15 | Nonce, utilizzato dalla crittografia AES-CTR. | varies |
| 16 - var | Dati criptati. | varie |
Tabella 3.1: pacchetto di dati, inviato dal Fornitore al Richiedente tramite una notifica o inviato dal Richiedente al Fornitore tramite una scrittura.
| Ottetto | Tipo di dati | Descrizione | Valore |
|---|---|---|---|
| 0 - var | byte array |
Dati | varies, decodificalo in base all'ID dati della Tabella 1.2.2:
|
Tabella 3.2: dati non elaborati. Decriptati dai dati criptati nella Tabella 3.1.
Quando viene richiesta una notifica (ad es. richiesta di nome personalizzato tramite il bit 2 nella tabella 1.2.1), il fornitore di accoppiamento rapido deve:
- Genera 8 byte casuali crittograficamente per il nonce.
Cripta i dati utilizzando AES-CTR, dove ogni blocco di 16 byte viene generato utilizzando
encryptedBlock[i] = clearBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))dove
- La chiave AES è il secret condiviso del passaggio 4 della procedura.
- clearBlock[i] è un blocco da 16 byte che inizia da data[i * 16]. L'ultimo blocco può essere inferiore a 16 byte.
Esegui concat(encryptedBlock[0], encryptedBlock[1],…) per creare i dati criptati.
Genera HMAC-SHA256 per
sha256(concat((K ^ opad), sha256(concat((K ^ ipad), concat(nonce, encrypted_data)))))dove
- K viene generato da concat(shared_secret, 48-byte ZEROs), dove shared_secret proviene dal passaggio 4 della procedura.
- opad è un riempimento esterno di 64 byte, costituito da byte ripetuti con valore
0x5C. - ipad è un padding interno di 64 byte, costituito da byte ripetuti con valore
0x36.
Prendi i primi 8 byte di HMAC-SHA256 come prefisso del pacchetto di dati.
Quando riceve una richiesta di scrittura, il provider di accoppiamento rapido deve:
- Verifica l'integrità dei dati controllando i primi 8 byte di HMAC-SHA256.
Decripta i dati criptati utilizzando AES-CTR, dove ogni blocco viene generato utilizzando
clearBlock[i] = encryptedBlock[i] ^ AES(key, concat((uint8) i, 0x00000000000000, nonce))dove
- encryptedBlock[i] è un blocco di 16 byte che inizia da encrypted_data[i * 16]. L'ultimo blocco può essere inferiore a 16 byte.
- La chiave AES viene generata o identificata dall'handshake, ad esempio
- Nel flusso di denominazione 1, proviene da ECDH e non verrà utilizzato di nuovo per questo accoppiamento. Tutte le richieste che arrivano criptate con questa chiave senza riavviare la procedura devono essere rifiutate.
- nel flusso di denominazione 2, è la chiave dell'account.
Esegui concat(clearBlock[0], clearBlock[1],…) per creare i dati non elaborati.