Rapport du projet de fin d’étudesInterception des échanges dans une connexion

SSL/TLSApplication à l’analyse des données de

géolocalisation envoyées par un smartphone

François-Xavier Aguessy Côme Demoustier

Encadrant : Olivier Paul

SSR 2011-2012

Sommaire

Introduction 3

I Géolocalisation et application aux smartphones 4

1 Les méthodes de géolocalisation 41.1 Géolocalisation par satellite . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.2 Géolocalisation par Wi-Fi . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41.3 Géolocalisation par GSM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51.4 Géolocalisation hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Les utilisations de la géolocalisation par un smartphone 62.1 Navigation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2 Informations à proximité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.3 Gardiennage virtuel (ou geofencing) . . . . . . . . . . . . . . . . . . . . . . 72.4 Publicité ciblée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

II Rappels sur les protocoles de sécurité 9

3 Les protocoles HTTP et HTTPS 9

4 Les protocoles SSL et TLS 9

5 Les certificats, leur intégration système et le processus d’authentifica-tion 10

III Étude du proxy et de l’architecture 13

6 Architecture de base 13

7 Les proxys HTTP et HTTPS 137.1 Proxy HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147.2 Proxy HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

IV Mise en pratique et résultats 15

8 La mise en place d’un proxy transparent 158.1 Proxy transparent HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158.2 Proxy transparent HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158.3 Proxy HTTPS autoconfiguré . . . . . . . . . . . . . . . . . . . . . . . . . . 17

9 Protocol Buffers 199.1 Les varints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199.2 Interpréter les protocol buffers . . . . . . . . . . . . . . . . . . . . . . . . . 199.3 Exemple de décodage de données encodées en Protocol Buffer . . . . . . . . 20

10 Échanges des données de localisation sur iOS 2210.1 Données envoyées lors de la géolocalisation du téléphone . . . . . . . . . . . 2210.2 Données envoyées pour constituer la base de données de BSSID d’Apple . . 24

1

11 Localisation et Sécurité sur Android 2911.1 Contexte de l’analyse sur OS Android . . . . . . . . . . . . . . . . . . . . . 29

11.1.1 Émulateur Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2911.1.2 Machine Virtuelle Android . . . . . . . . . . . . . . . . . . . . . . . 3011.1.3 Téléphone sous OS Android . . . . . . . . . . . . . . . . . . . . . . . 31

11.2 Préambule à l’étude de la localisation sur Android . . . . . . . . . . . . . . 3111.2.1 Choix de la version du système . . . . . . . . . . . . . . . . . . . . . 3111.2.2 Installation du SDK et outils du SDK . . . . . . . . . . . . . . . . . 3211.2.3 "Unlock" et "Rootage" de l’HTC Desire HD . . . . . . . . . . . . . . 3211.2.4 Outils de sécurité Android et transition à la géolocalisation . . . . . 34

12 Etude des données de géolocalisation sur Android et des échanges asso-ciés 3612.1 Premiere analyse système orienté sur la localisation . . . . . . . . . . . . . . 3612.2 Localisation ponctuelle avec Google Maps . . . . . . . . . . . . . . . . . . . 39

12.2.1 Description de la manipulation . . . . . . . . . . . . . . . . . . . . . 3912.2.2 Observation des échanges sur le proxy . . . . . . . . . . . . . . . . . 39

12.3 Localisation périodique et silencieuse avec www.Google.com/loc/m/api . . . 42

V Vie privée et proposition de solutions 45

13 Réglages appropriés du smartphone 4513.1 Réglages sur un iPhone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4513.2 Réglages sur Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

14 Filtrage 46

15 Solutions logicielles 4715.1 Serveur copie du serveur distant . . . . . . . . . . . . . . . . . . . . . . . . 4715.2 Autres solutions envisagées . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Conclusion 49

Annexes 50

A Certificat AC racine du proxy 50

B Protocol Buffer 51B.1 Tableau des wire type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

C Décodage des données interceptées lors de la localisation d’un iPhone 51C.1 Fichier .proto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51C.2 Script python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

D Décodage des données d’utilisations envoyée par un iPhone à Apple 52D.1 Fichier .proto envoi de BSSID . . . . . . . . . . . . . . . . . . . . . . . . . . 52D.2 Fichier .proto envoi d’antennes GSM . . . . . . . . . . . . . . . . . . . . . . 52D.3 Script python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53

E Serveur copie d’Apple 54E.1 Script python wloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54E.2 Script de test du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56

E.2.1 Fichier .proto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

2

Introduction

Ce rapport constitue un compte-rendu complet de notre Projet de Fin d’Études concer-nant l’interception de données dans une connexion SSL grâce à un proxy. L’objectif premierde cette interception est d’étudier les échanges de données de géolocalisation sur les OSmobiles iOS et Android. Nous présentons donc ici nos résultats "pratiques" précédés derappels théoriques sur la géolocalisation, les échanges sécurisés et sur les certificats. Unesection sera aussi consacrée à l’étude du Protocol Buffer qui occupe une part très impor-tante dans le décodage des données de géolocalisation.

L’origine de ce projet a été un article publié dans le magasine MISC [1] à propos desdonnées de géolocalisation sur iPhone et qui nous explique l’intérêt d’un proxy HTTPSdans les échanges SSL. Celui-ci permet en effet, grâce à l’équivalent d’un Man-in-the-Middle d’obtenir des données confidentielles. Les applications pourraient être très diverseset être menées sur de nombreux types de données telles que des données bancaires, maisnous nous intéresserons dans ce rapport uniquement aux données de géolocalisation.

Au travers de ce rapport, nous avons aussi tenu à décrire les réflexions, les démarches,les tests, les opérations intermédiaires que nous avons dû effectuer pour répondre à notreproblématique, tout ceci afin de refléter l’évolution du projet. Toutes nos sources et bases derecherche seront référencées puis détaillées dans une bibliographie en fin de document. Enannexe, nous présentons des documents et des travaux ayant un rapport direct avec l’étude,mais à lire de préférence en parallèle pour ne pas perdre la logique et l’enchainement durapport.

Il est dès à présent intéressant de faire remarquer que l’étude sur iOS et l’étude surAndroid ont été abordées sous le même angle en terme d’objectif pour établir une compa-raison pertinente, mais la manière de s’approprier les deux systèmes et de mener à bienles analyses a été différente. Ainsi, l’étude sur Android propose un préambule sur le sys-tème permettant d’obtenir un maximum de résultats alors que les échanges sur iOS, plussimples, ont permis d’envisager une solution de protection de la vie privée plus aboutie.

3

Première partie

Géolocalisation et application auxsmartphones1 Les méthodes de géolocalisation

Les smartphones disposent de plus en plus d’applications liées à la géolocalisation. Eneffet, ceux-ci peuvent maintenant devenir de véritables navigateurs GPS, donner des infor-mations sur des lieux, personnes ou activités à proximité, mais aussi s’adaptent de plus enplus à la position à laquelle ils se trouvent : alertes lorsque l’on rentre dans un périmètre,changement de profil lorsque l’on arrive au travail,... La géolocalisation est donc devenueun élément crucial pour les smartphones. Il existe de nombreuses techniques pour se géolo-caliser. Chaque technique a ses particularités et ses avantages, et les constructeurs utilisentdésormais plusieurs techniques complémentaires pour géolocaliser plus précisément et plusrapidement les smartphones. Nous allons décrire dans cette partie les différentes techniquesqui peuvent être utilisées pour se géolocaliser.

1.1 Géolocalisation par satellite

La géolocalisation par satellite est la technologie de géolocalisation la plus répandueactuellement. Elle permet à un équipement de calculer sa position en utilisant les signauxémis par différents satellites. Le GPS est la constellation de satellites la plus utilisée dansle monde pour la géolocalisation. Elle est constituée de satellites américains. Il en existed’autres similaires, par exemple GLONASS (Russie) et Galileo (Union Européenne).

Pour se géolocaliser, une puce doit utiliser au moins 4 satellites [2], mais on considèrequ’en moyenne, à chaque instant, une puce GPS peut recevoir en moyenne les signaux de6 satellites différents. Pour calculer sa position, une puce GPS doit mesurer sa distanceavec 3 satellites. Pour cela elle utilise le temps parcouru depuis entre le satellite et lapuce. Cependant, l’heure du terminal n’étant pas parfaitement précise, il est nécessaire dedéterminer le décalage temporel du terminal grâce à un quatrième satellite.

Figure 1 – Trilatération [3]

Avec les distances mesurées, la puce GPS effectue unetrilatération. La trilatération est un principe similaire àla triangulation, car elle permet de calculer la positiond’un point à partir de plusieurs mesures, mais, contraire-ment cette dernière, elle utilise des points d’intersectionde sphères. Bien sûr, le système GPS est capable d’affinerles mesures si plus de satellites sont à portée.

Ce système de géolocalisation est assez précis (une di-zaine de mètres près), mais les puces présentes sur lessmartphones sont très petites, et ne reçoivent donc qu’unsignal provenant des satellites très atténué ce qui fait quela géolocalisation par satellite n’est possible qu’en exté-rieur et est assez lente.

1.2 Géolocalisation par Wi-Fi

La géolocalisation utilisant les points d’accès Wi-Fi est une technologie beaucoup plusrécente, particulièrement adaptée à la ville. Pour se géolocaliser, un smartphone commence

4

par dresser la liste de tous les BSSID présents autour de lui. Les BSSID sont les adressesMAC des cartes réseau Wi-Fi des points d’accès. Ceux-ci sont envoyés régulièrement parles points d’accès pour permettre aux terminaux Wi-Fi de s’y connecter. Une fois une listedes BSSID à proximité établie, il y a deux possibilités :

– soit le téléphone envoie cette liste à un serveur qui connaît la plupart des coordonnéesgéographiques des points d’accès. Ce serveur calcule alors la position du smartphoneet la lui envoie.

– soit le téléphone envoie une partie de la liste des BSSID au serveur, qui lui répondune liste de BSSID sur un plus grand périmètre avec leurs coordonnées et c’est lesmartphone qui calcule sa position.

Pour permettre cette géolocalisation à l’aide des points d’accès Wi-Fi, il faut aupara-vant établir une liste la plus complète possible des bornes Wi-Fi avec leurs cordonnées géo-graphiques (latitude, longitude). Celle-ci peut être établie de nombreuses façons, certainesbases de données sont publiques, d’autres peuvent être achetées (par exemple Skyhook [4]qui est utilisé notamment par Apple, Sony, Samsung...). Pour les créer ou les enrichir, il estpossible d’utiliser des données envoyées par les téléphones mobiles soit lorsqu’ils essayentde se localiser, soit en envoyant régulièrement les points d’accès qu’ils ont rencontrés. Ilest aussi possible d’utiliser des véhicules se déplaçant sur les routes principales et quienregistrent les données Wi-Fi qu’ils détectent avec leur position.

1.3 Géolocalisation par GSM

La géolocalisation par GSM a été utilisée avant la démocratisation des puces GPSdans les smartphones, mais continue de l’être. Cette géolocalisation utilise les antennesGSM à portée du téléphone, mais plusieurs techniques différentes permettent de calculersa position :

Géolocalisation par différence de temps observée (EOTD) : La distance avec l’an-tenne à laquelle est connecté le téléphone est calculée par le téléphone grâce au tempsécoulé entre l’émission et la réception d’une requête qu’il émet vers l’antenne.

Géolocalisation par l’identifiant de cellule : Cette géolocalisation utilise l’antenne àlaquelle est connecté le téléphone. Elle est identifiée avec l’ensemble identifiant decellules (Cell-Id), code de pays (MCC), code opérateur (MNC) et code de groupementde cellules (LAC). La position du téléphone sera estimée avec une précision pouvantaller de la centaine de mètres (en ville) à plusieurs kilomètres (à la campagne) suivantla portée de l’antenne. Elle a cependant l’avantage d’être très rapide.

Géolocalisation par triangulation : Cette technique de géolocalisation est une évolu-tion de la technique précédente, au lieu de se limiter à une seule antenne, le téléphonerepère plusieurs (au moins 3) antennes à portée et calcule alors sa position avec plusde précision.

Toutes ces techniques nécessitent de maintenir une base de données de toutes les an-tennes GSM avec leurs coordonnées, et de transmettre au téléphone les données dont il abesoin pour se géolocaliser. Il existe plusieurs bases de données dont certaines sont libres(par exemple OpenCellID [5]).

1.4 Géolocalisation hybride

La géolocalisation hybride utilise plusieurs des méthodes de géolocalisation évoquéesprécédemment. Elle peut ainsi combiner les avantages de la géolocalisation GSM (très ra-pide) Wi-Fi (rapide et très précis en ville) et GPS (précis et possible partout en extérieur).

5

Nous pouvons voir en Figure 2 le déroulement sous Android lorsqu’un utilisateur veut selocaliser.

Figure 2 – Calcul de la localisation sous Android [6]

La première étape est d’utiliser un cache de la dernière position connue, c’est évidem-ment le plus simple à effectuer, mais ne fonctionne que si le cache est très récent et que leterminal n’est pas en mouvement. Ensuite, le smartphone calcule une première estimationde sa position en utilisant les Cell-ID. Il calcule alors sa position en utilisant les pointsd’accès Wi-Fi. Si cette position n’est pas assez précise ou s’il n’y a pas de réseau Wi-Fi àproximité, le calcul de la position GPS est effectué. On peut ainsi voir que les téléphonesAndroid procèdent du plus rapide et moins précis (GSM), vers le plus lent et plus précis(GPS).

Il est bon de voir aussi que la géolocalisation par Wi-Fi est un très bon complémentdu GPS, car elle permet de se géolocaliser très précisément en ville où le signal GPS peutne pas être assez puissant, mais est totalement inefficace en campagne, là où le signal GPSest le plus fort. Nous pouvons voir un tableau de comparaison des différentes techniquesde localisation en Table 1.

Technologie GSM Wi-Fi GPS HybrideVitesse de géolocalisation Très rapide Rapide Lent Progressif

Utilisation de "data" Oui Oui Non Oui ou NonPrécision 100m–10km 10–50m 10–100m 10m–10kmFonctionne Mieux en ville Ville Mieux hors ville Partout

Table 1 – Comparaison des différentes techniques de géolocalisation

2 Les utilisations de la géolocalisation par un smartphoneComme nous l’évoquions dans l’introduction, les utilisations de la géolocalisation sont

de plus en plus importantes avec la très forte augmentation du nombre de smartphones quipossèdent tous des capacités à se localiser. Nous allons étudier les applications majeuresde cette technologie.

2.1 Navigation

La première utilisation grand public qui a été faite de la géolocalisation, depuis l’utili-sation de puces GPS dans les smartphones, est de transformer le smartphone en véritable

6

systèmes de navigation GPS. Celui-ci a l’avantage de toujours être en possession de l’uti-lisateur qui peut donc l’utiliser dès qu’il en a besoin. De plus, il possède des avantagesque la plupart des systèmes de navigations GPS existants n’avaient pas (mis à part lesmodèles haut de gamme) :

– Un accès aux données en permanence qui permet d’avoir des informations en tempsréel sur l’état du trafic, les travaux en cours...

– Une puissance de calcul élevée permettant de calculer un changement d’itinérairebeaucoup plus vite

– Une interface plus agréable à utiliser, avec un grand écran tactile– Les applications de navigation GPS même payantes reviennent beaucoup moins cherque d’acheter un GPS autonome si, bien évidemment, on possède déjà le smartphone.

– Les applications et les cartes qu’elles contiennent sont mises à jour régulièrement cequi permet d’avoir une cartographie à jour ce qui n’est pas le cas de tous les systèmesde navigations GPS.

Cependant, les applications de navigation sur smartphone n’ont pas que des avantagespar rapport aux systèmes de navigations GPS. En effet, souvent les appareils dédiés à lanavigation ont des puces et antennes GPS beaucoup plus performantes et permettent doncde garder le signal GPS même dans les grandes villes, ce qui n’est pas forcément le cas dessmartphones. Ils possèdent aussi l’avantage d’être un appareil dédié à la navigation, quidonc n’est pas victime des problèmes qui peuvent survenir sur un smartphone qui sert àbeaucoup d’autres usages : pannes, batterie vide...

2.2 Informations à proximité

Une utilisation majeure de la géolocalisation qui s’est fortement développée avec l’ex-pansion du smartphone est la possibilité d’avoir des informations sur ce qui est à proximité.Les applications sont multiples, elles peuvent concerner des monuments, restaurants, hô-tels, parking, gares, stations de métro... L’avantage est que la géolocalisation n’a pas besoind’être parfaite, seulement rapide. En effet, le plus important est de pouvoir déterminerla zone dans laquelle est l’utilisateur du smartphone, à une centaine de mètres près, celasuffit pour lui donner toutes informations sur les services qui l’entourent.

L’évolution de cette utilisation de la géolocalisation est la réalité augmentée. La réalitéaugmentée représente les systèmes permettant d’ajouter des informations à une représen-tation en 2 ou 3 dimensions de l’environnement réel de l’utilisateur souvent provenantde l’appareil photo d’un smartphone. C’est par exemple la vue en temps réel d’une ruepar l’appareil photo du smartphone sur laquelle on ajoute les stations de métro avec leurdistance. Pour la réalité augmentée, la géolocalisation est indispensable, afin de donner àl’utilisateur les informations les plus précises possible en fonction du lieu où il est.

2.3 Gardiennage virtuel (ou geofencing)

Le gardiennage virtuel est une utilisation récente de la géolocalisation sur les smart-phones. Cela consiste à effectuer des opérations sur un smartphone lorsqu’il rentre dansun périmètre défini. Cela peut par exemple permettre de donner des alertes à l’utilisateurdès qu’il arrive dans un endroit ou même de changer les paramètres du téléphone quandl’utilisateur arrive chez lui ou à son travail. Cela peut permettre aussi pour des parentsd’avoir une alerte lorsque leur enfant sort d’une zone de confiance. Plus généralement,avec le geofencing, il est possible de définir des zones dans lesquelles effectuer certainesactions personnalisées. C’est une utilisation qui est assez récente, mais qui se développerapidement puisque la plupart des smartphones de dernières générations sont compatibles.

7

2.4 Publicité ciblée

Cette dernière utilisation est particulièrement importante pour les entreprises, no-tamment pour Google qui en a fait son business model pour le système d’exploitationmobile Android. L’avantage du smartphone est qu’il est en permanence sur l’utilisateur.En connaissant en permanence la localisation d’un smartphone, il est possible de savoirpartout où est allé l’utilisateur et donc ce qu’il a fait et ce qui lui plaît. C’est ainsi quela publicité peut être ciblée en fonction des envies de l’utilisateur et adaptée aux lieux àcôté desquels il vit.

8

Deuxième partie

Rappels sur les protocoles de sécurité3 Les protocoles HTTP et HTTPS

Dans ce projet, les protocoles applicatifs utilisés sont HTTP et HTTPS pour deséchanges classiques client/serveur. Notre client sera le possesseur du smartphone au traversdes applications telles que Google Maps qu’il va utiliser. Les serveurs seront les serveursde Google et Apple pour leur service de localisation. Nous verrons que des services fonc-tionnant en arrière-plan sur les deux types de smartphone vont utiliser le protcole HTTPSpour initialiser "silencieusement" des connexions avec ces serveurs et échanger des donnéeschiffrées qui seront analysées avec le proxy.

En effet, le protocole HTTPS, Hypertext Transfer Protocol Secure, a été conçu àpartir du protocole HTTP pour supporter la protection par chiffrement des requêtes etdes réponses. Ce protocole permet à l’aide des certificats d’authentifier le serveur sur lequella connexion est souhaitée et d’engager une communication chiffrée sur le port 443. Ceprotocole emploie les mêmes requêtes que HTTP type HEAD, GET ou la requête POSTpour soumettre, comme dans le cadre de ce projet, des données encodées avec le ProtocoleBuffer de Google. HTTPS diffère de HTTP dans le fait qu’il va faire appel au protocoleSSL, celui-ci va prendre en charge toute la protection de la couche applicative. HTTPScorrespond donc au protocole HTTP implémenté au-dessus de SSL situé dans la couchesession du modèle OSI. A noter que l’authentification mutuelle est possible avec SSL, maissuppose que le client possède lui aussi un certificat.

Remarque : Le proxy implique une nouvelle entité dans les échanges, il se forme alorsune double connexion client - serveur décrite dans la partie Etude du proxy et de l’archi-tecture (8.2)

4 Les protocoles SSL et TLSSSL, Secure Socket Layer, assure donc une communication sécurisée entre le client

et le serveur. Ce protocole, aujourd’hui très répandu, doit sa réussite et son utilisationmassive à sa facilité d’implémentation. En effet, d’un côté son indépendance vis-à-vis de lacouche applicative évite le redéveloppement complet de nouvelles applications. D’un autrecôté sa particularité d’être basé dans la couche session sur la couche transport permetune adaptation facile au niveau réseau et au niveau du matériel. Bien que les conditionsd’utilisation et objectifs ne soient pas exactement les mêmes, une connexion SSL est, parexemple, bien plus légère et facile à administrer qu’un tunnel IPSec. Ainsi, des applicationstelles que HTTP et FTP ont vu leur version sécurisée naitre grâce à SSL : HTTPS etFTPS auxquels on a attribué les ports 443 et 990 au niveau de la couche transport. Pourun navigateur ou une application client, il suffira de faire appel aux librairies SSL puisouvrir un socket pour initialiser une connexion sécurisée avec le serveur distant devantsupporter lui aussi SSL. [7]

Ces librairies, disponibles librement avec le projet OpenSSL, vont notamment gérer leséchanges SSL comme le SSL "handshake", les certificats et les algorithmes de chiffrementtels que RSA pour l’échange de clés secrètes et AES pour le chiffrement des données.

SSL est construit selon 4 modules ou 4 sous-protocoles et le protocole SSL recordchargé de protéger les données en elles-mêmes [8](voir Figure 3) :

9

POP3S HTTPS TELNETS FTPS

SSL handshake protocol

SSL change cipher spec protocol SSL alert protocol SSL application

data protocolSSL record protocol

UDP TCP

IP

Figure 3 – Organisation du protocole SSL [8]

– Le protocole SSL handshake : initialise l’échange SSL avec l’authentification parcertificat, l’échange des paramètres de sécurités...

– Le protocole SSL change cipher spec : pour établir de nouveaux paramètres desécurité dans un échange

– Le protocole SSL alert : transmission d’alertes– Le protocole SSL application data : la couche applicative transmet directement sesdonnées au protocole SSL record pour les transmettre de façon sécurisée. Utiliséquand l’initialisation a été effectuée avec succès par le SSL handshake.

TLS, Transport Layer Security, correspond au protocole SSL repris par l’IETF danssa version 3.1.

5 Les certificats, leur intégration système et le processusd’authentification

Les certificats sont les éléments de base dans l’authentification des serveurs et parfoisdes clients. Un certificat a pour objectif d’éviter l’usurpation d’identité en faisant inter-venir une entité tierce, une Autorité de Certification (AC) qui va signer ce certificat. Uneusurpation d’identité se matérialiserait par la procuration d’une clé publique appartenantà une entité malveillante et se faisant passer pour le serveur souhaité. Nous ne nous éten-drons pas ici sur la mise en place d’une PKI (Public Key Infrastructure), nous rappelonssimplement que l’Autorité de Certification racine possède un certificat autosigné. Les cer-tificats peuvent être générés en interne (PKI interne à une entreprise) ou bien la gestionpeut être externalisée à l’aide de sociétés spécialisées telles que VeriSign.

Dans une connexion classique à un serveur web en HTTPS, seul ce serveur sera au-thentifié par un certificat qui lui aura été délivré. Ce certificat aura donc été signé parune AC, elle-même possédant un certificat signé par son AC mère jusqu’à remonter à l’ACracine autosignée (c’est la chaîne de certification). Un certificat standard du format X509contient de nombreuses informations, dont les plus importantes :

– un numéro de version– un numéro de série– L’algorithme utilisé pour la signature du certificat

10

– Les champs concernant l’AC qui a fourni ce certificat– Les dates de validité– Le nom du sujet détenteur du certificat– L’algorithme utilisé avec la clé publique– La clé publique– La signature du certificat par l’ACDe manière pratique, nous mettons en Annexe A le certificat autosigné par le proxy.

Il s’agit d’un fichier au format .pem, il existe d’autres extensions telles que .cer .der qu’ilfaut remplacer en .crt pour Android [9]

Lorsque le SSL Handshake est initialisé, le serveur va envoyer son certificat au client.Sur son système d’exploitation, ce client possède nativement un magasin de certificatsdes AC reconnues et considérées comme fiables pour utiliser leur clé publique. Il récupèredonc la clé publique de l’AC correspondant au nom indiqué dans le certificat envoyé par leserveur. Avec cette clé, il déchiffre la signature du certificat pour obtenir le hash effectuépar l’AC. De son côté, le client va hasher le certificat, et si ces 2 hashs correspondent,l’authentification est vérifiée. Si l’AC concernée n’est pas une AC mère, la machine vaaussi vérifier la chaine de certification.

Figure 4 – Magasin de certification Android

Pour les connexions HTTPS, un navigateur tel que Google Chrome va utiliser le ma-gasin de certificats de l’OS sur lequel il est installé alors que Firefox possède son propremagasin de certificats. C’est aussi pourquoi il est essentiel en terme de sécurité de vérifierla source de ces logiciels (OS ou navigateur). Si un attaquant parvient à modifier un de ceslogiciels en y intégrant nativement des certificats d’AC malveillants alors il pourra mettreen place des serveurs usurpant l’identité d’autres serveurs avec des certificats générés parl’AC malveillante sans que le client ne reçoive aucune alerte.

En effet, en temps normal, si le client se connecte à un serveur dont l’AC n’est pasreconnue par l’OS ou le navigateur, le navigateur va alors émettre une alerte et demanderconfirmation avant de continuer (d’autres cas peuvent déclencher une alerte comme lacorrespondance du nom de domaine souhaité et le nom indiqué dans le certificat, ou les

11

dates de validité). D’autres applications comme nous l’avons observé avec Google Mapssur Android refusent tout simplement la connexion tant que le certificat n’est pas reconnu.Nous allons donc voir comment ajouter des certificats sur des OS tels que iOS ou Android.Lorsqu’une entreprise utilise une PKI interne pour son intranet, il est aussi très utile depouvoir rajouter des certificats aux machines Windows et Linux.

Si l’utilisateur/client ne fait pas attention à ces alertes de sécurité ou bien installevolontairement ou sans consciemment le vouloir un certificat d’AC sur sa machine alors,il devient une cible facile pour l’attaque du Man-in-the-Middle

12

Troisième partie

Étude du proxy et de l’architecture6 Architecture de base

Dans cette partie, nous allons voir l’architecture dont nous disposons pour effectuer lesmanipulations afin de pouvoir intercepter les données de géolocalisation envoyées par lessmartphones. Nous travaillerons sur les systèmes d’exploitation mobiles iOS et Android carApple et Google sont actuellement de loin les deux leaders sur le marché des smartphones.Nous effectuerons les tests avec un iPhone 3GS fonctionnant sous iOS 5.1.1 et un HTCDesire HD fonctionnant sous Android Ice Cream Sandwich 4.0.

Smartphone

Ordinateur

Internet

Serveur smartphone

Point  d’accès  sans-fil

et routeur

Figure 5 – Architecture de base

Comme nous pouvons le voir sur la Figure 5, nous disposons d’un point d’accès sans-filsur lequel est connecté le smartphone en Wi-Fi. Ce point d’accès tourne sous le systèmed’exploitation Tomato [10], un firmware libre basé sur le noyau Linux et est donc aussiun routeur et firewall et pourra donc nous permettre d’effectuer des opérations simplesde filtrage. Le smartphone dialogue avec un serveur sur Internet appartenant soit à Applepour iOS soit à Google pour Android avec lequel il échange les informations de localisation.Sur le réseau local où se situe le smartphone, nous disposons d’un ordinateur permettantde contrôler le routeur en SSH ainsi que de faire tourner les services qui seront nécessairesà notre étude.

7 Les proxys HTTP et HTTPSLes échanges de géolocalisation entre le smartphone et le serveur sont effectués avec

le protocole HTTPS. Nous allons donc étudier dans cette partie les moyens dont nousdisposons pour les intercepter.

13

7.1 Proxy HTTP

Avant d’étudier l’interception du protocole HTTPS, nous allons nous intéresser auprotocole HTTP sur lequel il se base. Il existe deux moyens faciles pour intercepter duHTTP.

Le premier est tout simplement écouter ce qui passe sur le réseau. En effet, le protocoleHTTP n’est pas chiffré et peut donc être lu intégralement. Ceci peut être effectué parexemple sur notre architecture en utilisant le protocole WinPcapRemote sur le routeur quipermet d’utiliser celui-ci comme périphérique de capture distant avec le logiciel Wiresharktournant sur un ordinateur Windows [11]. Il est ainsi possible de capturer, déchiffrer etenregistrer tout le trafic HTTP.

Client

Serveur Web

Conn

exio

n 1

Conn

exio

n 2

Proxy

Figure 6 –Proxy

La deuxième technique d’interception du HTTP est d’utiliser unproxy HTTP. Un proxy est un logiciel qui sert de relai entre deuxéquipements qui dialoguent. Un proxy HTTP doit se placer entre leclient et le serveur. Il se comporte alors comme le serveur pour leclient et comme le client pour le serveur. C’est en fait exactementle même principe que l’attaque Man-in-the-Middle. Il crée donc unedouble connexion comme nous pouvons le voir sur la Figure 6. Unserveur proxy peut-être utile pour faire des opérations de filtrage oude mise en cache pour protéger un serveur web ou un réseau local, maispeut aussi être utile pour écouter très simplement le trafic qui passe,car tout le contenu qui passe d’une connexion à l’autre est connu parle proxy.

7.2 Proxy HTTPS

Nous allons désormais nous intéresser au protocole HTTPS (Hy-perText Transfer Protocol Secure). Celui étant sécurisé par SSL/TLS,il est maintenant impossible d’utiliser la simple écoute pour intercep-ter les communications entre le client et le serveur. En revanche, ladeuxième méthode d’interception présentée ci-dessus est toujours pos-sible : avec un proxy HTTPS.

Cette fois encore le proxy créé une double connexion HTTPS. Dansune connexion derrière un proxy le client HTTPS ne recevra pas le cer-tificat du serveur Web, mais un certificat provenant du proxy. En effet,le seul qui possède la clé secrète correspondant au certificat envoyé parle serveur Web est le serveur web lui même ; il serait donc impossibleau proxy de déchiffrer les messages du clients avec cette clé. Le proxyHTTPS est donc obligé de générer à la volée un certificat contenantles mêmes attributs que le certificat du serveur mis à part la clé publique et la signaturequ’il génère lui même. Le proxy envoie donc au client un certificat signé par lui et conte-nant une clé publique dont il possède la clé privée. Il pourra donc déchiffrer les messagesque lui enverra le client avec le certificat qu’il a créé et chiffrer les messages envoyés auserveur avec le certificat qu’il a reçu du serveur. Ainsi, le proxy pourra avoir l’intégralitédes échanges effectués entre le client et le serveur en clair. Ce qui empêche normalementd’utiliser ce principe pour intercepter des données échangées entre un client et un serveurHTTPS est la chaîne de certification qui se trouve alors violée. En effet, le client n’a nor-malement pas dans son magasin de certificat le certificat racine utilisé par le proxy poursigner le certificat qu’il a généré à la volée. Il aura donc une alerte sur son navigateur luidisant qu’il est peut-être en train d’être attaqué.

14

Quatrième partie

Mise en pratique et résultats8 La mise en place d’un proxy transparent

La première étape pour intercepter les données de géolocalisation entre un smartphoneet le serveur avec lequel il communique en HTTPS est de mettre en place un proxyHTTPS. Nous voulions rendre la configuration de ce proxy la plus transparente possiblepour pouvoir intercepter les données de géolocalisation sans que cela puisse être connude l’utilisateur. Nous avons utilisé pour toutes les manipulations le proxy sslmeat [12]qui permet d’intercepter, enregistrer et déchiffrer des flux HTTPS et est open source,multiplateforme et très léger.

8.1 Proxy transparent HTTP

Un proxy transparent est un proxy qui est mis en place sans aucune interventionde l’utilisateur et sans que celui-ci ne puisse s’en apercevoir. Le déploiement d’un proxyHTTP transparent est assez facile, car le HTTP contient des informations redondantesavec les informations contenues dans les paquets IP : le nom d’hôte permet de connaîtrel’adresse de destination. Il suffit donc de faire une redirection en NAT sur le point d’accèspour rediriger tous les paquets à destination du port 80 (HTTP) sur le port 9999 (leport du proxy) sur l’ordinateur sur lequel tourne le proxy pour mettre en place un proxytransparent. Ceci peut se faire sous Linux avec iptables avec une commande telle que :

iptables -t nat -A PREROUTING -i br0 -s ! 192.168.0.10 -p tcp --dport 80 \-j DNAT --to 192.168.0.10:9999

Où 192.168.0.10 est l’adresse IP de l’ordinateur sur lequel tourne le proxy et br0 l’in-terface sur laquelle arrivent les paquets provenant des clients qui vont passer par le proxy.

8.2 Proxy transparent HTTPS

La première étape dont on ne peut se passer pour faire fonctionner le proxy HTTPSest d’ajouter le certificat racine du proxy sur le smartphone. Cela peut se faire très simple-ment sur un iPhone en envoyant le certificat par email puis en l’installant. Sur Android,l’installation se fait depuis la carte SD et via le menu "Sécurité" (voir Figure 7)

Figure 7 – Ajout d’un certificat sous iPhone et Android

15

Ensuite, pour mettre en place le proxy transparent HTTPS , notre première tentativea été d’essayer de faire la même chose que pour le HTTP :

iptables -t nat -A PREROUTING -i br0 -s ! 192.168.0.10 -p tcp --dport 443 \-j DNAT --to 192.168.0.10:9999

Cependant, il était impossible d’établir une connexion avec un serveur HTTPS decette manière. Nous avons donc analysé l’intégralité des échanges qu’il y avait au niveaudu proxy (voir Figure 8).

Client HTTPS Proxy HTTPS Serveur web HTTPS

TCP SYN

TCP SYN, ACK

TCP ACK

TCP ACK

HTTP CONNECT clients1.google.com:443

TCP ACK

HTTP Connection established

TCP SYN

TCP SYN, ACK

TCP ACK

SSL Client Hello

SSL Server Hello

SSL Certificate, Hello Done

SSL Client Key Exchange,Encrypted Handshake Message

SSL Encrypted Handshake Message

SSL Client Hello

SSL Server Hello

SSL Certificate, Hello Done

SSL Encrypted Handshake Message

SSL Client Key Exchange,Encrypted Handshake Message

Encrypted Data

Encrypted Data

Encrypted Data

Encrypted Data

Figure 8 – Échanges lors de l’établissement d’une connexion SSL via un proxy SSL(configuré sur le client)

Grâce à l’analyse de cet échange, on a pu voir que la différence entre le proxy HTTPStransparent et le proxy configuré se situe au niveau du paquet envoyé par le client auproxy : "HTTP CONNECT clients1.Google.com:443". En effet, avant l’établissement de laconnexion HTTPS entre le client et le proxy, le client commence par dire au proxy vers

16

quel serveur il veut se connecter (ici clients1.Google.com sur le port 443) afin que celui-ciétablisse la connexion de son côté. On atteint ici en effet un problème qui ne se pose pasen HTTP, car le proxy HTTP a tout de suite accès au serveur auquel veut se connecterle client par l’intermédiaire de la variable HTTP "Host". Au contraire, en HTTPS, leproxy n’a pas accès à la requête HTTP qui viendra uniquement quand le tunnel chiffrésera établi. Il ne sait donc pas sur quel serveur il peut se connecter et ouvrir la deuxièmeconnexion, ni quel certificat il peut envoyer au client. Nous pouvons voir dans la Figure 9une illustration des problèmes de décision qui se posent au proxy.

Client HTTPS NAT Proxy HTTPS

TCP SYN / 192.168.0.46:10200 ->74.125.230.229:443

TCP ACK

SSL Client Hello

SSL Server Hello

TCP SYN / 192.168.0.1:10300 -> 192.168.0.10:9999

TCP SYN, ACK / 192.168.0.10:9999 -> 192.168.0.1:10300

TCP SYN, ACK / 74.125.230.229:443 -> 192.168.0.46:10200

TCP ACK

TCP ACK

TCP ACK

SSL Client Hello

SSL Server Hello Quel certificat envoyer ? Je ne  connais  pas  l’hôte  qui  va  

être contacté

Quel serveur Web contacter ?

Figure 9 – Tentative d’établissement d’une connexion via un proxy HTTPS transparent

Ainsi, il n’est pas possible d’établir de la même manière qu’en HTTP un proxy HTTPSvraiment transparent pour l’utilisateur.

8.3 Proxy HTTPS autoconfiguré

Comme nous nous sommes aperçus qu’il n’était pas possible de faire un vrai proxytransparent en HTTPS (en plus de l’ajout de certificat sur le client qui est toujours néces-saire), nous avons essayé de trouver les techniques permettant de configurer le proxy surle client de la manière la plus simple possible. Cette configuration automatique du proxys’effectue en deux étapes.

La première étape est d’écrire un fichier PAC (Proxy Auto-Config). C’est un fichier deconfiguration qui contient toutes les instructions nécessaires pour configurer le proxy surun navigateur ou un poste client. Voici le fichier de configuration que nous avons écrit.// Fichier de config automatique des navigateursfunction FindProxyForURL(url , host) {

return "PROXY 192.168.0.5:9999";}

C’est un fichier très simple écrit en javascript qui doit définir la fonction "FindProxyFo-rURL" et retourner les paramètres du proxy en fonction de l’URL que l’on veut atteindre.Ce fichier permet donc d’avoir une gestion plus intelligente du proxy, ce qui ne nous serapas utile ici.

17

La deuxième étape est d’utiliser le protocole WPAD (Web Proxy AutoDiscovery Pro-tocol). Ce protocole permet aux navigateurs configurés sur "découverte du proxy auto-matique" de récupérer automatiquement le fichier "wpad.dat" si ce fichier est à l’URL dela forme suivante : http://wpad.sous-domaine.domaine.fr/wpad.dat. Le domaine et le sous-domaine doivent être définis par le DHCP. Ainsi, le navigateur ou le système compatibleavec le WPAD configure automatiquement l’utilisation de proxy. Le navigateur Chromeest par exemple configuré par défaut en "configuration automatique du proxy", il est doncpar ce moyen très facile de le faire passer par un proxy de son choix si on est administra-teur du réseau sur lequel il se connecte. Les iPhone ne sont pas compatibles avec le WPAD(seulement avec les fichiers PAC pour lesquels il faut donner l’URL manuellement), cepen-dant, il est possible d’utiliser des fichiers de configurations très faciles à installer contenantles paramètres du proxy ainsi que des certificats.

18

9 Protocol BuffersLe protocol buffer [13] créé et utilisé par Google est un protocole ouvert permettant de

coder et normaliser l’échange et l’interprétation de données. Nous nous sommes aperçusqu’il est utilisé à la fois par les serveurs d’Apple pour échanger des données de localisationavec les iPhone et par les serveurs de Google pour échanger les informations de localisationavec les smartphones Android. Nous avons donc décidé de l’étudier afin de pouvoir décoderces données de localisation.

9.1 Les varints

Le varint est un type de données très utilisé dans les protocol buffers pour stocker desentiers sur un octet et plus. Pour coder un entier, pour chaque octet, le premier bit estmis à 1, sauf pour le dernier octet (afin de savoir que c’est le dernier octet). Ensuite, pourles bits restants, les octets les moins significatifs sont mis en premier. Voici un exemple dedécodage d’un varint.

1010 1100 0000 0010 -> 010 1100 000 0010 (on supprime les premiers bits)-> 000 0010 010 1100 (octets les plus significatifs en premiers)-> 10010 1100 = 300 (suppression des 0 inutiles)

9.2 Interpréter les protocol buffers

Une unité de donnée au sein d’un flux encodé avec en protocol buffers est composé dedeux parties :une clé “key” : elle indique le type et la façon d’interpréter la donnée échangéeune valeur : contenu de la donnée qui suit cette clé

La clé est un varint et est elle-même composée de deux éléments :le wire type : il est codé sur les trois derniers bits de la clé et indique la longueur de

la valeur de la donnée. Chaque wire type regroupe plusieurs types qui sont définisprécisément par Google et permettent de connaître exactement la taille de la donnéepour délimiter une unité avant de passer à la suivante. Il existe 6 wire type différentsqui peuvent être trouvés en Annexe B.1

le tag : il fait référence à un champ dans un fichier ".proto" personnalisable par l’uti-lisateur du protocol buffer. Il indique comment véritablement interpréter la donnée(type exact et signification) après avoir récupéré sa taille.

Nous pouvons voir sur la figure 10 l’interprétation que l’on peut faire d’une unité de donnéeoù la clé est par exemple codée sur 1 octet.

Voici l’exemple du déchiffrement de l’hexadécimal "08 96 01" à l’aide des protocolbuffers.

– Premier bit de 08 à 0, donc la clé fait 1 octet– 0x08 → varint key 0000 1000 → on enlève le bit de poids fort 000 1000– 0001 → “tag” = 1 → voir le fichier “.proto” correspondant. Imaginons que le type

du tag 1 soit "int32"– 0x 96 01 est donc un varint → 1001 0110 0000 0001

– on enlève les bits de poids forts → 001 0110 000 0001– on inverse les groupes de 7 bits puis on les concatène → 00000010010110 →

10010110– on obtient : 2 + 4 + 16 + 128 = 150

19

 

Figure 10 – Interprétation d’une unité de donnée où la clé fait 1 octet

La donnée envoyée est donc une variable varint (de type int32 comme est défini le tag 1dans le fichier .proto) et dont la valeur vaut 150

9.3 Exemple de décodage de données encodées en Protocol Buffer

Nous allons désormais pour illustrer les parties précédentes donner l’exemple du dé-codage de données encodées en Protocol Buffer. Ces données sont extraites de donnéesenvoyées par Apple et qui seront analysées ensuite en 10.2. C’est une analyse similaire quia permis de créer le fichier .proto que l’on peut trouver en Annexe D.1.

Voici les données que nous allons analyser :000000: 00 01 00 05 65 6e 5f 55 53 00 00 00 09 35 2e 31 | ....en_US....5.1000010: 2e 39 42 31 37 36 00 00 00 64 00 00 2a 92 0a 1b | .9B176...d..*...000020: 0a 05 4e 38 38 41 50 12 12 69 50 68 6f 6e 65 20 | ..N88AP..iPhone000030: 4f 53 35 2e 31 2f 39 42 31 37 36 1a 4e 0a 11 33 | OS5.1/9B176.N..3000040: 36 3a 38 37 3a 32 34 3a 37 39 3a 32 61 3a 36 33 | 6:87:24:79:2a:63000050: 10 0c 18 a0 ff ff ff ff ff ff ff ff 01 22 2a 09 | ............."*.000060: 77 79 bb a6 08 50 48 40 11 64 60 0a fc ce 8c 03 | wy...PH@.d‘.....000070: 40 1d ba b6 98 42 2d f3 78 ac 42 35 fd 59 e2 42 | @....B-.x.B5.Y.B000080: 49 bc 5d 5b 54 3b 6d b5 41 38 00 1a 4e 0a 11 33 | I.][T;m.A8..N..3000090: 36 3a 38 37 3a 32 34 3a 37 39 3a 32 61 3a 36 31 | 6:87:24:79:2a:61[...]

Tout d’abord, il faut trouver où commence l’encodage en protocol buffer. Pour cela,on peut essayer chaque octet et voir si c’est cohérent, mais avec un peu d’habitude, ons’aperçoit que souvent, le protocol buffer commence avec 0x0A (tag = 1 ; type = 2 ce quicorrespond aux éléments dont la taille est donnée par l’octet qui suit tels que les string,les champs répétés ou les messages ) , 0x08 (tag = 1 ; type = 0, un varint) ou 0x09 (tag= 1 ; type = 1, nombre de 64 bits). Ici, le protocol buffer paraît commencer par exempleà l’octet no 0x3D. Le premier octet est 0A ce qui signifie que le tag est 1 et que l’octetqui suit est la taille de la valeur. On arrive à lire la suite en ASCII, ce qui veut dire quec’est surement une chaîne de caractère de type string. Elle contient le BSSID et fait eneffet 0x11 (= 17) octets. Ensuite, vient 10 (tag = 2, type = varint) un entier de valeur0x0C =12 . Cela correspond en fait au canal Wi-Fi utilisé. Ensuite vient 18 (tag = 3 ;type = varint) codé sur 10 octets, c’est la valeur -96 qui correspond à la qualité du signal.22 (Tag = 4, type = 1) représente soit une chaine de caractère, soit un message (bloc dedonnées protcol buffer). Comme ce qui suit n’a pas l’air d’être des caractères intelligibles,c’est qu’il s’agit surement d’un bloc de données de taille 0x2A = 42.

La suite, 09 (tag = 1, type = 64 bits) confirme le fait qu’on soit dans un nouveau bloc,car le numéro de tag recommence à 1. Le nombre de 64 bits vaut en double 48.6252640167ce qui correspond à une latitude. Ensuite, 11 (tag = 2, type = 64bits) est l’entête de lavaleur 2.44375416667 codée sur un type double. Cela correspond à une longitude. Ensuite

20

vient 1D (tag = 3 ; type = 32 bits) qui en float vaut 359480148.357 ce qui représenteexactement le nombre de secondes entre le premier janvier 2001 et la mesure. Nous n’avonspas réussi à interpréter les valeurs qui suivent, mais l’avantage du protocol buffer est qu’onpeut le décoder, même si on ne sait pas ce quoi les données correspondent : l’entête 2D(tag = 5, type = 32bits) signifie que le nombre qui suit prend 4 octets : 0xF3 0x78 0xACet 0x42. Suivent les entêtes suivants : 35 (tag = 6 ; type = 32bits), 49 (tag = 9 ; type =64bits), 38(tag =7 ;type=varint). On arrive à l’entête 1A (tag = 3 ; type = 1) qui ne semblepas cohérent avec ce qui précède. C’est en fait à cet endroit qu’on s’aperçoit qu’ensuiterecommence quelque chose de similaire à ce que l’on a décodé depuis le début et quec’est 1A 4E était l’entête qui l’englobait. Il aurait donc fallu commencer notre décodage 2octets avant pour prendre en compte la structure englobante. Ensuite recommence doncune utilité de donnée exactement similaire à celle que l’on vient de décoder.

D’après l’étude des quelques données précédentes, nous pouvons en déduire le fichier.proto suivant :

message WifiMeasurement {required string bssid = 1;optional int64 channel = 2;optional int64 signal_strength = 3;message Location {

optional double latitude = 1;optional double longitude = 2;optional float timestamp = 3;#Les valeurs inconnues sont optionnelles#Les protocol buffers passent les valeurs qu’ils ne connaissent pas

}required Location location = 4;

}

message BlockBSSIDNocturne {repeated WifiMeasurement wifi = 3;

}

Ce fichier permettra à un script python de décoder toutes les données que nous venonsd’étudier, et peut-être même plus si certains messages se répètent. Il permettra aussi decoder des données choisies par l’utilisateur suivant le même format.

Sur le site de développeur de Google https://developers.Google.com/protocol-buffers/,toute la documentation et les sources sont disponibles pour intégrer le protocole buffer àses applications et générer les fichiers .proto. Il faut par ailleurs noter la présence d’unoutil très pratique (que nous avons découvert après avoir décodé un grand nombre de flux"à la main")$ protoc --decode_raw < [flux de data encodée grâce au protocole buffer]

Enfin, nous conclurons cette partie sur les Protocol Buffer en vous invitant à lire cetarticle très intéressant fourni par une équipe de "Sysdream - IT Security Services" propo-sant un travail de reverse engineering sur le protocole buffer [14]. En effet, le script pythontéléchargeable à la fin permet de recréer le fichier .proto en analysant une applicationbinaire utilisant le protocole buffer pour générer des flux de données.

21

10 Échanges des données de localisation sur iOSSur les smartphones Apple fonctionnant sur iOS, il existe deux types de données de

localisation qui sont échangées entre un serveur d’Apple et un iPhone : les données échan-gées lors de la géolocalisation du smartphone et les données échangées pour permettre àApple de constituer sa base de données de BSSID. Nous allons étudier dans les partiessuivantes ces deux échanges de manière approfondie.

10.1 Données envoyées lors de la géolocalisation du téléphone

Lorsqu’un utilisateur veut se géolocaliser sur un iPhone, celui-ci peut utiliser troistechniques différentes comme nous l’avons vu précédemment (Géolocalisation par GSM,Géolocalisation Wi-Fi, Géolocalisation GPS). Nous allons voir dans cette partie unique-ment les échanges effectués avec les serveurs d’Apple lors de la géolocalisation Wi-Fi,car la géolocalisation GPS ne nécessite pas d’échange avec un serveur d’Apple et que nousn’avons jamais vu passer d’échange concernant la géolocalisation GSM, nous pouvons doncsupposer que celle-ci ne s’effectue que quand il n’y a pas de connexion Wi-Fi.

Nous avons lu [1] que lorsqu’un iPhone voulait se connecter à un réseau Wi-Fi, iléchangeait des données avec le serveur d’Apple situé à l’URL https://gs-loc.apple.com. Cecis’est tout de suite confirmé avec nos tests qui montraient plusieurs échanges HTTPS entrece serveur et le téléphone à chaque fois qu’une application voulait utiliser la géolocalisationet que le Wi-Fi était allumé. Pour analyser les données envoyées lors de cet échange, nousavons utilisé le proxy sslmeat présenté en 8. Ce proxy enregistre tous les paquets qu’iltransmet dans une base de données sqlite avec le numéro du paquet, l’heure à laquelleil a été enregistré, l’adresse et le port source et destination, le nom d’host et en binaire(BLOB) toutes les données qui étaient contenues dans ce paquet.

Pour récupérer les données utiles, il y a un outil fourni avec le proxy qui permet enutilisant la commande./showp packets.db

d’afficher en console tout le contenu de tous les paquets enregistrés avec les données binairesà la fois en hexadécimal et en ASCII. Cependant, afficher tous les paquets peut renvoyerune quantité de données énorme assez difficile à traiter. Nous avons donc utilisé une simplerequête sur la base de données sqlite pour supprimer tous les paquets dont nous n’avionspas besoin au moins dans un premier temps :DELETE FROM ’packets’ WHERE hostname NOT LIKE "%gs-loc.apple.com%"

Nous avons donc pu récupérer facilement grâce à la commande ./showp les donnéesbrutes suivantes :192.168.0.46:53886 17.174.2.27:443 POST gs−loc .apple.com:443POST /clls/wloc HTTP/1.1Host: gs−loc .apple.com

000000: 00 01 00 05 65 6e 5f 55 53 00 00 00 09 35 2e 31 | . . . .en_US... .5.1000010: 2e 39 42 31 37 36 00 00 00 01 00 00 00 2a 12 13 | .9B176.. . . . . .∗ . .000020: 0a 11 65 30 3a 39 31 3a 66 35 3a 66 65 3a 66 36 | . . e0:91: f5:fe : f6000030: 3a 36 30 18 00 20 c0 0c 2a 0e 63 6f 6d 2e 61 70 | :60.. . .∗ .com.ap000040: 70 6c 65 2e 4d 61 70 73 | ple .Maps

17.174.2.27:443 192.168.0.46:53886 200 gs−loc .apple.com:443HTTP/1.1 200 OKDate: Sun, 18 Mar 2012 16:55:40 GMTContent−Length: 74784

22

000000: 00 01 00 00 00 01 00 01 24 16 12 2e 0a 11 65 30 | . . . . . . . . $ . . . . . e0000010: 3a 39 31 3a 66 35 3a 66 65 3a 66 36 3a 36 30 12 | :91: f5:fe : f6:60.000020: 16 08 e0 e6 ce 9a 12 10 fe e2 db 6e 18 2a 28 31 | . . . . . . . . . . .n.∗(1000030: 30 05 58 2c 60 9a 01 a8 01 01 12 2c 0a 10 30 3a | 0.X, ‘ . . . . . . , . . 0 :000040: 31 65 3a 38 63 3a 34 63 3a 32 35 3a 37 62 12 15 | 1e:8c:4c:25:7b. .000050: 08 c2 c2 ce 9a 12 10 f5 cc db 6e 18 2a 28 2f 30 | . . . . . . . . . .n.∗(/0000060: 08 58 2e 60 6e a8 01 0b 12 2d 0a 10 65 30 3a 61 | .X. ‘n.... −..e0:a000070: 31 3a 64 37 3a 37 33 3a 39 34 3a 63 12 16 08 fc | 1:d7:73:94:c . . . .000080: 9b cf 9a 12 10 fb dd db 6e 18 2a 28 32 30 0b 58 | . . . . . . . .n.∗(20.X000090: 28 60 98 01 a8 01 0b 12 2d 0a 10 65 30 3a 61 31 | ( ‘. . . . . . − . .e0:a10000a0: 3a 64 37 3a 63 3a 63 37 3a 62 34 12 16 08 8f e7 | :d7:c:c7:b4 . . . . .0000b0: ce 9a 12 10 f9 b6 dc 6e 18 2d 28 2d 30 10 58 25 | . . . . . . .n.−(−0.X%0000c0: 60 b0 01 a8 01 0b 12 2c 0a 0f 30 3a 31 65 3a 34 | ‘ . . . . . . , . .0 :1e:40000d0: 63 3a 32 31 3a 65 3a 64 64 12 16 08 df 9f cf 9a | c:21:e:dd. . . . . . .0000e0: 12 10 d2 e5 db 6e 18 2a 28 2e 30 0a 58 3d 60 80 | . . . . .n.∗(.0.X=‘.0000f0: 02 a8 01 01 12 2d 0a 10 30 3a 31 36 3a 63 66 3a | ..... −..0:16:cf :000100: 61 34 3a 36 64 3a 39 30 12 16 08 d7 fc ce 9a 12 | a4:6d:90 . . . . . . . .000110: 10 bf be dc 6e 18 32 28 2e 30 08 58 25 60 d7 01 | . . . .n.2(.0.X%‘..000120: a8 01 01 12 2c 0a 10 30 3a 32 32 3a 33 66 3a 38 | .. . . , . .0:22:3 f :8000130: 36 3a 33 61 3a 34 63 12 15 08 bb f1 ce 9a 12 10 | 6:3a:4c . . . . . . . . .000140: d0 cf dc 6e 18 2a 28 2f 30 0c 58 3e 60 7e a8 01 | . . .n.∗(/0.X>‘~..[ . . . ]

Ces données avaient l’air très intéressantes, car on pouvait déjà y lire des BSSIDen ASCII. D’après l’article précédemment cité [1] nous avons découvert que ces donnéesétaient encodées à l’aide des Protocol Buffers. Nous avons donc décodé ces données de lamême manière que décrit en 9.3 afin de générer le fichier .proto permettant de décoderautomatiquement toutes les données codées de la même manière. Celui-ci est donné enAnnexe C.

Enfin, pour avoir un rendu facile à lire des données contenues dans les échanges ana-lysés, nous avons écrit un script python permettant d’une part d’afficher les données enconsole de manière organisée et claire et d’autre part de générer un fichier KML (KeyholeMarkup Language) [15] contenant les BSSID et leurs coordonnées géographiques donnantla possibilité d’être affiché sur Google Earth ou Google Maps. Ce script python est fournien Annexe C.

Voici l’échange présenté plus haut décodé avec le script python et son affichage sur unecarte Google Maps (voir Figure 11)

POST /clls/wloc HTTP/1.1Host: gs−loc .apple.com

Langue : en_USOS Version : 5.1.9B176Wifi BSSID : e0:91: f5:fe : f6:60APIName : com.apple.Maps

−−−−−−−−−

HTTP/1.1 200 OK

Wifi BSSID : e0:91: f5:fe : f6:60Latitude : 48.87655264Longitude : 2.32190334Confiance : 42−−−−−−Wifi BSSID : 0:1e:8c:4c:25:7bLatitude : 48.87650626Longitude : 2.32187509Confiance : 42−−−−−−Wifi BSSID : e0:a1:d7:73:94:cLatitude : 48.87662076

Longitude : 2.32189691Confiance : 42−−−−−−Wifi BSSID : e0:a1:d7:c:c7:b4Latitude : 48.87655311Longitude : 2.32201081Confiance : 45−−−−−−Wifi BSSID : 0:1e:4c:21:e:ddLatitude : 48.87662559Longitude : 2.32190674Confiance : 42−−−−−−Wifi BSSID : 0:16:cf :a4:6d:90Latitude : 48.87658071Longitude : 2.32202047Confiance : 50−−−−−−Wifi BSSID : 0:22:3f :86:3a:4cLatitude : 48.87656635Longitude : 2.3220424Confiance : 42−−−−−−

Nous pouvons constater avec ces échanges que le BSSID du point d’accès sur lequel

23

Figure 11 – Affichage des BSSID et de la position exacte sur une carte Google Maps

est connecté le téléphone (e0 :91 :f5 :fe :f6 :60) est envoyé au serveur d’Apple qui répondune liste de 201 BSSID avec leurs coordonnées (latitude, longitude) ainsi qu’un indice deconfiance sur ces coordonnées. Ce serveur doit donc connaître le BSSID qui lui est envoyépar le téléphone et en avoir les coordonnées. Si celui-ci n’est pas dans sa base de données,le serveur le signale au téléphone qui lui renvoie une liste contenant tous les BSSID despoints d’accès à proximité, ce qui permet au serveur d’envoyer une liste similaire à celleci-dessus.

Le calcul de la position exacte du téléphone n’est donc pas effectué sur le serveurd’Apple, mais sur le téléphone qui, grâce à tous les BSSID dont il connaît la positionpourra calculer sa position exacte en fonction de la puissance des signaux dont il a lescoordonnées. Cependant, on peut constater avec la représentation graphique de la Figure11 qu’avec le seul BSSID envoyé par le téléphone, le serveur d’Apple a une vision d’où estsitué le téléphone (le centre du cercle) très proche de la réalité (le rond rouge). On peutaussi constater avec la capture précédente qu’aucun identifiant permettant d’identifier lesmartphone ou l’utilisateur n’est transmis (si ce n’est le BSSID et l’adresse IP du pointd’accès sur lequel il est connecté). Il est donc impossible à Apple d’utiliser ces seulesinformations pour suivre un utilisateur ce qui est bon pour la protection de la vie privéedes utilisateurs.

10.2 Données envoyées pour constituer la base de données de BSSIDd’Apple

Toujours dans l’article [1] nous avons appris que pour maintenir à jour sa base dedonnées de BSSID avec leurs coordonnées géographiques, Apple utilise tous les smart-

24

phones iOS. En effet, ces téléphones enverraient régulièrement la nuit les points d’accèsWi-Fi qu’ils ont "rencontrés" avec leurs coordonnées à ce moment. Cependant, même enlaissant le téléphone configuré sur le proxy pendant plusieurs jours, nous n’avons pas vules échanges partir du téléphone la nuit. C’est au bout de quelque temps que nous noussommes aperçus qu’il fallait avoir activé l’envoi des "Diagnostics et utilisations" à Applepour que ces échanges se passent.

Par ailleurs, l’article ayant du être effectué sur une version antérieure d’iOS, il y était ditque le serveur contacté par les iPhone la nuit avait comme adresse https://iphone-services.apple.com. Sur la version d’iPhone dont nous disposions, les envois se sont en fait effectuésvers le serveur https://gsp10-ssl.Apple.com. De plus, ils ne se font pas forcément la nuit,à heure régulière, mais quand le téléphone est branché et connecté à un réseau Wi-Fi etqu’il n’effectue pas de tâche particulière. Ce qui est quand même généralement souvent lanuit.

Nous avons pu récupérer les données brutes suivantes :192.168.0.46:49163 17.174.2.54:443 POST gsp10−ssl .apple.com:443POST /hcy/pbcwloc HTTP/1.1Host: gsp10−ssl .apple.com

000000: 00 01 00 05 65 6e 5f 55 53 00 00 00 09 35 2e 31 | . . . .en_US... .5.1000010: 2e 39 42 31 37 36 00 00 00 64 00 00 2a 92 0a 1b | .9B176...d. .∗ . . .000020: 0a 05 4e 38 38 41 50 12 12 69 50 68 6f 6e 65 20 | . .N88AP. .iPhone000030: 4f 53 35 2e 31 2f 39 42 31 37 36 1a 4e 0a 11 33 | OS5.1/9B176.N..3000040: 36 3a 38 37 3a 32 34 3a 37 39 3a 32 61 3a 36 33 | 6:87:24:79:2a:63000050: 10 0c 18 a0 ff f f f f f f f f f f f f f f 01 22 2a 09 | . . . . . . . . . . . . . " ∗ .000060: 77 79 bb a6 08 50 48 40 11 64 60 0a fc ce 8c 03 | wy. . .PH@.d‘ . . . . .000070: 40 1d ba b6 98 42 2d f3 78 ac 42 35 fd 59 e2 42 | @. . . .B−.x.B5.Y.B000080: 49 bc 5d 5b 54 3b 6d b5 41 38 00 1a 4e 0a 11 33 | I . ] [T;m.A8..N..3000090: 36 3a 38 37 3a 32 34 3a 37 39 3a 32 61 3a 36 31 | 6:87:24:79:2a:610000a0: 10 0c 18 a0 ff f f f f f f f f f f f f f f 01 22 2a 09 | . . . . . . . . . . . . . " ∗ .0000b0: 77 79 bb a6 08 50 48 40 11 64 60 0a fc ce 8c 03 | wy. . .PH@.d‘ . . . . .0000c0: 40 1d ba b6 98 42 2d f3 78 ac 42 35 fd 59 e2 42 | @. . . .B−.x.B5.Y.B0000d0: 49 bc 5d 5b 54 3b 6d b5 41 38 01 1a 4d 0a 10 66 | I . ] [T;m.A8..M. . f0000e0: 34 3a 63 61 3a 65 35 3a 61 63 3a 36 3a 34 39 10 | 4:ca:e5:ac:6:49.0000f0: 01 18 a1 ff f f f f f f f f f f f f f f 01 22 2a 09 77 | . . . . . . . . . . . . " ∗ .w000100: 79 bb a6 08 50 48 40 11 64 60 0a fc ce 8c 03 40 | y. . .PH@.d‘ . . . . .@000110: 1d ba b6 98 42 2d f3 78 ac 42 35 fd 59 e2 42 49 | . . . .B−.x.B5.Y.BI000120: bc 5d 5b 54 3b 6d b5 41 38 00 1a 4c 0a 0f 30 3a | . ] [T;m.A8..L..0:000130: 31 66 3a 63 36 3a 64 3a 32 65 3a 61 66 10 06 18 | 1f :c6:d:2e:af . . .000140: a2 ff f f f f f f f f f f f f f f 01 22 2a 09 77 79 bb | . . . . . . . . . . " ∗ .wy.000150: a6 08 50 48 40 11 64 60 0a fc ce 8c 03 40 1d ba | . .PH@.d‘ . . . . .@. .000160: b6 98 42 2d f3 78 ac 42 35 fd 59 e2 42 49 bc 5d | . .B−.x.B5.Y.BI. ]000170: 5b 54 3b 6d b5 41 38 00 1a 4d 0a 10 30 3a 32 34 | [T;m.A8..M..0:24000180: 3a 64 34 3a 36 63 3a 31 61 3a 63 30 10 0b 18 a3 | :d4:6c:1a:c0. . . .000190: ff f f f f f f f f f f f f f f 01 22 2a 09 77 79 bb a6 | . . . . . . . . . " ∗ .wy. .0001a0: 08 50 48 40 11 64 60 0a fc ce 8c 03 40 1d ba b6 | .PH@.d‘ . . . . .@. . .0001b0: 98 42 2d f3 78 ac 42 35 fd 59 e2 42 49 bc 5d 5b | .B−.x.B5.Y.BI. ] [0001c0: 54 3b 6d b5 41 38 00 1a 4d | T;m.A8..M[ . . . ]

Nous avons ensuite procédé de la même manière que dans la partie précédente pour,générer le fichier .proto correspondant à cet envoi puis avons écrit un script dont le code estfourni en Annexe D.1. Pour afficher ces données de manières claires en console et pouvoirgénérer le fichier .kml à afficher sur une carte.

Voici les données décodées et leur affichage sur une carte Google Earth :

POST /hcy/pbcwloc HTTP/1.1Host: gsp10−ssl .apple.com

Langue : en_USVersion hardware : N88APVersion OS: iPhone OS5.1/9Wifi BSSID : 36:87:24:79:2a:61

channel : 12signal_strength : −96latitude : 48.6252640167longitude : 2.44375416667timestamp : 359480148.357 −−> 23/05 17:35:48−−−−−−Wifi BSSID : f4:ca:e5:ac:6:49

25

channel : 1signal_strength : −95latitude : 48.6252640167longitude : 2.44375416667timestamp : 359480148.357 −−> 23/05 17:35:48−−−−−−Wifi BSSID : 0:1f :c6:d:2e:afchannel : 6signal_strength : −94latitude : 48.6252640167longitude : 2.44375416667timestamp : 359480148.357 −−> 23/05 17:35:48−−−−−−Wifi BSSID : 0:24:d4:6c:1a:c0channel : 11signal_strength : −93latitude : 48.6252640167

longitude : 2.44375416667timestamp : 359480148.357 −−> 23/05 17:35:48−−−−−−Wifi BSSID : 6a:7 f :74:1c: f1:dchannel : 6signal_strength : −93latitude : 48.6252640167longitude : 2.44375416667timestamp : 359480148.357 −−> 23/05 17:35:48−−−−−−Wifi BSSID : f4:ca:e5:ac:6:48channel : 1signal_strength : −93latitude : 48.6252640167longitude : 2.44375416667timestamp : 359480148.357 −−> 23/05 17:35:48[ . . . ]

Figure 12 – Envoi nocturne affiché sur une carte Google Earth

Avec les mesures que nous avons faites et les résultats de cette capture, nous pouvonsconstater que les données qui sont envoyées à Apple sont uniquement des identifiants depoints d’accès wifi (BSSID et canal), le moment exact de la mesure ainsi que la force dusignal et les coordonnées du téléphone au moment où il a capté ces réseaux Wifi. On s’estaussi aperçu que les positions des réseaux Wifi ne sont envoyées à Apple que si la positiondu téléphone était calculée avec le GPS (donc uniquement en extérieur). De plus, commedans le cas précédent, il n’y a aucune information permettant d’identifier l’utilisateur (misà part la version de son hardware et de l’OS). Là encore, la vie privée de l’utilisateur sembleêtre préservée et l’utilisation de ces envois nocturnes est uniquement pour pouvoir ensuiteutiliser la géolocalisation beaucoup plus rapidement en ville grâce à la géolocalisation Wifi.

26

L’affichage sur la carte que nous pouvons voir sur la Figure est assez confus. C’est enfait car le téléphone une fois qu’il a trouvé sa position GPS retient tous les points d’accèsqu’il capte. Pour chaque endroit défini par les coordonnées géographiques, il y a donc ungrand nombre de points d’accès.

En essayant de décoder tous les paquets envoyés au serveur https://gsp10-ssl.Apple.com,nous nous sommes aperçus que le script marchait très bien pour certains paquets, mais paspour d’autres. En essayant de créer un autre fichier .proto pour le deuxième type d’envoi,nous nous sommes aperçus qu’en plus d’envoyer des BSSID avec leurs coordonnées, lesiPhone envoient aussi de la même manière que les BSSID les coordonnées des antennesGSM à portée comme nous pouvons le voir sur la capture ci-dessous présentée brute puisdécodée à l’aide du code fourni en Annexe D.2.192.168.0.46:51730 17.174.2.54:443 POST gsp10−ssl .apple.com:443POST /hcy/pbcwloc HTTP/1.1Host: gsp10−ssl .apple.com

000000: 00 01 00 05 65 6e 5f 55 53 00 00 00 09 35 2e 31 | . . . .en_US... .5.1000010: 2e 39 42 31 37 36 00 00 00 64 00 00 03 06 0a 1b | .9B176...d. . . . . .000020: 0a 05 4e 38 38 41 50 12 12 69 50 68 6f 6e 65 20 | . .N88AP. .iPhone000030: 4f 53 35 2e 31 2f 39 42 31 37 36 12 73 08 d0 01 | OS5.1/9B176.s . . .000040: 10 01 18 84 ea 01 20 b5 ce 2a 28 a4 ff f f f f f f | . . . . . . . .∗ ( . . . . .000050: ff f f f f f f 01 30 bc 54 38 37 42 2a 09 8b d9 c9 | . . . . . 0 .T87B∗ . . . .000060: 17 6b 6c 48 40 11 ae 26 bd dd 00 b9 02 40 1d ba | .klH@..&.. . . .@. .000070: b6 98 42 2d 2d 4c 2d 42 35 fd 59 e2 42 49 61 7d | . .B−−L−B5.Y.BIa}000080: 3c a3 7b 76 b5 41 4a 0e 63 6f 6d 2e 61 70 70 6c | <.{v.AJ.com.appl000090: 65 2e 4d 61 70 73 58 ff f f f f f f f f f f f f f f f f | e.MapsX. . . . . . . . .0000a0: 01 62 04 46 72 65 65 78 14 80 01 bc 01 88 01 02 | .b.Freex . . . . . . . .0000b0: 12 64 08 d0 01 10 01 18 84 ea 01 20 b5 ce 2a 28 | .d. . . . . . . . . ..∗(0000c0: a7 ff f f f f f f f f f f f f f f 01 30 bc 54 38 be 03 | . . . . . . . . . . 0 .T8..0000d0: 42 2a 09 33 df 53 cb 68 6c 48 40 11 74 6f 8f ef | B∗.3.S.hlH@.to . .0000e0: 9c b7 02 40 1d ba b6 98 42 2d 2e 4c 3d 42 35 fd | . . .@. . . .B−.L=B5.0000f0: 59 e2 42 49 cd 51 3c e0 7b 76 b5 41 58 ff f f f f | Y.BI.Q<.{v.AX. . .000100: ff f f f f f f f f f f 01 62 04 46 72 65 65 78 18 80 | . . . . . . .b.Freex. .000110: 01 b6 01 88 01 02 12 74 08 d0 01 10 01 18 84 ea | . . . . . . . t . . . . . . . .000120: 01 20 b5 ce 2a 28 b7 ff f f f f f f f f f f f f f f 01 | . . . ∗ ( . . . . . . . . . .000130: 30 bc 54 38 be 03 42 2a 09 35 e0 e2 97 30 6c 48 | 0.T8..B∗.5...0lH000140: 40 11 71 04 04 ce ad b3 02 40 1d ba b6 98 42 2d | @.q. . . . . .@. . . .B−000150: cc a5 a8 42 35 fd 59 e2 42 49 18 55 bf 6e 7c 76 | . . .B5.Y.BI.U.n|v000160: b5 41 4a 0e 63 6f 6d 2e 61 70 70 6c 65 2e 4d 61 | .AJ.com.apple.Ma000170: 70 73 58 ff f f f f f f f f f f f f f f f f 01 62 04 46 | psX. . . . . . . . . .b.F000180: 72 65 65 78 0a 80 01 84 01 88 01 | reex . . . . . . .[ . . . ]

POST /hcy/pbcwloc HTTP/1.1Host: gsp10−ssl .apple.com

Langue : en_USVersion hardware : N88APVersion OS: iPhone OS5.1/9B17MCC : 208MNC : 1LAC : 29956CellID : 698165Attenuation : −73Latitude : 48.84523295Longitude : 2.33773385Timestamp : 360086638.747 −−> 30/05 18:03:58APIName : com.apple.MapsOperateur : Free−−−−−−

MCC : 208MNC : 1LAC : 29956

CellID : 698165Attenuation : −65Latitude : 48.8448654167Longitude : 2.33759816667Timestamp : 360086697.899 −−> 30/05 18:04:57APIName :Operateur : Free−−−−−−

MCC : 208MNC : 1LAC : 29956CellID : 655967Attenuation : −86Latitude : 48.8445925667Longitude : 2.33753441667Timestamp : 360086750.965 −−> 30/05 18:05:50APIName :Operateur : Free[ . . . ]

Les données envoyées sont assez complètes puisqu’elles contiennent les informations

27

suivantes permettant d’identifier les antennes GSM : le MCC (Mobile Country Code)correspondant au pays, le MNC (Mobile Network Code) correspondant à l’opérateur, leLAC, le CellID qui est l’identifiant de cellule ainsi que les mêmes paramètres que pour lesréseaux Wi-Fi : Atténuation, Latitude, Longitude et heure précise de la mesure.

Nous pouvons voir sur la Figure 13 l’affichage sur Google Earth d’un envoi nocturneaprès avoir utilisé le GPS dans une rue. On s’aperçoit aisément que lorsque l’on utilise leGPS de manière continue, le téléphone mémorise toutes les informations sur les réseauxGSM (et de la même manière en Wi-Fi) qu’il capte. Cependant, cela veut dire aussi quelorsque le GPS n’est pas actif ou utilisé, le téléphone ne fera pas de calcul GPS par luimême pour enrichir la base de données d’Apple.

Figure 13 – Envoi nocturne affiché sur une carte Google Earth

28

11 Localisation et Sécurité sur AndroidAprès avoir analysé le comportement des téléphones Apple et des serveurs correspon-

dants, nous allons effectuer la même étude pour les téléphones de Google afin de comparerl’attitude et les objectifs des deux concurrents vis-à-vis des données de localisation. Nousallons donc débuter la même procédure à l’aide du proxy pour un téléphone sur OS Androidpuis voir jusqu’où nous pouvons pousser l’analyse du système concernant notre probléma-tique et comment nous allons devoir adapter cette procédure pour obtenir un maximumde résultats pertinents.

11.1 Contexte de l’analyse sur OS Android

Avant de nous plonger dans l’étude des échanges de données de localisation sur lesystème de Google, nous avons envisagé plusieurs moyens d’entreprendre nos tests etaccéder à un maximum d’informations. Trois possibilités se présentent pour travailler surAndroid : l’émulateur Android proposé dans le SDK de Google, les machines virtuellesAndroid disponibles pour architectures x86, les téléphones OS Android disponibles sur lemarché.

11.1.1 Émulateur Android

Nous allons voir dans la section suivante que Google met à disposition des dévelop-peurs un kit de développement très complet ainsi qu’une documentation disponible enligne à destination des développeurs d’application pour Google Play (anciennement ap-pelé Android Market). Ce SDK, Software Development Kit, disponible à cette adresse [16],propose notamment un gestionnaire de périphériques Android virtuels : l’Android VirtuelDevice Manager (voir Figure 14). L’avantage de cet émulateur est que l’on peut facilement

Figure 14 – Android Virtual Device Manager

obtenir les sources et les images de toutes les versions du système de Google, de la version1.5 à la version 4.0.3 qui a été ajoutée très récemment. Il s’agit donc d’un excellent outil

29

pour les développeurs désirant tester la compatibilité de leurs applications sur les versionsde l’OS.

Cependant, cet outil peut simuler une connexion internet disponible via la machinehost par une connexion data 3G mais il sera impossible de simuler une interface Wifi(voir Figure 15). Cette solution devient alors peu pertinente pour notre problématique

Figure 15 – Connexions d’un Android virtuel

de géolocalisation, elle pose le même problème vis-à-vis de la simulation du GPS et desantennes GSM.

11.1.2 Machine Virtuelle Android

Grâce au projet Android-x86 [17], supporté aussi par la société Intel [18], des images detoutes les versions du système Android sont disponible au format iso pour des architecturesx86. Il est alors facile d’installer une VM Android sur une machine et un OS host classiquetel que nous pouvons le voir sur la Figure 16 où nous avons utilisé Virtual-Box. À noter

Figure 16 – Android x86 sur VirtualBox

qu’il est donc aussi possible de créer une clé USB bootable Android. Le gros avantagede cette solution est qu’un simple Alt+F1 permet d’obtenir un shell root sur le système

30

afin de l’étudier au mieux. Les inconvénients rejoignent ceux de l’émulateur : très peu depilotes Wifi sont supportés par le noyau, il faut donc se contenter de la virtualisation del’interface Ethernet et bien qu’il soit possible de simuler une position GPS, cette solutionest très limitée en terme de mobilité et nous ne pouvons étudier la localisation GSM.

11.1.3 Téléphone sous OS Android

La seule solution restante est aussi la plus naturelle : utiliser un téléphone mobilefonctionnant sous Android. L’avantage est que nous pourrons étudier librement tous lesmoyens de localisation : Wifi, GPS, GSM et nous rapprocher au maximum des conditionsréelles. En contrepartie, nous devons faire face aux contraintes imposées par les construc-teurs et des opérateurs dont le plus important est le verrouillage du système et de sonbootloader.

Nous avons donc choisi de faire cette étude directement sur des téléphones Android.Pour contrôler au mieux notre device et obtenir les résultats que nous souhaitons, il faudradonc passer dans la prochaine partie - Préambule à l’étude de la localisation sur Android- par une étape de déverrouillage du téléphone et prendre possession de quelques outils dusystème de Google.

11.2 Préambule à l’étude de la localisation sur Android

L’essentiel du projet est effectué sur un smartphone HTC Desire HD sorti en 2010 sousla version 2.2 Froyo. Il a été mise à jour dans le courant de l’année 2011 sous la version 2.3Gingerbread et devrait accueillir la version 4.0 IceScreamSandwich (ICS) au mois d’août2012. Ce téléphone a été acheté desimlocké, nous mettons donc de côté toute contraintelogicielle ou matérielle provenant de l’opérateur.

11.2.1 Choix de la version du système

Le problème connu concernant les smartphones Android est la fragmentation des ver-sions du système. En échange d’une grande liberté offerte par Google aux constructeurset opérateurs sur la manipulation de son système d’exploitation, les utilisateurs souffrentd’importants retards concernant la mise à jour de leurs smartphones et tablettes. Alorsque la version 4.0 a été présentée lors de la conférence Google I/O de juin 2011, celle-ci nereprésente en mai 2012 que 9% de la répartition alors que la version 2.3 représente toujours55% de la répartition et 22% pour la version 2.2 [19]. Néanmoins, la version 4.0 est la plusadaptée à notre projet, car la possibilité de paramétrer un proxy sur les connexions Wifiest nativement installée sur l’OS, chose impossible sur les versions 2.3 et antérieure. Deplus, le nombre de smartphones et de tablettes vendus aujourd’hui étant considérable, laversion 4.0 sera sans aucun doute majoritairement répandue et utilisée en 2012-2013. Ilest plus intéressant et profitable d’étudier un système récent.

Ainsi, le coeur de ce préambule à l’étude de la localisation sur Android va être de passerle smartphone Desire HD 2.3 sur la version 4.0. Ce portage est rendu (légalement) possiblegrâce aux communautés de développeurs telles que CyanogenMod [20] qui adaptent lessources du système Android fournies par Google (ou à partir des sources de ROMs fourniespar des constructeurs pour leurs produits récents) aux smartphones non officiellementmis à jour par les constructeurs. Nous allons donc remplacer la ROM officielle 2.3 enROM "custom" 4.0. Le procédé sera décrit dans ses grandes lignes pour ne pas sortir denotre problématique, mais il va aussi nous permettre de mieux comprendre l’architecturelogicielle du smartphone afin de mieux le manipuler plus tard.

31

Note : la version Android 2.3 étant encore largement répandue nous ajouterons desremarques importantes concernant cette version lors de notre étude de la localisation. Eneffet, il est très intéressant de voir l’évolution concrète de la politique de Google envers lesproblèmes de vie privée que pose la récolte de données de géolocalisation.

11.2.2 Installation du SDK et outils du SDK

Installer le SDK Android disponible à http://developer.android.com/sdk/index.html estessentiel pour accéder aux 2 outils majeurs dans la manipulation du device Android (Note :une fois le SDK lancé il faut aussi installer le "SDK Platform-tools") :<repertoire-sdk>/plateform-tools/fastboot : cet outil va permettre de flasher des

images sur les partions Boot et Recovery à partir du bootloader<repertoire-sdk>/plateform-tools/adb : cet outil permet de communiquer avec le

device Android pour échanger des fichiers, échanger des applications, obtenir unshell... ADB est l’acronyme de Android Debug Bridge [21].

Remarque 1 : pour utiliser l’outil adb il faut autoriser le débogage USB sur le téléphone, surla version ICS 4.0 : "Paramètres/Section Système : Options pour les développeurs/cocherdébogage USB"Remarque 2 : dans l’analyse des données de localisation nous utiliserons à la fois un shelldepuis une machine Linux grâce à la commande "./adb shell" et un terminal directementinstallé sur le smartphoneRemarque 3 : la manipulation des outils du SDK est particulièrement aisée à partir d’unemachine sous Linux, nous avons travaillé la plupart du temps depuis une machine Ubuntu.Pour lancer l’interface graphique du SDK et, par exemple, manipuler l’émulateur Android,AVD manager, il faut lancer : <repertoire-sdk>/tools/android .

11.2.3 "Unlock" et "Rootage" de l’HTC Desire HD

Installer une ROM personnalisée permettant, entre autres, d’obtenir une version An-droid plus récente nécessite de débloquer le verrouillage du smartphone imposé par leconstructeur. Ceci permet d’accéder aux différentes partitions du smartphone et de les"flasher" avec de nouvelles images logicielles.

Un smartphone Android est construit sur 6 partitions principales [22] :la partition Boot : contient le noyau ou kernel du système, peut être flashée avec un

nouveau noyaula partition System : contient le système Android dans "/system" basé sur le noyau,

peut être flashée avec une ROM customla partition Userdata : contient les données utilisateurs dans "/data", cette partition

est particulièrement importante pour la suite de notre projet, car elle va contenir denombreuses données de localisation

la partition Hboot : contient le bootloader verrouillé par le constructeur et que nousallons "unlocker" dans la première étape

la partition Recovery : contient le système recovery du device qui permet de restaurerle système et d’effectuer des opérations telles que le formatage "wipe" des donnéessystèmes ou utilisateurs, gérer les partitions présentes sur la carte SD, monter lapartition de la carte SD sur une machine...

la partition Radio : gère toutes les connexions spécifiques à la téléphonie (connexionGSM, 3G...). Peut être flashée avec une nouvelle ROM radio.

32

La première étape du processus de "Rootage" dans sa globalité consiste donc à "unlo-cker" le smartphone afin de pouvoir contrôler le bootloader et manipuler ces partitions, enparticulier le Boot et le Recovery. Devant l’enthousiasme provoqué par les communautésde développeurs, HTC et d’autres constructeurs permettent aujourd’hui de déverrouiller"officiellement" leur device. C’est le cas pour le Desire HD dont la procédure détaillée estdisponible sur leur site dédié aux développeurs [23]. Une fois cette procédure effectuéenous pouvons redémarrer le smartphone en gardant le bouton VOL- appuyé pour accéderau bootloader et au mode Fastboot. Il faut alors connecter le smartphone en USB surune machine qui aura un terminal ouvert sur "<repertoire-sdk>/plateform/tools/", noussommes alors en mode Fastboot USB.

Nous pouvons effectuer la deuxième étape : installer ou "flasher" un recovery person-nalisé sur la partition Recovery nous permettant d’effacer l’ancien système et d’installernotre nouvelle ROM personnalisée et rootée Android 4.0. Nous effectuons les commandessuivantes (voir Figure 17) :

sudo ./fastboot devices //permet de vérifier que le device est connecté à notre machine en mode Fastboot./flashboot flash recovery <repertoire_imgRecovery>/<file_imgRecovery>.img //permet de flasher//la nouvelle Rom recovery dans la partition recovery

Figure 17 – Fastboot

Note : Nous choisissons de télécharger une image de rom recovery ClockWorkMod quiest la plus répandue aujourd’hui et disponible sur internet en version 5.0.2.3 .

La troisième étape consiste à flasher le noyau de la Rom custom. Une Rom custom seprésente généralement sous la forme d’un .zip contenant une image du noyau "boot.img"et un répertoire système qui sera flashé grâce au recovery dans l’étape suivante. De nom-breuses ROMs personnalisées sont disponibles sur le site de CyanogenMod réputées pourleur fiabilité et stabilité. La Rom faite pour le Desire HD utilisée ici sera tirée du site dela communauté de XDA Developper, elle est basée sur le système Android 4.0 et sur laROM CyanogenMod9. Il faut extraire l’image du noyau boot.img du dossier compressé et,par exemple, la placer dans le répertoire platform-tools du SDK, on peut alors effectuerla commande suivante :

./flashboot flash boot boot.img

Enfin, quatrième et dernière étape, nous redémarrons en mode recovery disponibleà partir du Hboot. La première chose à faire est de nettoyer le système en faisant un

33

formatage complet "full wipe" : wipe data, wipe cache, wipe battery stats, wipe dalvikcache... Il faut ensuite monter la carte SD sur notre machine Ubuntu pour copier dessus ledossier .zip complet de la rom custom. Nous pouvons alors utiliser le fonction principaledu recovery personnalisé : "install zip from sdcard" qui va installer notre rom Android 4.0.Ainsi, nous redémarrons le smartphone normalement et nous pouvons utiliser notre nouvelOS.

Important : Les deux avantages principaux de cette manipulation sont premièrementd’obtenir un système plus récent et d’obtenir les droits root sur notre device grâce à notreROM "rootée". Nous allons donc pouvoir par exemple, avec l’outil ./adb ou un terminaldirectement sur smartphone, analyser en tant qu’administrateur la partition /data in-disponible autrement. Obtenir ce droit nécessite de faire très attention à la source de laROM Android et aux applications installées qui pourraient alors aussi acquérir ces droitsde façon malveillante.

11.2.4 Outils de sécurité Android et transition à la géolocalisation

Nous avons déjà introduit l’utilisation de l’outil ./adb du SDK Android pour accéderà un shell root et analyser notre système. Bien que les Applications Android fonctionnentsur une machine virtuelle Java nommée Dalvik, ce système d’exploitation est basé sur unnoyau Linux. Nous allons donc utiliser tous les outils basiques tels que cp, ls, find, ps,top... Nous avons en plus installé l’application "Android Terminal Emulator" permettantd’émuler un terminal directement sur le device et de passer en Root avec la commande"su", la ROM demande alors la confirmation de l’appropriation des droits (voir Figure 18).

Figure 18 – Architecture Android – Demande de droits root

Ainsi en effectuant la simple commande "ps" puis en la filtrant nous obtenons nospremiers résultats :root@android:/ # ps | grep Locationapp_34 4316 1306 199988 44616 ffffffff 4001146c S com.Google.android.apps.maps:NetworkLocationServiceapp_34 4350 1306 192720 41640 ffffffff 4001146c S com.Google.android.apps.maps:LocationFriendService

Nous avons donc en particulier un processus de localisation géré par l’applicationGoogle Maps.

34

Deux autres outils sont utiles pour l’étude du système Android et notamment pourl’étude de la sécurité sur Android : [24]logcat : fournit des messages de log en temps réel sur tous les événements interagissant

au sein du système, la quantité d’information est donc très importantedumpsys : fournit des informations sur les services en marche sur le système

Les deux outils peuvent être utilisés directement sur le smartphone ou bien avec adb(plus efficace dans son utilisation avec l’historique et la complétion des commandes), nousallons tester dumpsys :

~/android-sdk-linux/platform-tools$ ./adb shell dumpsys > ./dumpsys_test.txt~/android-sdk-linux/platform-tools$ gedit ./dumpsys_test.txt &

En étudiant dumpsys_test.txt nous observons qu’un service "location" fonctionne, nouspouvons donc faire une recherche sur ce même fichier pour arriver à la section "DUMPOF SERVICE location". Le résultat que nous obtenons est à la hauteur de nos attentes,il fournit des données précises de géolocalisation.

Il est donc temps de plonger au coeur de notre étude sur les données de localisationsur Android traitée dans la partie suivant ce préambule et qui commencera donc par ledétail du résultat obtenu par le Dump du service de localisation.

35

12 Etude des données de géolocalisation sur Android et deséchanges associés

Dans cette partie nous allons commencer par reprendre le dump du service de localisa-tion fonctionnant sur Android et faire une première analyse du système dans son ensembleorientée sur la localisation. Ensuite nous étudierons la localisation utilisée avec l’appli-cation Google Maps pour des localisations ponctuelles. Comment les données sont-ellesstockées ? Quelles informations peut-on récupérer en mettant en place notre architectureavec le proxy ? Enfin, notre projet est parti du fait qu’Apple envoyait durant la nuit eten fond de tâche des informations de localisation pour optimiser sa base de données etpeut-être établir des profils pouvant atteindre la vie privée des utilisateurs. Qu’en est-il dusystème de Google et de l’anonymat de ses données ? Nous ajouterons une section rassem-blant quelques observations que nous avons faites lors de lancement d’applications tiercestelles que les PagesJaunes, la SNCF, Allocine...

12.1 Premiere analyse système orienté sur la localisation

Reprenons notre fichier dumpsys_test.txt pour analyser le dump du service de locali-sation. Ce dump contient plusieurs sous-sections :

- La section Location Listeners : elle donne les dernières demandes de localisationsfaites par des applications au service de localisation du système et le résultat retourné.Dans l’exemple suivant, extrait de dumpsys_test.txt nous pouvons voir que l’applicationYahoo ! Weather a effectué une requête de ce type. Remarque : En mettant en place leproxy, on observe que cette application, sans avoir été volontairement lancée, effectuerégulièrement des requêtes silencieuses de localisation.

DUMP OF SERVICE location:/* Section Location Listeners: */network: //indique la source de localisation: réseau wifi

UpdateRecord{417517a8 mProvider: network mUid: 10110}mProvider=network mReceiver=Receiver{4184c868 Intent PendingIntent{418b0438: PendingIntentRecord

{418b1f48 com.yahoo.mobile.client.android.weather startService}}}mUpdateRecords: {network=UpdateRecord{417517a8 mProvider: network mUid: 10110}}

mMinTime=1800000 mMinDistance=4000.0mSingleShot=falsemUid=10110mLastFixBroadcast:

mProvider=network mTime=1339378558391 //date de la requêtemLatitude=45.7770824 mLongitude=4.831412 // coordonnées de géolocalisationmHasAltitude=false mAltitude=0.0mHasSpeed=false mSpeed=0.0mHasBearing=false mBearing=0.0mHasAccuracy=true mAccuracy=36.0 //coefficient de précisionmExtras=Bundle[mParcelledData.dataSize=148]

mLastStatusBroadcast=0

Il est facile de vérifier l’emplacement correspondant aux coordonnées de géolocalisationen les entrant directement sur maps.Google.fr, le résultat est extrêmement précis, le lieuindiqué tombe sur le bâtiment où est situé le point d’accès sans-fil.

- La section Records by Provider : les providers étant "passive" pour la localisationGSM et "network" pour la localisation Wifi

La section Last Known Locations : comme la source "Android Forensics" l’indique, ils’agit de la section la plus intéressante, elle fournit les dernières localisations obtenues etconnues par le smartphone.

Last Known Locations:passive:

36

mProvider=network mTime=1339390771685mLatitude=45.777118 mLongitude=4.8315332mHasAltitude=false mAltitude=0.0mHasSpeed=false mSpeed=0.0mHasBearing=false mBearing=0.0mHasAccuracy=true mAccuracy=39.0mExtras=Bundle[mParcelledData.dataSize=148]

network:mProvider=network mTime=1339390771685mLatitude=45.777118 mLongitude=4.8315332mHasAltitude=false mAltitude=0.0mHasSpeed=false mSpeed=0.0mHasBearing=false mBearing=0.0mHasAccuracy=true mAccuracy=39.0mExtras=Bundle[mParcelledData.dataSize=148]

La structure des données est la même que pour les autres sections.Remarque : grâce à la même source nous remarquons que le service iphonesubinfo

fournit le numéro IMEI du Desire HD qui l’identifie de manière unique sur les réseauxGSM/UMTS.

Continuons notre première analyse du système avec quelques commandes simples etqui nous permettra de mieux nous orienter. Nous avons déjà une bonne idée des serviceset processus présents, passons au système de fichiers (les résultats non pertinents sontsupprimés) :

~/android-sdk-linux/platform-tools$ ./adb shell find / -iname "*location*"/system/app/NetworkLocation.apk // correspond à l’application Google de localisation Wifi et 3G.// Elle est à l’origine du processus NetworkLocation et est nativement installée dans le système Android.// Ne pas confondre avec l’application Google Maps. NetworkLocation n’est pas Open Source/system/etc/permissions/android.hardware.location.gps.xml // déclaration des permissions de localisation/system/etc/permissions/com.android.location.provider.xml ///system/framework/com.android.location.provider.jar // les classes disponibles pour les développeurs/data/data/com.Google.android.location // contient les données//concernant le service "location" de l’application NetworkLocation.

Voir la Note sur la version 2.3

~/android-sdk-linux/platform-tools$ ./adb shell find /system -iname "*maps*"/system/app/Maps.apk // correspond à l’application Google Maps/system/etc/permissions/com.Google.android.maps.xml/system/framework/com.Google.android.maps.jar // classes de l’API Google Maps

~/android-sdk-linux/platform-tools$ ./adb shell find /data -iname "*maps*"/data/data/com.Google.android.apps.maps // données utilisateurs pour l’application Google Maps/data/data/com.Google.android.apps.maps/app_sslcache/mobilemaps.clients.Google.com.443

Note sur la version 2.3 : De nombreuses sources sur internet s’intéressant aux pro-blèmes de vie privée et de géolocalisation[25] indiquent la présence d’un fichier "cache.wifi"et d’un fichier "cache.cell" contenant les derniers 50 à 200 identifiants GSM et BSSID ren-contrés avec leurs coordonnées géographiques. Ce point parait central dans notre projet,mais nous ne trouvons pas ces deux fichiers sur notre système 4.0. Pour vérifier l’existencede ces deux fichiers selon la version utilisée, nous avons effectué la recherche sur deuxautres devices :

– une tablette HP TouchPad rootée avec une ROMCM9 (Android 4.0) : même résultat,les fichiers ne sont pas présents.

– un smartphone ZTE rooté avec une ROM CM7 (Android 2.3) : les deux fichiers sontbien présents.

Les deux fichiers sont en binaires, pour les décoder nous utiliser un script python./parse.py dont la source est disponible sur ce lien [26] :

37

/media/Shared_Disk/CoursTSP/3A/PFE$ ./parse.py cache.wifidb version: 1total: 200

key accuracy conf. latitude longitude time00:1f:9d:20:e3:63 64 92 48.624980 2.442601 01/25/12 15:53:23 +0000fe:b1:5c:fa:fa:cb 80 87 48.619797 2.428877 02/15/12 08:09:54 +000000:21:d8:df:4c:e0 60 92 49.261889 1.198878 04/14/12 12:12:26 +0000f4:ca:e5:ff:cd:a0 235 87 48.619586 2.428148 06/01/12 07:56:09 +0000f4:ca:e5:ff:cd:a2 80 92 48.619766 2.428685 06/01/12 07:56:09 +0000e0:a1:d7:73:00:50 132 92 48.619185 2.428820 06/01/12 07:56:09 +0000f4:ca:e5:da:78:3d 60 92 48.619119 2.428704 06/01/12 07:56:09 +000000:18:e7:65:45:f0 59 92 49.269951 1.203300 06/04/12 00:30:21 +00004c:ac:0a:2f:ee:85 75 87 49.269633 1.203711 06/07/12 07:51:47 +000000:19:70:33:0f:54 137 92 49.269819 1.203684 06/07/12 07:53:17 +0000f0:f0:02:67:6f:32 171 92 49.269856 1.203368 06/07/12 07:53:17 +00005c:33:8e:be:42:5a 60 92 49.269905 1.203295 06/07/12 07:53:17 +0000

/media/Shared_Disk/CoursTSP/3A/PFE$ ./parse.py cache.celldb version: 1total: 50

key accuracy conf. latitude longitude time208:20:20181:1181973 943 75 48.941226 2.260738 06/04/12 15:01:19 +0000208:20:20171:14242710 703 75 48.924856 2.256506 06/04/12 17:25:04 +0000208:20:20171:14248920 904 75 48.911108 2.267676 06/04/12 17:26:15 +0000208:20:20181:1181376 897 75 48.914011 2.250000 06/04/12 17:27:06 +0000208:20:246:3892 2151 75 48.948599 2.032179 06/08/12 08:19:40 +0000208:20:20371:2431877 1358 75 48.945660 2.148444 06/08/12 08:23:58 +0000208:20:20181:1183478 919 75 48.904848 2.229808 06/08/12 08:30:03 +0000208:20:20081:13634527 532 75 48.878982 2.322230 06/08/12 09:00:15 +0000

Tous les résultats ne sont pas affichés dans ce rapport, mais nous pouvons donc observer200 BSSID et 50 identifiants d’antennes GSM avec leurs coordonnées, la précision, la datedu 25 janvier au 8 Juin 2012. Suite à la polémique engendrée par la création de tels fichierssur iOS, Google aurait pu décider de faire évoluer aussi son système et de stopper ce typede cache ou bien le dissimuler d’une autre manière.

Voici quelques portions de trajets parmi les 200 positions enregistrées sur une map

Figure 19 – Carte Google Maps d’une partie des BSSID enregistrés

38

12.2 Localisation ponctuelle avec Google Maps

12.2.1 Description de la manipulation

Maintenant que nous avons un bon aperçu des services de localisation et de l’environ-nement des fichiers pour la localisation, analysons l’échange effectué entre le smartphoneAndroid et les serveurs de Google pour une localisation avec Google Maps. Contrairementà Apple qui renvoie une série de BSSID au téléphone qui effectue les calculs lui-même, ilest déjà connu que Google préfère effectuer le calcul sur ses propres serveurs et renvoyerdirectement la position géographique. Il convient d’effacer le cache de Google Maps afind’obtenir le plus d’information possible lors de l’échange(touche Menu/Gérer les applica-tions/Maps/Effacer les données).

Adresse IP du Desire HD : 192.168.0.13Adresse IP du proxy sur machine Ubuntu : 192.168.0.17Adresse MAC du point d’accès sans-fil (BSSID) : 00 :1A :2B :57 :71 :76GPS désactivé : nous nous concentrons sur la géolocalisation réseau car l’identification desBSSID peut permettre l’identification des lieux et des utilisateurs.

12.2.2 Observation des échanges sur le proxy

1. paramétrage du proxy sur la connexion wifi du smartphone2. lancement du proxy ./proxy3. lancement de l’application Google Maps4. demande de localisation sur l’application5. résultats :

Nous observons tout d’abord en faisant un ./adb logcat que l’Application Google Mapsfait appel au service de localisation réseauI/ActivityManager( 1414): Start proc com.Google.android.apps.maps:NetworkLocationServicefor service com.Google.android.apps.maps/com.Google.android.location.internal.server.NetworkLocationService:pid=5178 uid=10034 gids={3003, 1015}

Puis nous observons les flux sur le proxy./showp packets.db > echanges_lyon_gmaps.txt

De nombreuses requêtes apparaissent, mais un échange contenant le nom de notreBSSID "NUMERICABLE_MAP" attire notre attention :

Requête en SSL du smartphone au serveur mobilemaps.clients.Google.com/glm/mmapdepuis le port 43299

[00000102] 06/02/29,23:33:58,464594 192.168.0.13:43299 74.125.230.192:443POST mobilemaps.clients.Google.com:443POST /glm/mmap HTTP/1.1Content-Type: application/binaryContent-Length: 1059Host: mobilemaps.clients.Google.comConnection: Keep-AliveUser-Agent: Mozilla/5.0 (Linux; U; Android 4.0.4; fr-fr; Build/IMM76D) AppleWebKit/534.30(KHTML, like Gecko) Version/4.0 Mobile Safari/534.30 (ace IMM76D); gzip

000000: 00 17 f2 b7 24 ac 49 90 19 79 00 02 66 72 00 19 | ....$.I..y..fr..000010: 61 6e 64 72 6f 69 64 3a 48 54 43 2d 61 63 65 2d | android:HTC-ace-000020: 44 65 73 69 72 65 20 48 44 00 08 36 2e 38 2e 31 | Desire HD..6.8.1000030: 2e 30 31 00 12 67 6d 6d 2d 61 6e 64 72 6f 69 64 | .01..gmm-android

39

000040: 2d 67 6f 6f 67 6c 65 3e 00 00 01 f9 0a 03 34 38 | -Google>......48000050: 38 10 01 18 d0 01 20 01 2a 03 47 4d 4d 92 01 06 | 8..... .*.GMM...000060: 53 59 53 54 45 4d 9a 01 10 36 66 33 37 32 63 32 | SYSTEM...6f372c2000070: 39 30 65 65 31 66 32 64 64 a2 01 a0 02 44 51 41 | 90ee1f2dd....DQA000080: 41 41 4d 30 41 41 41 44 6d 78 71 68 31 74 4f 47 | AAM0AAADmxqh1tOG000090: 66 37 2d 6f 34 62 74 64 53 6f 5a 69 4c 68 55 53 | f7-o4btdSoZiLhUS0000a0: 4d 48 70 47 73 4d 31 35 4c 33 49 39 68 39 6d 57 | MHpGsM15L3I9h9mW/* trame coupée */000260: 4a 30 63 4d 59 78 51 61 7a 63 58 6f 3a 33 76 62 | J0cMYxQazcXo:3vb000270: 73 44 48 70 70 77 2d 78 50 67 52 34 32 32 0e 08 | sDHppw-xPgR422..000280: 05 12 05 46 20 53 46 52 20 0a 28 d0 01 3a 10 12 | ...F SFR .(..:..000290: 0c 31 33 2e 30 2e 31 36 38 2e 31 39 32 18 02 12 | .13.0.168.192...0002a0: 04 18 07 30 0f 22 6e 0a 22 0a 19 08 de 82 03 10 | ...0."n.".......0002b0: f0 a8 d3 06 18 0a 20 d0 01 28 ff ff ff ff ff ff | ...... ..(......0002c0: ff ff ff 01 10 8c e7 e0 e0 fd 26 12 38 08 8d e7 | ..........&.8...0002d0: e0 e0 fd 26 12 2f 0a 11 30 30 3a 31 61 3a 32 62 | ...&./..00:1a:2b0002e0: 3a 35 37 3a 37 31 3a 37 36 12 0f 4e 55 4d 45 52 | :57:71:76..NUMER0002f0: 49 43 41 42 4c 45 5f 4d 41 50 20 b5 ff ff ff ff | ICABLE_MAP .....000300: ff ff ff ff 01 1a 0e 0a 0a 0d 54 1f 49 1b 15 8e | ..........T.I...000310: 6f e1 02 40 01 07 02 ba 80 d5 00 49 ba 5f 02 ba | o..@.......I._..000320: 80 d5 00 49 ba 5f 00 10 00 00 1d 08 00 00 1a 39 | ...I._.........9000330: 01 01 6c 00 00 00 ec 0a 12 08 80 02 10 00 10 0b | ..l.............000340: 18 04 20 01 28 01 35 00 00 c0 3f 4a 19 08 0f 10 | .. .(.5...?J....000350: ef 86 02 18 cd b6 01 20 10 38 00 40 ff ff ff ff | ....... .8.@....000360: ff ff ff ff ff 01 4a 19 08 0f 10 f0 86 02 18 cd | ......J.........000370: b6 01 20 10 38 00 40 ff ff ff ff ff ff ff ff ff | .. .8.@.........000380: 01 4a 19 08 0f 10 ef 86 02 18 cc b6 01 20 10 38 | .J........... .8000390: 00 40 ff ff ff ff ff ff ff ff ff 01 4a 19 08 0f | .@..........J...0003a0: 10 ee 86 02 18 cd b6 01 20 10 38 00 40 ff ff ff | ........ .8.@...0003b0: ff ff ff ff ff ff 01 4a 19 08 0f 10 ef 86 02 18 | .......J........0003c0: ce b6 01 20 10 38 00 40 ff ff ff ff ff ff ff ff | ... .8.@........0003d0: ff 01 4a 19 08 0f 10 f0 86 02 18 cc b6 01 20 10 | ..J........... .0003e0: 38 00 40 ff ff ff ff ff ff ff ff ff 01 4a 19 08 | 8.@..........J..0003f0: 0f 10 f0 86 02 18 ce b6 01 20 10 38 00 40 ff ff | ......... .8.@..000400: ff ff ff ff ff ff ff 01 4a 19 08 0f 10 ee 86 02 | ........J.......000410: 18 cc b6 01 20 10 38 00 40 ff ff ff ff ff ff ff | .... .8.@.......000420: ff ff 01

La fin de la trame semble être structurée pour délivrer des données, il s’agit doncprobablement de données encodées par le protocole buffer. Comme l’indique ce lien http://bigbrothermobile.com/blog/?p=83 qui présente une manipulation semblable sur la ver-sion 2.3, seule une partie de la trame semble être encodée en protocole buffer. Grâce auprogramme Blob_Sqlite [27], nous exportons donc le payload de cette trame pour effectuerdes tests de lecture dessus. L’export est un binaire que nous éditons avec l’éditeur héxadé-cimal GHex. Afin de trouver où débute le protocole buffer, nous effectuons la commande :

PFE/blob_echanges_lyon_gmaps$ protoc --decode_raw < ./data_from_packets_42

avec un offset (en octet) de départ incrémenté de 1 à chaque fois et nous obtenonsenfin un message cohérent :

0: "5\350\001\000\372\001\215\001\n\203\00160=KDmsrqBI6KgBJ1Tq8kv47QnQrCJcTXz2TE4"15: "-2MctBlW3Loae9rmdxLRMPGzoc55UQceUsEW8wiObkkT9FnUbcW2h40hECyhZ06JXWG_CxJtwJoipn5vw3qj"10: 0xe81042624b5f6b56234292661: "\001\210\002\001\240\002\001)\000\000\000\313\010\001\022\306\001\nN\n\0056.8.1\032#2:MpXoJ0cMYxQazcXo:3vbsDHppw-xPgR422\016\010\005\022\005F SFR\n(\320\001:\020\022\01413.0.168.192\030\002\022\004\030\0070\017\"n\n\"\n\031\010\336\202\003\020\360\250\323\006\030\n \320\001(\377\377\377\377\377\377\377\377\377\001\020\214\347\340\340\375&\0228\010\215\347\340\340\375&\022/\n\02100:1a:2b:57:71:76\022\017NUMERICABLE_MAP \265\377\377\377\377\377\377\377\377\001\032\016\n\n\rT\037I\033\025\216o\341\002@\001\007\002\272\200\325\000I\272_\002\272\200\325\000I\272_\000\020\000\000\035\010\000\000\0329\001\001l\000\000\000\354\n\022\010\200\002\020\000"2: 113: 44: 15: 1

40

6: 0x3fc000009 {

1: 152: 336473: 233734: 167: 08: 18446744073709551615

}/* série de coordonnées GSM */

9 {1: 152: 336463: 233724: 167: 08: 18446744073709551615

}

Nous pouvons voir que seul un BSSID est transféré avec son adresse IP, il correspondau BSSID auquel nous sommes connectés. Grâce à la même source notons que l’entête de cemessage contient des tokens et des identifiants qui peuvent se retrouver dans des échangesd’authentification au compte Google et qui permettraient d’associer un utilisateur à unedonnée de localisation.

Réponse du serveur de Google La réponse faite par le serveur est bien plus longue,l’analyse est plus difficile et ne fait pas apparaitre de structure de données pouvant êtreanalysée avec le protocol buffer. Nous pouvons supposer que cette réponse contient desimages fournies à l’application Google Maps.

[00000103] 08/13/17,21:38:47,097097 74.125.230.192:443 192.168.0.13:43299200 mobilemaps.clients.Google.com:443HTTP/1.1 200 OKContent-Type: application/binaryContent-Length: 2061Date: Mon, 11 Jun 2012 15:10:11 GMTExpires: Mon, 11 Jun 2012 15:10:11 GMTCache-Control: private, max-age=0X-Content-Type-Options: nosniffX-Frame-Options: SAMEORIGINX-XSS-Protection: 1; mode=blockServer: GSE

000000: 00 17 3e 00 00 00 00 29 00 00 00 02 08 00 07 6c | ..>....).......l000010: 00 00 07 f9 0a 04 08 39 10 00 4a e4 01 0a 11 08 | .......9..J.....000020: 0f 10 ef 86 02 18 cd b6 01 20 10 40 de 81 b7 54 | ......... .@...T000030: 12 ce 01 44 52 41 54 00 09 00 00 00 b1 0c 88 a5 | ...DRAT.........000040: 95 87 39 15 de bf a7 ba 90 2b 69 43 71 46 c0 8c | ..9......+iCqF..000050: a7 3f d4 fe 44 01 c1 da ef 06 75 f0 5b 35 7e df | .?..D.....u.[5~.000060: 8c 62 72 1e c7 f6 df 0e 53 59 07 e3 bf 0f 0b f4 | .br.....SY......000070: c8 aa 0a 09 c5 45 81 04 a2 a3 8a ee 99 2c a2 6e | .....E.......,.n000080: 8b ad d5 36 ab 24 29 80 64 13 88 64 43 cc 33 1a | ...6.$).d..dC.3.000090: 98 3f b7 94 67 52 44 72 8d 85 e1 a9 68 fa 91 b8 | .?..gRDr....h...0000a0: 5c 3d 1d a7 3b ea d7 43 08 3b 49 65 30 ee 1b fd | \=..;..C.;Ie0...0000b0: 0d 2f 6f a7 23 ef b9 ed 12 b2 e3 33 8e 88 62 28 | ./o.#......3..b(0000c0: 7f c7 ec 39 82 7d 31 a6 01 98 fa 1a f2 e6 89 1c | ...9.}1.........0000d0: 79 97 7d 44 16 d0 33 a5 be 10 04 9f 77 5f 29 94 | y.}D..3.....w_).

Remarque sur l’application Navigation : le répertoire de cache de l’application Maps-Navigation contient les dernières maps utilisées avec des fichiers audios dictant le dernieritinéraire.

41

12.3 Localisation périodique et silencieuse avec www.Google.com/loc/m/api

Tout le travail précédent sur les fonctions et le codage de données de localisationsur le système de Google va nous permettre d’étudier aisément notre objectif final : desdonnées sont-elles transférées à la manière d’Apple pour l’unique besoin de Google et nonde l’utilisateur ? Nous allons aussi essayer de comprendre en cas de transferts de données,si celles-ci peuvent être liées à l’utilisateur et l’identifier.

Nous avons donc laissé tourner régulièrement et sur de longues périodes le Desire HDconnecté au proxy afin d’observer son comportement.

Il n’apparait pas que des bases de données comme celles d’Apple ou bien de longs fi-chiers tels que cache.wifi ou cache.cell soient échangés avec les serveurs de Google mais nousobservons sans difficulté des échanges "silencieux", périodiques et aussi effectués lorsquenous sortons le smartphone de veille, avec le serveur de Google : www.Google.com/loc/m/api.

La trame qui est envoyée régulièrement est assez légère, voici ce que nous récupéronsauprès du proxy :

[00000102] 06/23/68,10:28:02,872203 192.168.0.13:49375 74.125.230.242:443POST www.Google.com:443POST /loc/m/api HTTP/1.1Content-Type: application/binaryContent-Length: 511Host: www.Google.comConnection: Keep-AliveUser-Agent: GoogleMobile/1.0 (ace IMM76D); gzip

000000: 00 02 00 00 1f 6c 6f 63 61 74 69 6f 6e 2c 31 31 | .....location,11000010: 31 36 2c 61 6e 64 72 6f 69 64 2c 67 6d 6d 2c 65 | 16,android,gmm,e000020: 6e 5f 55 53 bb bd ec ea b0 39 06 e9 00 01 67 00 | n_US.....9....g.000030: 00 01 c9 00 01 01 00 01 00 08 67 3a 6c 6f 63 2f | ..........g:loc/000040: 75 6c 00 00 00 04 50 4f 53 54 6d 72 00 00 00 04 | ul....POSTmr....000050: 52 4f 4f 54 00 00 00 01 a1 00 01 67 1f 8b 08 00 | ROOT.......g....000060: 00 00 00 00 00 00 e3 6a 65 e4 62 31 34 34 34 13 | .......je.b1444.000070: 72 4c cc 4b 29 ca cf 4c d1 4f cf cf 4f cf 49 d5 | rL.K)..L.O..O.I.000080: af 4c cc ce 2a d5 cf 4d 4c 2f 2d ca b7 32 d1 33 | .L..*..ML/-..2.3000090: d0 33 d2 f7 74 f6 31 35 76 d3 37 32 36 35 34 b7 | .3..t.15v.72654.0000a0: b4 2a 2d 4e 2d d2 2f 4a cd 49 4d 2c 4e d5 cd 4e | .*-N-./J.IM,N..N0000b0: ad 2c 96 52 36 b2 ca af 08 08 34 8f 2f cd 2a 73 | .,.R6.....4./.*s0000c0: 4d 4f ae cc 73 a9 b0 f2 f6 ca 2d 2b 0f 4a 29 a9 | MO..s.....-+.J).0000d0: f0 f0 f0 ce 2b 29 2c d7 62 4d 2b 8a 77 0b 32 e2 | ....+),.bM+.w.2.0000e0: e3 60 15 62 75 53 08 76 0b 52 e0 d2 b8 c0 a8 b4 | .‘.buS.v.R......0000f0: 86 89 4b 9a 4b 88 e3 5e 13 b3 40 db e3 cb 6c 12 | ..K.K..^..@...l.000100: 5c 0a 17 18 1d 54 02 58 05 da 1b 6e 6e fb ab 26 | \....T.X...nn..&000110: d4 ce c4 71 f2 f7 0d 10 4b 9b 8b 41 48 d4 2f d4 | ...q....K..AH./.000120: d7 35 c8 d3 d9 d1 c9 c7 55 d7 dc d5 d8 31 3e c4 | .5......U....1>.000130: 35 38 44 61 cf 7f 28 60 74 f8 f6 e8 ee ad 45 cc | 58Da..(‘t.....E.000140: 42 f2 40 c5 9c 7e ae a1 6e f1 a6 ce 66 26 0a 0b | B.@..~..n...f&..000150: 10 0a 5e ec f8 ba e6 22 8b 90 2c 50 01 bb 9f 6b | ..^...."..,P...k000160: 88 bb ab 63 90 c2 62 84 f4 83 fb ed 97 1f 31 83 | ...c..b.......1.000170: a5 d9 f2 8b 12 f3 d2 53 15 96 20 64 5f de fc d5 | .......S.. d_...000180: 34 fd 30 93 90 1a 50 9a 1f e4 87 f0 4c b7 4c 85 | 4.0...P.....L.L.000190: 80 d2 a4 9c cc 64 85 f9 48 ea 40 96 1c 31 11 52 | .....d..H.@..1.R0001a0: 02 aa e3 f1 c9 2c 4b 4d ca af d0 4d 33 b2 30 51 | .....,KM...M3.0Q0001b0: 58 8a 66 18 33 d8 2c 01 24 7f 41 bc b4 17 dd 4b | X.f.3.,.$.A....K0001c0: b3 d8 98 38 98 94 76 30 72 c9 72 89 a0 06 97 86 | ...8..v0r.r.....0001d0: 10 72 80 4d 64 e4 58 72 ef 2f 88 85 69 f9 32 22 | .r.Md.Xr./..i.2"0001e0: 2d c7 0c 4f 94 e0 5a 81 37 b8 56 a0 59 72 98 09 | -..O..Z.7.V.Yr..0001f0: ec 74 0b 45 00 0c 8b ef 13 74 02 00 00 00 00 | .t.E.....t.....

Nous ne pouvons distinguer de structure de données au premier abord, cependantl’entête indique que le payload a été compressé (gzip).

De la même manière que pour l’analyse sur Google Maps, nous exportons cette trameà l’aide de l’outil Blob_Sqlite afin d’obtenir un binaire du contenu de la trame. Une

42

recherche rapide nous indique en plus que le format gzip débute par les octets 0x 1F 8B.À l’aide de GHex, nous éditons donc le fichier en hexadécimal afin de le faire débuter à cetendroit. Il ne reste plus qu’à renommer le fichier avec une extension .gz et utiliser gzip :

$mv trame_analysee trame_analysee.gz$gzip -d trame_analysee.gz

En ouvrant directement ce fichier binaire décompressé avec un éditeur de texte, onconstate la présence structurée de noms de points d’accès, il est donc fort probable que lesinformations aient été envoyées avec le protocole buffer. Utilisons le script pour le décoder :

En commentaire // l’analyse des tags importants

$ protoc --decode_raw < ./data_from_packets_261 {

1: "1116"2: "android/Google/yakju/maguro:4.0.2/ICL53F/235179:user/release-keys"3: "2:oxPQ7_ujvEgcynDx:KJmvwRdtxHHKntqw"// clé d’authentification de l’utilisateur qui fait le lien avec une session gmail5: "fr_FR"6 { // Structure de données concernant le réseau GSM auquel appartient le téléphone

1: 52: "F SFR"4: 105: 208

}}4 {

1 {1 { // Strucutre de données concernant une antenne GSM/UMTS à portée

1: 49502 // Location Area Code2: 13955462 // Cell ID3: 10 // Mobile Network Code: SFR4: 208 // Mobile Country Code : France8: 36 // Coefficient de précision10: 5

}2: 1339339194375 //timestamp: $date -d @1339339194.375 --> Sun Jun 10 16:39:54 CEST 2012

}2 {

1:2 {

1: "" // Note - dans la version 2.3, ce tag contenait directement le BSSID déclaré en hexadécimal2: "NUMERICABLE-7E3A_TEST" // Nom du point d’accès4: 18446744073709551548 // Coefficient de puissance du signal reçu8: 112396300662// Conversion décimale du BSSID normalement en hexadécimal --> 1A2B577176 --> 00:1A:2B:57:71:76

}2 { //Même analyse pour le reste des BSSID

1: ""2: "NEUF_5C64"4: 184467440737095515208: 159276424296 // 00:25:15:9D:5C:68

}2 {

1: ""2: "NETGEAR"4: 184467440737095515238: 129560080352 // 00:1E:2A:61:EF:E0

}2 {

1: ""2: "orange"4: 184467440737095515248: 11104375713001

}2 {

1: ""2: "SFR WiFi Public"

43

4: 184467440737095515198: 231056718257257

}2 {

1: ""2: "Livebox-f284"4: 184467440737095515258: 109259435241

}2 {

1: ""2: "NUMERICABLE_TEST"4: 184467440737095515498: 112396300662

}}

Nous remarquons alors que ce sont tous les BSSID à portée du smartphone à l’ins-tant où est envoyée cette trame. Connaitre tous ces BSSID avec le coefficient de puis-sance permet sans aucun doute à Google d’établir une cartographie "réseau" très com-plète, mais aussi de savoir où est localisé l’utilisateur à chaque instant t=timestamp.En effet, nous retrouvons en début de trame, comme pour l’application Google Maps(#2 :MpXoJ0cMYxQazcXo :3vbsDHppw-xPgR), une clé "2 :oxPQ7_ujvEgcynDx :KJmv-wRdtxHHKntqw" qui pourrait identifier un compte gmail associé au smartphone Android.L’anonymat parait donc fortement compromis.

44

Cinquième partie

Vie privée et proposition de solutionsNous allons finir cette étude par les moyens pour un utilisateur de protéger sa vie privée

des problèmes de confidentialité que nous avons pu apercevoir dans les parties précédentes.

13 Réglages appropriés du smartphoneLa première manière de protéger sa vie privée peut sembler évidente, mais n’est pas for-

cément si évidente à mettre en oeuvre. En effet, régler de façon appropriée son smartphonepermet de limiter une grande partie des échanges de géolocalisation entre le smartphoneet un serveur distant. Mais, devant la multitude de paramètres de configuration d’unsmartphone, il n’est pas toujours évident de trouver les réglages à effectuer.

13.1 Réglages sur un iPhone

Le premier réglage à effectuer pour protéger sa vie privée est de désactiver les envoisde "Diagnostic et utilisation". Pour cela, aller dans l’application Réglages -> Général-> Informations -> Diagnostic et utilisation -> Ne pas envoyer (voir Figure 20). Ons’aperçoit tout de suite du nombre de sous-menus pour trouver ce paramètre. En cas demauvais paramétrage au premier démarrage de l’appareil, il est presque impossible qu’unutilisateur tombe par hasard sur ce réglage. Ce réglage supprime l’intégralité des envoisnocturnes de l’iPhone aux serveurs d’Apple (envois de BSSID et d’antennes GSM) ainsique d’autres statistiques d’utilisation du téléphone.

Figure 20 – Désactiver l’envoi des données diagnostic – Services de localisation

Le deuxième paramétrage important concernant les envois de données de géolocalisa-tion se situe dans Réglages -> Service de localisation (voir Figure 20). Il y a ici deux choixpossibles, désactiver complètement les services de localisation sur l’iPhone. Ainsi, il n’yaura plus aucun envoi à Apple, mais cette solution ne permet plus d’utiliser aucun moyende géolocalisation ni le GPS. La deuxième chose possible est plus intéressante, il y est

45

possible de limiter les applications qui peuvent avoir accès aux données de localisation.Ainsi, si une application n’est pas autorisée à avoir ces données de localisation, elle nepourra jamais connaître la position du téléphone. Il est préférable de limiter les applica-tions autorisées à avoir les données de localisation aux applications qui en ont vraimentl’utilité.

Dans les paramétrages de l’iPhone, il n’est cependant pas possible d’interdire leséchanges avec le serveur https://gs-loc.apple.com en limitant la géolocalisation à la géolo-calisation GPS. Il faudra donc trouver une autre technique pour ceux qui ne désirent pasqu’un serveur distant sache quand on est chez soi ou non.

13.2 Réglages sur Android

Nous retrouvons des paramètres similaires sur Android. Dans les menus Paramètres> Services de Localisations (voir Figure 21). Il est possible d’activer ou de désactiver lalocalisation réseau ainsi que la localisation GPS. Attention, ces réglages ont un impact surtoutes les applications du téléphone nécessitant un service de localisation.

Figure 21 – Services de localisation et Autorisation des applications sur Android

Il est aussi possible de couper les envois de localisation silencieux vers https://Google.com/loc/m/api en décochant l’option "Localisation et Recherche" visant, comme il estindiqué, à "améliorer vos résultats de recherche et autres services de Google".

Pour mieux protéger sa vie privée, il est essentiel de faire attention, lors du téléchar-gement d’une application, à tous les services système auxquels vont faire appel ces appli-cations (voir Figure 21) afin de repérer les appels systèmes abusifs (contact du téléphone,data, localisation non nécessaire au fonctionnement...)

14 FiltrageNous allons dans cette partie décrire une autre technique permettant de protéger plus

efficacement sa vie privée. Cette technique consiste à filtrer sur le firewall/point d’accès

46

tous les paquets à destination d’une adresse précise. Par exemple https://gs-loc.apple.compour Apple et https://mobilemaps.clients.Google.com pour Google. Ce filtrage peut êtreeffectué par exemple avec les commandes iptables suivantes :iptables -A OUTPUT -d gs-loc.apple.com -p tcp --dport 443 -j DROPiptables -A OUTPUT -d mobilemaps.clients.Google.com -p tcp --dport 443 -j DROP

Avec ce filtrage, on supprime donc l’intégralité des flux de localisation échangés entrele smartphone et le serveur distant, mais on perd aussi forcément ses avantages : la géolo-calisation en Wi-Fi n’est plus possible.

15 Solutions logiciellesPour remédier aux problèmes de vie privée causés par les services de géolocalisation

sur smartphone sans perdre les avantages de ce type de géolocalisation qui est très efficaceen intérieur et en ville, il faut développer des solutions logicielles, permettant de filtrer lesinformations trop personnelles et laisser passer assez d’informations pour pouvoir utilisercette géolocalisation. Nous allons évoquer différentes possibilités dans cette partie, maisseule la première sera développée, car nous avons pu la mettre en place.

15.1 Serveur copie du serveur distant

Le principe de cette solution est de reproduire une copie du serveur distant (apparte-nant soit à Google soit à Apple) et de rediriger tous les flux permettant la géolocalisationvenant du téléphone sur le serveur copie (sur lequel on est donc sûr qu’il n’y a aucuntraçage). Bien sûr, il faudra récupérer une copie de la base de données de BSSID avecleurs coordonnées présentes sur le serveur d’Apple. Pour cela, quand un BSSID ne serapas dans la base de données, il suffira de le récupérer sur la base de données d’Apple, puisensuite de l’ajouter à une base de données locale.

Le serveur copie d’Apple sera hébergé sur l’ordinateur du réseau local. Sur le serveurweb Apache installé sur ce poste, il est configuré un VirtualHost permettant au serveurde se reconnaître sous le nom d’hôte "gs-loc.apple.com", permettant d’activer ssl et avecScriptAlias permettant d’activer l’exécution de scripts cgi :<VirtualHost *:443>DocumentRoot "/home/sites/test/"ServerName gs-loc.apple.comSSLEngine onSSLCertificateFile /Applications/MAMP/conf/ssl/server.crtSSLCertificateKeyFile /Applications/MAMP/conf/ssl/server.keyScriptAlias /clls/ /home/sites/test/cgi/clls/</VirtualHost>

Le script permettant de retourner les BSSID et leur cordonnées au téléphone sera unscript python exécuté via CGI (une interface permettant d’exécuter des scripts sur unserveur web). Cela permet de retourner un résultat dynamique tout en étant écrit dans lelangage python qui permet d’utiliser les Protocol Buffers. La page appelée sur le serveurd’Apple est la page "clls/wloc". Elle aura donc la même adresse sur le serveur copie.

Le script python s’exécutant quand la page wloc est appelée peut être trouvé en AnnexeE.1. Nous allons en expliquer les grandes lignes.

La première étape est de lire les données envoyées par le smartphone pour trouver leBSSID à localiser. Si ce BSSID est dans la base de données (stockée en sqlite dans notrescript) du serveur copie, alors, on prend 200 BSSID (le nombre généralement envoyé parApple en zone Wi-Fi dense) de latitude et longitude proche (50 de longitude et latitude

47

croissante et décroissante). On les encode en protocol buffer et les envoie au téléphone. Sile BSSID n’est pas dans la base de données, on en fait la demande à Apple, stocke tous lesBSSID renvoyés dans la base de données et envoie la réponse au téléphone. Ce script n’estbien sûr pas optimisé, mais permet assez simplement de limiter les requêtes effectuées versle serveur d’Apple.

La dernière étape pour faire fonctionner ce script est d’activer une redirection NATdes paquets vers https://gs-loc.apple.com vers l’ordinateur sur lequel tourne le script.

iptables -t nat -A PREROUTING -i br0 -s 192.168.0.46 -d gs-loc.apple.com \-p tcp --dport 443 -j DNAT --to 192.168.0.10:443

Il faut aussi ajouter au téléphone le certificat généré sur l’ordinateur pour le serveurhttps avec comme nom "*.Apple.com".

Pour tester ce serveur, nous avons aussi utilisé un script qui peut être trouvé en AnnexeE.2 permettant d’effectuer la même requête sur le serveur copie et sur le serveur d’Appleafin de comparer ensuite les réponses et voir si celles-ci sont cohérentes.

Remarque : Cette technique est évidemment possible uniquement dans un endroitoù on contrôle le réseau, par exemple chez soi. Cela pourrait poser un problème, car cen’est pas le cas la plupart du temps. Cependant, en dehors de chez soi, Apple ne disposepas d’assez d’informations pour identifier une personne. Cette solution permet donc delimiter efficacement la possibilité de traçabilité depuis les serveurs d’Apple sans perdre lesavantages de la localisation en intérieur et sans avoir besoin de jailbreaker son téléphone.

15.2 Autres solutions envisagées

Il y a plusieurs autres solutions logicielles que nous avons envisagées pour se protégerdes envois effectués par les smartphones vers les serveurs distants :Envoyer des informations fausses : la première est de mettre en place un filtrage

qui modifie les informations permettant au service distant d’identifier l’utilisateur(par exemple avec les serveurs d’Android, supprimer ou modifier la clé identifiant lecompte gmail). Ainsi, il serait toujours possible de profiter du service, sans donner sesinformations personnelles. Il faudrait bien sûr vérifier que le serveur distant acceptede recevoir des informations fausses.

Réduire la taille de la liste envoyée : S’il n’est pas possible d’envoyer des informa-tions fausses au serveur, il est peut-être possible de réduire les informations envoyées(envoyer par exemple un BSSID un peu plus lointain et toujours le même) pour quele serveur ne soit plus en mesure de géolocaliser précisément le téléphone.

Exécuter un programme sur le téléphone : En utilisant un téléphone rooté sousAndroid ou jailbreaké pour les iPhones, il est possible d’exécuter un programmepersonnalisé en tâche de fond. Il est ainsi possible de développer un programme quieffectue le filtrage des données envoyées depuis le téléphone ce qui permet de pou-voir faire le filtrage en permanence. Nous avons en effet observé lors des échangessur Android avec des applications telles que Allociné des informations sensibles pas-ser tel que le numéro de téléphone. Cette solution serait possible à mettre en placeen partant du projet TaintDroid [28] disponible avec une démonstration sur le lienhttp://appanalysis.org/demo/index.html. Dans cette démonstration, l’utilisateur estalerté que son IMEI est transféré alors l’application lancée n’en à aucunement be-soin.

48

Conclusion

Cette étude nous a permis de nous plonger au coeur des informations échangées entre unsmartphone et les serveurs d’Apple et de Google. Nous avons ainsi pu nous rendre comptede la quantité très conséquente de données qui sont envoyées depuis les smartphones surces serveurs et qui peuvent contenir des informations personnelles, identifiant l’utilisateursans que celui-ci n’en soit réellement conscient.

Nous soulignons ici l’importance du rôle du certificat et de la chaîne de certificationdans les échanges SSL pour garantir l’authentification des entités concernées pour éviterl’attaque du Man-in-the-Middle.

Travailler sur ce projet nous a permis d’appréhender de nouvelles compétences tech-niques, dans la manipulation du Python, du Protocol Buffer, du proxy et du systèmed’exploitation des smartphones iOS / Android.

L’évolution du projet nous a fait modifier notre plan de départ. En effet, nous n’avonspas pu développer la partie sur les scénarios d’attaques comme nous le voulions. En contre-partie, nous avons analyser au maximum les données échangées sur les deux systèmes etproposer des solutions pour garantir une meilleure protection de la vie privée.

Nous espérons que ce rapport participera aussi à une certaine sensibilisation des uti-lisateurs à comprendre l’impact que peut avoir une mauvaise gestion de son magasin decertificat et de ses navigateurs. De même, il faut rester conscient que des applicationsanodines peuvent récupérer sur leur serveur des informations personnelles.

Enfin, ce rapport pourrait constituer une aide à ceux qui souhaitent se lancer dansl’étude de l’échange de données encodées en Protocol Buffer, commencer à manipuler lesystème Android/iOS et avoir une vue d’ensemble sur la géolocalisation.

49

AnnexesA Certificat AC racine du proxy

Figure 22 – Détails du certificat de l’AC racine du proxy

50

B Protocol Buffer

B.1 Tableau des wire type

Type Signification Utilisé pour les types0 Varint int32, int64, uint32, uint64, sint32, sint64, bool, enum1 64-bit fixed64, sfixed64, double2 Length-delimited string, bytes, embedded messages, packed repeated fields3 Start group groups (deprecated)4 End group groups (deprecated)5 32-bit fixed32, sfixed32, float

Table 2 – Tableau des wire type [29]

C Décodage des données interceptées lors de la localisationd’un iPhone

C.1 Fichier .proto

message WifiDetected {required string bssid = 1;message Location {

required int64 latitude = 1;required int64 longitude = 2;optional int64 confiance = 3;

}optional Location location= 2;

}

message BlockBSSIDVersApple {repeated WifiDetected wifi = 2;optional string APIName = 5;

}

message BlockBSSIDDepuisApple {repeated WifiDetected wifi = 2;

}

C.2 Script python

import BSSIDApple_pb2

def ListWifiVersApple(wifi_list) :for wifi in wifi_list .wifi :

print "Wifi BSSID : " , wifi .bssidprint "APIName : " , wifi_list .APIName

def generateKML(wifi_list ,chemin) :fichier = open(chemin, "w")fichier .write(’<?xml version="1.0" encoding="UTF-8"?>\n’)fichier .write(’<kml xmlns="http://www.opengis.net/kml/2.2">\n’)fichier .write(’<Document>\n’)for wifi in wifi_list .wifi :

i f wifi .HasField(’location’) :fichier .write(’\t<Placemark>\n’)fichier .write(’\t\t<name>’)fichier .write(wifi .bssid)fichier .write(’</name>\n’)fichier .write(’\t\t<Point>\n’)

51

fichier .write(’\t\t<coordinates>’ + str(wifi . location.longitude ∗ pow(10,−8)) + ’,’ + str(wifi . location.latitude ∗ pow(10,−8)) + ’,0</coordinates>\n’)

fichier .write(’\t\t</Point>\n’)fichier .write(’\t</Placemark>\n’)

fichier .write(’</Document>\n’)fichier .write(’</kml>’)

def ListWifiDepuisApple(wifi_list) :for wifi in wifi_list .wifi :

print "Wifi BSSID : " , wifi .bssidi f wifi .HasField(’location’) :

print "Latitude : " ,wifi . location. latitude ∗ pow(10,−8)print "Longitude : " ,wifi . location.longitude ∗ pow(10,−8)print "Confiance : " , wifi . location.confiance

print " ------ "

liste_wifi_vers_apple = BSSIDApple_pb2.BlockBSSIDVersApple()fichier = open("./data_from_packets_1.dat" ,"r")contenu_fichier = fichier .read() ;print(contenu_fichier[:337]) # en−tetes HTMLprint("\nLangue : " + contenu_fichier[345:350])print("OS Version : "+ contenu_fichier[354:364])liste_wifi_vers_apple.ParseFromString(contenu_fichier[369:])ListWifiVersApple(liste_wifi_vers_apple)fichier . close() ;print("\n---------\n")liste_wifi_depuis_apple = BSSIDApple_pb2.BlockBSSIDDepuisApple()fichier = open("./data_from_packets_2.dat" ,"r")contenu_fichier = fichier .read() ;print(contenu_fichier[:73]) # en−tetes HTMLliste_wifi_depuis_apple.ParseFromString(contenu_fichier[89:])ListWifiDepuisApple(liste_wifi_depuis_apple)generateKML(liste_wifi_depuis_apple,"./bssid.kml")

D Décodage des données d’utilisations envoyée par un iPhoneà Apple

D.1 Fichier .proto envoi de BSSID

message WifiMeasurement {required string bssid = 1;optional int64 channel = 2;optional int64 signal_strength = 3;message Location {

optional double latitude = 1;optional double longitude = 2;optional float valeur_inconnue3 = 3;optional float valeur_inconnue5 = 5;optional float valeur_inconnue6 = 6;optional double timestamp = 9;

}required Location location = 4;

}

message BlockBSSIDNocturne {repeated WifiMeasurement wifi = 3;optional fixed32 valeur_inconnue4 = 4;optional fixed32 valeur_inconnue5 = 5;

}

D.2 Fichier .proto envoi d’antennes GSM

message GSMMeasurement {optional int64 MCC= 1;optional int64 MNC= 2;optional int64 LAC= 3;optional int64 cellID = 4;optional int64 attenuation = 5;

52

message Location {optional double latitude = 1;optional double longitude = 2;optional fixed32 valeur_inconnue3 = 3;optional fixed32 valeur_inconnue4 = 4;optional fixed32 valeur_inconnue5 = 5;optional fixed32 valeur_inconnue6 = 6;optional double timestamp = 9;

}required Location location = 8;optional string APIName = 9;optional int64 varint11 = 11;optional string operateur = 12;optional int64 varint15 = 15;optional int64 varint16 = 16;

}

message BlockGSMNocturne {repeated GSMMeasurement gsm = 2;

}

D.3 Script python

import BSSIDNocturne_pb2import GSMNocturne_pb2import osimport datetime

def ListWifiNocturne(wifi_list) :for wifi in wifi_list .wifi :

print "Wifi BSSID : " , wifi .bssidprint "channel : " , wifi .channelprint "signal_strength : " , wifi .signal_strengthi f wifi .HasField(’location’) :

print "latitude : " , wifi . location. latitudeprint "longitude : " , wifi . location.longitudeprint "timestamp : " , wifi . location.timestamp , " --> " , datetime.datetime.fromtimestamp(int(wifi .

location.timestamp)) .strftime(’%d/%m %H:%M:%S’)print " ------ "

def ListGSMNocturne(gsm_list) :for gsm in gsm_list.gsm:

print "MCC : " , gsm.MCCprint "MNC : " , gsm.MNCprint "LAC : " , gsm.LACprint "CellID : " , gsm.cellIDprint "Attenuation : " , gsm.attenuationi f gsm.HasField(’location’) :

print "Latitude : " , gsm.location. latitudeprint "Longitude : " , gsm.location.longitudeprint "Timestamp : " , gsm.location.timestamp , " --> " , datetime.datetime.fromtimestamp(int(gsm.

location.timestamp)) .strftime(’%d/%m %H:%M:%S’)print "APIName : " , gsm.APINameprint "Operateur : " , gsm.operateurprint " ------ "

liste_gsm = GSMNocturne_pb2.BlockGSMNocturne()fichier = open("./data_from_packets_gsm.dat" ,"r")contenu_fichier = fichier .read() ;print(contenu_fichier[:313]) # en−tetes HTMLprint("\nLangue : " + contenu_fichier[317:323])print("Version hardware : "+ contenu_fichier[347:353])print("Version OS: "+ contenu_fichier[354:371])liste_gsm.ParseFromString(contenu_fichier[521:])ListGSMNocturne(liste_gsm)

liste_wifi = BSSIDNocturne_pb2.BlockBSSIDNocturne()fichier = open("./data_from_packets_bssid.dat" ,"r")contenu_fichier = fichier .read() ;print(contenu_fichier[:311]) # en−tetes HTML

53

print("\nLangue : " + contenu_fichier[318:324])print("Version hardware : "+ contenu_fichier[348:354])print("Version OS: "+ contenu_fichier[356:370])liste_wifi .ParseFromString(contenu_fichier[326:])ListWifiNocturne(liste_wifi)

E Serveur copie d’Apple

E.1 Script python wloc

#!/usr/bin/pythonimport BSSIDApple_pb2import datetimefrom struct import packimport binasciiimport sysimport cgi , cgitbimport urllib2import sqlite3

def EnregistreBSSIDDepuisApple(wifi_list ,conn) :i = 0c = conn.cursor()c.execute( ’ ’ ’CREATETABLE IF NOTEXISTS bssid (bssid text PRIMARYKEY, latitude float , longitude float ,

valeur_inconnue3 integer , valeur_inconnue5 integer , valeur_inconnue6 integer , valeur_inconnue11integer , valeur_inconnue12 integer , valeur_inconnue21 integer) ’ ’ ’)

conn.commit()for wifi in wifi_list .wifi :

i f wifi .HasField(’location’) :i f wifi . location. latitude ∗ pow(10,−8) != − 180 and wifi . location.longitude ∗ pow(10,−8) != − 180:

c.execute(’REPLACE INTO bssid VALUES (?,?,?,?,?,?,?,?,?)’ , (wifi .bssid, wifi . location. latitude ∗ pow(10,−8), wifi . location.longitude ∗ pow(10,−8),wifi . location.valeur_inconnue3,wifi . location.valeur_inconnue5,wifi . location.valeur_inconnue6,wifi . location.valeur_inconnue11,wifi . location.valeur_inconnue12,wifi . location.valeur_inconnue21))

i = i + 1conn.commit()

def demandeCoordonnees(bssid) : #Interroge la base de donnees d’Apple pour y prendre les coordonees des bssidthe_url = ’https://gs-loc.apple.com/clls/wloc’user_agent = ’locationd (unknown version) CFNetwork/548.1.4 Darwin/11.0.0’liste_wifi = BSSIDApple_pb2.BlockBSSIDApple()wifi = liste_wifi .wifi .add()wifi .bssid = bssidliste_wifi .valeur_inconnue1 = 0liste_wifi .valeur_inconnue2 = 0liste_wifi .APIName = "com.apple.Maps"chaine_liste_wifi = liste_wifi .SerializeToString()longueur_chaine_liste_wifi = len(chaine_liste_wifi)data = "\x00\x01\x00\x05"+"en_US"+"\x00\x00\x00\x09"+"5.1.9B176"+"\x00\x00\x00\x01\x00\x00\x00" + chr(

longueur_chaine_liste_wifi) + chaine_liste_wifi;req = urllib2 .Request(the_url, data)req.add_header("User-Agent" , user_agent)req.add_header("Content-type" , "application/x-www-form-urlencoded")req.add_header("Accept" , "*/*")req.add_header("Accept-Language" , "en-us")req.add_header("Accept-Encoding" , "gzip, deflate")req.add_header("Accept-Charset" , "utf-8")handle = urllib2 .urlopen(req)the_page = handle.read()

liste_wifi = BSSIDApple_pb2.BlockBSSIDApple()liste_wifi .ParseFromString(the_page[10:])return (liste_wifi)

def chercheCoordonnesBDD(bssid,conn) :c = conn.cursor()coordonnees = [ ]for row in c.execute("SELECT * FROM bssid WHERE bssid LIKE \’" + bssid+"\’") :

coordonnees = row

54

i f len(coordonnees) == 0 : #on a pas trouve le bssid en base de donneesliste_bssid = demandeCoordonnees(bssid)EnregistreBSSIDDepuisApple(liste_bssid ,conn)

else :liste_bssid = BSSIDApple_pb2.BlockBSSIDApple()wifi = liste_bssid.wifi .add()wifi .bssid = bssidwifi . location. latitude = int(coordonnees[1]∗pow(10,8))wifi . location.longitude = int(coordonnees[2]∗pow(10,8))wifi . location.valeur_inconnue3 = coordonnees[3]wifi . location.valeur_inconnue5 = coordonnees[4]wifi . location.valeur_inconnue6 = coordonnees[5]wifi . location.valeur_inconnue11 = coordonnees[6]wifi . location.valeur_inconnue12 = coordonnees[7]wifi . location.valeur_inconnue21 = coordonnees[8]

#On prends les 50+50+50+50 bssid plus proches dans une direction donneefor row in c.execute(’SELECT * FROM bssid WHERE latitude < ’ + str(coordonnees[1]) + ’ ORDER BY latitude

DESC LIMIT 0,50’) :wifi = liste_bssid.wifi .add()wifi .bssid = row[0]wifi . location. latitude = int(row[1]∗pow(10,8))wifi . location.longitude = int(row[2]∗pow(10,8))wifi . location.valeur_inconnue3 = row[3]wifi . location.valeur_inconnue5 = row[4]wifi . location.valeur_inconnue6 = row[5]wifi . location.valeur_inconnue11 = row[6]wifi . location.valeur_inconnue12 = row[7]wifi . location.valeur_inconnue21 = row[8]

for row in c.execute(’SELECT * FROM bssid WHERE latitude > ’ + str(coordonnees[1]) + ’ ORDER BY latitudeASC LIMIT 0,50’) :

wifi = liste_bssid.wifi .add()wifi .bssid = row[0]wifi . location. latitude = int(row[1]∗pow(10,8))wifi . location.longitude = int(row[2]∗pow(10,8))wifi . location.valeur_inconnue3 = row[3]wifi . location.valeur_inconnue5 = row[4]wifi . location.valeur_inconnue6 = row[5]wifi . location.valeur_inconnue11 = row[6]wifi . location.valeur_inconnue12 = row[7]wifi . location.valeur_inconnue21 = row[8]

for row in c.execute(’SELECT * FROM bssid WHERE longitude > ’ + str(coordonnees[2]) + ’ ORDER BY longitudeASC LIMIT 0,50’) :

wifi = liste_bssid.wifi .add()wifi .bssid = row[0]wifi . location. latitude = int(row[1]∗pow(10,8))wifi . location.longitude = int(row[2]∗pow(10,8))wifi . location.valeur_inconnue3 = row[3]wifi . location.valeur_inconnue5 = row[4]wifi . location.valeur_inconnue6 = row[5]wifi . location.valeur_inconnue11 = row[6]wifi . location.valeur_inconnue12 = row[7]wifi . location.valeur_inconnue21 = row[8]

for row in c.execute(’SELECT * FROM bssid WHERE longitude < ’ + str(coordonnees[2]) + ’ ORDER BY longitudeDESC LIMIT 0,50’) :

wifi = liste_bssid.wifi .add()wifi .bssid = row[0]wifi . location. latitude = int(row[1]∗pow(10,8))wifi . location.longitude = int(row[2]∗pow(10,8))wifi . location.valeur_inconnue3 = row[3]wifi . location.valeur_inconnue5 = row[4]wifi . location.valeur_inconnue6 = row[5]wifi . location.valeur_inconnue11 = row[6]wifi . location.valeur_inconnue12 = row[7]wifi . location.valeur_inconnue21 = row[8]

return liste_bssid

print

# Recuperation du BSSID de la variable POST envoyee par smartphone

55

raw_data = sys.stdin.read()liste_wifi_vers_apple = BSSIDApple_pb2.BlockBSSIDApple()liste_wifi_vers_apple.ParseFromString(raw_data[19:])for wifi in liste_wifi_vers_apple.wifi :

bssid = wifi .bssid

#Construction du contenu de la reponsecontent = "\x00\x01\x00\x00\x00\x01\x00\x00"longueurPB = 0;PB= ""conn = sqlite3 .connect(’bssid.db’)liste_wifi = chercheCoordonnesBDD(bssid,conn)PB=liste_wifi .SerializeToString()longueurPB = len(PB)content = content + binascii .unhexlify(hex(longueurPB)[2:]) +PBsys.stdout.write(content) # On envoit le resultat au telephone

E.2 Script de test du serveur

import urllibimport urllib2import BSSIDApple_pb2import sqlite3

def ListWifiDepuisApple(wifi_list) :for wifi in wifi_list .wifi :

print "Wifi BSSID : " , wifi .bssidi f wifi .HasField(’location’) :

print "Latitude : " ,wifi . location. latitude ∗ pow(10,−8)print "Longitude : " ,wifi . location.longitude ∗ pow(10,−8)

print " ------ "i f wifi_list .HasField(’valeur_inconnue1’) :

print "Inconnu1 : " , "%X" %wifi_list .valeur_inconnue1i f wifi_list .HasField(’valeur_inconnue2’) :

print "Inconnu2 : " , "%X" %wifi_list .valeur_inconnue2i f wifi_list .HasField(’APIName’) :

print "APIName : " , wifi_list .APIName

def demandeCoordonneesServeurApple(bssid) :the_url = ’https://gs-loc.apple.com/clls/wloc’user_agent = ’locationd (unknown version) CFNetwork/548.1.4 Darwin/11.0.0’liste_wifi = BSSIDApple_pb2.BlockBSSIDApple()wifi = liste_wifi .wifi .add()wifi .bssid = bssidliste_wifi .valeur_inconnue1 = 0liste_wifi .valeur_inconnue2 = 0liste_wifi .APIName = "com.apple.Maps"chaine_liste_wifi = liste_wifi .SerializeToString()longueur_chaine_liste_wifi = len(chaine_liste_wifi)data = "\x00\x01\x00\x05"+"en_US"+"\x00\x00\x00\x09"+"5.1.9B176"+"\x00\x00\x00\x01\x00\x00\x00" + chr(

longueur_chaine_liste_wifi) + chaine_liste_wifi;

req = urllib2 .Request(the_url, data)req.add_header("User-Agent" , user_agent)req.add_header("Content-type" , "application/x-www-form-urlencoded")req.add_header("Accept" , "*/*")req.add_header("Accept-Language" , "en-us")req.add_header("Accept-Encoding" , "gzip, deflate")req.add_header("Accept-Charset" , "utf-8")handle = urllib2 .urlopen(req)the_page = handle.read()

fichier = open("./resultat-apple.dat" ,"w")fichier .write(the_page)fichier . close()

liste_wifi = BSSIDApple_pb2.BlockBSSIDApple()liste_wifi .ParseFromString(the_page[10:])ListWifiDepuisApple(liste_wifi)

56

def demandeCoordonneesServeurCopie(bssid) :the_url = ’https://gs-loc.apple.dev/clls/wloc’user_agent = ’locationd (unknown version) CFNetwork/548.1.4 Darwin/11.0.0’liste_wifi = BSSIDApple_pb2.BlockBSSIDApple()wifi = liste_wifi .wifi .add()wifi .bssid = bssidliste_wifi .valeur_inconnue1 = 0liste_wifi .valeur_inconnue2 = 0liste_wifi .APIName = "com.apple.Maps"chaine_liste_wifi = liste_wifi .SerializeToString()longueur_chaine_liste_wifi = len(chaine_liste_wifi)data = "\x00\x01\x00\x05"+"en_US"+"\x00\x00\x00\x09"+"5.1.9B176"+"\x00\x00\x00\x01\x00\x00\x00" + chr(

longueur_chaine_liste_wifi) + chaine_liste_wifi;

req = urllib2 .Request(the_url, data)req.add_header("User-Agent" , user_agent)req.add_header("Content-type" , "application/x-www-form-urlencoded")req.add_header("Accept" , "*/*")req.add_header("Accept-Language" , "en-us")req.add_header("Accept-Encoding" , "gzip, deflate")req.add_header("Accept-Charset" , "utf-8")handle = urllib2 .urlopen(req)the_page = handle.read()fichier = open("./resultat-serveur-copie.dat" ,"w")fichier .write(the_page)fichier . close()liste_wifi = BSSIDApple_pb2.BlockBSSIDApple()liste_wifi .ParseFromString(the_page[10:])ListWifiDepuisApple(liste_wifi)

demandeCoordonneesServeurApple("0:13:10:1F:9A:72")demandeCoordonneesServeurCopie("0:13:10:1F:9A:72")

E.2.1 Fichier .proto

message WifiDetected {required string bssid = 1;message Location {

optional int64 latitude = 1;optional int64 longitude = 2;optional int64 valeur_inconnue3 = 3;optional int64 valeur_inconnue4 = 4;optional int64 valeur_inconnue5 = 5;optional int64 valeur_inconnue6 = 6;optional int64 valeur_inconnue7 = 7;optional int64 valeur_inconnue8 = 8;optional int64 valeur_inconnue9 = 9;optional int64 valeur_inconnue10 = 10;optional int64 valeur_inconnue11 = 11;optional int64 valeur_inconnue12 = 12;optional int64 valeur_inconnue21 = 21;

}

optional Location location= 2;}

message BlockBSSIDApple {optional int64 valeur_inconnue0 = 1;repeated WifiDetected wifi = 2;optional int32 valeur_inconnue1 = 3;optional int32 valeur_inconnue2 = 4;optional string APIName = 5;

}

57

Références[1] Alain Pannetrat. Analyser la géolocalisation sur iphone grâce à un proxy de déchiffre-

ment ssl. MISC, jan 2012. Article sur les interceptions de données de géolocalisationqui nous a donné l’idée de notre projet.

[2] Frédéric GRAPPE. Le système GPS. http://www.fredericgrappe.com/enseignement/entrainement/GPS.pdf.

[3] Qu’est-ce que la trilatération ? http://eu.mio.com/fr_be/global-positioning-system_4991.htm.

[4] Skyhook. http://www.skyhookwireless.com/. Base de données propriétaire recensantles points d’accès wifi ainsi que leurs coordonnées.

[5] OpenCellID. http://www.opencellid.org/. Base de données libre des antennes GSMavec leurs coordonnées.

[6] Android developers : Obtaining User Location. http://developer.android.com/guide/topics/location/obtaining-user-location.html. Documentation Android sur le calcul dela géolocalisation.

[7] Securing Sockets with OpenSSL. http://www.informit.com/articles/article.aspx?p=22078.

[8] Maryline Laurent. Authentification, VPN, Chiffrement. http://www.informit.com/articles/article.aspx?p=22078, Jun 2012.

[9] Google. Utilisation de certificats sécurisés. http://support.google.com/mobile/bin/answer.py?hl=fr&answer=168934.

[10] Routeur Tomato. http://www.polarcloud.com/tomato.[11] WinPcapRemote. http://wiki.wireshark.org/CaptureSetup/WinPcapRemote.[12] Sslmeat. http://code.google.com/p/sslmeat/. Proxy HTTPS open-source.[13] Protocol Buffers. https://developers.google.com/protocol-buffers/.[14] Sysdream. Reverse-engineering of protobuf-based applications. http://www.sysdream.

com/reverse-engineering-protobuf-apps.[15] Google. KML Documentation. https://developers.google.com/kml/documentation/.[16] Téléchargement du SDK Android. http://developer.android.com/sdk/index.html.[17] Android x86. http://www.android-x86.org/.[18] Intel. Getting started on Android for x86. http://software.intel.com/en-us/blogs/

2011/10/11/.[19] Android Fragmentation Visualized. http://opensignalmaps.com/reports/

fragmentation.php.[20] CyanogenMod. http://www.cyanogenmod.com/.[21] Android Debug Bridge. http://developer.android.com/guide/developing/tools/adb.

html.[22] Partitions principales Android. http://wiki.cyanogenmod.com/wiki/Fastboot.[23] Dévérouiller smartphone HTC. http://htcdev.com/bootloader/.[24] Andrew Hoog. Android Forensics : Investigation, Analysis and Mobile Security for

Google Android. SYNGRESS.[25] Android Tracking – from a forensic point of view. http://articles.forensicfocus.com/

2012/02/27/android-tracking-from-a-forensic-point-of-view/.

58

[26] Android Locdump. https://github.com/packetlss/android-locdump.[27] BlobSqlite. http://mvmn.wordpress.com/2011/07/13/sqlite-blob-exporter-with-gui/.

Logiciel permettant d’extraire facilement les données binaires (BLOB) d’une basede données sqlite sous forme de fichiers séparés.

[28] TaintDroid. http://appanalysis.org/index.html.[29] Tableau des wire type des protocol buffers. https://developers.google.com/

protocol-buffers/docs/encoding#structure.

Table des figures1 Trilatération [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42 Calcul de la localisation sous Android [6] . . . . . . . . . . . . . . . . . . . . 63 Organisation du protocole SSL [8] . . . . . . . . . . . . . . . . . . . . . . . 104 Magasin de certification Android . . . . . . . . . . . . . . . . . . . . . . . . 115 Architecture de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136 Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147 Ajout d’un certificat sous iPhone et Android . . . . . . . . . . . . . . . . . 158 Échanges lors de l’établissement d’une connexion SSL via un proxy SSL

(configuré sur le client) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169 Tentative d’établissement d’une connexion via un proxy HTTPS transparent 1710 Interprétation d’une unité de donnée où la clé fait 1 octet . . . . . . . . . . 2011 Affichage des BSSID et de la position exacte sur une carte Google Maps . . 2412 Envoi nocturne affiché sur une carte Google Earth . . . . . . . . . . . . . . 2613 Envoi nocturne affiché sur une carte Google Earth . . . . . . . . . . . . . . 2814 Android Virtual Device Manager . . . . . . . . . . . . . . . . . . . . . . . . 2915 Connexions d’un Android virtuel . . . . . . . . . . . . . . . . . . . . . . . . 3016 Android x86 sur VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . . 3017 Fastboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3318 Architecture Android – Demande de droits root . . . . . . . . . . . . . . . . 3419 Carte Google Maps d’une partie des BSSID enregistrés . . . . . . . . . . . . 3820 Désactiver l’envoi des données diagnostic – Services de localisation . . . . . 4521 Services de localisation et Autorisation des applications sur Android . . . . 4622 Détails du certificat de l’AC racine du proxy . . . . . . . . . . . . . . . . . . 50

Liste des tableaux1 Comparaison des différentes techniques de géolocalisation . . . . . . . . . . 62 Tableau des wire type [29] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

59