Appareil Bluetooth à basse consommation (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 ultérieure.
L'avenant suivant à la spécification Association express permettra la prise en charge des appareils Low Energy (LE) uniquement et Low Energy 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 |
|---|---|
| shall | is required to (est requis pour) : permet de définir des exigences. |
| must | est utilisé pour exprimer : une conséquence naturelle d'une exigence obligatoire précédemment énoncée OU une déclaration de fait indiscutable (qui est toujours vraie, quelles que soient les circonstances). |
| will | it is true that (il est vrai que) : utilisé uniquement dans les énoncés de faits. |
| should | is recommended that (il est recommandé de) : utilisé pour indiquer que parmi plusieurs possibilités, l'une d'elles est recommandée comme étant particulièrement adaptée, mais pas obligatoire. |
| mai | is permitted to : permet d'autoriser des options. |
| peut | is able to (est capable de) : utilisé pour relier des instructions de manière causale. |
Caractéristique d'association basée sur une clé
Message du demandeur 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 de l'appareil BLE et le bit 5 pour indiquer si le chercheur 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 |
Options
|
varie | Obligatoire |
| 2 - 7 | uint48 |
Soit :
|
varie | Obligatoire |
| 8 - 13 | uint48 |
Adresse BR/EDR du chercheur | varie | Présent uniquement si le bit 1 ou 3 de l'indicateur est défini |
| n - 15 | Valeur aléatoire (salage) | 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 d'association basée sur une clé peut être utilisé pour fournir des options d'association supplémentaires au chercheur.
| 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 |
Options
|
varie |
| 2 | uint8 |
Nombre d'adresses du fournisseur (dans la version actuelle, le nombre est de 1 ou 2, car nous devons modifier le mode de chiffrement par bloc en 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 (salage) | varie |
Un fournisseur compatible avec la spécification des appareils BLE doit lire les bits 4 et 5 pour comprendre les fonctionnalité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, il doit répondre par
type 0x02pour indiquer sa préférence pour l'association LE. - Pour un fournisseur en mode double, il peut répondre par
type 0x02pour indiquer une préférence d'association BR/EDR ou LE.
- Pour un fournisseur LE uniquement, il doit répondre par
- Pour les cas de fournisseur en mode double LE Audio (LEA), consultez Exemple : Association avec un fournisseur en mode double LEA.
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 établit et maintient un canal BLE L2CAP pour l'envoi et la réception de messages. Le serveur L2CAP de l'Association express doit implémenter le contrôle de flux basé sur les crédits LE.
Cette caractéristique permet au Chercheur de lire la valeur PSM, puis d'établir une connexion L2CAP sécurisée à l'aide de la valeur PSM.
| Caractéristique du service d'Association express | Chiffré | Autorisations | UUID |
|---|---|---|---|
| PSM de flux de messages | Oui | Lecture | 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 : Les écouteurs sans fil se composent de deux éléments : un écouteur principal et un écouteur secondaire. Le rôle de ces composants est interchangeable dans certaines conditions. En supposant que A est le composant principal et B le composant secondaire, en raison de l'épuisement 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 de l'Association express, il doit déconnecter de manière proactive la connexion L2CAP existante. Le chercheur d'Association express peut ensuite rétablir la connexion du flux de messages L2CAP avec le nouveau composant principal.
Caractéristique supplémentaire de la clé d'accès
Cette caractéristique permet de fournir une protection contre les attaques de l'intercepteur sur les composants supplémentaires.
Protection contre les attaques MITM de faux membres CSIS
L'Association express nécessite une protection contre les attaques MITM dans le cadre de la procédure d'association. Comme 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 de la caractéristique
| Caractéristique du service d'Association express | Chiffré | Autorisation | UUID |
|---|---|---|---|
| Clé d'accès supplémentaire | Non | Lecture,écriture,notification | 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 via une connexion GATT d'Association express.
| Octet | Type de données | Description | Valeur |
|---|---|---|---|
| 0-15 | uint128 | Bloc de clé d'accès supplémentaire chiffré | Variable |
Format de données brutes
Après avoir déchiffré les données chiffrées à l'aide du secret partagé, le format est le suivant :
| Octet | Type de données | Description | Valeur |
|---|---|---|---|
| 0 | uint8 | Type de message | une des
|
| 1-3 | uint24 | Clé d'accès à six chiffres | Variable |
| 4-9 | uint48 | Adresse du composant de liaison cible | Variable |
| 10 | uint8 | Code d'état, utilisé uniquement par l'opération de lecture | Une
|
| 11-15 | Valeur aléatoire (salage) | Variable |
Le composant principal (premier composant associé) sert de pont entre le chercheur d'Association express et les composants associés supplémentaires. La caractéristique doit respecter les consignes suivantes :
- Lorsqu'il reçoit une requête d'écriture de la part du chercheur d'association express, le fournisseur doit :
- Définir l'adresse du composant en cours d'association
- Envoyez le code 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 de liaison
- Code d'état "En attente", 0x01
- Avant que le fournisseur n'envoie une notification au chercheur de l'Association express, il définit le résultat de la requête de lecture avec
- Clé d'accès du composant en cours d'association
- 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 d'échec, 0x02
Pour en savoir plus, consultez le diagramme MITM 1 et le diagramme MITM 2.
Configuration d'appareil requise pour l'édition limitée
LE Advertising
Pour le mode visible ou non visible, le fournisseur doit utiliser l'adresse RPA pour diffuser les données Fast Pair.
Capacité de liaison
Pour les appareils compatibles LE, le chercheur doit créer une liaison avec la connexion LE existante. Une fois la validation de l'association basée sur une clé d'Association express réussie, le fournisseur doit autoriser l'association avec l'adresse RPA et définir la fonctionnalité d'E/S sur DisplayYesNo pour la validation de la clé d'accès d'Association express.
Configuration requise pour les appareils LEA
LEA Advertising
Pour les appareils bimodes : En mode visible, le fournisseur doit annoncer les données d'Association express avec l'adresse d'identité. En mode non détectable, le fournisseur doit annoncer les données d'Association express avec une adresse privée résoluble (RPA). Il est fortement recommandé d'utiliser l'ancienne annonce (BT 4.2) pour assurer la rétrocompatibilité avec les appareils plus anciens. Il est nécessaire de modifier l'IRK chaque fois que l'appareil est réinitialisé.
Pour les appareils non bimodes : En mode visible ou non visible, le fournisseur doit utiliser la publicité étendue (BT 5.0) avec RPA pour diffuser les données Fast Pair.
L'annonce connectable LE contenant les données du service FP doit inclure l'UUID CAS conformément aux exigences du profil d'adaptateur Bluetooth (BAP 1.0.1) et du profil audio commun.
Le fournisseur peut indiquer la fonctionnalité LEA en incluant l'UUID CAS (0x1853) dans les données de service (type d'annonce 0x16) ou les UUID de classe de service 16 bits (type d'annonce 0x02 ou 0x03), quel que soit le mode visible.
Pour les annonces non détectables, si l'espace disponible dans l'annonce ancienne 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 LEA
Le Seeker doit créer une liaison avec la connexion LE existante. Une fois la validation de l'association basée sur une clé d'Association express réussie, le fournisseur en mode double doit autoriser l'association avec l'adresse d'identité et l'adresse privée résoluble (RPA), tandis que le fournisseur en mode non double doit autoriser l'association avec l'adresse privée résoluble (RPA) et définir la fonctionnalité d'E/S sur DisplayYesNo pour la validation de la clé d'accès d'Association express.
Canal de communication interne entre les composants
La connexion GATT existante est conservée pour assurer la protection MITM sur les composants supplémentaires. Le composant associé principal doit gérer la distribution des messages entre l'appareil de recherche d'Association express et ses autres composants.
La communication interne est utilisée pour Initial Pair et Subsequent Pair.
- Lorsque la procédure d'association basée sur une clé est transmise au 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 les livraisons de clés d'accès entre le chercheur d'association express et ses composants restants.
Temps de modification de la capacité d'E/S
- Changer la capacité d'E/S en DisplayYesNo lorsque la procédure d'association basée sur une clé est réussie
- Si l'appareil comporte plusieurs composants, tous les composants doivent être définis sur DisplayYesNo.
- Le fournisseur ne doit pas remplacer la fonctionnalité d'E/S par DisplayYesNo dans un cas exceptionnel :
Retroactive Pair, dont le bit 3 de la demande d'association basée sur une clé est défini sur 1 (voir Message du chercheur au fournisseur).
- Rétablir le paramètre par défaut de la capacité d'E/S
- Association initiale
- Si la connexion LE est interrompue, mettre fin à la session d'Association express
- Une fois l'appareil principal associé, s'il n'y a pas d'autre demande d'écriture de clé d'accès dans les 15 secondes, mettez fin à la session d'Association express.
- Après réception d'une demande d'écriture de clé d'accès supplémentaire, si le composant en cours d'association n'est pas associé dans les 15 secondes, mettez fin à la session d'Association express.
- Une fois tous les composants associés, s'il n'y a pas de demande d'écriture de clé de compte dans les 15 secondes, mettez fin à la session d'Association express.
- Une fois la demande d'écriture de la clé de compte reçue, définissez un délai avant expiration de 15 secondes pour mettre fin à la session d'Association express.
- Association ultérieure
- Si la connexion LE est interrompue, mettre fin à la session d'Association express
- Une fois l'appareil principal associé, s'il n'y a pas d'autre demande d'écriture de clé d'accès dans les 15 secondes, mettez fin à la session d'Association express.
- Après réception d'une demande d'écriture de clé d'accès supplémentaire, si le composant en cours d'association n'est pas associé dans les 15 secondes, mettez fin à la session d'Association express.
- Lorsque tous les composants sont associés, mettez fin à la session d'Association express
- Association initiale
Masquer l'indication de l'UI
Lorsque le casque n'est pas prêt pour l'association, 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 chercheur de ne pas afficher l'UI d'association suivante (voir Charge utile publicitaire : données de compte d'association express).
Configuration requise pour les appareils LE Audio
Conditions requises pour le Bluetooth
Consultez Android, recommandations concernant les casques LE Audio.
Compatibilité CTKD
Pour les appareils bimodes, la CTKD de LE vers BR/EDR est obligatoire et conforme aux exigences du BAP.
Annonce de la cible
Un périphérique doit utiliser l'annonce ciblée pour solliciter une connexion à partir d'un appareil central associé. Les annonces ciblées sont définies dans le BAP et le CAP pour la gestion des connexions conformément au tableau 8.4 (p. 48/58) de la spécification CAP 1.0.
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 le CSIP, cela améliorera les performances de la connexion du profil, puis lancera rapidement la procédure d'association CSIP pour les autres écouteurs.
Mise en cache robuste GATT (fortement recommandée)
Si le fournisseur n'est pas un seul appareil, mais un ensemble coordonné avec l'implémentation CSIP, pour réduire le nombre de fois où la découverte des services est effectuée 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 visible ou non visible, si l'appareil comporte plusieurs composants, les données de l'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 annoncer les données d'association express pour les fonctionnalités étendues. Consultez la section Masquer l'indication de l'interface utilisateur.
Visibilité du service GATT
La base de données GATT doit être la même 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 : Le chercheur n'est pas compatible avec l'assistant d'éducation locale
Le fournisseur doit être rétrocompatible avec le chercheur qui n'est pas compatible avec LEA.
Composants
- Fournisseur : A2DP/HFP/LEA
- Seeker : A2DP/HFP
Comportement attendu pour l'association initiale/l'association ultérieure
- Le fournisseur annonce les données du service Association express (0xFE2C) avec l'adresse d'identité (initiale) ou l'adresse privée résoluble (RPA, ultérieure).
- Utiliser l'ancienne version de la publicité
- Le chercheur reçoit l'annonce du fournisseur avec l'adresse d'identité pour l'association initiale ou l'adresse RPA pour l'association ultérieure.
- Le chercheur envoie une demande d'association basée sur une clé
- Le bit 5 de l'option 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 é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é
- Le bit 0 doit être égal à 0.
- Le bit 1 doit être défini sur 0
- L'adresse doit être une adresse publique
- Le Seeker crée une liaison avec le transport BR/EDR.
- La fonctionnalité d'E/S est définie sur DisplayYesNo pour BR/EDR
- Le chercheur et le fournisseur effectuent la procédure de validation de la clé d'accès de l'Association express.
Scénario 2 : Lorsque le Seeker est compatible avec LEA
Composants
- Fournisseur
- Compatibilité avec A2DP/HFP/LEA
- Composant unique
- Seeker
- Compatibilité : A2DP/HFP/LEA
Comportement attendu pour l'association initiale/l'association ultérieure
- Le fournisseur annonce les données du service Association express (0xFE2C) avec l'adresse d'identité (initiale) ou l'adresse privée résoluble (RPA, ultérieure).
- Utiliser l'ancienne version de la publicité
- Le chercheur envoie une demande d'association basée sur une clé
- Le bit 5 de l'indicateur 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 égal à 0.
- Le bit 1 doit être défini sur 1.
- L'adresse est l'adresse d'identité
- Le Seeker crée une liaison avec la connexion LE existante sur le transport LE.
- La direction CTKD va de LE à BR/EDR
- La fonctionnalité d'E/S est définie sur DisplayYesNo pour LE
- Le chercheur et le fournisseur effectuent la procédure de validation de la clé d'accès de l'Association express.
Scénario 3 : Le Seeker est compatible avec LEA et CSIP est impliqué
Composants
- Fournisseur
- Compatibilité avec A2DP/HFP/LEA
- Plusieurs composants
- Le composant principal est BR/EDR/LE
- Le composant secondaire est réservé à l'édition limitée
- Seeker
- Compatibilité avec A2DP/HFP/LEA
Comportement attendu pour l'association initiale/l'association ultérieure
- Le composant principal annonce les données du service Association express (0xFE2C) avec l'adresse d'identité (initiale) ou l'adresse privée résoluble (ultérieure).
- Utiliser l'ancienne version de la publicité
- Le chercheur envoie une demande d'association basée sur une clé au composant principal.
- Le bit 5 de l'indicateur 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 égal à 0.
- Le bit 1 doit être défini sur 1.
- Voici l'adresse :
- La première adresse est l'adresse d'identité du composant principal
- La deuxième adresse est l'adresse d'association du composant secondaire. Le deuxième composant utilise également cette adresse pour diffuser des annonces CSIP.
- Le chercheur crée une liaison avec le composant principal sur la connexion LE existante.
- La direction CTKD va de LE à BR/EDR
- La fonctionnalité d'E/S est définie sur DisplayYesNo pour LE
- Le chercheur crée une liaison 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 est refusée
- Le chercheur et le fournisseur effectuent une procédure de protection MITM pour associer le composant secondaire. Le fournisseur doit implémenter les deux scénarios.
- Le chercheur 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 du composant associé par lecture
Problème connu
La fonctionnalité FP pour LEA a été optimisée pour fonctionner avec Android V (Android 15).
À l'inverse, nous avons rencontré de nombreux problèmes avec les casques compatibles avec LEA, mais qui ne disposent pas de l'implémentation Association express sur LEA appropriée (c'est-à-dire uniquement Association express sur Classic). Plus précisément, par exemple, lorsque l'adresse privée résoluble (RPA) du fournisseur n'est pas générée 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'absence d'affichage des notifications de batterie des écouteurs, l'absence de fonctionnalité de changement de source audio (SASS), des échecs d'association initiaux et ultérieurs généralisés, etc.
Par conséquent, nous recommandons vivement aux partenaires d'implémenter la spécification Association express-LEA pour les nouveaux appareils et les appareils existants sur le terrain (via des mises à jour Over The Air) compatibles avec les deux modes.