Spécifications de l'accessoire réseau Localiser mon appareil

v1.3

La spécification des accessoires du réseau Localiser mon appareil (FMDN) définit une approche chiffrée de bout en bout pour le suivi des appareils Bluetooth Low Energy (BLE) qui émettent des balises. Cette page décrit la FMDN comme une extension de la spécification Fast Pair. Les fournisseurs doivent activer cette extension s'ils disposent d'appareils compatibles avec FMDN et s'ils souhaitent activer le suivi de la position pour ces appareils.

Remarque :Si vous souhaitez intégrer la spécification des accessoires Localiser mon appareil, envoyez un formulaire de proposition d'appareil. Plus d'informations sur les étapes d'intégration et la certification seront bientôt disponibles.

Spécification GATT

Une caractéristique d'attributs génériques (GATT) supplémentaire doit être ajoutée au service Fast Pair avec la sémantique suivante:

Caractéristique du service Fast Pair	Chiffré	Autorisations	UUID
Actions des balises	Non	Lire, écrire et envoyer des notifications	FE2C1238-8366-4814-8EB0-01DE32100BEA

Tableau 1:Caractéristiques du service Fast Pair pour les FMDN

Authentification

Les opérations requises par cette extension sont effectuées en tant qu'opération d'écriture, sécurisée par un mécanisme de défi-réponse. Avant d'effectuer une opération, le chercheur doit effectuer une opération de lecture à partir de la caractéristique du tableau 1, ce qui génère un tampon au format suivant:

Octet	Type de données	Description	Valeur
0	uint8	Numéro de version majeure du protocole	0x01
1 - 8	tableau d'octets	Nonce aléatoire unique	varie

Chaque opération de lecture doit générer un nonce différent, et un nonce ne doit être valide que pour une seule opération. Le nonce doit être invalidé même si l'opération a échoué.

Le Seeker calcule ensuite une clé d'authentification à usage unique à utiliser dans une requête d'écriture ultérieure. La clé d'authentification est calculée comme décrit dans les tableaux 2 à 5. En fonction de l'opération demandée, le demandeur prouve sa connaissance d'une ou plusieurs des clés suivantes:

• Clé de compte: clé de compte Fast Pair de 16 octets, comme défini dans la spécification Fast Pair.

• Clé de compte propriétaire: le fournisseur choisit l'une des clés de compte existantes comme clé de compte propriétaire la première fois qu'un chercheur accède à la caractéristique Actions des balises. La clé de compte propriétaire choisie ne peut pas être modifiée tant que le fournisseur n'a pas été réinitialisé. Le fournisseur ne doit pas supprimer la clé de compte propriétaire lorsqu'il n'a plus d'emplacements de clé de compte disponibles.

  • Les fournisseurs qui acceptent déjà FMDN lors de l'association pour la première fois (ou lors de l'association après une réinitialisation d'usine) choisissent la première clé de compte, car il s'agit de la seule clé de compte existante lorsque le chercheur lit l'état de provisionnement lors de l'association.

  • Les fournisseurs qui bénéficient de la prise en charge de la FMDN après avoir été associés (par exemple, via une mise à jour du micrologiciel) peuvent choisir n'importe quelle clé de compte existante. Il est raisonnable de choisir la première clé de compte utilisée pour lire l'état de provisionnement à partir de la caractéristique des actions de balise après la mise à jour du micrologiciel, en supposant que l'utilisateur qui a effectué la mise à jour est le propriétaire actuel du fournisseur.

• Clé d'identité éphémère (EIK): clé de 32 octets choisie de manière aléatoire par le chercheur lors du processus de provisionnement de l'adresse FMDN. Cette clé permet de dériver des clés cryptographiques utilisées pour chiffrer de bout en bout les rapports de localisation. Le chercheur ne le révèle jamais au backend.

• Clé de récupération: définie comme SHA256(ephemeral identity key || 0x01), tronquée aux huit premiers octets. La clé est stockée dans le backend et le chercheur peut l'utiliser pour récupérer l'EIK, à condition que l'utilisateur exprime son consentement en appuyant sur un bouton de l'appareil.

• Clé de l'anneau: définie comme SHA256(ephemeral identity key || 0x02), tronquée aux huit premiers octets. La clé est stockée dans le backend et le chercheur ne peut l'utiliser que pour faire sonner l'appareil.

• Clé de protection contre le suivi indésirable: définie comme SHA256(ephemeral identity key || 0x03), tronquée aux huit premiers octets. La clé est stockée dans le backend et le Seeker ne peut l'utiliser que pour activer le mode de protection contre le suivi indésirable.

Opérations

Le format des données écrites dans la caractéristique est indiqué dans les tableaux 2 à 5. Chacune de ces opérations est abordée plus en détail plus loin dans cette section.

Octet	Type de données	Description	Valeur
0	uint8	ID de données	0x00: Lire les paramètres de la balise 0x01: Lire l'état de provisionnement 0x02: Définir la clé d'identité éphémère 0x03: Effacer la clé d'identité éphémère
1	uint8	Longueur des données	varie
2 - 9	tableau d'octets	Clé d'authentification unique	Les 8 premiers octets de HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 - var	tableau d'octets	Données supplémentaires	0x00: n/a 0x01: n/a 0x02: 32 octets correspondant à la clé d'identité éphémère, chiffrée AES-ECB-128 avec la clé de compte. Si le fournisseur dispose déjà d'une clé d'identité éphémère définie, envoyez également les huit premiers octets de SHA256(current ephemeral identity key || the last nonce read from the characteristic). 0x03: les 8 premiers octets de SHA256(ephemeral identity key || the last nonce read from the characteristic)

Tableau 2:Demande de provisionnement de balise.

Octet	Type de données	Description	Valeur
0	uint8	ID de données	0x04: Lire la clé d'identité éphémère avec le consentement de l'utilisateur
1	uint8	Longueur des données	0x08
2 à 9	tableau d'octets	Clé d'authentification unique	Les 8 premiers octets de HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length)

Tableau 3:Demande de récupération de la clé de provisionnement du balise.

Octet	Type de données	Description	Valeur
0	uint8	ID de données	0x05: sonnerie 0x06: Lire l'état de sonnerie
1	uint8	Longueur des données	varie
2 - 9	tableau d'octets	Clé d'authentification unique	Les 8 premiers octets de HMAC-SHA256(ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data)
10 - var	tableau d'octets	Données supplémentaires	0x05: 4 octets indiquant l'état de sonnerie, la durée de sonnerie et le volume de sonnerie. 0x06: n/a

Tableau 4:Requête de sonnerie.

Octet	Type de données	Description	Valeur
0	uint8	ID de données	0x07: Activer le mode de protection contre le suivi indésirable 0x08: Désactivation du mode de protection contre le suivi indésirable
1	uint8	Longueur des données	varie
2 à 9	tableau d'octets	Clé d'authentification unique	Les 8 premiers octets de 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	tableau d'octets	Données supplémentaires	0x07: 1 octet d'indicateurs de contrôle (facultatif) 0x08: les 8 premiers octets de SHA256(ephemeral identity key || the last nonce read from the characteristic)

Tableau 5:Requête de désactivation de la protection contre le suivi indésirable.

Les écritures réussies déclenchent des notifications, comme indiqué dans le tableau 6.

Les notifications avec un ID de données autre que 0x05: Modification de l'état de la sonnerie doivent être envoyées avant la fin de la transaction d'écriture qui déclenche la notification, c'est-à-dire avant l'envoi d'un PDU de réponse pour la requête d'écriture.

Octet	Type de données	Description	Valeur
0	uint8	ID de données	0x00: Lire les paramètres de la balise 0x01: Lire l'état de provisionnement 0x02: Définir la clé d'identité éphémère 0x03: Clé d'identité éphémère effacée 0x04: Lire la clé d'identité éphémère avec le consentement de l'utilisateur 0x05: Modification de l'état de la sonnerie 0x06: Lire l'état de sonnerie 0x07: Activer le mode de protection contre le suivi indésirable 0x08: Désactivation du mode de protection contre le suivi indésirable
1	uint8	Longueur des données	varie
2 à 9	tableau d'octets	Authentification	Détail par opération
10 - var	tableau d'octets	Données supplémentaires	0x00: 8 octets indiquant la puissance de transmission, la valeur de l'horloge, la méthode de chiffrement et les fonctionnalités de sonnerie, chiffré AES-ECB-128 avec la clé de compte (avec remplissage à zéro) 0x01: 1 octet indiquant l'état de provisionnement, suivi de l'ID éphémère actuel (20 ou 32 octets), le cas échéant 0x04: 32 octets correspondant à la clé d'identité éphémère, chiffrée AES-ECB-128 avec la clé de compte 0x05: 4 octets indiquant le nouvel état et le déclencheur du changement 0x06: trois octets indiquant les composants qui sonnent activement et le nombre de décisecondes restantes pour la sonnerie D'autres ID de données utilisent des données supplémentaires vides

Tableau 6:Réponse du service de balise.

Le tableau 7 liste les codes d'erreur GATT possibles renvoyés par les opérations.

Code	Description	Remarques
0x80	Non authentifiés	Renvoyé en réponse à une requête d'écriture en cas d'échec de l'authentification (y compris dans le cas où un ancien nonce a été utilisé).
0x81	Valeur non valide	Rendue lorsque des valeurs non valides sont fournies ou que les données reçues comportent un nombre d'octets inattendu.
0x82	Aucun consentement de l'utilisateur	Rendue en réponse à une requête d'écriture avec l'ID de données 0x04: Lire la clé d'identité éphémère avec le consentement de l'utilisateur lorsque l'appareil n'est pas en mode association.

Tableau 7:Codes d'erreur GATT.

Lire le paramètre de la balise

Le chercheur peut interroger le fournisseur sur les paramètres du balise en effectuant une opération d'écriture sur la caractéristique consistant en une requête de la table 2 avec l'ID de données 0x00. Le fournisseur vérifie que la clé d'authentification à usage unique fournie correspond à l'une des clés de compte stockées sur l'appareil.

Si la validation échoue, le fournisseur renvoie une erreur non authentifiée.

En cas de réussite, le fournisseur envoie une réponse de la table 6 avec l'ID de données 0x00. Le fournisseur crée le segment de données comme suit:

Octet	Type de données	Description	Valeur
0	uint8	Puissance calibrée	Puissance calibrée telle que reçue à 0 m (valeur comprise dans la plage [-100, 20]). Représenté sous la forme d'un entier signé, avec une résolution de 1 dBm.
1 à 4	uint32	Valeur de l'horloge	Valeur de l'horloge actuelle en secondes (big endian).
5	uint8	Sélection de courbes	Courbe elliptique utilisée pour le chiffrement: 0x00 (par défaut): SECP160R1 0x01: SECP256R1 (nécessite la publicité étendue)
6	uint8	Composants	Nombre de composants pouvant sonner: 0x00: indique que l'appareil ne peut pas sonner. 0x01: indique qu'un seul composant peut sonner. 0x02: indique que deux composants, les écouteurs gauche et droit, peuvent sonner indépendamment. 0x03: indique que trois composants, les écouteurs gauche et droit et l'étui, peuvent sonner indépendamment.
7	uint8	Fonctionnalités de sonnerie	Les options acceptées sont les suivantes: 0x00: Sélection du volume de sonnerie non disponible. 0x01: Sélection du volume de la sonnerie disponible. Si ce paramètre est défini, le fournisseur doit accepter et gérer trois niveaux de volume, comme indiqué dans la section Opération de sonnerie.
8-15	tableau d'octets	Marge intérieure	Ajout de zéros pour le chiffrement AES.

Les données doivent être chiffrées AES-ECB-128 avec la clé de compte utilisée pour authentifier la requête.

Le segment d'authentification est défini comme les huit premiers octets de HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data after encryption || 0x01).

Lire l'état de provisionnement de la balise

Le chercheur peut interroger le fournisseur sur l'état de provisionnement du balise en effectuant une opération d'écriture sur la caractéristique consistant en une requête de la table 2 avec l'ID de données 0x01. Le fournisseur vérifie que la clé d'authentification à usage unique fournie correspond à l'une des clés de compte stockées sur l'appareil.

Si la validation échoue, le fournisseur renvoie une erreur non authentifiée.

En cas de réussite, le fournisseur envoie une notification avec une réponse de la table 6 avec l'ID de données 0x01. Le fournisseur crée le segment de données comme suit:

Octet	Type de données	Description	Valeur
0	uint8	État de provisionnement	Un masque de bits ayant les valeurs suivantes: Bit 1 (0x01): défini si une clé d'identité éphémère est définie pour l'appareil. Bit 2 (0x02): défini si la clé d'authentification à usage unique fournie correspond à la clé du compte propriétaire.
1 à 20 ou 32	tableau d'octets	Identifiant éphémère actuel	20 ou 32 octets (selon la méthode de chiffrement utilisée) indiquant l'ID éphémère actuel diffusé par la balise, le cas échéant.

Le segment d'authentification est défini comme les huit premiers octets de HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Définir une clé d'identité éphémère

Pour provisionner un fournisseur non provisionné en tant que balise FMDN ou modifier la clé d'identité éphémère d'un fournisseur déjà provisionné, le chercheur effectue une opération d'écriture sur la caractéristique consistant en une requête de la table 2 avec l'ID de données 0x02. Le Fournisseur vérifie que:

• La clé d'authentification à usage unique fournie correspond à la clé du compte propriétaire.
• Si un hachage d'une clé d'identité éphémère a été fourni, la clé d'identité éphémère hachée correspond à la clé d'identité éphémère actuelle.
• Si aucun hachage d'une clé d'identité éphémère n'a été fourni, vérifiez que le fournisseur n'a pas déjà été provisionné en tant que balise FMDN.

Si la validation échoue, le fournisseur renvoie une erreur non authentifiée.

En cas de réussite, la clé d'identité éphémère est récupérée par AES-ECB-128 en la déchiffrant à l'aide de la clé de compte correspondante. La clé doit être conservée sur l'appareil. À partir de ce moment-là, le fournisseur doit commencer à diffuser des trames FMDN. La nouvelle clé d'identité éphémère prend effet immédiatement après la fin de la connexion BLE. Le fournisseur envoie une réponse du tableau 6 avec l'ID de données 0x02.

Le segment d'authentification est défini comme les huit premiers octets de HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Effacer la clé d'identité éphémère

Pour désprovisionner la partie balise du fournisseur, le chercheur effectue une opération d'écriture sur la caractéristique, qui consiste en une requête de la table 2 avec l'ID de données 0x03. Le Fournisseur vérifie que:

• La clé d'authentification à usage unique fournie correspond à la clé du compte propriétaire.
• La clé d'identité éphémère hachée correspond à la clé d'identité éphémère actuelle.

Si le fournisseur n'est pas provisionné en tant que balise FMDN ou si la validation échoue, une erreur non authentifiée est renvoyée.

En cas de réussite, le fournisseur oublie la clé et cesse de diffuser des trames FMDN. Le fournisseur envoie une réponse du tableau 6 avec l'ID de données 0x03. Le segment d'authentification est défini comme les huit premiers octets de HMAC-SHA256(account key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Lire la clé d'identité éphémère avec le consentement de l'utilisateur

Cette option n'est disponible que pour récupérer une clé perdue, car elle n'est stockée localement que par le chercheur. Par conséquent, cette fonctionnalité n'est disponible que lorsque l'appareil est en mode association ou pendant une durée limitée après qu'un bouton physique a été enfoncé sur l'appareil (ce qui constitue le consentement de l'utilisateur).

Le chercheur doit stocker la clé de récupération dans le backend pour pouvoir récupérer la clé en texte clair, mais il ne stocke pas la clé EIK elle-même.

Pour lire l'EIK, le chercheur effectue une opération d'écriture sur la caractéristique, qui consiste en une requête de la table 3 avec l'ID de données 0x04. Le fournisseur vérifie que:

• La clé de récupération hachée correspond à la clé de récupération attendue.
• L'appareil est en mode de récupération EIK.

Si la validation échoue, le fournisseur renvoie une erreur non authentifiée.

Si l'appareil n'est pas en mode association, le fournisseur renvoie une erreur "Aucun consentement de l'utilisateur".

En cas de réussite, le fournisseur envoie une réponse de la table 6 avec l'ID de données 0x04.

Le segment d'authentification est défini comme les huit premiers octets de HMAC-SHA256(recovery key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Fonctionnement de la sonnerie

Le demandeur peut demander au fournisseur de diffuser un son en effectuant une opération d'écriture sur la caractéristique, qui consiste en une requête de la table 4 avec l'ID de données 0x05. Le fournisseur crée le segment de données comme suit:

Octet	Type de données	Description	Valeur
0	uint8	Fonctionnement de la sonnerie	Un masque de bits ayant les valeurs suivantes: Bit 1 (0x01): Sonnerie droite Bit 2 (0x02): sonner l'écouteur gauche Bit 3 (0x04): boîtier de sonnerie 0xFF: Sonnerie de tous les composants 0x00: Arrêter la sonnerie
1 - 2	uint16	Délai avant expiration	Délai avant expiration en décisecondes. Ne doit pas être égal à zéro et ne doit pas dépasser l'équivalent de 10 minutes. Le fournisseur utilise cette valeur pour déterminer la durée pendant laquelle le téléphone doit sonner avant de se couper. Le délai avant expiration remplace celui déjà en vigueur si un composant de l'appareil sonne déjà. Si l'opération de sonnerie est définie sur 0x00, le délai avant expiration est ignoré.
3	uint8	Volume	0x00: valeur par défaut 0x01: Faible 0x02: Moyen 0x03: élevé La signification exacte de ces valeurs dépend de l'implémentation.

À la réception de la demande, le fournisseur vérifie que:

• La clé d'authentification à usage unique fournie correspond à la clé de l'anneau.
• L'état demandé correspond aux composants pouvant sonner.

Si le fournisseur n'est pas provisionné en tant que balise FMDN ou si la validation échoue, une erreur non authentifiée est renvoyée. Toutefois, si le fournisseur a activé la protection contre le suivi indésirable et que l'indicateur d'authentification de l'appel manqué a été activé pour la requête de déclenchement de la protection contre le suivi indésirable, le fournisseur doit ignorer cette vérification. Les données d'authentification doivent toujours être fournies par le chercheur, mais elles peuvent être définies sur une valeur arbitraire.

Lorsqu'une sonnerie commence ou se termine, une notification est envoyée, comme indiqué dans le tableau 6 avec l'ID de données 0x05. Le contenu de la notification est défini comme suit:

Octet	Type de données	Description	Valeur
0	uint8	État de la sonnerie	0x00: démarré 0x01: Échec du démarrage ou de l'arrêt (tous les composants demandés sont hors plage) 0x02: Arrêté (expiration du délai) 0x03: Arrêté (appui sur le bouton) 0x04: Arrêté (requête GATT)
1	uint8	Composants de sonnerie	Masque de bits des composants qui sonnent activement, comme défini dans la requête.
2 à 3	uint16	Délai avant expiration	Durée restante de la sonnerie en décisecondes. Si l'appareil a cessé de sonner, 0x0000 doit être renvoyé.

Le segment d'authentification est défini comme les huit premiers octets de HMAC-SHA256(ring key, protocol major version number || the nonce used to initiate the ringing command || data ID || data length || additional data || 0x01).

Si l'appareil est déjà dans l'état de sonnerie demandé lorsqu'une requête de sonnerie ou d'arrêt de sonnerie est reçue, le fournisseur doit envoyer une notification avec un état de sonnerie ou 0x00: Débuté ou 0x04: Arrêté (requête GATT), respectivement. Cette requête remplace les paramètres de l'état existant afin que la durée de sonnerie puisse être prolongée.

Si le fournisseur dispose d'un bouton physique (ou si la détection tactile est activée), ce bouton doit arrêter la fonction de sonnerie s'il est enfoncé lorsque la sonnerie est active.

Remarque :Pour les fournisseurs qui incluent la détection de port sur la tête, pensez à vérifier que l'appareil n'est pas porté sur la tête avant de sonner au volume maximal. Si la détection de port d'écouteurs n'est pas prise en charge ou n'est pas fiable, augmentez progressivement le volume (afin que l'utilisateur ait le temps d'arrêter la sonnerie ou de retirer ses écouteurs).

Remarque :Le fournisseur doit continuer à sonner, quel que soit l'état de la connexion de l'utilisateur qui a demandé la sonnerie. Cela évite que l'appareil ne cesse de sonner en raison de la perte de la connexion lorsque le client s'éloigne trop de l'appareil. L'appareil ne peut alors pas être trouvé, car il a cessé de sonner et est trop éloigné du client pour qu'il puisse demander à nouveau de sonner.

Obtenir l'état de sonnerie du beacon

Pour obtenir l'état de sonnerie du beacon, le Seeker effectue une opération d'écriture sur la caractéristique, qui consiste en une requête de la table 4 avec l'ID de données 0x06. Le fournisseur vérifie que la clé d'authentification à usage unique fournie correspond à la clé de l'anneau.

Si le fournisseur n'est pas provisionné en tant que balise FMDN ou si la validation échoue, il renvoie une erreur non authentifiée.

En cas de réussite, le fournisseur envoie une notification avec une réponse de la table 6 avec l'ID de données 0x06. Le fournisseur crée le segment de données comme suit:

Octet	Type de données	Description	Valeur
0	uint8	Composants de sonnerie	Composants en sonnerie active, comme défini dans la requête de sonnerie.
1 - 2	uint16	Délai avant expiration	Durée restante de la sonnerie en décisecondes. Notez que si l'appareil ne sonne pas, 0x0000 doit être renvoyé.

Le segment d'authentification est défini comme les huit premiers octets de HMAC-SHA256 (ring key, protocol major version number || the last nonce read from the characteristic || data ID || data length || additional data || 0x01).

Mode de protection contre le suivi indésirable

Le mode de protection contre le suivi indésirable permet à tout client d'identifier les appareils abusifs sans communication avec le serveur. Par défaut, le fournisseur doit faire pivoter tous les identifiants, comme décrit dans la section Rotation des ID. Le service Localiser mon appareil peut transmettre une demande d'activation du mode Protection contre le suivi indésirable via le réseau Localiser mon appareil. Ainsi, le service oblige le fournisseur à utiliser temporairement une adresse MAC fixe, ce qui permet aux clients de détecter l'appareil et d'avertir l'utilisateur d'un éventuel suivi indésirable.

Pour activer ou désactiver le mode de protection contre le suivi indésirable de la balise, le chercheur effectue une opération d'écriture sur la caractéristique, qui consiste en une requête de la table 5 avec l'ID de données 0x07 ou 0x08, respectivement.

Lors de l'activation du mode de protection contre le suivi indésirable

Le fournisseur crée le segment de données comme suit:

Octet	Type de données	Description	Valeur
0	uint8	Indicateurs de contrôle	0x01: ignorer l'authentification du sonnerie. Lorsque ce paramètre est défini, les requêtes de sonnerie ne sont pas authentifiées en mode Protection contre le suivi indésirable. Si aucun indicateur n'est défini (l'octet est entièrement à zéro), vous pouvez omettre complètement la section de données et envoyer une section de données vide. Les indicateurs ne sont en vigueur que jusqu'à ce que le mode de protection contre le suivi indésirable soit désactivé.

Le fournisseur vérifie que la clé d'authentification à usage unique fournie correspond à la clé de protection contre le suivi indésirable. Si le fournisseur n'est pas provisionné en tant que balise FMDN ou si la validation échoue, une erreur non authentifiée est renvoyée.

Lorsque le mode de protection contre le suivi indésirable est activé, la balise doit réduire la fréquence de rotation de l'adresse privée MAC à une fois toutes les 24 heures. L'identifiant éphémère annoncé doit continuer à tourner comme d'habitude. Le type de frame doit être défini sur 0x41. L'état est également reflété dans la section Flags hachés.

Lorsque vous désactivez le mode de protection contre le suivi indésirable

Le Fournisseur vérifie que:

• La clé d'authentification unique fournie correspond à la clé de protection contre le suivi indésirable.
• La clé d'identité éphémère hachée correspond à la clé d'identité éphémère actuelle.

Si le fournisseur n'est pas provisionné en tant que balise FMDN ou si la validation échoue, le fournisseur renvoie une erreur non authentifiée.

Lorsque le mode de protection contre le suivi indésirable est désactivé, la balise doit recommencer à faire pivoter l'adresse MAC à un rythme normal, synchronisé avec la rotation de l'identifiant éphémère. Le type de frame doit être rétabli sur 0x40. L'état est également reflété dans la section Options hachées.

En cas de réussite, le fournisseur envoie une réponse de la table 6 avec l'ID de données 0x07 ou 0x08.

Le segment d'authentification est défini comme les huit premiers octets de HMAC-SHA256(unwanted tracking protection key, protocol major version number || the last nonce read from the characteristic || data ID || data length || 0x01).

Cadres annoncés

Après le provisionnement, le fournisseur doit diffuser des trames FMDN au moins une fois toutes les deux secondes. Si des trames Fast Pair sont annoncées, le fournisseur doit intercaler les trames FMDN dans les annonces Fast Pair standards. Par exemple, toutes les deux secondes, le fournisseur doit diffuser sept annonces Fast Pair et une annonce FMDN.

La puissance de transmission Bluetooth conductée pour les annonces FMDN doit être définie sur au moins 0 dBm.

Remarque :Nous vous recommandons de diffuser les trames FMDN même lorsque l'appareil est en mode basse consommation, car cela permet de le localiser en cas de perte. Pour certains appareils, il est possible qu'il ne soit pas possible de diffuser des annonces lorsque l'appareil est éteint en raison des conséquences sur l'autonomie de la batterie. Dans ce cas, nous vous recommandons vivement de réveiller régulièrement l'appareil et de diffuser des annonces pendant une courte période (par exemple, toutes les 10 minutes et pendant 10 secondes).

Le frame FMDN contient une clé publique utilisée pour chiffrer les rapports de localisation par n'importe quel client compatible qui contribue au réseau de crowdsourcing. Deux types de clés à courbe elliptique sont disponibles: une clé 160 bits qui s'adapte aux anciens trames BLE 4 ou une clé 256 bits qui nécessite BLE 5 avec des fonctionnalités publicitaires étendues. L'implémentation du fournisseur détermine la courbe utilisée.

Remarque :L'utilisation de clés 256 bits signifie que les téléphones plus anciens qui ne sont pas compatibles avec le BLE 5 ne peuvent pas analyser ni signaler les appareils publicitaires, ce qui réduit la taille du réseau.

Un frame FMDN est structuré comme suit :

Octet	Valeur	Description
0	0x02	Longueur
1	0x01	Valeur du type de données d'indicateur
2	0x06	Données des options
3	0x18 ou 0x19	Longueur
4	0x16	Valeur du type de données de service
5	0xAA	UUID de service 16 bits
6	0xFE	…
7	0x40 ou 0x41	Type de frame FMDN avec indication du mode de protection contre le suivi indésirable
8..27		Identifiant éphémère de 20 octets
28		Drapeaux hachés

Tableau 8:trame FMDN compatible avec une courbe 160 bits.

Le tableau 9 indique les décalages et les valeurs d'octets pour une courbe 256 bits.

Octet	Valeur	Description
0	0x02	Longueur
1	0x01	Valeur du type de données d'indicateur
2	0x06	Données des options
3	0x24 ou 0x25	Longueur
4	0x16	Valeur du type de données de service
5	0xAA	UUID de service 16 bits
6	0xFE	…
7	0x40 ou 0x41	Type de frame FMDN avec indication du mode de protection contre le suivi indésirable
8..39		Identifiant éphémère de 32 octets
40		Drapeaux hachés

Tableau 9:trame FMDN compatible avec une courbe 256 bits.

Calcul de l'identifiant éphémère (EID)

Un nombre aléatoire est généré par le chiffrement AES-ECB-256 de la structure de données suivante avec la clé d'identité éphémère:

Octet	Champ	Description
0 – 10	Marge intérieure	Valeur = 0xFF
11	K	Exposant de la période de rotation
12 à 15	TS[0]...TS[3]	Compteur de temps du signal, au format big-endian 32 bits. Les bits les plus bas de K sont effacés.
16 - 26	Marge intérieure	Valeur = 0x00
27	K	Exposant de la période de rotation
28 - 31	TS[0]...TS[3]	Compteur de temps du signal, au format big-endian 32 bits. Les bits les plus bas de K sont effacés.

Tableau 10:Construction d'un nombre pseudo-aléatoire.

Remarque:On suppose que l'appareil dispose d'un compteur temporel 32 bits en secondes.

Remarque:L'exposant de la période de rotation est fixe et défini sur 10, ce qui correspond à 1 024 secondes.

Le résultat de ce calcul est un nombre de 256 bits, noté r'.

Pour le reste du calcul, SECP160R1 ou SECP256R1 sont utilisés pour les opérations cryptographiques de courbe elliptique. Consultez les définitions des courbes dans la section SEC 2 : Recommended Elliptic Curve Domain Parameters (SECTION 2 : Paramètres de domaine de courbe elliptique recommandés), qui définit Fp, n et G, référencés ci-dessous.

r' est désormais projeté sur le champ fini Fp en calculant r = r' mod n. Enfin, calculez R = r * G, qui est un point sur la courbe représentant la clé publique utilisée. Le balise annonce Rx, qui est la coordonnée x de R, comme identifiant éphémère.

Options hachées

Le champ d'indicateurs hachés est calculé comme suit (les bits sont référencés du plus significatif au moins significatif):

• Bits 0 à 4: réservés (définis sur zéro).
• Les bits 5 et 6 indiquent le niveau de batterie de l'appareil comme suit :
  • 00: L'indication du niveau de la batterie n'est pas prise en charge
  • 01: Niveau de batterie normal
  • 10: niveau de batterie faible
  • 11: Niveau de batterie extrêmement faible (remplacement de la batterie nécessaire prochainement)
• Le bit 7 est défini sur 1 si la balise est en mode de protection contre le suivi indésirable, et sur 0 dans le cas contraire.

Pour générer la valeur finale de cet octet, il est XORé avec l'octet le moins significatif de SHA256(r).

Notez que r doit être aligné sur la taille de la courbe. Ajoutez des zéros en tant que bits les plus significatifs si sa représentation est inférieure à 160 ou 256 bits, ou les bits les plus significatifs doivent être tronqués si sa représentation est supérieure à 160 ou 256 bits.

Si la balise n'est pas compatible avec l'indication du niveau de la batterie et qu'elle n'est pas en mode de protection contre le suivi indésirable, elle est autorisée à omettre entièrement cet octet de la publicité.

Chiffrement avec EID

Remarque :Les détails suivants sur le chiffrement et le déchiffrement avec des EID ne sont inclus que pour compléter la spécification. Seul le chercheur les implémente, et non le fournisseur.

Pour chiffrer un message m, un observateur (ayant lu Rx à partir de la balise) procède comme suit:

1. Choisissez un nombre aléatoire s dans Fp, comme défini dans la section Calcul de l'EID.
2. Compute S = s * G.
3. Calculez R = (Rx, Ry) par substitution dans l'équation de la courbe et en sélectionnant une valeur Ry arbitraire parmi les résultats possibles.
4. Calculez la clé AES 256 bits k = HKDF-SHA256((s * R)x), où (s * R)x est la coordonnée x du résultat de la multiplication de la courbe. Le sel n'est pas spécifié.
5. Considérons URx et LRx comme les 80 bits supérieurs et inférieurs de Rx, respectivement, au format big-endian. De même, définissez USx et LSx pour S.
6. Calculez nonce = LRx || LSx.
7. Compute (m’, tag) = AES-EAX-256-ENC(k, nonce, m).
8. Envoyer (URx, Sx, m’, tag) au propriétaire, éventuellement via un service distant non approuvé.

Déchiffrement des valeurs chiffrées avec EID

Le client du propriétaire, qui est en possession de l'EIK et de l'exposant de la période de rotation, déchiffre le message comme suit:

1. Étant donné URx, obtenez la valeur du compteur de temps de la balise sur laquelle URx est basé. Pour ce faire, le client du propriétaire peut calculer les valeurs Rx pour les valeurs du compteur temporel de la balise pour le passé récent et le futur proche.
2. Étant donné la valeur du compteur de temps de la balise sur laquelle URx est basée, calculez la valeur prévue de r, comme défini dans la section Calcul de l'EID.
3. Calculez R = r * G et vérifiez qu'il correspond à la valeur de URx fournie par le viseur.
4. Calculez S = (Sx, Sy) par substitution dans l'équation de la courbe et en sélectionnant une valeur Sy arbitraire parmi les résultats possibles.
5. Calculez k = HKDF-SHA256((r * S)x), où (r * S)x est la coordonnée x du résultat de la multiplication de la courbe.
6. Compute nonce = LRx || LSx.
7. Compute m = AES-EAX-256-DEC(k, nonce, m’, tag).

Rotation des ID

Une adresse BLE résoluble (RPA) ou non résoluble (NRPA) doit être utilisée pour les trames FMDN de publicité. La RPA est obligatoire pour les appareils LE Audio (LEA) et recommandée pour les autres appareils, à l'exception des balises de localisation qui n'utilisent pas l'association.

L'annonce Fast Pair, l'annonce FMDN et les adresses BLE correspondantes doivent être diffusées en même temps. La rotation doit se produire toutes les 1 024 secondes en moyenne. Le moment précis où la balise commence à diffuser le nouvel identifiant doit être aléatoire pendant la période.

L'approche recommandée pour randomiser la durée de rotation consiste à la définir sur la prochaine durée de rotation prévue (si aucune randomisation n'a été appliquée) plus un facteur de temps aléatoire positif compris entre 1 et 204 secondes.

Lorsque l'appareil est en mode de protection contre le suivi indésirable, l'adresse BLE de la publicité FMDN doit être fixe, mais la RPA pour la publicité non détectable de FP (comme l'Association express) doit continuer à tourner. Il est acceptable d'utiliser des adresses différentes pour les différents protocoles.

Récupération après une perte de courant

La résolution de l'identifiant éphémère est fortement liée à sa valeur d'horloge au moment de la publicité. Il est donc important que le fournisseur puisse récupérer sa valeur d'horloge en cas de perte de courant. Il est recommandé que le fournisseur écrive sa valeur d'horloge actuelle dans la mémoire non volatile au moins une fois par jour, et qu'au démarrage, le fournisseur vérifie la NVM pour voir s'il existe une valeur à partir de laquelle l'initialisation doit être effectuée. Les résolveurs de l'identifiant éphémère implémenteraient la résolution sur une période suffisante pour permettre à la fois une dérive de l'horloge raisonnable et ce type de récupération en cas de perte de courant.

Les fournisseurs doivent tout de même faire tout leur possible pour minimiser les dérives de l'horloge, car la période de résolution est limitée. Au moins une méthode de synchronisation des horloges supplémentaire doit être implémentée (publicité de cadres Fast Pair non détectables ou implémentation du flux de messages).

Consignes d'implémentation de Fast Pair

Cette section décrit les aspects particuliers de l'implémentation de Fast Pair sur les fournisseurs compatibles avec FMDN.

Consignes spécifiques aux balises de localisation

• Si le fournisseur a été associé, mais que le FMDN n'a pas été provisionné dans les cinq minutes (ou si une mise à jour OTA a été appliquée alors que l'appareil est associé, mais qu'il n'a pas été provisionné avec FMDN), le fournisseur doit rétablir sa configuration d'usine et effacer les clés de compte stockées.
• Une fois le fournisseur associé, il ne doit pas modifier son adresse MAC tant que le FMDN n'est pas provisionné ou que cinq minutes ne se sont pas écoulées.
• Si la clé d'identité éphémère est effacée de l'appareil, celui-ci doit effectuer une réinitialisation d'usine et effacer également les clés de compte stockées.
• Le fournisseur doit rejeter les tentatives d'association Bluetooth normales et n'accepter que l'association Fast Pair.
• Le fournisseur doit inclure un mécanisme permettant aux utilisateurs de suspendre temporairement la publicité sans rétablir la configuration d'usine de l'appareil (par exemple, en appuyant sur une combinaison de boutons).
• En cas de perte de courant, l'appareil doit diffuser des trames Fast Pair non détectables jusqu'à la prochaine invocation de read beacon parameters (Lire les paramètres du balise). Cela permet au chercheur de détecter l'appareil et de synchroniser l'horloge, même en cas de dérive importante de l'horloge.
• Lorsque vous annoncez des cadres Fast Pair non détectables, les indications de l'UI ne doivent pas être activées.
• Les frames Fast Pair détectables ne doivent pas être annoncés tant que le fournisseur est provisionné pour FMDN.
• Le fournisseur ne doit pas exposer d'informations d'identification de manière non authentifiée (par exemple, des noms ou des identifiants).

Consignes spécifiques aux appareils Bluetooth classiques

Cette section décrit les aspects particuliers des appareils Bluetooth classiques compatibles avec FMDN.

Provisionnement FMDN des appareils déjà associés

Le fournisseur n'est pas toujours provisionné pour le FMDN lors de l'association avec le chercheur, mais un certain temps après. Dans ce cas, il est possible que le fournisseur ne dispose pas d'une adresse MAC BLE à jour, qui est requise pour établir une connexion GATT. Le fournisseur doit prendre en charge au moins l'une des méthodes suivantes pour que le chercheur puisse obtenir son adresse BLE lorsqu'il est déjà associé:

• Le fournisseur peut diffuser périodiquement les données de compte Fast Pair qui permettent à l'appareil à la recherche de l'appareil de trouver son adresse BLE via une analyse BLE.
  Cette approche convient aux fournisseurs qui n'implémentent pas le flux de messages.
• Le fournisseur peut fournir ces données via le flux de messages Fast Pair via le Bluetooth classique.
  Cette approche convient aux fournisseurs qui n'annoncent pas de trames Fast Pair lorsqu'ils sont connectés au chercheur via Bluetooth.

Prendre en charge les deux approches augmente les chances que l'utilisateur puisse provisionner l'appareil pour FMDN.

Flux de messages Fast Pair

Le fournisseur peut implémenter le flux de messages Fast Pair et l'utiliser pour informer le chercheur des informations sur l'appareil. L'implémentation du flux de messages permet d'utiliser certaines fonctionnalités, comme décrit dans cette section.

Le fournisseur doit envoyer des messages d'informations sur l'appareil une fois chaque fois que le canal RFCOMM du flux de messages est établi.

Version du micrologiciel (code d'informations sur l'appareil 0x09) et capacité de suivi

Lorsqu'une mise à jour du micrologiciel ajoute la prise en charge de la FMDN au fournisseur, un chercheur connecté peut en informer l'utilisateur et lui proposer de la provisionner. Sinon, l'utilisateur doit accéder manuellement à la liste des appareils Bluetooth pour lancer le provisionnement FMDN.

Pour ce faire, le fournisseur doit utiliser la propriété "Version du micrologiciel" (code 0x09) pour indiquer une valeur de chaîne représentant la version du micrologiciel. De plus, le fournisseur doit prendre en charge le protocole qui permet au chercheur de connaître les modifications de capacité dues aux mises à jour du micrologiciel.

Octet	Type de données	Description	Valeur
0	uint8	Événement d'informations sur l'appareil	0x03
1	uint8	Version du micrologiciel	0x09
2 - 3	uint16	Longueur des données supplémentaires	varie
var	tableau d'octets	Chaîne de version	varie

Tableau 11:Événement "Informations sur l'appareil" : version du micrologiciel mise à jour.

Lorsqu'il reçoit une requête de mise à jour des fonctionnalités (0x0601), si le fournisseur a activé la prise en charge du suivi des numéros de téléphone mobile, il doit répondre comme indiqué dans le tableau 12.

Octet	Type de données	Description	Valeur
0	uint8	Événement de synchronisation des fonctionnalités de l'appareil	0x06
1	uint8	Suivi des numéros autorisés	0x03
2 - 3	uint16	Longueur des données supplémentaires	0x0007
4	uint8	État du provisionnement de l'FMDN	0x00 si non provisionné ; 0x01 si provisionné par un compte
5 - 10	tableau d'octets	Adresse MAC BLE actuelle de l'appareil	varie

Tableau 12:Événement de synchronisation des fonctionnalités de l'appareil: fonctionnalité de suivi ajoutée.

Identifiant éphémère actuel (code d'informations sur l'appareil 0x0B)

Le fournisseur peut utiliser l'identifiant éphémère actuel (code 0x0B) pour signaler l'EID et la valeur de l'horloge actuels lorsque le fournisseur est provisionné pour FMDN, afin de synchroniser le chercheur en cas de dérive de l'horloge (par exemple, en raison d'une batterie déchargée). Sinon, le chercheur lance une connexion plus coûteuse et moins fiable à cette fin.

Octet	Type de données	Description	Valeur
0	uint8	Événement d'informations sur l'appareil	0x03
1	uint8	Identifiant éphémère actuel	0x0B
2 - 3	uint16	Longueur des données supplémentaires	0x0018 ou 0x0024
4 - 7	tableau d'octets	Valeur de l'horloge	Exemple: 0x13F9EA80
8 à 19 ou 31	tableau d'octets	EID actuel	Exemple : 0x1122334455667788990011223344556677889900

Tableau 13:Événement d'informations sur l'appareil: synchronisation de l'horloge.

Rétablir la configuration d'usine

Pour les appareils compatibles avec la réinitialisation d'usine: si une réinitialisation d'usine est effectuée, le fournisseur doit arrêter la balise et effacer la clé d'identité éphémère et toutes les clés de compte stockées, y compris la clé de compte du propriétaire.

Après un rétablissement de la configuration d'usine (manuel ou programmatique), le fournisseur ne doit pas commencer immédiatement à promouvoir Fast Pair pour éviter que le flux d'association ne commence immédiatement après la suppression de l'appareil par l'utilisateur.

Prévention du suivi indésirable

Les appareils FMDN certifiés doivent également respecter les exigences de la version d'implémentation de la spécification multiplate-forme pour la détection des traceurs de position indésirables (DULT).

Consignes spécifiques à la FMDN pour être conforme à la spécification DULT:

• Tout appareil compatible avec la FMDN doit être enregistré dans la console des appareils à proximité et la fonctionnalité "Localiser mon appareil" doit être activée.
• L'appareil doit implémenter le service et la caractéristique de non-propriétaire d'accessoire définis dans la version d'implémentation de la spécification DULT, y compris les opérations Informations sur l'accessoire et les commandes de non-propriétaire.
• Pendant la période de rétrocompatibilité, comme défini dans la spécification DULT, aucune modification n'est apportée au frame annoncé tel que défini dans ce document.
• Le "mode de protection contre le suivi indésirable" défini dans ce document correspond à l'état "séparé" défini par les spécifications DULT.
• Consignes d'implémentation des opcodes Informations sur l'accessoire :
  • Get_Product_Data doit renvoyer l'ID de modèle fourni par la console, avec des zéros pour remplir les 8 octets requis. Par exemple, l'ID de modèle 0xFFFFFF est renvoyé sous la forme 0x0000000000FFFFFF.
  • Get_Manufacturer_Name et Get_Model_Name doivent correspondre aux valeurs fournies dans la console.
  • Get_Accessory_Category peut renvoyer la valeur générique "Localiseur" si aucune autre catégorie ne correspond mieux au type d'appareil.
  • Get_Accessory_Capabilities doit indiquer la prise en charge de la sonnerie ainsi que la recherche d'identifiant BLE.
  • Get_Network_ID doit renvoyer l'identifiant de Google (0x02).
• Consignes d'implémentation de l'instruction Get_Identifier :
  • L'opération ne doit renvoyer une réponse valide que pendant cinq minutes après que l'utilisateur a activé le mode "Identification", qui nécessite une combinaison de pressions sur les boutons. Un signal visuel ou audio doit indiquer à l'utilisateur que le fournisseur est passé en mode. Les instructions spécifiques au modèle pour activer ce mode doivent être fournies à Google pour la certification et au moins 10 jours avant toute mise à jour ou modification des instructions.
  • La réponse est constituée des 10 premiers octets de l'identifiant éphémère actuel, suivis des 8 premiers octets de HMAC-SHA256(recovery key, the truncated current ephemeral identifier).
• Consignes d'implémentation de l'identifiant via NFC :
  • En tant qu'URL, utilisez find-my.googleapis.com/lookup.
  • Pour le paramètre e, utilisez la même réponse que celle créée pour Get_Identifier, encodé en hexadécimal.
  • Pour le paramètre pid, utilisez la même réponse que celle créée pour Get_Product_Data, encodé en hexadécimal.
• L'appareil doit obligatoirement inclure un générateur de son et prendre en charge la fonction de sonnerie. Conformément aux spécifications DULT, le générateur de son doit émettre un son avec une intensité sonore maximale de 60 phons, comme défini par la norme ISO 532-1:2017.
• Consignes d'implémentation de l'opcode Sound_Start :
  • La commande doit déclencher la sonnerie dans tous les composants disponibles.
  • Le volume maximal compatible doit être utilisé.
  • La durée recommandée pour la sonnerie est de 12 secondes.
• Les balises de localisation doivent inclure un mécanisme permettant aux utilisateurs de suspendre temporairement la publicité sans rétablir la configuration d'usine de l'appareil (par exemple, en appuyant sur une combinaison de boutons).
  • Les instructions de désactivation doivent être documentées dans une URL accessible au public et fournies à Google, comme condition préalable à la certification, au moins 10 jours avant toute mise à jour ou modification des instructions.
  • L'URL doit être compatible avec la localisation. En fonction du client, la langue est fournie soit sous forme de paramètre de requête ("hl=en"), soit à l'aide de l'en-tête HTTP "accept-language".

Consignes concernant les protocoles commutables

• Un seul protocole doit être utilisé à la fois. Assurez-vous qu'un seul réseau ne peut fonctionner simultanément sur l'appareil. Cette exigence est nécessaire pour s'assurer qu'il n'y a pas de mélange de données utilisateur sensibles entre différents protocoles.
• Il est recommandé d'intégrer un workflow de réinitialisation matérielle à l'appareil, qui permet à un utilisateur de reconfigurer un appareil avec un autre réseau.
• Le processus de mise à jour d'un appareil sur un réseau doit être convivial et équitable entre les réseaux. Un utilisateur doit pouvoir choisir le réseau qu'il souhaite utiliser sans donner la préférence à l'un des réseaux. Ce flux doit être approuvé par l'équipe Google.

Mises à jour du micrologiciel

Le processus et la distribution des mises à jour OTA doivent être gérés par le partenaire à l'aide de son propre workflow d'application mobile ou Web.

L'Association express permet d'envoyer des notifications à l'utilisateur pour l'informer des mises à jour OTA disponibles. Pour utiliser ce mécanisme:

• La dernière version du micrologiciel doit être mise à jour dans la console des appareils à proximité.
• Une application associée doit être définie dans la console des appareils à proximité. Il doit prendre en charge l'intent de mise à jour du micrologiciel.
• Le fournisseur doit implémenter la caractéristique GATT Version du micrologiciel.

Pour empêcher le suivi, l'accès à la caractéristique Version du micrologiciel doit être limité. Le Seeker lit d'abord l'état de provisionnement et fournit une clé d'authentification, comme défini dans cette spécification, puis lit la version du micrologiciel. Cette opération s'effectue via la même connexion. Si une tentative de lecture de la version du micrologiciel est effectuée, et que le fournisseur n'est pas associé ni qu'une opération authentifiée n'a pas été effectuée avec succès sur cette même connexion, le fournisseur doit renvoyer une erreur non authentifiée.

Compatibilité

Le réseau Localiser mon appareil nécessite l'activation des services de localisation et de la connexion Bluetooth. Nécessite une connexion au réseau mobile ou à Internet. Fonctionne sous Android 9 ou version ultérieure, dans certains pays et pour les utilisateurs à partir d'un certain âge.

Journal des modifications

Version FMDN	Date	Commentaire
v1		Version initiale de la spécification FMDN en accès anticipé.
v1.1	Feb 2023	Ajout d'une indication en texte clair du mode de protection contre le suivi indésirable. Ajout d'une option permettant d'ignorer l'authentification des requêtes de sonnerie en mode Protection contre le suivi indésirable.
v1.2	Avr. 2023	Modification de la définition de l'AK d'un propriétaire. Ajout d'une recommandation pour la récupération en cas de perte de courant dans les balises de localisation. Clarification concernant la randomisation des adresses MAC. Clarification concernant la rotation des adresses MAC en mode Protection contre le suivi indésirable. Ajout d'une consigne indiquant comment désactiver une balise de localisation.
v1.3	Déc. 2023	Ajout d'une précision sur les informations d'identification exposées par les balises de localisation. Ajout d'une exigence pour implémenter la spécification de prévention du suivi indésirable. Ajout de consignes pour les appareils de protocole commutables.