Appareil Bluetooth Low Energy (BLE)
L'implémentation du service Google Association express (GFPS) pour les appareils BLE est compatible avec la spécification Bluetooth Core v4.2 ou version ultérieure.
L'avenant suivant à la spécification Fast Pair permettra la prise en charge des appareils à basse consommation (LE) uniquement et à basse consommation audio (LEA) dans GFPS.
Niveaux de conformité
Les mots clés "shall", "must", "will", "should", "may" et "can" mentionnés dans la spécification sont expliqués ci-dessous :
| Terme | Description |
|---|---|
| doit | est requis pour : utilisé pour définir les exigences. |
| doit | est utilisé pour exprimer : une conséquence naturelle d'une exigence obligatoire précédemment énoncée OU une affirmation factuelle indiscutable (toujours vraie, quelles que soient les circonstances). |
| sera | il est vrai que : n'est utilisé que dans les déclarations de faits. |
| should | est recommandé : utilisé pour indiquer que, parmi plusieurs possibilités, l'une est recommandée comme particulièrement adaptée, mais pas obligatoire. |
| mai | est autorisé à : utilisé pour autoriser des options. |
| peut | est capable de : utilisé pour établir un lien de causalité entre les énoncés. |
Caractéristique d'association basée sur une clé
Message de l'utilisateur au fournisseur
La requête brute type 0x00 de la caractéristique d'association basée sur une clé utilise le bit 4 pour indiquer si le chercheur est compatible avec la spécification des appareils BLE et le bit 5 pour indiquer s'il est compatible avec LE Audio.
| Octet | Type de données | Description | Valeur | Obligatoire ? |
|---|---|---|---|---|
| 0 | uint8 |
Type de message | 0x00 = Demande d'association basée sur une clé |
Obligatoire |
| 1 | uint8 |
Indicateurs
|
varies | Obligatoire |
| 2 - 7 | uint48 |
Soit :
|
varies | Obligatoire |
| 8 - 13 | uint48 |
Adresse BR/EDR du demandeur | varies | Présent uniquement si le bit 1 ou 3 des indicateurs est défini |
| n – 15 | Valeur aléatoire (salt) | varies | 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 d'association basée sur une clé peut être utilisé pour fournir des options d'association supplémentaires au demandeur.
| Octet | Type de données | Description | Valeur |
|---|---|---|---|
| 0 | uint8 |
Type de message | 0x02 = Réponse étendue à l'association basée sur une clé |
| 1 | uint8 |
Indicateurs
|
varies |
| 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 blocs en AES-CTR si le nombre est supérieur ou égal à 3) |
varies |
| 3-8 ou 3-14 |
|
varies | |
| 9 – 15 ou 15 | Valeur aléatoire (salt) | varies |
Un fournisseur compatible avec la spécification des appareils BLE doit lire les bits 4 et 5 pour comprendre les capacités du chercheur.
- Lorsque le bit 4 est défini sur 0, le fournisseur doit ignorer le bit 5 et répondre au format
type 0x01. - Lorsque le bit 4 est défini sur 1,
- Pour un fournisseur LE uniquement, la réponse doit être
type 0x02pour indiquer la préférence d'association LE. - Pour un fournisseur en mode double, il peut répondre avec
type 0x02pour indiquer une préférence d'association BR/EDR ou LE.
- Pour un fournisseur LE uniquement, la réponse doit être
- Pour les cas de fournisseur en mode double LE Audio (LEA), consultez Exemple : Association avec un fournisseur en mode double LEA pour référence.
Caractéristique PSM (Protocol Service Multiplexor) du flux de messages
Pour prendre en charge le flux de messages pour les appareils BLE, l'Association express établira et maintiendra un canal BLE L2CAP pour l'envoi et la réception de messages. Association express Le serveur L2CAP doit implémenter le contrôle de flux basé sur le crédit LE.
Cette caractéristique permet au Seeker de lire la valeur PSM, puis d'établir une connexion L2CAP sécurisée par la valeur PSM.
| Caractéristique du service Association express | Chiffré | Autorisations | UUID |
|---|---|---|---|
| PSM du flux de messages | Oui | Lecture | FE2C1239-8366-4814-8EB0-01DE32100BEA |
| Octet | Type de données | Description | Valeur |
|---|---|---|---|
| 0 | uint8 |
État
|
varies |
| 1 - 2 | uint16 |
La valeur PSM doit être comprise entre 0x80 et 0xFF. | varies |
Remarque : Pour TWS, il existe deux composants : principal et secondaire. Le rôle de ces composants est interchangeable dans certaines conditions. En supposant que A soit le composant principal et B le composant secondaire, en raison de la décharge de la batterie du composant A , le composant B doit assumer le rôle de composant principal. Ce scénario est appelé role switch.
Après role switch, si le fournisseur ne peut pas gérer le flux de messages Association express, il doit déconnecter de manière proactive la connexion L2CAP existante. Le détecteur Association express peut ensuite rétablir la connexion au flux de messages L2CAP avec le nouveau composant principal.
Caractéristique supplémentaire des clés d'accès
Cette caractéristique vise à fournir une protection MITM sur les composants supplémentaires.
Protection MITM pour les faux membres CSIS
L'Association express nécessite une protection MITM dans le cadre de la procédure d'association. Étant donné que CSIS ne fournit pas de protection MITM, la conception actuelle de FP pour plusieurs composants doit être étendue pour fournir une protection MITM sur les composants supplémentaires.
Définition des caractéristiques
| Caractéristique du service Association express | Chiffré | Autorisation | UUID |
|---|---|---|---|
| Clé d'accès supplémentaire | Oui | Lire,écrire,notifier | FE2C123A-8366-4814-8EB0-01DE32100BEA |
Messages
Le format du message est appliqué aux opérations de lecture, d'écriture et de notification.
Format des données chiffrées
Les données chiffrées sont envoyées à l'aide de la connexion GATT de l'Association express.
| Octet | Type de données | Description | Valeur |
|---|---|---|---|
| 0-15 | uint128 | Bloc de clés d'accès supplémentaires chiffré | Variable |
Format des données brutes
Une fois les données chiffrées déchiffrées à l'aide du secret partagé, le format est le suivant :
| Octet | Type de données | Description | Valeur |
|---|---|---|---|
| 0 | uint8 | Type de message | l'un des
|
| 1-3 | uint24 | Clé d'accès à six chiffres | Variable |
| 4-9 | uint48 | Adresse du composant d'association cible | Variable |
| 10 | uint8 | Code d'état (utilisé uniquement par l'opération de lecture) | Une des
|
| 11-15 | Valeur aléatoire (salt) | Variable |
Le composant principal (premier composant associé) sert de pont entre le détecteur Association express et les autres composants associés. La caractéristique doit respecter les consignes suivantes :
- Lorsqu'il reçoit une requête d'écriture de Fast Pair Seeker, le fournisseur doit
- Définir l'adresse du composant en cours d'association
- Envoyer la clé d'accès au composant en cours d'association
- Définir le code d'état sur "En attente", 0x01
- Lorsqu'il reçoit une demande de lecture avant de recevoir la clé d'accès du composant en cours d'association, le fournisseur doit renvoyer un message avec
- Clé d'accès, n'importe quelle valeur
- Adresse du composant en cours d'association
- Code d'état "En attente", 0x01
- Avant que le fournisseur n'envoie une notification à Fast Pair Seeker, il définit le résultat de la demande de lecture avec
- .
- Clé d'accès du composant en cours d'association
- Adresse du composant en cours d'association
- Code d'état de réussite, 0x00
- En cas d'erreur irrécupérable du côté du fournisseur, définissez le résultat sur
- Clé d'accès, n'importe quelle valeur
- Adresse du composant en cours d'association
- Code d'état d'échec, 0x02
Pour en savoir plus, consultez les schémas 1 et 2 sur les attaques MITM.
Configuration requise pour les appareils LE
LE Advertising
En mode détectable ou non détectable, le Fournisseur doit utiliser RPA pour diffuser les données Fast Pair.
Capacité de liaison
Pour les appareils compatibles LE, le demandeur doit créer une association avec la connexion LE existante. Une fois la validation de l'association basée sur une clé Association express réussie, le Fournisseur doit autoriser l'association avec l'APR et définir la capacité d'E/S sur DisplayYesNo pour la validation de la clé d'accès Association express.
Configuration requise pour les appareils LEA
LEA Advertising
Pour les appareils à double mode : Pour le mode détectable, le fournisseur doit diffuser les données Association express avec l'adresse d'identité. En mode non détectable, le Fournisseur doit diffuser les données de l'Association express avec RPA. Il est fortement recommandé d'utiliser l'ancienne publicité (BT 4.2) pour prendre en charge les anciens appareils et assurer la rétrocompatibilité. Il est nécessaire de modifier l'IRK chaque fois que la configuration d'usine de l'appareil est rétablie.
Pour les appareils non double mode : Pour le mode détectable ou non détectable, le fournisseur doit utiliser la publicité étendue (BT 5.0) avec RPA pour diffuser les données Fast Pair.
La publicité connectable LE contenant des données de service FP doit inclure CAS UUID conformément aux exigences du Bluetooth Adapter Profile (BAP 1.0.1) et du Common Audio Profile.
Le fournisseur peut indiquer la capacité LEA en incluant le CAS UUID (0x1853) dans les données de service (type AD 0x16) ou dans les UUID de classe de service de 16 bits (type AD 0x02 ou 0x03), quel que soit le mode détectable.
Pour les annonces non détectables, si l'espace disponible dans les anciennes annonces est insuffisant en raison de l'inclusion des données de batterie et SASS, il est obligatoire d'inclure l'UUID CAS dans la réponse d'analyse.
Capacité de liaison des agences de sécurité
Le demandeur doit créer un lien avec la connexion LE existante. Après avoir réussi la validation de l'association basée sur une clé Association express, le fournisseur à double mode doit autoriser l'association avec l'adresse d'identité et l'adresse RPA, tandis que le fournisseur sans double mode doit autoriser l'association avec l'adresse RPA et définir la capacité d'E/S sur "DisplayYesNo" pour la validation du code secret Association express.
Canal de communication interne entre les composants
La connexion GATT existante est conservée pour effectuer la protection MITM sur les composants supplémentaires. Le composant associé principal doit gérer la distribution des messages entre le demandeur d'association express et ses composants restants.
La communication interne est utilisée pour Initial Pair et Subsequent Pair.
- Lorsque la procédure d'association basée sur une clé réussit sur le composant principal, celui-ci doit envoyer un message pour modifier la capacité d'E/S de ses composants restants.
- Une fois l'association express terminée, le composant principal doit envoyer un message pour réinitialiser la capacité d'E/S de ses composants restants.
- Lors de l'exécution de la procédure de clé d'accès supplémentaire, le composant principal doit gérer la transmission des clés d'accès entre le détecteur Association express et ses composants restants.
Modifier la capacité d'E/S
- Passer de la capacité d'E/S à DisplayYesNo lorsque la procédure d'association basée sur une clé est réussie
- Si l'appareil comporte plusieurs composants, ils doivent tous être définis sur DisplayYesNo.
- Une exception à la règle selon laquelle le fournisseur ne doit pas modifier la capacité d'E/S en DisplayYesNo est
Retroactive Pair, dont le bit 3 de la demande d'association basée sur une clé est défini sur 1. Consultez Message du demandeur au fournisseur.
- Rétablir le paramètre par défaut de la capacité d'E/S
- Association initiale
- Si la connexion LE est déconnectée, mettez fin à la session Association express.
- Une fois le serveur principal associé, si aucune autre demande d'écriture de clé d'accès n'est reçue dans les 15 secondes, la session Association express se termine.
- Si une demande d'écriture de clé d'accès supplémentaire est reçue et que le composant à associer n'est pas associé dans les 15 secondes, mettez fin à la session Association express.
- Une fois tous les composants associés, si aucune demande d'écriture de clé de compte n'est effectuée dans les 15 secondes, mettez fin à la session Association express.
- Une fois la demande d'écriture de la clé de compte reçue, définissez un délai de 15 secondes pour mettre fin à la session Association express.
- Association ultérieure
- Si la connexion LE est déconnectée, mettez fin à la session Association express.
- Une fois le serveur principal associé, si aucune autre demande d'écriture de clé d'accès n'est reçue dans les 15 secondes, mettez fin à la session Association express.
- Si une demande d'écriture de clé d'accès supplémentaire est reçue et que le composant à associer n'est pas associé dans les 15 secondes, mettez fin à la session Association express.
- Lorsque tous les composants sont liés, mettez fin à la session Association express.
- Association initiale
Masquer l'indication de l'UI
Lorsque le casque n'est pas prêt à être associé, le fournisseur doit utiliser type 0b0010 pour définir l'indication de masquage de l'UI pour les données de clé de compte afin d'indiquer au demandeur de ne pas afficher l'UI d'association ultérieure (voir Charge utile de l'annonce : données de compte Association express).
Configuration requise pour les appareils LE Audio
Conditions requises pour le Bluetooth
Consultez Recommandations concernant les casques LE Audio pour Android.
Assistance CTKD
Pour les appareils à double mode, le CTKD de LE à BR/EDR est obligatoire et conforme aux exigences du BAP.
Annonce de la cible
Un périphérique doit utiliser une annonce ciblée pour solliciter une connexion à un appareil central associé. Les annonces ciblées sont définies dans BAP et CAP pour la gestion des connexions conformément au tableau 8.4 de CAP 1.0 (p. 48/58).
Compatibilité avec le serveur GATT EATT
EATT permet à l'appareil central d'envoyer plusieurs transactions GATT en parallèle lorsque l'appareil est associé. Pour l'appareil compatible avec CSIP, les performances de connexion du profil seront améliorées, puis la procédure d'association CSIP commencera bientôt pour les autres écouteurs.
Mise en cache robuste GATT (fortement recommandée)
Si le fournisseur n'est pas un appareil unique, mais un ensemble coordonné avec une implémentation CSIP, pour réduire le nombre de découvertes de services et accélérer la connexion, le fournisseur doit implémenter la mise en cache GATT définie dans Bluetooth 5.1.
Exigences liées à l'Association express
LE Advertising
En mode détectable ou non détectable, si l'appareil comporte plusieurs composants, les données Association express doivent être annoncées par le composant principal. Si l'appareil n'est pas prêt pour l'association ultérieure, le composant secondaire peut diffuser des données Association express pour des fonctionnalités étendues. Consultez Masquer l'indication de l'UI.
Visibilité du service GATT
La base de données GATT doit être identique pour toutes les connexions GATT de transport LE. Le service LE Audio (0x184E) doit être inclus dans la base de données GATT de la connexion Association express.
Exemple : Association avec un fournisseur LEA en mode double
Scénario 1 : Lorsque le Seeker n'est pas compatible avec LEA
Le Fournisseur doit être rétrocompatible avec le Demandeur qui ne prend pas en charge LEA.
Composants
- Fournisseur : A2DP/HFP/LEA
- Seeker : A2DP/HFP
Comportement attendu pour l'association initiale / ultérieure
- Le fournisseur annonce les données du service Association express (0xFE2C) avec l'adresse d'identité (initiale) ou l'adresse RPA (ultérieure).
- Utiliser l'ancienne version de la publicité
- Le demandeur reçoit l'annonce du fournisseur avec l'adresse d'identité pour le premier appairage ou le RPA pour les appairages ultérieurs.
- Le demandeur envoie une demande d'association basée sur une clé
- Le bit 5 du flag de la requête d'association basée sur une clé est défini sur 0.
- Le fournisseur envoie une réponse d'association basée sur une clé avec une adresse publique dans l'un des formats suivants :
- Si le type de message 0x01 est utilisé, l'adresse doit être une adresse publique.
- Si le type de message 0x02 est utilisé
- Le bit 0 doit être défini sur 0.
- Le bit 1 doit être défini sur 0.
- L'adresse doit être une adresse publique.
- Le demandeur crée une liaison 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 de la clé d'accès Association express.
Scénario 2 : Lorsque le Seeker est compatible avec LEA
Composants
- Fournisseur
- Compatible avec A2DP/HFP/LEA
- Composant unique
- Seeker
- SupportA2DP/HFP/LEA
Comportement attendu pour l'association initiale / ultérieure
- Le fournisseur annonce les données du service Association express (0xFE2C) avec l'adresse d'identité (initiale) ou l'adresse RPA (ultérieure).
- Utiliser l'ancienne version de la publicité
- Le demandeur envoie une demande d'association basée sur une clé
- Le bit 5 du flag de la requête d'association basée sur une clé est défini sur 1.
- Le fournisseur envoie une réponse d'association basée sur une clé avec le type de message 0x02.
- Le bit 0 doit être défini sur 0.
- Le bit 1 doit être défini sur 1.
- L'adresse est l'adresse de l'identité
- Le demandeur crée un lien avec la connexion LE existante sur le transport LE.
- 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 de la clé d'accès Association express.
Scénario 3 : lorsque le Seeker prend en charge la LEA et que le CSIP est impliqué
Composants
- Fournisseur
- Compatible avec A2DP/HFP/LEA
- Plusieurs composants
- Le composant principal est BR/EDR/LE.
- Le composant secondaire est réservé à LE
- Seeker
- Compatible avec A2DP/HFP/LEA
Comportement attendu pour l'association initiale / ultérieure
- Le composant principal annonce les données du service Association express (0xFE2C) avec l'adresse d'identité (initiale) ou l'adresse RPA (ultérieure).
- Utiliser l'ancienne version de la publicité
- Le demandeur envoie une demande d'association basée sur une clé au composant principal.
- Le bit 5 du flag de la requête d'association basée sur une clé est défini sur 1.
- Le composant principal envoie une réponse d'association basée sur une clé avec le type de message 0x02.
- Le bit 0 doit être défini sur 0.
- Le bit 1 doit être défini sur 1.
- Voici les adresses :
- La première adresse est l'adresse d'identité du composant principal.
- La deuxième adresse est l'adresse associable du composant secondaire. Le deuxième composant utilise également cette adresse pour la publicité CSIP.
- Le demandeur crée un lien avec le composant principal 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 chercheur crée un lien avec le composant secondaire dont l'adresse provient de la réponse étendue de l'association basée sur une clé.
- La capacité d'E/S doit être "DisplayYesNo". Sinon, la demande d'association doit être refusée.
- Le demandeur et le fournisseur doivent suivre la procédure de protection MITM pour associer le composant secondaire. Le fournisseur doit implémenter les deux scénarios suivants :
- Le Seeker attend d'être associé au composant secondaire.
Diagramme séquentiel pour MITM
Cette session décrit la séquence de la procédure de protection contre les attaques MITM.
Obtenir la clé d'accès du composant associé par notification
Obtenir la clé d'accès à partir du composant en cours d'association par lecture
Problème connu
FP pour LEA a été optimisé pour fonctionner avec Android V(Android 15).
À l'inverse, nous avons rencontré de nombreux problèmes avec des casques compatibles avec LEA, mais qui ne disposent pas de la bonne implémentation Association express sur LEA (c'est-à-dire uniquement Association express sur Classic). Par exemple, lorsque le RPA du fournisseur n'est pas généré par la bonne clé de résolution d'identité (IRK) et que l'adresse ne peut pas être résolue. Bien que nous n'ayons pas pu tester une liste complète de configurations de casques, nos tests limités ont révélé divers problèmes, y compris l'échec de l'affichage des notifications de batterie des écouteurs, l'absence de fonctionnalité de commutation audio (SASS), des échecs d'association initiaux et ultérieurs généralisés, et plus encore.
Nous conseillons donc vivement aux partenaires d'implémenter la spécification Fast Pair-LEA pour les nouveaux appareils et les appareils existants sur le terrain (via des mises à jour OTA) compatibles avec les modes doubles.