Appareil Bluetooth à basse consommation (BLE)
L'implémentation du service d'association express de Google (GFPS) pour les appareils BLE est compatible avec la spécification Bluetooth Core 4.2 ou version ultérieure.
L'avenant suivant à la spécification de l'Association express autorise la compatibilité pour les appareils à basse consommation (LE) uniquement et les appareils audio à basse consommation (LEA) dans GFPS.
Niveaux de conformité
Les mots clés "devra", "doit", "va", "devrait", "peut" et "peut" mentionnés dans la spécification sont expliqués ci-dessous:
| Terme | Description |
|---|---|
| doit | est obligatoire pour : permet de définir les exigences. |
| doit | est utilisé pour exprimer: une conséquence naturelle d'une exigence obligatoire précédemment énoncée ; OU une déclaration de fait incontestable (qui est toujours vraie, quelles que soient les circonstances). |
| will | il est vrai que : ce terme n'est utilisé que dans des déclarations factuelles. |
| should | est recommandé que : utilisé pour indiquer que, parmi plusieurs possibilités, l'une est recommandée car elle est particulièrement adaptée, mais pas obligatoire. |
| mai | est autorisé à : utilisé pour autoriser des options. |
| peut | est capable de : utilisé pour établir un lien entre les énoncés et l'énoncé d'une manière causale. |
Caractéristique de la combinaison basée sur les clés
Message du demandeur au fournisseur
La requête brute type 0x00 de la caractéristique de paire basée sur les clés utilise le bit 4
pour indiquer si le Seeker prend en charge la spécification d'appareil BLE et utilise la
Bit 5 indiquant si le Seeker prend en charge LE Audio.
| Octet | Type de données | Description | Valeur | Obligatoire ? |
|---|---|---|---|---|
| 0 | uint8 |
Type de message | 0x00 = requête d'association basée sur une clé |
Obligatoire |
| 1 | uint8 |
Indicateurs
|
varie | Obligatoire |
| 2 – 7 | uint48 |
Soit:
|
varie | Obligatoire |
| 8 – 13 | uint48 |
Adresse BR/EDR du demandeur | varie | Présent uniquement si le bit 1 ou 3 d'indicateurs est défini |
| n - 15 | Valeur aléatoire (sel) | varie | Obligatoire |
Message du fournisseur au demandeur
Lorsque le bit 4 de la requête est défini, le nouveau message de réponse type 0x02 pour
La caractéristique de paire basée sur les clés peut être utilisée pour fournir une liaison supplémentaire
options pour le Seeker.
| Octet | Type de données | Description | Valeur |
|---|---|---|---|
| 0 | uint8 |
Type de message | 0x02 = réponse étendue de couplage basé sur des clés |
| 1 | uint8 |
Indicateurs
|
varie |
| 2 | uint8 |
Nombre d'adresses du fournisseur (dans la version actuelle, le nombre est 1 ou 2, car nous devons modifier le mode de chiffrement par bloc sur AES-CTR si le nombre est supérieur ou égal à 3) |
varie |
| 3 - 8 ou 3 - 14 |
|
varie | |
| 9 - 15 ou 15 | Valeur aléatoire (sel) | varie |
Un fournisseur prenant en charge la spécification d'appareil BLE doit lire Bit 4 et Bit 5 pour comprendre ses capacités
- Lorsque le bit 4 est égal à 0, le fournisseur ignore le bit 5 et répond avec le format
type 0x01 - Lorsque le bit 4 est égal à 1,
- Dans le cas d'un fournisseur LE uniquement, il doit répondre par
type 0x02pour indiquer la préférence de liaison. - Pour le fournisseur en mode double, il peut répondre avec
type 0x02pour indiquer Préférence en matière d'association BR/EDR ou LE.
- Dans le cas d'un fournisseur LE uniquement, il doit répondre par
- Pour les cas d'utilisation du double mode fournisseur LE Audio (LEA), consultez l'article Exemple: association avec le fournisseur en mode double LEA pour référence
Caractéristiques du PSM (Protocol Service Multiplexor) de flux de messages
Afin de prendre en charge le flux de messages pour les appareils BLE, l'Association express établit et maintenir un canal BLE L2CAP pour envoyer et recevoir des messages. Association express Le serveur L2CAP mettra en œuvre un contrôle de flux basé sur le crédit LE.
Cette caractéristique permet au demandeur de lire la valeur PSM, puis d'établir une connexion L2CAP sécurisée par la valeur PSM.
| Caractéristique du service d'association express | Chiffré | Autorisations | UUID |
|---|---|---|---|
| PSM de flux de messages | Oui | Lire | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Octet | Type de données | Description | Valeur |
|---|---|---|---|
| 0 | uint8 |
État
|
varie |
| 1 - 2 | uint16 |
La valeur PSM doit être comprise entre 0x80 et 0xFF | varie |
Remarque:Pour TWS, il existe deux
principaux et secondaires. Le rôle de ces composants est
interchangeables dans certaines conditions. En supposant que A est l'élément principal et que B est
le composant secondaire, en raison de la décharge de la batterie du composant A , le composant B doit
pour qu'il assume le rôle de composant principal. Ce scénario s'appelle role switch.
Après role switch, si le fournisseur
ne peut pas gérer le flux de messages avec Association express, il doit déconnecter de manière proactive
une connexion L2CAP existante. L'utilisateur en quête de l'association express peut ensuite rétablir le L2CAP
la connexion du flux de messages au nouveau composant principal.
Caractéristiques supplémentaires de la clé d'accès
Cette caractéristique vise à fournir une protection MITM sur la couche supplémentaire composants.
Protection MITM pour les faux membres du CSIS
L'Association express nécessite une protection MITM lors de la procédure d'association. En tant que CSIS n'offre pas de protection MITM, la conception actuelle de FP pour plusieurs doit être étendu pour fournir une protection MITM sur le composants.
Définition des caractéristiques
| Caractéristique du service Association express | Chiffré | Autorisation | UUID |
|---|---|---|---|
| Clé d'accès supplémentaire | Oui | Lecture,écriture,notification | FE2C123A-8366-4814-8EB0-01DE32100BEA |
Messages
Le format de message est appliqué aux opérations de lecture, d'écriture et de notification.
Format de données chiffrées
Les données chiffrées sont envoyées via la connexion Fast Pair GATT.
| Octet | Type de données | Description | Valeur |
|---|---|---|---|
| 0-15 | uint128 | Bloc de clés d'accès chiffré supplémentaire | Variable |
Format de données brutes
Après avoir déchiffré les données chiffrées à l'aide d'une clé secrète partagée, le format est le suivant :
| Octet | Type de données | Description | Valeur |
|---|---|---|---|
| 0 | uint8 | Type de message | au choix :
|
| 1-3 | uint24 | Clé d'accès à 6 chiffres | Variable |
| 4-9 | uint48 | Adresse du composant de liaison cible | Variable |
| 10 | uint8 | Code d'état, utilisé uniquement par les opérations de lecture | Au choix :
|
| 11-15 | Valeur aléatoire (sel) | Variable |
Le principal (premier composant lié) est le pont entre l'Association express Chercheur et composants supplémentaires de liaison. La caractéristique doit suivez les consignes suivantes:
- À la réception d'une requête d'écriture de la part d'un chercheur en combinaison express, le Fournisseur doit
- Définir l'adresse du composant en cours de liaison
- Envoyer la clé d'accès au composant en cours de liaison
- Définir le code d'état sur "En attente", 0x01
- Lors de la réception d'une requête de lecture avant de recevoir une clé d'accès du composant
le Fournisseur doit renvoyer un message contenant
- Clé d'accès, n'importe quelle valeur
- Adresse du composant en cours de liaison
- Code d'état en attente, 0x01
- Définit le résultat avant que le fournisseur n'envoie la notification au demandeur d'Association express
pour la requête de lecture avec
- Clé d'accès du composant en cours de liaison
- Adresse du composant en cours de liaison
- Code d'état de réussite, 0x00
- En cas d'erreur irrécupérable côté fournisseur, définissez le résultat
- Clé d'accès, n'importe quelle valeur
- Adresse du composant en cours de liaison
- Code d'état de l'échec, 0x02
Consultez le schéma MITM 1 et Pour en savoir plus, consultez le schéma MITM 2.
Configuration requise pour les appareils LE
LE Advertising
Pour le mode détectable ou non visible, le fournisseur doit utiliser la RPA pour pour annoncer les données FastPair.
Capacité de liaison
Pour les appareils compatibles LE, le Seeker doit créer une liaison avec les LE Connection. Une fois la vérification de l'association basée sur les clés par Association express effectuée, le Le fournisseur doit autoriser la liaison avec la RPA et définir la capacité d'E/S sur DisplayYesNo pour valider les clés d'accès pour l'Association express.
Configuration requise pour l'appareil LEA
LEA Advertising
Pour les appareils en mode double: Pour le mode visible, le Fournisseur doit diffuser des annonces pour les données Association express avec des adresse e-mail. Pour le mode non visible, le Fournisseur doit annoncer les données de l'Association express avec la RPA. Nous vous recommandons vivement d'utiliser l'ancienne publicité (BT 4.2) pour prendre en charge pour assurer la rétrocompatibilité. Vous devez modifier IRK chaque fois que la configuration d'usine de l'appareil est rétablie.
Pour les appareils qui ne sont pas en mode double: Pour le mode "visible" ou "non visible", le Fournisseur doit utiliser (BT 5.0) à l'aide d'une RPA pour annoncer les données FastPair.
L'annonce LE Connectable contenant des données du service FP doit inclure : UUID CAS conformément aux Bluetooth Adapter Profile (BAP 1.0.1) et Profil audio courant cette exigence. Pour les publicités non visibles, si l'espace disponible est insuffisant dans l'ancienne publicité en raison de l'inclusion des données sur la batterie et les données SASS, est obligatoire pour inclure l'UUID CAS dans la réponse d'analyse dans ce cas.
Capacité de liaison LEA
Le Seeker doit créer une liaison avec la connexion LE existante. Après avoir réussi vérification de l'Association express basée sur des clés, le Fournisseur doit autoriser l'association à l'adresse d'identité et au RPA alors que le Fournisseur n'utilise pas le mode double, il doit autoriser l'association à la RPA et définir la capacité d'E/S sur DisplayYesNo pour l'Association express Validation des clés d'accès.
Canal de communication interne entre les composants
La connexion GATT existante est conservée pour assurer la protection MITM sur le composants supplémentaires. Le composant principal lié doit gérer le message les livraisons entre le chercheur de l'association express et ses autres composants.
La communication interne est utilisée pour Initial Pair et Subsequent Pair.
- Une fois la procédure de paire basée sur les clés effectuée sur le composant principal, envoie un message pour modifier la capacité d'E/S restante composants
- Une fois l'Association express terminée, le composant principal envoie un message pour réinitialiser Capacité d'E/S des autres composants
- Lors de l'exécution d'une procédure de clé d'accès supplémentaire, le composant principal gère Diffusions de clés d'accès entre le chercheur d'association express et ses autres composants
Délai de modification de la capacité d'E/S
- Remplacement de la capacité d'E/S par DisplayYesNo lorsque la procédure de couplage basé sur les clés a réussi.
- Si l'appareil est constitué de plusieurs composants, tous les composants doivent être définis sur DisplayYesNo
- Le Fournisseur doit faire exception
ne pas définir la capacité d'E/S sur DisplayYesNo est
Retroactive Pair, dont le bit 3 de requête de couplage basé sur les clés est défini sur 1, voir Message du demandeur au fournisseur
- Définir la fonctionnalité d'E/S sur le paramètre par défaut
- Association initiale
- Si la connexion LE est déconnectée, mettre fin à la session Association express
- Une fois l'instance principale liée, s'il n'y a pas d'autre écriture de clé d'accès requête dans 15 secondes, mettre fin à la session Association express
- Après réception d'une demande d'écriture de clé d'accès supplémentaire, si le composant l'association ne l'est pas dans les 15 secondes, mettre fin à la session Association express
- Une fois tous les composants associés, en l'absence d'écriture de clé de compte, requête dans les 15 secondes, mettre fin à la session Association express
- Après réception de la demande d'écriture de clé de compte, définissez un délai avant expiration de 15 secondes sur terminer la session Association express
- Association ultérieure
- Si la connexion LE est déconnectée, mettre fin à la session Association express
- Une fois l'instance principale liée, s'il n'y a pas d'autre écriture de clé d'accès requête dans les 15 secondes, mettre fin à la session Association express
- Après réception d'une demande d'écriture de clé d'accès supplémentaire, si le composant l'association ne l'est pas dans les 15 secondes, mettre fin à la session Association express
- Lorsque tous les composants sont liés, mettre fin à la session d'association express
- Association initiale
Masquer l'indication dans l'interface utilisateur
Lorsque le casque n'est pas prêt à être associé, le Fournisseur doit utiliser type 0b0010
définir une indication de masquage de l'interface utilisateur pour les données de la clé du compte afin d'indiquer au demandeur de ne pas afficher
UI d'association ultérieure (voir Charge utile publicitaire: données de compte Association express).
Configuration requise pour les appareils LE Audio
Configuration Bluetooth requise
Consultez les recommandations relatives aux casques Android et LE Audio.
Assistance CTKD
Pour les appareils à double mode, le CTKD de LE à BR/EDR est obligatoire et conforme à la BAP.
Annonce sur les cibles
Un périphérique périphérique doit utiliser une annonce ciblée pour solliciter une connexion à partir d'un appareil central couplé. Annonces ciblées définies dans BAP et CAP de la gestion des connexions conformément au tableau 8.4 CAP 1.0 (p. 48/58).
Assistance GATT EATT pour les serveurs
EATT permet à l'appareil central d'envoyer plusieurs transactions GATT en parallèle. lorsque l'appareil est associé. Pour l'appareil compatible avec la CSIP, elle augmentera les performances de la connexion de profil, avant de commencer à créer rapidement une liaison CSIP procédure pour les autres écouteurs.
Mise en cache robuste avec GATT (fortement recommandé)
Si le fournisseur n'est pas un appareil unique, mais un ensemble coordonné avec l'implémentation de la CSIP, afin de réduire le nombre de la recherche de services et à accélérer la connexion, le Fournisseur doit implémenter la mise en cache GATT définie dans le Bluetooth 5.1.
Configuration requise pour l'Association express
LE Advertising
Pour le mode détectable ou le mode non visible, si l'appareil possède plusieurs les données de l'Association express doivent être annoncées par le composant principal. Si le appareil n'est pas prêt pour une association ultérieure, le composant secondaire peut annoncent les données de l'Association express pour les fonctionnalités étendues. voir Masquer l'indication de l'interface utilisateur
Visibilité du service GATT
La base de données GATT doit être identique pour toutes les connexions GATT du transport LE. LE Audio (0x184E) doit être inclus dans la base de données GATT de la connexion Fast Pair.
Exemple: association à un fournisseur en mode double LEA
Scénario 1 – Lorsque le demandeur n'accepte pas LEA
Le Fournisseur doit disposer d'une rétrocompatibilité pour le demandeur qui n'a prend en charge LEA.
Composants
- Fournisseur: A2DP/HFP/LEA
- Chercheur: A2DP/HFP
Comportement attendu pour la paire initiale / la paire suivante
- Le fournisseur annonce le service Association express
(0xFE2C) par l'adresse d'identité (initiale) ou l'appel RPA (ultérieur).
- Utiliser l'ancienne version de la publicité
- Le demandeur reçoit les annonce avec l'adresse d'identité pour la première ou la RPA pour l'association ultérieure
- Le Seeker envoie une requête d'association basée sur une clé.
- L'indicateur bit-5 de la requête de couplage basé sur une clé est défini sur 0
- Le fournisseur envoie une réponse de couplage basée sur des clés avec une adresse publique dans l'une des
les éléments suivants:
- Si le type de message 0x01 est utilisé, l'adresse doit être une adresse publique
- Si le type de message 0x02 est utilisé
- Bit-0 doit être 0
- Bit-1 doit être 0
- L'adresse doit être publique
- The Seeker crée un lien avec le transport BR/EDR
- La capacité d'E/S est définie sur DisplayYesNo pour BR/EDR
- Le demandeur et le fournisseur effectuent la procédure de validation des clés d'accès par Association express
Scénario 2 – Lorsque le demandeur soutient LEA
Composants
- Fournisseur
- Compatible avec A2DP/HFP/LEA
- Composant unique
- Chercheur
- SupportA2DP/HFP/LEA
Comportement attendu pour la paire initiale / la paire suivante
- Le fournisseur annonce le service Association express
(0xFE2C) par l'adresse d'identité (initiale) ou l'appel RPA (ultérieur).
- Utiliser l'ancienne version de la publicité
- Le Seeker envoie une requête d'association basée sur une clé.
- L'indicateur bit-5 de la requête de couplage basé sur une clé est défini sur 1
- Le fournisseur envoie une réponse d'association basée sur des clés avec un message de type 0x02.
- Bit-0 doit être 0
- Bit-1 doit être 1
- L'adresse est l'adresse d'identité
- Le Seeker crée un lien avec le
Connexion LE sur LE Transport
- La direction CTKD va de LE à BR/EDR
- La capacité d'E/S est définie sur DisplayYesNo pour LE
- Le demandeur et le fournisseur effectuent la procédure de validation des clés d'accès par Association express
Scénario 3 : lorsque le demandeur apporte son soutien à la LEA et au CSIP
Composants
- Fournisseur
- Compatible avec A2DP/HFP/LEA
- Plusieurs composants
- L'élément principal est BR/EDR/LE
- Le composant secondaire est LE uniquement
- Chercheur
- Compatible avec A2DP/HFP/LEA
Comportement attendu pour la paire initiale / la paire suivante
- Le composant principal annonce l'Association express
les données de service (0xFE2C) avec l'adresse d'identité (initiale) ou l'adresse d'accès principale (RPA, ultérieure).
- Utiliser l'ancienne version de la publicité
- L'application Seeker envoie une requête d'association basée sur des clés au composant principal.
- L'indicateur bit-5 de la requête de couplage basé sur une clé est défini sur 1
- Le composant principal envoie une réponse d'association basée sur des clés avec un message de type 0x02.
- Bit-0 doit être 0
- Bit-1 doit être 1
- L'adresse est la suivante :
- La première adresse est l'adresse d'identité du composant principal.
- La deuxième adresse est l'adresse pouvant être associée pour le composant secondaire, Le second composant utilise également cette adresse pour diffuser des annonces CSIP.
- Le Seeker crée un lien avec le
sur la connexion LE existante
- La direction CTKD va de LE à BR/EDR
- La capacité d'E/S est définie sur DisplayYesNo pour LE
- Le Seeker crée un lien avec les
composant dont l'adresse provient d'une réponse étendue de couplage basé sur des clés
- La capacité d'E/S doit être "DisplayYesNo", sinon refuser la demande d'association
- Le demandeur et le fournisseur suivent la procédure de protection MITM pour associer le composant secondaire, le Fournisseur devra mettre en œuvre les deux scénarios
- L'utilisateur attend d'être lié au composant secondaire
Diagramme séquentiel pour MITM
Cette session vise à décrire la séquence de la procédure de protection MITM.
Obtenir la clé d'accès à partir du composant en cours d'association via une notification
Obtenir la clé d'accès à partir du composant en cours de liaison via la fonction de lecture
Problème connu
FP pour LEA a été optimisé pour fonctionner avec Android V.
À l'inverse, nous avons rencontré de nombreux problèmes avec les casques compatibles avec LEA. mais qu'il manque la bonne implémentation de l'Association express plutôt que LEA (c'est-à-dire que seule l'Association express utilise classique). Plus précisément, par exemple, lorsque le RPA du fournisseur n'est pas généré par la clé de résolution d'identité (IRK) correcte et que l'adresse ne peut pas être résolue. Nous n'avons pas pu tester une liste complète de casques nos tests limités ont révélé différents problèmes, y compris des défaillances pour afficher les notifications relatives à la batterie des écouteurs, absence de commutation audio (SASS) les échecs d'association initiaux et ultérieurs généralisés, etc.
Par conséquent, nous conseillons vivement aux partenaires d'implémenter l'approche Association express-LEA pour les nouveaux appareils et les appareils existants sur le terrain. (via des mises à jour Over The Air) compatibles avec le double mode.