MAC Address Randomization : tour d’horizon

1. Introduction

Depuis récemment, les systèmes de traçage Wi-Fi se multiplient. Ceux-ci enregistrent la présence des appareils équipés d’une interface Wi-Fi active au cours du temps (notamment les smartphones), ce qui permet entre autres de calculer leur mobilité (cf. une représentation schématique en figure 1). Des exemples existent dans de nombreuses villes de France et dans le monde : centres commerciaux à Paris et Rennes, musées et métro de Londres, le long de routes à Lyon et Houston... Une entreprise singapourienne effectue même la collecte à l’aide de drones. L’armée américaine utiliserait également des drones pour sniffer des villes entières en zone de conflit [1]. Le traçage Wi-Fi est donc un problème à l’échelle planétaire.

2. Traçage Wi-Fi : fonctionnement

S’il existe beaucoup de manières de tracer un smartphone moderne (cf. article de MISC n°81 [2]), se servir des données de la couche MAC est particulièrement efficace. Les appareils possédant une interface Wi-Fi active, afin de connaître la liste des réseaux proches disponibles, effectuent des scans. Pour cela, ils envoient continuellement des trames appelées probe requests, sollicitant une réponse des points d’accès alentours. Ce mécanisme s’appelle la découverte de service. Il est également possible pour les appareils d’attendre de recevoir les annonces des points d’accès alentours, mais ce mode de fonctionnement est moins utilisé par les smartphones, car il est plus lent (plus de latence), et consomme plus de batterie puisqu’il nécessite d’écouter la ligne plus longuement.

Le mécanisme de découverte de service rend le traçage trivial pour plusieurs raisons :

• les appareils possédant une interface Wi-Fi émettent des trames sur cette couche plusieurs fois par minute ;
• ces trames sont émises même si l’appareil n’est pas associé à un point d’accès (autrement dit, connecté à un réseau Wi-Fi) ;
• toutes ces trames contiennent un identifiant unique, l’adresse MAC de la carte Wi-Fi de l’appareil.

Cette adresse MAC est un numéro de série globalement unique de 6 octets, habituellement représenté sous le format suivant : ab:cd:ef:01:23:45. Les trois premiers octets constituent l’Organizationally Unique Identifer (OUI). Toute valeur de cet OUI doit être réservée (achetée) par les constructeurs pour pouvoir être utilisée. Cette association est publique. Par conséquent, l’adresse MAC par défaut d’une carte Wi-Fi permet de connaître son constructeur.

2.1 Et encore d’autres raisons de scanner

À noter aussi que, de manière problématique, beaucoup d’appareils modernes émettent des probe requests même si l’interface Wi-Fi est désactivée, afin de conserver les capacités de géolocalisation. En effet, on peut localiser un appareil par trilatération en connaissant les réseaux Wi-Fi proches. Sous Android, plusieurs options gèrent l’envoi de probe requests, dont une option « scan toujours actif ». Cette option est souvent bien cachée dans les options de l’appareil. Constatez par vous-même : sur un OnePlus One sous Oxygen OS (la version d’Android customisée de OnePlus), il faut aller dans Paramètres > Localisation > 3 petits points en haut à droite > Recherche pour trouver l’option (cf. figure 2). Même en la cherchant expressément, nous ne l’avons pas trouvée nous-mêmes [3].

De manière similaire, la dernière version d’iOS ne désactive plus les scans lorsque l’option Wi-Fi est désactivée. Cela est officiellement annoncé par Apple [4].

3. MAC address randomization : fonctionnement

Heureusement, une technique pour faire face à cette situation commence à se développer : le changement aléatoire d’adresse MAC (MAC address randomization, que nous abrègerons « randomization » dans la suite de cet article). Cette technique fut introduite dans un article de 2005 [5]. L’idée est simple : remplacer fréquemment l’adresse MAC par une nouvelle adresse aléatoire. Ainsi, un système de traçage ne sera plus en capacité d’effectuer le lien entre deux détections de trames émises par le même appareil, et ne pourra donc plus calculer sa mobilité.

4. Différences d’implémentations

La randomization commença à être implémentée en 2014 en tant que fonctionnalité principale de divers systèmes d’exploitation :

• iOS à partir d’iOS 8 ;
• Windows depuis Windows 10 ;
• Android depuis Android 6.0 (un patch gère également Android 5.0 pour certains appareils) ;
• certains drivers Linux depuis le kernel 3.18.

De par l’absence de standardisation, les différents fabricants se sont chacun mis à implémenter la randomization de leur propre manière. De plus, la technique nécessite un support correct de 3 composants produits par des acteurs différents pour fonctionner correctement :

• le firmware du chipset Wi-Fi ;
• le driver équivalent, commandant ce dernier ;
• les applications du système d’exploitation.

Ces dernières peuvent être multiples. Par exemple, sous Android, un processus système s’occupe de provoquer des scans réguliers, mais ceux-ci peuvent également être déclenchés par n’importe quelle application possédant la permission CHANGE_WIFI_STATE. En conséquence, on observe des patterns de scans irréguliers sur de nombreux appareils, notamment s’ils sont manipulés. Pour donner un exemple, la figure 3 montre les temps entre deux scans successifs sur un canal donné pour un Nexus 6P lorsque celui-ci est manipulé. On voit clairement que des scans ont lieu à intervalle régulier toutes les 30 secondes, suivis d’un nouveau scan une seconde plus tard. Mais de nombreux scans ponctuels cassent cette régularité. On observe une bien plus grande régularité sur un appareil non manipulé.

Un manque de support par un des trois composants impliqués dans la randomization peut expliquer une implémentation incomplète. Par exemple, un commentaire dans le premier driver Linux implémentant la randomization indique que l’adresse MAC ne peut pas être changée à chaque scan, par manque de support du firmware [6].

Voyons plus en détail les spécificités existantes dans les implémentations principales.

4.1 iOS

Apple a commencé à ajouter la randomization avec iOS 8. Dans cette version, elle n’est utilisée que lorsque les appareils sont en sleep mode et non associés. En pratique, il est laborieux de parvenir à obtenir des trames avec adresses aléatoires, même en cherchant activement à le faire. iOS 9 étend la randomization à des cas plus généraux. Nos tests montrent que la randomization est désormais activée lorsque l’écran est allumé.

Sous iOS, l’ensemble de l’adresse MAC est aléatoire, y compris les 3 premiers octets. Ceci efface la possibilité de savoir qu’une trame provient d’un appareil Apple, information pouvant être dérivée de ces octets.

Les appareils Apple que nous avons observés (iOS 8 et 9) conservent fréquemment la même adresse aléatoire sur plusieurs scans d’affilée.

4.2 Android

Sous Android, seuls les 3 derniers octets de l’adresse MAC sont aléatoires. Les trois premiers (OUI) prennent la valeur spécifique à Android DA:A1:19. Comme Android est open source, certaines surcouches constructeurs changent cet OUI. Par exemple, le Nexus 6 de Motorola remplace cet OUI par 92:68:C3.

Les appareils Android que nous avons testés (6.0) changent d’adresse à chaque scan.

4.3 Windows

Windows introduit une fonctionnalité intéressante : la randomization n’est pas utilisée uniquement pour la découverte de service, mais également tout au long de l’association. En conséquence, les appareils connectés à un réseau ne révèlent pas leur vraie adresse MAC. Pour ce faire, une adresse est générée à partir du nom de réseau, de l’adresse MAC et de deux clés secrètes (une relative au réseau et une propre à l’interface Wi-Fi) :

adresse = SHA256(SSID, adresse_mac, connection_id, secret)[0:6].

4.4 Tails

Tails, distribution Linux orientée anonymat, utilise une implémentation particulière. Au démarrage de la machine, une adresse aléatoire est générée et utilisée pour toute la session. Seuls les 3 derniers octets de l’adresse sont anonymisés.

5. Pourquoi ce n’est pas suffisant

Pour de nombreuses raisons, la randomization seule n’est pas suffisante. Les probe requests ne contiennent pas qu’une simple adresse MAC, ils sont riches en informations pouvant être exploitées pour effectuer le lien entre deux trames, voire créer un fingerprint de l’appareil cible. Un fingerprint (empreinte) est un identifiant de l’appareil créé à partir des différentes informations récupérées. Si cet identifiant n’est pas unique, on parle de quasi-identifiant.

5.1 SSIDs

Le premier problème, et pas des moindres, est connu depuis longtemps. Il s’agit du fait que les noms de réseaux connus de l’appareil (Service Set IDentifiers ou SSIDs) sont souvent ajoutés aux probe requests. En effet, tous les appareils n’ont pas encore abandonné ce mode de fonctionnement au profit des probe requests dites « broadcast » contenant un SSID nul et forçant tous les points alentours à répondre.

Ce problème est plus large que celui qui nous intéresse aujourd’hui, puisque les noms de réseaux connus possèdent de l’information supplémentaire sur leur utilisateur. Leur sémantique peut par exemple contenir des noms de personnes ou de lieu, voire des informations sensibles (« Juvenile Detention Classroom » est un vrai nom de réseau rencontré in the wild). Les noms de réseaux uniques peuvent être reliés à une localisation précise via des bases de données publiques [7].

Pour revenir à notre problème, un SSID utilisé par une seule personne dans une population cible (par exemple, un réseau domestique) pourra faire office d’identifiant unique. Une combinaison de SSIDs plus communs peut facilement aboutir au même résultat. Changer l’adresse MAC n’est alors plus vraiment utile si les probe requests contiennent un autre identifiant unique.

5.2 Numéros de séquence

Les numéros de séquences (sequence numbers) peuvent également être exploités pour faire le lien entre deux groupes de trames proches. En effet, ceux-ci changent de façon prédictible (très généralement contiguë). Un changement d’adresse ne passe alors pas inaperçu : cf. figure 4.

Il est à noter que les numéros de séquence sont inutiles pendant la découverte de service. Ils pourraient sans soucis être laissés à 0 ou prendre une valeur aléatoire.

5.3 Autres identifiants prédictibles

Sur le même modèle que les numéros de séquences, d’autres identifiants dont la valeur change de façon prédictible d’une trame à l’autre peuvent servir à faire le lien entre plusieurs trames émises avec des adresses MAC différentes. C’est le cas par exemple d’un champ nommé Dialog Token, présent dans les trames du protocole Wi-Fi Direct, un protocole permettant l’échange de données directement entre deux stations (clients Wi-Fi).

Un autre exemple est le scrambler seed, un champ de la couche physique utilisé par une des méthodes de codage de l’information utilisée dans les technologies Wi-Fi, OFDM (Orthogonal Frequency-Division Multiplexing). Afin d’améliorer les performances du codage, les trames sont XORées avec une valeur générée par un PRNG à partir d’une graine (le scrambler seed). Cette graine est ajoutée à chaque trame afin que la cible puisse la décoder. Le problème qui nous intéresse est que cette graine varie de façon prédictible, voire pas du tout (selon les implémentations) et peut donc être utilisée comme identifiant ou quasi-identifiant d’un appareil. Notons que, comme ce dernier cas exploite un champ de la couche physique, il nécessite l’emploi d’un matériel plus avancé (et coûteux) qu’une simple carte Wi-Fi.

5.4 Information Elements

Il reste un dernier champ contenant de l’information intéressante : les Information Elements (IEs, aussi appelés tags ou tagged parameters). Ceux-ci servent à indiquer les capacités de l’appareil vis-à-vis de nombreux protocoles (débits supportés, nombre de porteuses disponibles, support de nombreux aspects de protocoles...). Par exemple, l’IE « HT capabilities » représenté en figure 5 indique de nombreuses informations relatives au support du Wi-Fi sur la bande des 5 GHz.

Ces IEs étant présents en grande quantité, ils peuvent être utilisés pour former un fingerprint de l’appareil. Afin de quantifier l’information apportée par chaque champ, on peut utiliser l’entropie, qui mesure cela.

L’entropie donne une mesure en bits, bits d’entropie signifiant qu’un appareil est identifiable parmi en moyenne dans un jeu de données. L’entropie se calcule de la manière suivante :

où f_i,_j est la fréquence de la valeur j pour l’élément i dans le jeu de données.

Pour cette étude, nous nous sommes inspirés de Panopticlick, outil en ligne assez célèbre qui effectue ce calcul pour les navigateurs web [8].

Après quantification sur d’importantes bases de données de probe requests (jusqu’à 8 millions d’enregistrements), nous avons trouvé les résultats suivants.

Si on considère chaque IE individuellement :

• un IE unique peut apporter plus de 5 bits d’entropie ;
• tous les IEs étudiés (une dizaine parmi les plus courants) conservaient toujours la même valeur dans toutes les trames émises pour plus de 95% des appareils ;
• certains IEs, tels que « Supported rates » (qui, comme son nom l’indique, donne les débits supportés), sont présents dans presque toutes les probe requests observées ;
• pour prendre un exemple, l’IE « HT capabilities info » est un sous-champ de l’IE présenté en figure 5. Sur l’un de nos jeux de données, cet IE apporte 4.74 bits d’entropie, est ajouté dans les probe requests de 90% des appareils et ne change jamais de valeur pour 95.9% de ceux-ci.

Si on considère l’ensemble des IEs ajoutés dans les trames d’un appareil donné, l’entropie doit être calculée pour le tout. On ne peut pas simplement additionner les entropies individuelles, car il y a de fortes dépendances dans les probabilités de présence des différents IEs. Nous avons calculé l’entropie globale des 12 IEs les plus répandus, et avons obtenu les résultats suivants :

• les valeurs de l’ensemble de ces IEs ne changent pas d’une trame à l’autre pour 90% des appareils.
• on obtient jusqu’à 7 bits d’entropie pour un jeu de données de 10 000 appareils, soit la possibilité d’identifier un appareil parmi 128.

Si ce chiffre de 1 parmi 128 peut paraître faible en comparaison de la taille du jeu de données, il faut prendre en compte le fait que ce dernier s’étale sur plusieurs mois. Les informations présentes dans les IEs peuvent servir dans des cas plus locaux, où la probabilité d’identifier uniquement un appareil serait plus élevée (sur une journée ou sur une heure par exemple).

5.4.1 WPS

En plus de l’entropie apportée par chacun de ces champs, il n’est pas impossible de carrément rencontrer des identifiants uniques dans ces IEs. Cela est problématique, puisque c’est précisément ce que l’on cherche à éviter avec la randomization. C’est notamment le cas avec l’IE indiquant le support du protocole WPS (protocole permettant de s’associer à un point d’accès en appuyant sur un bouton physique sur celui-ci, ce qui est déjà critiquable en terme de sécurité). Cet IE, utilisé par 4 à 8% des appareils dans nos jeux de données, contient un UUID, identifiant unique par définition. Comme si cela ne suffisait pas, la RFC relative aux UUIDs préconise leur génération à partir d’une adresse MAC [9]. L’implémentation majoritaire de cette génération est celle du logiciel wpa_supplicant. L’algorithme utilisé est présenté en figure 6. La seed utilisée pour le SHA1 étant publique (dans le code source de wpa_supplicant) et l’espace des adresses MAC possible étant assez réduit, on peut donc retrouver les adresses MAC utilisées pour générer le UUID par brute-force en seulement quelques secondes de calcul. C’est ce que nous avons fait, en obtenant pour résultat que l’adresse MAC des appareils utilisant cet IE est retrouvable de cette manière dans pas moins de 95% des cas.

5.5 Timing

Des travaux antérieurs ont montré la possibilité de créer un fingerprint d’un appareil à partir du pattern d’émission de ses probe requests. Ces travaux utilisaient plusieurs heures de trafic pour entraîner un classifieur, alors en mesure de décider si une autre capture de trafic provenait du même appareil ou non. Dès lors que la randomization est utilisée, cela devient plus difficile. Une adresse MAC n’est gardée que lors d’un scan unique, ce qui ne laisse qu’un faible nombre de probe requests pour entraîner notre classifieur.

Toutefois, nous avons quand même réussi à obtenir quelques résultats montrant que le timing pouvait toujours apporter un peu d’information sur les appareils et ainsi former un quasi-identifiant. Plusieurs algorithmes de machine learning (apprentissage supervisé ou non) sont capables de déterminer avec une précision supérieure à celle d’un choix aléatoire si deux jeux de probe requests donnés proviennent du même appareil ou non à partir de leur timing (66% de précision contre 50% pour un choix aléatoire).

5.6 Autres soucis d’implémentations

Lors de nos tests sur différents appareils récents, nous avons pu constater d’autres manquements dans les implémentations de la randomization. Par exemple, les firmwares de certains chipsets génèrent des adresses aléatoires avec un biais tellement fort que nombre d’entre elles sont réutilisées plusieurs fois par le même appareil. Il est aussi courant de voir un appareil utilisant une adresse aléatoire lancer un scan avec sa vraie adresse MAC sous certaines conditions (par exemple, il suffit que l’écran soit allumé pour le Nexus 6P).

Pour prendre un exemple concret, voici ce que nous avons pu observer pour le Nexus 6P, un smartphone sous Android 6.0 sorti fin 2015. Pour ce faire, nous avons capturé son trafic avec plusieurs cartes en mode monitor, sur plusieurs canaux, pendant plusieurs jours :

Nous avons testé 6 smartphones récents de cette manière (Android et iOS), et avons trouvé des soucis similaires sur tous ceux-ci (au moins 2 par appareil).

5.7 Attaques actives

Si nous avons décrit jusque là des attaques utilisant des informations collectées passivement sur les trames émises, les attaques actives ne sont pas non plus à négliger. La randomization est utilisée dans la plupart des implémentations uniquement pour la découverte de service (à part celle de Windows 10), ce qui fait que d’autres cas de figure peuvent révéler accidentellement l’adresse MAC réelle de l’appareil. Par exemple, la célèbre attaque Karma consiste à publier un nom de réseau connu de la cible pour que celle-ci effectue une demande d’association. Si le but d’une telle attaque est généralement de se placer en position de man-in-the-middle, celle-ci peut être utilisée dans notre cas pour récupérer l’adresse réelle. En effet, toutes les trames échangées à partir de la demande d’association seront effectuées avec l’adresse MAC réelle dans la plupart des implémentations.

D’autres protocoles peuvent être utilisés pour parvenir au même résultat, par oubli d’adaptation du protocole à la randomization. Les appareils utilisant Wi-Fi Direct ajoutent un Information Element contenant peu d’informations sur leur capacité à gérer les différentes options de ce protocole. Afin de les obtenir, une autre station enverra une requête ANQP (Access Network Query Protocol). Nous avons montré que dans certaines implémentations, cette réponse utilise la vraie adresse MAC de l’appareil, même s’il utilise la randomization [10].

5.8 Autres détails d’implémentation

Pour être exhaustifs, mentionnons aussi le fait que d’autres techniques peuvent encore être élaborées pour récupérer de l’information sur un appareil. Pour cela, on peut s’inspirer des techniques de fingerprinting de driver de carte Wi-Fi qui existent dans la littérature. Par exemple, on peut récupérer des informations relatives au champ duration, à l’adaptation de la vitesse de transmission à la charge du réseau, ou encore à l’implémentation des mécanismes de CSMA/CA ou de RTS/CTS [11].

5.9 Autres couches et interfaces

Bien entendu, il ne faut pas oublier qu’un smartphone possède de nombreuses interfaces dont les données peuvent être croisées. Le Bluetooth et les différents protocoles cellulaires possèdent également des failles qui peuvent être exploitées. De plus, d’autres couches du modèle OSI peuvent être à leur tour la cible de fingerprinting pour récupérer des identifiants potentiels. Dans notre cas, c’est la couche physique qui nous intéresse, puisque les appareils non associés à un point d’accès ne produiront pas de trafic sur les couches plus hautes que la couche liaison de données. Je vous renvoie à l’article de MISC n°81 pour plus de détails sur ces techniques. Les techniques nécessitant d’extraire de l’information de la couche physique sont cependant généralement plus coûteuses, car elles nécessitent l’emploi d’un matériel plus élaboré (et coûteux) qu’une simple carte Wi-Fi en mode monitor.

Conclusion

L’ajout progressif de la technique de changement aléatoire de l’adresse MAC (MAC address randomization) est une bonne chose pour la défense de la vie privée des utilisateurs d’appareils Wi-Fi portatifs. Cependant, de nombreux manquements existent encore dans toutes les implémentations, car des techniques existent pour récupérer de l’information sur un appareil et possiblement créer un nouvel identifiant unique de celui-ci.

Heureusement, le déploiement de la randomization continue et s’améliore progressivement. Par exemple, Google s’y est attelé sur la base de nos recommandations. À partir de la version 8 d’Android (Oreo), les probe requests ne contiendront plus que deux Information Elements, nécessaires au fonctionnement correct du protocole [12].

Nous avons également produit une liste de recommandations pour une implémentation correcte de la randomization. Dans les grandes lignes, cette liste suggère de corriger les problèmes détaillés dans cet article [13].

Afin de garantir une bonne implémentation par les différents constructeurs, l’idéal serait qu’un standard s’impose et soit inclus aux spécifications de la norme 802.11. Il ne faut pas oublier que les différences d’implémentations apportent de l’information sur un appareil, et peuvent donc servir de levier à l’identification d’un appareil dans un jeu de données. Pour aller dans ce sens, nous avons présenté les résultats de nos recherches au groupe d’étude IEEE 802 relatif à la vie privée (IEEE 802 EC Privacy Recommendation Study Group).

Les lecteurs intéressés par plus de détails concernant les différents aspects abordés dans cet article pourront se diriger vers mon manuscrit de thèse [14].

Remerciements

Je remercie Mathieu Cunche pour la relecture de cet article et l’encadrement de ma thèse en général.

Références

[1] Jeremy Scahill and Glenn Greenwald. The NSA’s secret role in the U.S. assassination program. The Intercept, 2014.

[2] Célestin Matte. Fingerprinting de smartphones : votre téléphone est-il traçable ? - MISC n°81, septembre 2015

[3] Célestin Matte, Mathieu Cunche, and Vincent Toubiana. Does disabling Wi-Fi prevent my Android phone from sending Wi-Fi frames ? Research Report RR-9089, Inria - Research Centre Grenoble – Rhône-Alpes ; INSA Lyon, août 2017.

[4] https://support.apple.com/en-us/HT208086

[5] Marco Gruteser and Dirk Grunwald. Enhancing Location Privacy in Wireless LAN Through Disposable Interface Identifiers : A Quantitative Analysis. In : Mobile Networks and Applications 10.3 (2005)

[6] Emmanuel Grumbach. Iwlwifi : mvm : support random MAC address for scanning. Linux commit effd05ac479b , 2014.

[7] https://wigle.net

[8] https://panopticlick.eff.org/

[9] P. Leach, M. Mealling, and R. Salz. A Universally Unique IDentifier (UUID) URN Namespace. RFC 4122. Internet Engineering Task Force, juillet 2005.

[10] Mathy Vanhoef, Célestin Matte, Mathieu Cunche, Leonardo Cardoso, and Frank Piessens. Why MAC Address Randomization is not Enough : An Analysis of Wi-Fi Network Discovery Mechanisms. In AsiaCCS,mai 2016

[11] KN Gopinath, Pravin Bhagwat, and K Gopinath. An empirical analysis of heterogeneity in ieee 802.11 MAC protocol implementations and its implications. In Proceedings of the 1st international workshop on wireless network testbeds, experimental evaluation & characterization, ACM, 2006.

[12] Giles Hogben. Changes to Device Identifiers in Android O. https://android-developers.googleblog.com/2017/04/changes-to-device-identifiers-in.html. 2017.

[13] [STDS-802-Privacy] Guidelines proposition for correct implementation of MAC address randomization, http://grouper.ieee.org/groups/802/PrivRecsg/email/msg00278.html

[14] Célestin Matte. Wi-Fi Tracking : Fingerprinting Attacks and Counter-Measures. 2017. Thèse de doctorat. Université de Lyon.