Procédure d'association express

Procédure

Au lieu d'appeler immédiatement l'une des procédures d'association normales BR/EDR ou BLE, le Seeker active d'abord les notifications sur la caractéristique d'association basée sur des clés, puis y écrit les données du Tableau 1.1.

Lors du traitement d'une requête d'écriture d'un chercheur d'association express, le fournisseur d'Association express doit procéder comme suit:

  1. Si le champ facultatif "Clé publique" est présent :
    1. Si l'appareil n'est pas en mode association, ignorez l'écriture et la fermeture.
    2. Sinon :
      1. Utilisez la clé publique reçue (un point de 64 octets sur la courbe elliptique secp256r1), la clé privée anti-spoofing préinstallée (également secp256r1) et l'algorithme Diffie-Hellman à courbe elliptique pour générer une clé AES 256 bits.
      2. Utilisez SHA-256 pour hacher la clé AES 256 bits.
      3. Prenez les 128 premiers bits du résultat. Il s'agit de la clé AES anti-spoofing, utilisée à l'étape suivante.

  2. À l'aide de l'algorithme AES-128, essayez de déchiffrer la valeur. Étant donné que la valeur est un bloc AES 16 octets unique, aucun mode de chiffrement par vecteur d'initialisation ou multibloc n'est nécessaire.

    1. Quelle clé utiliser :
      1. Si une clé AES anti-spoofing a été générée à l'étape 1, utilisez-la.
      2. Sinon, essayez chaque clé de la liste persistante des clés de compte.
    2. Si une clé parvient à déchiffrer la valeur, interrompre la lecture et passer à l'étape suivante.

    3. La valeur est correctement déchiffrée si le résultat correspond au format du tableau 1.2.1 ou du tableau 1.2.2 (c'est-à-dire, si elle contient l'adresse BLE actuelle du fournisseur d'associations rapides ou l'adresse publique du fournisseur d'Association express).

      REMARQUE: un salage est joint à la fin du paquet. Dans la mesure du possible, ces salages doivent être suivis et, si le fournisseur reçoit une requête contenant une valeur de salage déjà utilisée, la requête doit être ignorée pour éviter les attaques par rejeu.

    4. Au lieu de suivre les salages, si l'écriture inclut l'adresse privée du fournisseur, un autre moyen d'empêcher les attaques par rejeu consiste à avancer l'heure de la prochaine rotation des adresses privées pouvant être résolues afin que la rotation ait lieu avant que la prochaine écriture d'association basée sur des clés ne soit acceptée.

  3. Si aucune clé n'a pu déchiffrer la valeur, ignorez l'écriture et la fermeture.

    1. Notez le nombre d'échecs. Lorsque le nombre d'échecs atteint 10, toutes les nouvelles requêtes échouent immédiatement. Réinitialisez le nombre d'échecs après cinq minutes, après mise sous tension ou après une opération réussie.

  4. Sinon, enregistrez la clé réussie sous le nom K. Marquez ce K comme utilisable pour déchiffrer les écritures de clé d'accès et de nom personnalisé reçues sur ce lien LE, mais pas pour d'autres écritures ni pour aucune autre écriture sur aucun autre lien. Démarrez un minuteur à supprimer K au bout de 10 secondes si l'association n'a pas été lancée. Supprimez également K si ce lien LE se déconnecte.

  5. Produisez la réponse brute de 16 octets présentée dans le Tableau 1.3, en concaténant le type et l'adresse BR/EDR du fournisseur, puis en remplissant le reste du paquet avec un bloc d'octets aléatoires (c'est-à-dire un salage).

  6. Chiffrez la réponse brute avec K pour générer la réponse chiffrée de 16 octets présentée dans le tableau 1.4. Envoyez cette information via une notification sur la caractéristique de l'association basée sur des clés.

  7. Lisez l'indicateur de requête:

    1. Si le bit 2 est défini sur 1 pour l'octet d'indicateurs de la requête, envoyez une notification à la caractéristique de données supplémentaires en indiquant un nom personnalisé.
    2. Si le bit 1 est défini sur 1 pour l'octet d'indicateurs de la requête:
      1. Cela indique que le demandeur demande au fournisseur d'initier la liaison à l'adresse BR/EDR du demandeur, qui est présente dans les octets 8 à 13.
      2. Envoyez une demande d'association à l'adresse BR/EDR du chercheur. La demande d'association doit être décrite ci-dessous (étape "Pendant l'association").
      3. Pourquoi cela est nécessaire: le fait de demander au fournisseur de se lancer permet de résoudre un problème sur certains appareils.
    3. Si le bit 1 est défini sur 0 pour l'octet d'indicateurs de la requête:
      1. Attendez jusqu'à 10 secondes pour recevoir une demande d'association. Si vous n'en recevez aucune, quittez.
      2. Notez qu'il peut s'agir d'une requête BR/EDR, provenant d'une adresse différente (l'adresse publique du demandeur, et non son adresse privée pouvant être résolue). Nous vérifierons à nouveau lors de l'association que l'appareil à l'origine de la demande est en possession de K.

  8. Pendant l'association:

    1. Lorsqu'un paquet de requête/réponse d'association est reçu du demandeur : si les fonctionnalités de l'appareil de la requête sont NoInput/NoOutput, terminez l'association afin d'éviter d'utiliser la méthode d'association Just Works.
    2. Pour le paquet de requête/réponse d'association envoyé par le fournisseur: définissez le champ "Device Capabilities" (Capacités de l'appareil) sur Display/YesNo (Affichage/YesNo), et les exigences d'authentification sur MITM Protection Required (Protection MITM requise). Cela déclenche la méthode d'association par comparaison numérique (également appelée confirmation de clé d'accès sur Android). Nous nous appuyons sur ces informations pour confirmer que l'appareil à l'origine de la demande est bien le chercheur Association express et qu'il n'y a pas d'homme du milieu. Consultez des exemples.
    3. La raison est la suivante: la méthode d'association externe est mieux adaptée, mais la plate-forme ne l'expose pas sur toutes les versions d'Android souhaitées.

  9. Lorsque la confirmation de la clé d'accès est nécessaire, attendez jusqu'à 10 secondes pour qu'une écriture dans la caractéristique de clé d'accès soit nécessaire.

    1. Normalement, avec cette méthode d'association, l'utilisateur confirme que les clés d'accès affichées sur l'écran de chaque appareil sont identiques. À la place, nous les transférons via BLE, et chiffrées à l'aide de la clé pré-partagée de confiance, uniquement pour cette association.
    2. Notez que cette approche ne doit pas être adoptée pour les appareils dotés d'un écran ou d'un clavier, car elle présente un léger compromis sur la protection MITM. Pour le moment, l'Association express n'est pas compatible avec ces types d'appareils.
    3. Si le délai de 10 secondes expire sans qu'aucune clé d'accès ne soit écrite, supprimez K.

  10. Lorsqu'une valeur est écrite dans la caractéristique de clé d'accès, il s'agit du bloc de clé d'accès chiffré. Déchiffrez-la avec K pour obtenir un bloc de clé d'accès brut, dont le format est indiqué dans Characteristic: Clé d'accès > Tableau 2.2 (type = Clé d'accès du chercheur).

  11. Si le déchiffrement échoue, ignorez l'écriture et supprimez K.

  12. Sinon, le bloc de clé d'accès brut contient une clé d'accès à six chiffres PSeeker, qui est la clé d'accès attendue par le chercheur.

  13. Comparez PSeeker avec notre propre clé d'accès attendue, PProvider.

    1. Si les valeurs sont égales, répondez "oui" à la confirmation.
    2. Sinon, répondez "non" à l'invite de confirmation, ce qui entraîne l'échec de l'association.

  14. Que l'association ait échoué ou non, générez un autre bloc de clé d'accès brut, avec le format indiqué dans Characteristic: Passkey > Tableau 2.2, contenant notre propre clé d'accès attendue, PProvider.

    1. Vérifiez que le type de bloc est correct (clé d'accès du fournisseur ; voir le tableau). REMARQUE: Ne réutilisez pas le salage du bloc de clé d'accès reçu du demandeur. Générez une nouvelle valeur aléatoire.

  15. Chiffrez le bloc de clé d'accès brut avec K et envoyez le bloc de clé d'accès chiffré obtenu via une notification sur la caractéristique de clé d'accès.

  16. S'il reçoit et déchiffre la clé d'accès P appropriée, il répond également "oui" à la confirmation, et l'association aboutit.

    1. Si l'association réussit, marquez K comme utilisable pour déchiffrer les écritures de la clé de compte sur ce lien LE, mais pas pour toute écriture ultérieure de clé d'accès ni aucune autre écriture sur un autre lien. Démarrez un minuteur pour supprimer K au bout de 10 secondes. Supprimez également K après toute tentative d'écriture d'une clé de compte et, conformément à l'étape 4, si le lien LE se déconnecte.
    2. Si l'association échoue, supprimez la touche K.

  17. Redéfinissez le champ "Fonctionnalités de l'appareil" sur les fonctionnalités d'E/S par défaut et rétablissez la valeur par défaut "Exigences d'authentification" pour que les nouvelles associations se poursuivent comme prévu.

Notez que pour les fournisseurs qui ne nécessitent pas d'association, le demandeur n'envoie pas de requête d'association au fournisseur. Les étapes 8 à 17 sont ignorées. En outre, "K" est utilisé dans la caractéristique de clé de compte.

Exemples
Exemple 1:Tentative d'association réussie (pas de "man-in-the-middle").
Exemple 2:Échec de la tentative d'association, avec un homme du milieu