Le lieu choisi se situe le long de la “Petite Ceinture” (ancienne voie ferrée qui fait le tour de Paris), sur une portion ouverte aux promeneurs, sous le pont de l'avenue Jean Moulin (Paris XIVe).

Vidéo de présentation (2')

Avantages :

• on capte très peu de signaux Bluetooth venant de l'environnement (2 adresses MAC dans le cas de l'exemple),
• les individus passent “au compte-gouttes” (surtout en semaine en hiver !),
• ils sont en mode “promenade” donc plutôt disposés pour papoter,
• on est à l'abri de la pluie

Détails du dispositif de capture : Détection des signaux BT en environnement Linux

1/ Toutes les adresses détectées (115), qu'elles soient liées au passage de promeneurs sur la petite ceinture ou à des appareils “parasites” plus lointains, sont clairement identifiées par l'analyseur btmon.

Les principales sources détectées sont :

1. appareil Apple (environ 95%)
2. application TousAntiCovid (environ 1%)
3. autres (adresses public BR/EDR : étiquette de smartphone, appareils audio…)

2/ Toutes… sauf 2 !! Pour ces adresses, l'analyseur n'apporte aucune information de type constructeur et/ou UUID : seraient-ce des signaux émis par des personnes à la suite d'injections ? Cela reste à déterminer et, si c'est le cas, la proportion est faible ce qui rend la mise en évidence beaucoup plus difficile.

3/ Dans de nombreux cas (“balise” iPhone ou TAC), l'émission du PKM ne s'accompagne pas de l'émission de l'étiquette du smartphone. On ne détecte donc pas le smartphone en tant que tel (caractérisé par : signal type BR/EDR et mention “Major class : Phone” .. Minor Class : Smartphone“).

4/ Une dizaine de rencontres avec des détenteurs d'iPhone m'a permis de conclure que l'indication de l'information Apple par btmon est fiable, c'est-à-dire que cette indication correspond bien à la présence d'un appareil Apple à proximité et que cet appareil est bien la source de l'adresse PKM.

5/ À propos des iPhone, il est important de noter que, à partir des versions 7 ou 8 (à préciser), une balise peut-être émise alors que la fonction BT semble éteinte. En fait, sur ces appareils il y a 2 niveaux d'activation du BT :

1. Un “gros” bouton qui rend le smartphone visible (avec son étiquette) et l'échange de fichiers possible
2. Si ce 1er bouton est “off”, cela coupe la visibilité nominative mais des émissions BT sont LE toujours possibles en tache de fond. Il faut se rendre dans les paramètres pour sélectionner les émissions autorisées.

La mise en “Mode Avion” coupe toute émission.

• Présentation récapitulative des sessions 1 à 3 (vidéo - 13')
• Fichier tableur récapitulatif (.ods)

• 55 minutes
• 17 personnes sont passées (souvent seule mis à part un groupe de 4 et un groupe de 3).
• 2 cas de signaux “PKM”.
• L'un des PKM était lié à un monsieur “à la veste jaune” qui est passé dans un sens puis dans l'autre environ 15 minutes plus tard : j'ai entamé la discussion lors du second passage.

• Vidéo "rapport" de la session (présentation des captures et analyses - 10')
• Fichier tableur récapitulatif (.ods)
• Annexe 1 : Analyse complémentaire avec puissance du signal (vidéo 4'30) : Où l'on montre la corrélation très nette entre la puissance du signal (valeur RSSI) et la présence d'une personne “émettrice”, du moins dans le cas où l'émission vient d'un smartphone.
• Annexe 2 : Précision à propos de la lecture de la feuille "log adresses MAC" (vidéo 2'30)

Conclusion : l'adresse PKM était émise par l'iPhone du bonhomme (= balise iBeacon) L'émission a lieu même lorsque la fonction BT est éteinte ! Il a fallu placer l'appareil en “mode avion” pour que la balise disparaisse.

Remarques :

• 2 smartphones “étiquettés” sont apparus : 1 BlackView, 1 Redmi
• 2 personnes (sur 17) ont semblé être source d'un PKM. Par comparaison, lors de mes sessions à Montsouris en août dernier, j'avais évalué la fréquence à 1 PKM pour 2 personnes. L'échantillon de ce jour était-il particulièrement biaisé ou bien y aurait-il eu une tendance globale à la baisse de cette fréquence ?
• sur les 10 PKM captés, 9 sont identifiés comme provenant de “Apple Inc.” par le logiciel btmon.

Données brutes :

• Capture écran et audio intégrale (55') (j'ai camouflé l'écran sur la portion 17'10 - 17'50 : je consultais ma boîte mails !)
• Log btscan-shell (.txt)
• Log btmon (.txt)

• 30', de 15h15 à 15h45
• beaucoup plus de passage qu'hier (beau temps, après-midi) : je n'ai pas réussi à suivre

• cas très intéressant à 15h18 - 15h21 : deux dames passent. L'une d'elles est manifestement liée à un “PKM” (6A:62…). Je ne m'en suis pas rendu compte sur le moment, mais la mention “ManufacturerData Key” ne s'est pas affichée. De fait, l'analyse du log Btmon montre que le PKM n'est associé à aucun constructeur.

En outre, à 15h19'38” on assiste à un “changement de masque” : 6A:62… est remplacé par 7E:85…

• Pour cette nouvelle adresse, toujours aucune info constructeur. L'analyse des logs d'apparition des adresses et puissance RSSI montre que l'une a remplacé l'autre. Puis a disparu dès que les dames se sont éloignées.

Manque de pot, elles ne souhaitaient pas prendre davantage part à l'étude.

• Pour ces deux PKM, btmon indique :
  • 6A:62… : Unknown (0xfd64) Service Data (UUID 0xfd64): d146438de87da3b0bb4aab8dc9b0901402e7
  • 7E:85… : Unknown (0xfd64) Service Data (UUID 0xfd64): d146438de87da3b0bb4af8a91275810002e7

• Après recherches, il s'avère que cela provient de l'application TAC. UUID0xFD6FTracer :

TousAntiCovid n'utilise pas le cadre de Exposure Notification Framework développé par Google et Apple, mais met en œuvre l'échange d'informations de contact lui-même. La fonctionnalité est très similaire - seul l'UUID de la BluetoothLE Beacon est 0xFD64 (au lieu de 0xFD6F).

• Vidéo "rapport" de la session (10'30)
• Fichier tableur récapitulatif (.ods)
• Point méthode : récupération des infos constructeur pour chaque adresse "MAC" détectée (vidéo - 8')

Conclusion :

sur 45 adresses PKM “4-7” détectées :

• 2 sont des adresses BT Classic (étiquettes de smartphones, de type “public”)
• 4 sont produites par TAC
• 39 (le reste) sont indiquées comme émises par des appareils “Apple Inc.”

Donc pas de place pour des émissions liées à des injections, à moins que celles-ci ne soient “déguisées” en appareils Apple !!

Données brutes :

• Capture écran et audio intégrale (25')
• Log btscan-shell (.txt)
• Log btmon (.txt)

• 45', de 15h15 à 16h environ.
• 31 PKM, dont 24 identifiés “Apple, Inc.”, 0 TAC, 7 divers (1 étiquette de smartphone -adresse BR/EDR-, 4 appareils audio, 2 à clarifier).
• 5 personnes détentrices de iPhone ont accepté de participer à des observations.

• Fichier tableur récapitulatif (.ods)

Conclusions :

• Pour chacune des 5 personnes “iPhone”, l'adresse détectée est identifiée par btmon comme provenant d'un appareil Apple. Lorsque l'iPhone est mis en “BT off” ou en “Mode Avion”, le PKM n'est plus affiché : cela montre que le PKM est effectivement émis par cet appareil, et que l'indication de btmon est fiable.

• 3 personnes avaient un iPhone 5 ou 6 : pour ces appareils, la diffusion du PKM cesse dès lors que le BT est éteint.
• 2 personnes avaient des iPhone plus récents (8 et 10(X)). Pour les 2, une balise peut-être émise alors que la fonction BT semble éteinte. En fait, sur le modèle X, il y a 2 niveaux d'activation du BT :

1. Un “gros” bouton qui rend le smartphone visible (avec son étiquette) et l'échange de fichiers possible
2. Si ce 1er bouton est “off”, cela coupe la visibilité nominative mais des émissions BT sont LE toujours possibles en tache de fond. Il faut se rendre dans les paramètres pour sélectionner les émissions autorisées.

La mise en “Mode Avion” coupe toute émission.

• Pour 2 PKM*, btmon n'apporte aucune information permettant d'identifier l'émetteur. C'est la première fois que je trouve des adresses aussi “muettes”. Compte-tenu de la puissance des signaux signal (maxi inférieur à -80dB), elles étaient probablement liées à des personnes qui ne sont pas passées par le tunnel : il n'y avait pas moyen de récolter davantage d'info. Ce type d'adresse reste à éclaircir.

* 4B:02:10:DF:80:CF et 4C:F7:C1:07:50:23, en même temps, entre 15:51:29 et 15:52:29.