v1.3
La spécification d'accessoires Localiser mon appareil (FMDN) définit une approche chiffrée de bout en bout pour suivre le balisage des appareils Bluetooth à basse consommation (BLE). Cette page décrit la fonctionnalité FMDN en tant qu'extension de la spécification Association express. Les fournisseurs doivent activer cette extension s'ils disposent d'appareils compatibles avec FMDN et souhaitent activer le suivi de la position pour ces appareils.
Spécification GATT
Une caractéristique d'attributs génériques (GATT) supplémentaires doit être ajoutée au service d'association express avec la sémantique suivante:
Caractéristique du service d'association express | Chiffrée | Autorisations | UUID |
---|---|---|---|
Actions sur les balises | Non | Lire, écrire et envoyer des notifications | FE2C1238-8366-4814-8EB0-01DE32100BEA |
Tableau 1:caractéristiques du service Association express pour FMDN.
Ratio d'économie d'énergie (EER)
Les opérations requises par cette extension sont effectuées en tant qu'opérations d'écriture sécurisées par un mécanisme défi-réponse. Avant d'effectuer toute opération, le moteur de recherche 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 ponctuel | varie |
Chaque opération de lecture doit entraîner un nonce différent. Un nonce ne doit être valide que pour une seule opération. Le nonce doit être invalidé même si l'opération échoue.
Le demandeur 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. Selon l'opération demandée, le demandeur prouve qu'il connaît une ou plusieurs des clés suivantes:
Clé de compte: clé de compte Association express de 16 octets, telle que définie dans la spécification de l'Association express.
Clé de compte propriétaire: le fournisseur choisit l'une des clés de compte existantes comme clé du compte propriétaire la première fois qu'un chercheur accède à la caractéristique "Actions de la balise". La clé de compte propriétaire choisie ne peut pas être modifiée tant que la configuration d'usine du fournisseur n'a pas été rétablie. Le fournisseur ne doit pas supprimer la clé du compte propriétaire lorsqu'il a épuisé ses emplacements de clés de compte sans frais.
Les fournisseurs qui prennent déjà en charge FMDN lors de l'association pour la première fois (ou qui la prennent en charge lors de l'association après le rétablissement de la configuration d'usine) choisissent la première clé de compte, car il s'agit de la seule clé de compte existante lorsque le demandeur lit l'état de provisionnement lors de l'association.
Les fournisseurs qui bénéficient de la compatibilité FMDN après leur association (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 permettant de lire l'état de provisionnement à partir de la caractéristique des actions de la 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 de l'exécution du processus de provisionnement FMDN. Cette clé permet d'obtenir des clés cryptographiques utilisées pour le chiffrement de bout en bout des rapports sur les zones géographiques. Le Seeker ne la révèle jamais au backend.
Clé de récupération: définie sur
SHA256(ephemeral identity key || 0x01)
, tronquée aux huit premiers octets. La clé est stockée sur le backend, et le Seeker 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 sonnerie: définie comme
SHA256(ephemeral identity key || 0x02)
, tronquée aux huit premiers octets. La clé est stockée sur le backend, et le Seeker ne peut l'utiliser que pour faire sonner l'appareil.Clé de protection contre le suivi indésirable: définie en tant que
SHA256(ephemeral identity key || 0x03)
, tronquée aux huit premiers octets. La clé est stockée sur 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 sur la caractéristique est indiqué dans les tableaux 2 à 5. Chacune des 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 |
|
1 | uint8 | Longueur des données | varie |
2 – 9 | tableau d'octets | Clé d'authentification à usage 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 |
|
Tableau 2:Demande de provisionnement des balises
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 à usage 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 clé de provisionnement des balises
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | ID de données |
|
1 | uint8 | Longueur des données | varie |
2 – 9 | tableau d'octets | Clé d'authentification à usage 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 |
|
Tableau 4:Demande d'appel.
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | ID de données |
|
1 | uint8 | Longueur des données | varie |
2 – 9 | tableau d'octets | Clé d'authentification à usage 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 |
|
Tableau 5:Demande de 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: Ring state change doivent être envoyées avant la fin de la transaction d'écriture qui déclenche la notification, c'est-à-dire avant l'envoi d'une PDU de réponse pour la requête d'écriture.
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | ID de données |
|
1 | uint8 | Longueur des données | varie |
2 – 9 | tableau d'octets | Ratio d'économie d'énergie (EER) | Détaillé par opération |
10 - var | tableau d'octets | Données supplémentaires |
|
Tableau 6:Réponse du service de balises.
Le tableau 7 liste les codes d'erreur GATT possibles renvoyés par les opérations.
Code | Description | Notes |
---|---|---|
0x80 | Non authentifiés | Est renvoyé en réponse à une requête d'écriture lorsque l'authentification échoue (y compris dans le cas où un ancien nonce était utilisé). |
0x81 | Valeur non valide | Est renvoyé lorsqu'une valeur non valide est fournie ou que les données reçues présentent un nombre inattendu d'octets. |
0x82 | Pas de consentement de l'utilisateur | Est renvoyé en réponse à une requête d'écriture avec l'ID de données 0x04: Read Ephemeral identité key with user consent (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 demandeur peut interroger le fournisseur pour obtenir les paramètres de la balise en effectuant une opération d'écriture sur la caractéristique composée d'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 du tableau 6 avec l'ID de données 0x00. Le fournisseur construit le segment de données comme suit:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Puissance calibrée | Puissance calibrée 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 d'horloge actuelle en secondes (big endian). |
5 | uint8 | Sélection de la courbe | Courbe elliptique utilisée pour le chiffrement:
|
6 | uint8 | Composants | Le nombre de composants qui peuvent sonner:
|
7 | uint8 | Fonctionnalités de sonnerie | Voici les options compatibles:
|
8-15 | tableau d'octets | Marge intérieure | Aucune marge intérieure 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 demandeur peut interroger le fournisseur pour connaître l'état de provisionnement de la balise en effectuant une opération d'écriture sur la caractéristique constituée d'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 réponse du tableau 6 avec l'ID de données 0x01. Le fournisseur construit 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:
|
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 annoncé par la balise, s'il est défini pour l'appareil. |
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 demandeur effectue une opération d'écriture sur la caractéristique qui consiste en une requête du tableau 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 du 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, le fournisseur doit commencer à annoncer des trames FMDN. La nouvelle clé d'identité éphémère prend effet immédiatement après l'arrêt 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 annuler le provisionnement de la partie Beacon du fournisseur, le demandeur effectue une opération d'écriture sur la caractéristique, qui consiste en une requête du tableau 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 du 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 que la validation échoue, il renvoie une erreur non authentifiée.
En cas de réussite, le fournisseur oublie la clé et cesse d'annoncer 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 avoir appuyé sur un bouton physique (ce qui constitue le consentement de l'utilisateur).
Le Seeker doit stocker la clé de récupération sur 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 demandeur effectue une opération d'écriture sur la caractéristique, sous la forme d'une requête du tableau 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 de l'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 "Pas de consentement de l'utilisateur".
En cas de réussite, le fournisseur envoie une réponse du tableau 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)
.
Sonnerie
Le demandeur peut demander au fournisseur d'émettre un son en effectuant une opération d'écriture sur la caractéristique, qui consiste en une requête provenant de la table 4 avec l'ID de données 0x05. Le fournisseur construit le segment de données comme suit:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Sonnerie | Un masque de bits ayant les valeurs suivantes:
|
1 - 2 | uint16 | Délai avant expiration | Délai avant expiration en secondes. Cette valeur ne doit pas être égale à zéro ni supérieure à l'équivalent de 10 minutes. Le fournisseur utilise cette valeur pour déterminer la durée de la sonnerie avant de se mettre sous silence. Le délai avant expiration remplace celui déjà appliqué 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 |
|
À 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 qui peuvent sonner.
Si le fournisseur n'est pas provisionné en tant que balise FMDN ou que la validation échoue, il renvoie une erreur non authentifiée. Toutefois, si le fournisseur dispose d'une protection contre le suivi indésirable active et que l'indicateur d'authentification par sonnerie est activé pour la demande de protection contre le suivi indésirable qui a été déclenchée, 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.
Lorsque la sonnerie démarre ou prend fin, 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 |
|
1 | uint8 | Sonneries de composants | Masque de bits des composants qui sonnent activement, comme défini dans la requête. |
2 – 3 | uint16 | Délai avant expiration | Temps restant pour 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à à l'état de sonnerie demandé lorsqu'une demande de sonnerie ou d'arrêt de la sonnerie est reçue, le fournisseur doit envoyer une notification indiquant l'état de sonnerie, ou 0x00: démarré ou 0x04: arrêté (requête GATT), respectivement. Cette requête ignore les paramètres de l'état existant afin que la durée de la sonnerie puisse être prolongée.
Si le fournisseur dispose d'un bouton physique (ou si la fonctionnalité de détection tactile est activée), ce bouton doit arrêter la fonction de sonnerie s'il est enfoncé lorsque la sonnerie est active.
Obtenir l'état de la sonnerie de la balise
Pour obtenir l'état de sonnerie de la balise, le demandeur effectue une opération d'écriture sur la caractéristique, qui consiste en une requête provenant 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é d'anneau.
Si le fournisseur n'est pas provisionné en tant que balise FMDN ou en cas d'échec de la validation, le fournisseur renvoie une erreur non authentifiée.
En cas de réussite, le fournisseur envoie une réponse du tableau 6 avec l'ID de données 0x06. Le fournisseur construit le segment de données comme suit:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Sonneries de composants | Composants qui sonnent activement, tels que définis dans la requête qui sonne. |
1 - 2 | uint16 | Délai avant expiration | Temps restant pour 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 est destiné à permettre à tout client d'identifier les appareils abusifs sans communication avec le serveur. Par défaut, le fournisseur doit alterner tous les identifiants comme décrit dans la section Rotation des ID. Le service Localiser mon appareil peut relayer une requête d'activation du mode de 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 demandeur effectue une opération d'écriture sur la caractéristique, qui consiste en une requête du tableau 5 avec les ID de données 0x07 ou 0x08 respectivement.
En cas d'activation du mode de protection contre le suivi indésirable
Le fournisseur construit le segment de données comme suit:
Octet | Type de données | Description | Valeur |
---|---|---|---|
0 | uint8 | Indicateurs de contrôle |
Les indicateurs ne s'appliquent 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 des adresses privées 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 Indicateurs hachés.
En cas de désactivation du mode de protection contre le suivi indésirable
Le fournisseur vérifie que:
- La clé d'authentification à usage 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 que la validation échoue, il 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 taux normal, en synchronisant la rotation de l'identifiant éphémère. Le type de cadre doit être redéfini sur 0 x 40. L'état est également reflété dans la section Indicateurs hachés.
En cas de réussite, le fournisseur envoie une réponse du tableau 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)
.
Frames promus
Après le provisionnement, le fournisseur doit annoncer des trames FMDN au moins une fois toutes les deux secondes. Si des trames Association express sont annoncées, le fournisseur doit entrelacer les trames FMDN dans les annonces standards pour l'Association express. Par exemple, toutes les deux secondes, le fournisseur doit annoncer sept annonces Association express et une annonce FMDN.
La trame FMDN contient une clé publique permettant de chiffrer les rapports de localisation par tout client d'assistance contribuant au réseau de crowdsourcing. Deux types de clés à courbe elliptique sont disponibles: une clé de 160 bits adaptée aux anciennes trames BLE 4, ou une clé de 256 bits nécessitant la technologie BLE 5 avec des fonctionnalités publicitaires étendues. L'implémentation du fournisseur détermine la courbe utilisée.
Une trame FMDN est structurée comme suit.
Octet | Valeur | Description |
---|---|---|
0 | 0x02 | Longueur |
1 | 0x01 | Valeur du type de données des options |
2 | 0x06 | Données d'indicateurs |
3 | 0 x 18 ou 0 x 19 | Longueur |
4 | 0x16 | Valeur du type de données de données de service |
5 | 0xAA | UUID de service 16 bits |
6 | 0xFE | ... |
7 | 0 x 40 ou 0 x 41 | Type de trame FMDN avec indication du mode de protection contre le suivi indésirable |
8..27 | Identifiant éphémère de 20 octets | |
28 | Indicateurs hachés |
Tableau 8:trame FMDN compatible avec une courbe de 160 bits.
Le tableau 9 présente les valeurs et les décalages d'octets pour une courbe de 256 bits.
Octet | Valeur | Description |
---|---|---|
0 | 0x02 | Longueur |
1 | 0x01 | Valeur du type de données des options |
2 | 0x06 | Données d'indicateurs |
3 | 0 x 24 ou 0 x 25 | Longueur |
4 | 0x16 | Valeur du type de données de données de service |
5 | 0xAA | UUID de service 16 bits |
6 | 0xFE | ... |
7 | 0 x 40 ou 0 x 41 | Type de trame FMDN avec indication du mode de protection contre le suivi indésirable |
8..39 | Identifiant éphémère de 32 octets | |
40 | Indicateurs hachés |
Tableau 9:trame FMDN compatible avec une courbe de 256 bits.
Calcul de l'identifiant éphémère (EID)
Une valeur aléatoire est générée par AES-ECB-256 en chiffrant la structure de données suivante avec la clé d'identité éphémère:
Octet | Champ | Description |
---|---|---|
Entre 0 et 10 | Marge intérieure | Valeur = 0xFF |
11 | K | Exposant de la période de rotation |
12 – 15 | TS[0]...TS[3] | Compteur de temps sur les balises, au format big-endian 32 bits. Les K bits les plus bas sont effacés. |
16–26 | Marge intérieure | Valeur = 0 x 00 |
27 | K | Exposant de la période de rotation |
28 - 31 | TS[0]...TS[3] | Compteur de temps sur les balises, au format big-endian 32 bits. Les K bits les plus bas sont effacés. |
Tableau 10:Construction d'un nombre pseudo-aléatoire.
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 à courbe elliptique. Consultez les définitions des courbes dans la section
SEC 2: Paramètres de domaine de la 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. La balise annonce Rx
, qui est la coordonnée x
de R
, comme identifiant éphémère.
Indicateurs hachés
Le champ des 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 des zéros).
- Les bits 5 à 6 indiquent le niveau de batterie de l'appareil, comme suit :
- 00: Incompatibilité avec l'indication du niveau de batterie
- 01: Niveau de batterie normal
- 10: Niveau de batterie faible
- 11: Niveau de batterie très faible (le remplacement de la batterie sera bientôt nécessaire)
- 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 produire la valeur finale de cet octet, il est xor-ed 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 comme 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 l'annonce.
Chiffrement avec EID
Pour chiffrer un message m
, un visiteur (ayant lu Rx
à partir de la balise) doit procéder comme suit:
- Choisissez un nombre aléatoire
s
dansFp
, tel que défini dans la section Calcul de l'EID. - Calculez
S = s * G
. - Calculez
R = (Rx, Ry)
par substitution dans l'équation de courbe et en choisissant une valeurRy
arbitraire parmi les résultats possibles. - Calculez la clé AES 256 bits
k = HKDF-SHA256((s * R)x)
, où(s * R)x
est la coordonnéex
du résultat de la multiplication de la courbe. Le sel n'est pas spécifié. - Soit
URx
etLRx
correspondant respectivement aux 80 bits supérieur et inférieur deRx
au format big-endian. De la même manière, définissezUSx
etLSx
pourS
. - Calculez
nonce = LRx || LSx
. - Calculez
(m’, tag) = AES-EAX-256-ENC(k, nonce, m)
. - Envoyez
(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 possède l'EIK et l'exposant de période de rotation, déchiffre le message comme suit:
- Avec
URx
, obtenez la valeur du compteur de temps de la balise sur laquelleURx
est basé. Pour ce faire, le client du propriétaire peut calculer les valeursRx
pour les valeurs de compteur de l'heure de la balise dans le passé récent et le futur proche. - Compte tenu de la valeur du compteur de temps de la balise sur laquelle
URx
est basé, calculez la valeur anticipée der
, telle que définie dans la section Calcul de l'EID. - Calculez
R = r * G
et vérifiez une correspondance avec la valeur deURx
fournie par le viseur. - Calculez
S = (Sx, Sy)
par substitution dans l'équation de courbe et en choisissant une valeurSy
arbitraire parmi les résultats possibles. - Calculez
k = HKDF-SHA256((r * S)x)
, où(r * S)x
est la coordonnéex
du résultat de la multiplication de la courbe. - Calculez
nonce = LRx || LSx
. - Calculez
m = AES-EAX-256-DEC(k, nonce, m’, tag)
.
Rotation des ID
Une adresse BLE résolvable (RPA) ou non résolus (NRPA) doit être utilisée pour diffuser des trames FMDN publicitaires. Le RPA est requis pour les appareils LE Audio (LEA) et est recommandé pour les autres appareils, à l'exception des tags de localisation qui n'utilisent pas l'association.
L'annonce Association express, l'annonce FMDN et la ou les adresses BLE correspondantes doivent alterner en même temps. La rotation doit avoir lieu toutes les 1 024 secondes en moyenne. Le moment précis auquel la balise commence à diffuser le nouvel identifiant doit être aléatoire dans la fenêtre.
L'approche recommandée pour rendre la durée de rotation aléatoire consiste à la définir sur la prochaine date de rotation anticipée (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 l'annonce FMDN doit être corrigée, mais le RPA pour les annonces FP non visibles (comme Association express) doit continuer à tourner. Il est acceptable d'utiliser différentes adresses pour les différents protocoles.
Reprise après une coupure de courant
La résolution de l'identifiant éphémère est fortement liée à sa valeur d'horloge au moment de l'annonce. Il est donc important que le fournisseur puisse récupérer sa valeur d'horloge en cas de coupure de courant. Il est recommandé que le fournisseur écrit sa valeur d'horloge actuelle dans la mémoire non volatile au moins une fois par jour et qu'au moment du démarrage, le fournisseur vérifie la NVM pour voir s'il existe une valeur à partir de laquelle l'initialisation est disponible. Les résolveurs de l'identifiant éphémère implémenteraient la résolution sur une fenêtre de temps suffisante pour permettre à la fois une dérive d'horloge raisonnable et ce type de récupération de perte de puissance.
Les fournisseurs doivent tout de même s'efforcer de minimiser les dérives d'horloge, car la fenêtre de temps de résolution est limitée. Au moins une autre méthode de synchronisation d'horloge doit être mise en œuvre (annonce de frames Association express non visibles ou implémentation du flux de messages).
Consignes d'implémentation de l'Association express
Cette section décrit des aspects spéciaux de l'implémentation de l'Association express sur les fournisseurs qui acceptent les FMDN.
Consignes spécifiques aux tags de localisation
- Si le fournisseur a été associé, mais que le service 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 pas provisionné par 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 FMDN n'est pas provisionné ou avant un délai de cinq minutes.
- Si la clé d'identité éphémère est effacée de l'appareil, celui-ci doit rétablir la configuration d'usine et effacer également les clés de compte stockées.
- Le fournisseur doit rejeter les tentatives d'association Bluetooth normales et accepter uniquement l'association Association express.
- Le fournisseur doit inclure un mécanisme permettant aux utilisateurs d'arrêter temporairement la publicité sans rétablir la configuration d'usine de l'appareil (par exemple, en appuyant sur une combinaison de boutons).
- Après une coupure de courant, l'appareil doit annoncer les frames Association express non visibles jusqu'au prochain appel des paramètres de la balise de lecture. Cela permet au chercheur de détecter l'appareil et de synchroniser l'horloge même si une dérive d'horloge importante s'est produite.
- Lorsque vous faites la promotion de frames Association express non visibles, les indications de l'interface utilisateur ne doivent pas être activées.
- Les trames Association express visibles ne doivent pas être annoncées lorsque le fournisseur est provisionné pour FMDN.
- Le Fournisseur ne doit divulguer aucune information d'identification de manière non authentifiée (par exemple, des noms ou des identifiants).
Consignes propres aux appareils Bluetooth classiques
Cette section décrit des aspects particuliers des appareils Bluetooth classiques compatibles avec FMDN.
Gestion des numéros FMDN d'appareils déjà associés
Le fournisseur n'est pas toujours provisionné pour le FMDN lors de l'association avec le Seeker, mais un certain temps après. Dans ce cas, le fournisseur peut ne pas disposer d'une adresse MAC BLE à jour requise pour établir une connexion GATT. Le fournisseur doit prendre en charge au moins l'une des méthodes suivantes pour que le demandeur obtienne son adresse BLE lorsqu'il est déjà associé:
- Le fournisseur peut annoncer régulièrement les données du compte Association express qui permettent au demandeur de trouver son adresse BLE à l'aide d'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 Association express via le Bluetooth classique.
Cette approche convient aux fournisseurs qui n'annoncent pas de frames Association express lorsqu'ils sont connectés au Seeker via Bluetooth.
La prise en charge de ces deux approches augmente les chances que l'utilisateur puisse provisionner l'appareil pour FMDN.
Flux de messages associé à l'Association express
Le fournisseur peut implémenter un flux de messages Association express et l'utiliser pour informer le chercheur sur les informations sur l'appareil. La mise en œuvre du flux de messages active certaines fonctionnalités, comme décrit dans cette section.
Le fournisseur doit envoyer des messages d'informations sur l'appareil une fois que le canal RFCOMM de flux de messages est établi.
Version du micrologiciel (code d'informations sur l'appareil 0x09) et fonctionnalité de suivi
Lorsqu'une mise à jour du micrologiciel ajoute la prise en charge FMDN au fournisseur, un demandeur connecté peut en informer l'utilisateur et proposer de le 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é de version du micrologiciel (code 0x09) pour signaler une valeur de chaîne représentant la version du micrologiciel. En outre, le fournisseur doit prendre en charge le protocole qui permet au chercheur d'être informé des modifications des fonctionnalités 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 de données supplémentaire | varie |
var | tableau d'octets | Chaîne de version | varie |
Tableau 11:Événement d'informations sur l'appareil: mise à jour de la version du micrologiciel.
À la réception d'une requête de mise à jour des fonctionnalités (0x0601), si le fournisseur a activé la prise en charge du suivi FMDN, 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 FMDN | 0x03 |
2 – 3 | uint16 | Longueur de données supplémentaire | 0x0007 |
4 | uint8 | État du provisionnement FMDN | 0x00 si non géré ; 0x01 si géré 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 indiquer l'EID et la valeur d'horloge actuels lorsque le fournisseur est provisionné pour le FMDN, afin de synchroniser le chercheur en cas de dérive d'horloge (par exemple, en raison d'un déchargement de la batterie). Sinon, le chercheur initie 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 | 0 x 0 M |
2 – 3 | uint16 | Longueur de données supplémentaire | 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 le rétablissement de la configuration d'usine: si la configuration d'usine est rétablie, le fournisseur doit arrêter le balisage 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 à faire la promotion de l'association express immédiatement, afin d'empêcher le processus d'association de démarrer immédiatement après la suppression de l'appareil par l'utilisateur.
Prévention contre le suivi indésirable
Les appareils FMDN certifiés doivent également répondre aux 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 à FMDN pour être conforme à la spécification DULT:
- Tout appareil compatible avec FMDN doit être enregistré dans la console d'appareil à proximité et avoir la fonctionnalité "Localiser mon appareil" activée.
- L'appareil doit implémenter la caractéristique et le service non-propriétaire de l'accessoire définis dans la version d'implémentation de la spécification DULT, y compris les opérations Informations complémentaires et Commandes des non-propriétaires.
- Pendant la période de rétrocompatibilité, telle que définie 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 la spécification DULT.
- Consignes pour la mise en œuvre des opcodes Accessory Information :
- La fonction Get_Product_Data doit renvoyer l'ID de modèle fourni par la console, sans ajouter de remplissage pour respecter les exigences de 8 octets. 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 "Location Tracker" si aucune autre catégorie ne correspond mieux au type d'appareil.
- Get_Accessory_Capabilities doit indiquer la compatibilité avec les sonneries ainsi que la recherche d'identifiants BLE.
- La fonction Get_Network_ID doit renvoyer l'identifiant de Google (0x02).
- Consignes pour la mise en œuvre de l'opcode 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", ce qui nécessite plusieurs pressions sur le bouton. Un signal visuel ou audio doit indiquer à l'utilisateur que le fournisseur est passé dans ce mode. Les instructions spécifiques au modèle pour l'activation de ce mode doivent être fournies à Google comme exigence de certification et au moins 10 jours avant toute mise à jour ou modification des instructions.
- La réponse est construite comme suit: les 10 premiers octets de l'identifiant éphémère actuel, suivi des 8 premiers octets de
HMAC-SHA256(recovery key, the truncated current ephemeral identifier)
.
- Consignes d'implémentation de l'opcode Sound_Start :
- La commande doit déclencher la sonnerie dans tous les composants disponibles.
- Utilisez le volume maximal accepté.
- La durée recommandée pour la sonnerie est de 12 secondes.
- Les balises de localisation doivent inclure un mécanisme permettant aux utilisateurs d'arrêter 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 via une URL accessible au public et fournies à Google comme exigence de certification et au moins 10 jours avant toute mise à jour ou modification des instructions.
- L'URL doit être compatible avec la localisation. Selon le client, la langue sera fournie sous forme de paramètre de requête ("hl=en") ou à l'aide de l'en-tête HTTP "accept-language".
Consignes concernant les protocoles commutables
- Vous ne devez utiliser qu'un seul protocole à la fois. Assurez-vous qu'un seul réseau peut fonctionner simultanément sur l'appareil. Cette exigence est nécessaire pour éviter tout mélange de données utilisateur sensibles entre différents protocoles.
- Nous vous recommandons d'intégrer un workflow de réinitialisation matérielle à l'appareil qui permet à un utilisateur de reconfigurer son appareil avec un autre réseau.
- Le processus de mise à jour d'un appareil vers 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.
Compatibilité
Le réseau Localiser mon appareil nécessite l'activation des services de localisation et du Bluetooth. Nécessite une connexion au réseau mobile ou à Internet. Fonctionne sous Android 9 ou version ultérieure et dans certains pays, pour les utilisateurs éligibles à l'âge.
Journal des modifications
Version FMDN | Date | Commentaire |
---|---|---|
v1 | Version initiale des spécifications FMDN pour l'accès anticipé. | |
v1.1 | Feb 2023 |
|
v1.2 | Avr. 2023 |
|
v1.3 | Déc. 2023 |
|