Rapport du projet de n dtudes Interception des changes dans une connexion SSL/TLS Application lanalyse des donnes de golocalisation

n envoyes par un smartphone

Franois-Xavier Aguessy

Cme Demoustier

Encadrant : Olivier Paul

SSR 2011-2012

Sommaire
Introduction I Golocalisation et application aux smartphones
mthodes de golocalisation Golocalisation par satellite . . Golocalisation par Wi-Fi . . . Golocalisation par GSM . . . Golocalisation hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

3 4
4 4 4 5 5 6 6 7 7 8

1 Les 1.1 1.2 1.3 1.4 2 Les 2.1 2.2 2.3 2.4

utilisations de la golocalisation par Navigation . . . . . . . . . . . . . . . . . Informations proximit . . . . . . . . . Gardiennage virtuel (ou geofencing) . . Publicit cible . . . . . . . . . . . . . .

un . . . . . . . .

smartphone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .

II

Rappels sur les protocoles de scurit

9
9 9

3 Les protocoles HTTP et HTTPS 4 Les protocoles SSL et TLS

5 Les certicats, leur intgration systme et le processus dauthentication 10

III

tude du proxy et de larchitecture

13
13

6 Architecture de base

7 Les proxys HTTP et HTTPS 13 7.1 Proxy HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14 7.2 Proxy HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

IV

Mise en pratique et rsultats

15

8 La mise en place dun proxy transparent 15 8.1 Proxy transparent HTTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.2 Proxy transparent HTTPS . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 8.3 Proxy HTTPS autocongur . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9 Protocol Buers 19 9.1 Les varints . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.2 Interprter les protocol buers . . . . . . . . . . . . . . . . . . . . . . . . . 19 9.3 Exemple de dcodage de donnes encodes en Protocol Buer . . . . . . . . 20 10 changes des donnes de localisation sur iOS 22 10.1 Donnes envoyes lors de la golocalisation du tlphone . . . . . . . . . . . 22 10.2 Donnes envoyes pour constituer la base de donnes de BSSID dApple . . 24

11 Localisation et Scurit sur Android 11.1 Contexte de lanalyse sur OS Android . . . . . . . 11.1.1 mulateur Android . . . . . . . . . . . . . . 11.1.2 Machine Virtuelle Android . . . . . . . . . 11.1.3 Tlphone sous OS Android . . . . . . . . . 11.2 Prambule ltude de la localisation sur Android 11.2.1 Choix de la version du systme . . . . . . . 11.2.2 Installation du SDK et outils du SDK . . . 11.2.3 "Unlock" et "Rootage" de lHTC Desire HD 11.2.4 Outils de scurit Android et transition la

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . golocalisation

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

. . . . . . . . .

29 29 29 30 31 31 31 32 32 34 36 36 39 39 39 42

12 Etude des donnes de golocalisation sur Android et des changes associs 12.1 Premiere analyse systme orient sur la localisation . . . . . . . . . . . . . . 12.2 Localisation ponctuelle avec Google Maps . . . . . . . . . . . . . . . . . . . 12.2.1 Description de la manipulation . . . . . . . . . . . . . . . . . . . . . 12.2.2 Observation des changes sur le proxy . . . . . . . . . . . . . . . . . 12.3 Localisation priodique et silencieuse avec www.Google.com/loc/m/api . . .

Vie prive et proposition de solutions

45

13 Rglages appropris du smartphone 45 13.1 Rglages sur un iPhone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45 13.2 Rglages sur Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46 14 Filtrage 46

15 Solutions logicielles 47 15.1 Serveur copie du serveur distant . . . . . . . . . . . . . . . . . . . . . . . . 47 15.2 Autres solutions envisages . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

Conclusion Annexes
A Certicat AC racine du proxy B Protocol Buer B.1 Tableau des wire type

49 50
50

51 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

C Dcodage des donnes interceptes lors de la localisation dun iPhone 51 C.1 Fichier .proto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 C.2 Script python . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51 D Dcodage des donnes dutilisations envoye D.1 Fichier .proto envoi de BSSID . . . . . . . . . D.2 Fichier .proto envoi dantennes GSM . . . . . D.3 Script python . . . . . . . . . . . . . . . . . . par un iPhone . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Apple 52 . . . . . . 52 . . . . . . 52 . . . . . . 53

E Serveur copie dApple 54 E.1 Script python wloc . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54 E.2 Script de test du serveur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 E.2.1 Fichier .proto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57

Introduction

Ce rapport constitue un compte-rendu complet de notre Projet de Fin dtudes concernant linterception de donnes dans une connexion SSL grce un proxy. Lobjectif premier de cette interception est dtudier les changes de donnes de golocalisation sur les OS mobiles iOS et Android. Nous prsentons donc ici nos rsultats "pratiques" prcds de rappels thoriques sur la golocalisation, les changes scuriss et sur les certicats. Une section sera aussi consacre ltude du Protocol Buer qui occupe une part trs importante dans le dcodage des donnes de golocalisation.

Lorigine de ce projet a t un article publi dans le magasine MISC [1] propos des donnes de golocalisation sur iPhone et qui nous explique lintrt dun proxy HTTPS dans les changes SSL. Celui-ci permet en eet, grce lquivalent dun Man-in-theMiddle dobtenir des donnes condentielles. Les applications pourraient tre trs diverses et tre menes sur de nombreux types de donnes telles que des donnes bancaires, mais nous nous intresserons dans ce rapport uniquement aux donnes de golocalisation.

Au travers de ce rapport, nous avons aussi tenu dcrire les rexions, les dmarches, les tests, les oprations intermdiaires que nous avons d eectuer pour rpondre notre problmatique, tout ceci an de reter lvolution du projet. Toutes nos sources et bases de recherche seront rfrences puis dtailles dans une bibliographie en n de document. En annexe, nous prsentons des documents et des travaux ayant un rapport direct avec ltude, mais lire de prfrence en parallle pour ne pas perdre la logique et lenchainement du rapport.

Il est ds prsent intressant de faire remarquer que ltude sur iOS et ltude sur Android ont t abordes sous le mme angle en terme dobjectif pour tablir une comparaison pertinente, mais la manire de sapproprier les deux systmes et de mener bien les analyses a t dirente. Ainsi, ltude sur Android propose un prambule sur le systme permettant dobtenir un maximum de rsultats alors que les changes sur iOS, plus simples, ont permis denvisager une solution de protection de la vie prive plus aboutie.

Premire partie

Golocalisation et application aux smartphones

1 Les mthodes de golocalisation
Les smartphones disposent de plus en plus dapplications lies la golocalisation. En eet, ceux-ci peuvent maintenant devenir de vritables navigateurs GPS, donner des informations sur des lieux, personnes ou activits proximit, mais aussi sadaptent de plus en plus la position laquelle ils se trouvent : alertes lorsque lon rentre dans un primtre, changement de prol lorsque lon arrive au travail,... La golocalisation est donc devenue un lment crucial pour les smartphones. Il existe de nombreuses techniques pour se golocaliser. Chaque technique a ses particularits et ses avantages, et les constructeurs utilisent dsormais plusieurs techniques complmentaires pour golocaliser plus prcisment et plus rapidement les smartphones. Nous allons dcrire dans cette partie les direntes techniques qui peuvent tre utilises pour se golocaliser.

1.1

Golocalisation par satellite

La golocalisation par satellite est la technologie de golocalisation la plus rpandue actuellement. Elle permet un quipement de calculer sa position en utilisant les signaux mis par dirents satellites. Le GPS est la constellation de satellites la plus utilise dans le monde pour la golocalisation. Elle est constitue de satellites amricains. Il en existe dautres similaires, par exemple GLONASS (Russie) et Galileo (Union Europenne). Pour se golocaliser, une puce doit utiliser au moins 4 satellites [2], mais on considre quen moyenne, chaque instant, une puce GPS peut recevoir en moyenne les signaux de 6 satellites dirents. Pour calculer sa position, une puce GPS doit mesurer sa distance avec 3 satellites. Pour cela elle utilise le temps parcouru depuis entre le satellite et la puce. Cependant, lheure du terminal ntant pas parfaitement prcise, il est ncessaire de dterminer le dcalage temporel du terminal grce un quatrime satellite. Avec les distances mesures, la puce GPS eectue une trilatration. La trilatration est un principe similaire la triangulation, car elle permet de calculer la position dun point partir de plusieurs mesures, mais, contrairement cette dernire, elle utilise des points dintersection de sphres. Bien sr, le systme GPS est capable daner les mesures si plus de satellites sont porte. Ce systme de golocalisation est assez prcis (une dizaine de mtres prs), mais les puces prsentes sur les smartphones sont trs petites, et ne reoivent donc quun signal provenant des satellites trs attnu ce qui fait que la golocalisation par satellite nest possible quen ext- Figure 1 Trilatration [3] rieur et est assez lente.

1.2

Golocalisation par Wi-Fi

La golocalisation utilisant les points daccs Wi-Fi est une technologie beaucoup plus rcente, particulirement adapte la ville. Pour se golocaliser, un smartphone commence

par dresser la liste de tous les BSSID prsents autour de lui. Les BSSID sont les adresses MAC des cartes rseau Wi-Fi des points daccs. Ceux-ci sont envoys rgulirement par les points daccs pour permettre aux terminaux Wi-Fi de sy connecter. Une fois une liste des BSSID proximit tablie, il y a deux possibilits : soit le tlphone envoie cette liste un serveur qui connat la plupart des coordonnes gographiques des points daccs. Ce serveur calcule alors la position du smartphone et la lui envoie. soit le tlphone envoie une partie de la liste des BSSID au serveur, qui lui rpond une liste de BSSID sur un plus grand primtre avec leurs coordonnes et cest le smartphone qui calcule sa position. Pour permettre cette golocalisation laide des points daccs Wi-Fi, il faut auparavant tablir une liste la plus complte possible des bornes Wi-Fi avec leurs cordonnes gographiques (latitude, longitude). Celle-ci peut tre tablie de nombreuses faons, certaines bases de donnes sont publiques, dautres peuvent tre achetes (par exemple Skyhook [4] qui est utilis notamment par Apple, Sony, Samsung...). Pour les crer ou les enrichir, il est possible dutiliser des donnes envoyes par les tlphones mobiles soit lorsquils essayent de se localiser, soit en envoyant rgulirement les points daccs quils ont rencontrs. Il est aussi possible dutiliser des vhicules se dplaant sur les routes principales et qui enregistrent les donnes Wi-Fi quils dtectent avec leur position.

1.3

Golocalisation par GSM

La golocalisation par GSM a t utilise avant la dmocratisation des puces GPS dans les smartphones, mais continue de ltre. Cette golocalisation utilise les antennes GSM porte du tlphone, mais plusieurs techniques direntes permettent de calculer sa position : Golocalisation par dirence de temps observe (EOTD) : La distance avec lantenne laquelle est connect le tlphone est calcule par le tlphone grce au temps coul entre lmission et la rception dune requte quil met vers lantenne. Golocalisation par lidentiant de cellule : Cette golocalisation utilise lantenne laquelle est connect le tlphone. Elle est identie avec lensemble identiant de cellules (Cell-Id), code de pays (MCC), code oprateur (MNC) et code de groupement de cellules (LAC). La position du tlphone sera estime avec une prcision pouvant aller de la centaine de mtres (en ville) plusieurs kilomtres ( la campagne) suivant la porte de lantenne. Elle a cependant lavantage dtre trs rapide. Golocalisation par triangulation : Cette technique de golocalisation est une volution de la technique prcdente, au lieu de se limiter une seule antenne, le tlphone repre plusieurs (au moins 3) antennes porte et calcule alors sa position avec plus de prcision. Toutes ces techniques ncessitent de maintenir une base de donnes de toutes les antennes GSM avec leurs coordonnes, et de transmettre au tlphone les donnes dont il a besoin pour se golocaliser. Il existe plusieurs bases de donnes dont certaines sont libres (par exemple OpenCellID [5]).

1.4

Golocalisation hybride

La golocalisation hybride utilise plusieurs des mthodes de golocalisation voques prcdemment. Elle peut ainsi combiner les avantages de la golocalisation GSM (trs rapide) Wi-Fi (rapide et trs prcis en ville) et GPS (prcis et possible partout en extrieur). 5

Nous pouvons voir en Figure 2 le droulement sous Android lorsquun utilisateur veut se localiser.

Figure 2 Calcul de la localisation sous Android [6] La premire tape est dutiliser un cache de la dernire position connue, cest videmment le plus simple eectuer, mais ne fonctionne que si le cache est trs rcent et que le terminal nest pas en mouvement. Ensuite, le smartphone calcule une premire estimation de sa position en utilisant les Cell-ID. Il calcule alors sa position en utilisant les points daccs Wi-Fi. Si cette position nest pas assez prcise ou sil ny a pas de rseau Wi-Fi proximit, le calcul de la position GPS est eectu. On peut ainsi voir que les tlphones Android procdent du plus rapide et moins prcis (GSM), vers le plus lent et plus prcis (GPS). Il est bon de voir aussi que la golocalisation par Wi-Fi est un trs bon complment du GPS, car elle permet de se golocaliser trs prcisment en ville o le signal GPS peut ne pas tre assez puissant, mais est totalement inecace en campagne, l o le signal GPS est le plus fort. Nous pouvons voir un tableau de comparaison des direntes techniques de localisation en Table 1. Technologie Vitesse de golocalisation Utilisation de "data" Prcision Fonctionne GSM Trs rapide Oui 100m10km Mieux en ville Wi-Fi Rapide Oui 1050m Ville GPS Lent Non 10100m Mieux hors ville Hybride Progressif Oui ou Non 10m10km Partout

Table 1 Comparaison des direntes techniques de golocalisation

Les utilisations de la golocalisation par un smartphone

Comme nous lvoquions dans lintroduction, les utilisations de la golocalisation sont de plus en plus importantes avec la trs forte augmentation du nombre de smartphones qui possdent tous des capacits se localiser. Nous allons tudier les applications majeures de cette technologie.

2.1

Navigation

La premire utilisation grand public qui a t faite de la golocalisation, depuis lutilisation de puces GPS dans les smartphones, est de transformer le smartphone en vritable

systmes de navigation GPS. Celui-ci a lavantage de toujours tre en possession de lutilisateur qui peut donc lutiliser ds quil en a besoin. De plus, il possde des avantages que la plupart des systmes de navigations GPS existants navaient pas (mis part les modles haut de gamme) : Un accs aux donnes en permanence qui permet davoir des informations en temps rel sur ltat du trac, les travaux en cours... Une puissance de calcul leve permettant de calculer un changement ditinraire beaucoup plus vite Une interface plus agrable utiliser, avec un grand cran tactile Les applications de navigation GPS mme payantes reviennent beaucoup moins cher que dacheter un GPS autonome si, bien videmment, on possde dj le smartphone. Les applications et les cartes quelles contiennent sont mises jour rgulirement ce qui permet davoir une cartographie jour ce qui nest pas le cas de tous les systmes de navigations GPS. Cependant, les applications de navigation sur smartphone nont pas que des avantages par rapport aux systmes de navigations GPS. En eet, souvent les appareils ddis la navigation ont des puces et antennes GPS beaucoup plus performantes et permettent donc de garder le signal GPS mme dans les grandes villes, ce qui nest pas forcment le cas des smartphones. Ils possdent aussi lavantage dtre un appareil ddi la navigation, qui donc nest pas victime des problmes qui peuvent survenir sur un smartphone qui sert beaucoup dautres usages : pannes, batterie vide...

2.2

Informations proximit

Une utilisation majeure de la golocalisation qui sest fortement dveloppe avec lexpansion du smartphone est la possibilit davoir des informations sur ce qui est proximit. Les applications sont multiples, elles peuvent concerner des monuments, restaurants, htels, parking, gares, stations de mtro... Lavantage est que la golocalisation na pas besoin dtre parfaite, seulement rapide. En eet, le plus important est de pouvoir dterminer la zone dans laquelle est lutilisateur du smartphone, une centaine de mtres prs, cela sut pour lui donner toutes informations sur les services qui lentourent. Lvolution de cette utilisation de la golocalisation est la ralit augmente. La ralit augmente reprsente les systmes permettant dajouter des informations une reprsentation en 2 ou 3 dimensions de lenvironnement rel de lutilisateur souvent provenant de lappareil photo dun smartphone. Cest par exemple la vue en temps rel dune rue par lappareil photo du smartphone sur laquelle on ajoute les stations de mtro avec leur distance. Pour la ralit augmente, la golocalisation est indispensable, an de donner lutilisateur les informations les plus prcises possible en fonction du lieu o il est.

2.3

Gardiennage virtuel (ou geofencing)

Le gardiennage virtuel est une utilisation rcente de la golocalisation sur les smartphones. Cela consiste eectuer des oprations sur un smartphone lorsquil rentre dans un primtre dni. Cela peut par exemple permettre de donner des alertes lutilisateur ds quil arrive dans un endroit ou mme de changer les paramtres du tlphone quand lutilisateur arrive chez lui ou son travail. Cela peut permettre aussi pour des parents davoir une alerte lorsque leur enfant sort dune zone de conance. Plus gnralement, avec le geofencing, il est possible de dnir des zones dans lesquelles eectuer certaines actions personnalises. Cest une utilisation qui est assez rcente, mais qui se dveloppe rapidement puisque la plupart des smartphones de dernires gnrations sont compatibles. 7

2.4

Publicit cible

Cette dernire utilisation est particulirement importante pour les entreprises, notamment pour Google qui en a fait son business model pour le systme dexploitation mobile Android. Lavantage du smartphone est quil est en permanence sur lutilisateur. En connaissant en permanence la localisation dun smartphone, il est possible de savoir partout o est all lutilisateur et donc ce quil a fait et ce qui lui plat. Cest ainsi que la publicit peut tre cible en fonction des envies de lutilisateur et adapte aux lieux ct desquels il vit.

Deuxime partie

Rappels sur les protocoles de scurit

3 Les protocoles HTTP et HTTPS
Dans ce projet, les protocoles applicatifs utiliss sont HTTP et HTTPS pour des changes classiques client/serveur. Notre client sera le possesseur du smartphone au travers des applications telles que Google Maps quil va utiliser. Les serveurs seront les serveurs de Google et Apple pour leur service de localisation. Nous verrons que des services fonctionnant en arrire-plan sur les deux types de smartphone vont utiliser le protcole HTTPS pour initialiser "silencieusement" des connexions avec ces serveurs et changer des donnes chires qui seront analyses avec le proxy. En eet, le protocole HTTPS, Hypertext Transfer Protocol Secure, a t conu partir du protocole HTTP pour supporter la protection par chirement des requtes et des rponses. Ce protocole permet laide des certicats dauthentier le serveur sur lequel la connexion est souhaite et dengager une communication chire sur le port 443. Ce protocole emploie les mmes requtes que HTTP type HEAD, GET ou la requte POST pour soumettre, comme dans le cadre de ce projet, des donnes encodes avec le Protocole Buer de Google. HTTPS dire de HTTP dans le fait quil va faire appel au protocole SSL, celui-ci va prendre en charge toute la protection de la couche applicative. HTTPS correspond donc au protocole HTTP implment au-dessus de SSL situ dans la couche session du modle OSI. A noter que lauthentication mutuelle est possible avec SSL, mais suppose que le client possde lui aussi un certicat. Remarque : Le proxy implique une nouvelle entit dans les changes, il se forme alors une double connexion client - serveur dcrite dans la partie Etude du proxy et de larchitecture (8.2)

Les protocoles SSL et TLS

SSL, Secure Socket Layer, assure donc une communication scurise entre le client et le serveur. Ce protocole, aujourdhui trs rpandu, doit sa russite et son utilisation massive sa facilit dimplmentation. En eet, dun ct son indpendance vis--vis de la couche applicative vite le redveloppement complet de nouvelles applications. Dun autre ct sa particularit dtre bas dans la couche session sur la couche transport permet une adaptation facile au niveau rseau et au niveau du matriel. Bien que les conditions dutilisation et objectifs ne soient pas exactement les mmes, une connexion SSL est, par exemple, bien plus lgre et facile administrer quun tunnel IPSec. Ainsi, des applications telles que HTTP et FTP ont vu leur version scurise naitre grce SSL : HTTPS et FTPS auxquels on a attribu les ports 443 et 990 au niveau de la couche transport. Pour un navigateur ou une application client, il sura de faire appel aux librairies SSL puis ouvrir un socket pour initialiser une connexion scurise avec le serveur distant devant supporter lui aussi SSL. [7] Ces librairies, disponibles librement avec le projet OpenSSL, vont notamment grer les changes SSL comme le SSL "handshake", les certicats et les algorithmes de chirement tels que RSA pour lchange de cls secrtes et AES pour le chirement des donnes. SSL est construit selon 4 modules ou 4 sous-protocoles et le protocole SSL record charg de protger les donnes en elles-mmes [8](voir Figure 3) :

POP3S

HTTPS

TELNETS

FTPS

SSL handshake protocol

SSL change cipher spec protocol

SSL alert protocol

SSL application data protocol

SSL record protocol

UDP IP

TCP

Figure 3 Organisation du protocole SSL [8] Le protocole SSL handshake : initialise lchange SSL avec lauthentication par certicat, lchange des paramtres de scurits... Le protocole SSL change cipher spec : pour tablir de nouveaux paramtres de scurit dans un change Le protocole SSL alert : transmission dalertes Le protocole SSL application data : la couche applicative transmet directement ses donnes au protocole SSL record pour les transmettre de faon scurise. Utilis quand linitialisation a t eectue avec succs par le SSL handshake. TLS, Transport Layer Security, correspond au protocole SSL repris par lIETF dans sa version 3.1.

Les certicats, leur intgration systme et le processus dauthentication

Les certicats sont les lments de base dans lauthentication des serveurs et parfois des clients. Un certicat a pour objectif dviter lusurpation didentit en faisant intervenir une entit tierce, une Autorit de Certication (AC) qui va signer ce certicat. Une usurpation didentit se matrialiserait par la procuration dune cl publique appartenant une entit malveillante et se faisant passer pour le serveur souhait. Nous ne nous tendrons pas ici sur la mise en place dune PKI (Public Key Infrastructure), nous rappelons simplement que lAutorit de Certication racine possde un certicat autosign. Les certicats peuvent tre gnrs en interne (PKI interne une entreprise) ou bien la gestion peut tre externalise laide de socits spcialises telles que VeriSign. Dans une connexion classique un serveur web en HTTPS, seul ce serveur sera authenti par un certicat qui lui aura t dlivr. Ce certicat aura donc t sign par une AC, elle-mme possdant un certicat sign par son AC mre jusqu remonter lAC racine autosigne (cest la chane de certication). Un certicat standard du format X509 contient de nombreuses informations, dont les plus importantes : un numro de version un numro de srie Lalgorithme utilis pour la signature du certicat 10

 Les champs concernant lAC qui a fourni ce certicat Les dates de validit Le nom du sujet dtenteur du certicat Lalgorithme utilis avec la cl publique La cl publique La signature du certicat par lAC De manire pratique, nous mettons en Annexe A le certicat autosign par le proxy. Il sagit dun chier au format .pem, il existe dautres extensions telles que .cer .der quil faut remplacer en .crt pour Android [9] Lorsque le SSL Handshake est initialis, le serveur va envoyer son certicat au client. Sur son systme dexploitation, ce client possde nativement un magasin de certicats des AC reconnues et considres comme ables pour utiliser leur cl publique. Il rcupre donc la cl publique de lAC correspondant au nom indiqu dans le certicat envoy par le serveur. Avec cette cl, il dchire la signature du certicat pour obtenir le hash eectu par lAC. De son ct, le client va hasher le certicat, et si ces 2 hashs correspondent, lauthentication est vrie. Si lAC concerne nest pas une AC mre, la machine va aussi vrier la chaine de certication.

Figure 4 Magasin de certication Android Pour les connexions HTTPS, un navigateur tel que Google Chrome va utiliser le magasin de certicats de lOS sur lequel il est install alors que Firefox possde son propre magasin de certicats. Cest aussi pourquoi il est essentiel en terme de scurit de vrier la source de ces logiciels (OS ou navigateur). Si un attaquant parvient modier un de ces logiciels en y intgrant nativement des certicats dAC malveillants alors il pourra mettre en place des serveurs usurpant lidentit dautres serveurs avec des certicats gnrs par lAC malveillante sans que le client ne reoive aucune alerte. En eet, en temps normal, si le client se connecte un serveur dont lAC nest pas reconnue par lOS ou le navigateur, le navigateur va alors mettre une alerte et demander conrmation avant de continuer (dautres cas peuvent dclencher une alerte comme la correspondance du nom de domaine souhait et le nom indiqu dans le certicat, ou les 11

dates de validit). Dautres applications comme nous lavons observ avec Google Maps sur Android refusent tout simplement la connexion tant que le certicat nest pas reconnu. Nous allons donc voir comment ajouter des certicats sur des OS tels que iOS ou Android. Lorsquune entreprise utilise une PKI interne pour son intranet, il est aussi trs utile de pouvoir rajouter des certicats aux machines Windows et Linux. Si lutilisateur/client ne fait pas attention ces alertes de scurit ou bien installe volontairement ou sans consciemment le vouloir un certicat dAC sur sa machine alors, il devient une cible facile pour lattaque du Man-in-the-Middle

12

Troisime partie

tude du proxy et de larchitecture

6 Architecture de base
Dans cette partie, nous allons voir larchitecture dont nous disposons pour eectuer les manipulations an de pouvoir intercepter les donnes de golocalisation envoyes par les smartphones. Nous travaillerons sur les systmes dexploitation mobiles iOS et Android car Apple et Google sont actuellement de loin les deux leaders sur le march des smartphones. Nous eectuerons les tests avec un iPhone 3GS fonctionnant sous iOS 5.1.1 et un HTC Desire HD fonctionnant sous Android Ice Cream Sandwich 4.0.

Point daccs sans-fil et routeur Smartphone

Internet

Serveur smartphone

Ordinateur

Figure 5 Architecture de base Comme nous pouvons le voir sur la Figure 5, nous disposons dun point daccs sans-l sur lequel est connect le smartphone en Wi-Fi. Ce point daccs tourne sous le systme dexploitation Tomato [10], un rmware libre bas sur le noyau Linux et est donc aussi un routeur et rewall et pourra donc nous permettre deectuer des oprations simples de ltrage. Le smartphone dialogue avec un serveur sur Internet appartenant soit Apple pour iOS soit Google pour Android avec lequel il change les informations de localisation. Sur le rseau local o se situe le smartphone, nous disposons dun ordinateur permettant de contrler le routeur en SSH ainsi que de faire tourner les services qui seront ncessaires notre tude.

Les proxys HTTP et HTTPS

Les changes de golocalisation entre le smartphone et le serveur sont eectus avec le protocole HTTPS. Nous allons donc tudier dans cette partie les moyens dont nous disposons pour les intercepter.

13

7.1

Proxy HTTP

Avant dtudier linterception du protocole HTTPS, nous allons nous intresser au protocole HTTP sur lequel il se base. Il existe deux moyens faciles pour intercepter du HTTP. Le premier est tout simplement couter ce qui passe sur le rseau. En eet, le protocole HTTP nest pas chir et peut donc tre lu intgralement. Ceci peut tre eectu par exemple sur notre architecture en utilisant le protocole WinPcapRemote sur le routeur qui permet dutiliser celui-ci comme priphrique de capture distant avec le logiciel Wireshark tournant sur un ordinateur Windows [11]. Il est ainsi possible de capturer, dchirer et enregistrer tout le trac HTTP. La deuxime technique dinterception du HTTP est dutiliser un proxy HTTP. Un proxy est un logiciel qui sert de relai entre deux Serveur Web quipements qui dialoguent. Un proxy HTTP doit se placer entre le client et le serveur. Il se comporte alors comme le serveur pour le client et comme le client pour le serveur. Cest en fait exactement le mme principe que lattaque Man-in-the-Middle. Il cre donc une double connexion comme nous pouvons le voir sur la Figure 6. Un serveur proxy peut-tre utile pour faire des oprations de ltrage ou de mise en cache pour protger un serveur web ou un rseau local, mais peut aussi tre utile pour couter trs simplement le trac qui passe, car tout le contenu qui passe dune connexion lautre est connu par le proxy.
Connexion 2

Proxy

7.2

Proxy HTTPS
Connexion 1

Nous allons dsormais nous intresser au protocole HTTPS (HyperText Transfer Protocol Secure). Celui tant scuris par SSL/TLS, il est maintenant impossible dutiliser la simple coute pour intercepter les communications entre le client et le serveur. En revanche, la deuxime mthode dinterception prsente ci-dessus est toujours possible : avec un proxy HTTPS. Cette fois encore le proxy cr une double connexion HTTPS. Dans une connexion derrire un proxy le client HTTPS ne recevra pas le cerClient ticat du serveur Web, mais un certicat provenant du proxy. En eet, le seul qui possde la cl secrte correspondant au certicat envoy par le serveur Web est le serveur web lui mme ; il serait donc impossible Figure 6 au proxy de dchirer les messages du clients avec cette cl. Le proxy Proxy HTTPS est donc oblig de gnrer la vole un certicat contenant les mmes attributs que le certicat du serveur mis part la cl publique et la signature quil gnre lui mme. Le proxy envoie donc au client un certicat sign par lui et contenant une cl publique dont il possde la cl prive. Il pourra donc dchirer les messages que lui enverra le client avec le certicat quil a cr et chirer les messages envoys au serveur avec le certicat quil a reu du serveur. Ainsi, le proxy pourra avoir lintgralit des changes eectus entre le client et le serveur en clair. Ce qui empche normalement dutiliser ce principe pour intercepter des donnes changes entre un client et un serveur HTTPS est la chane de certication qui se trouve alors viole. En eet, le client na normalement pas dans son magasin de certicat le certicat racine utilis par le proxy pour signer le certicat quil a gnr la vole. Il aura donc une alerte sur son navigateur lui disant quil est peut-tre en train dtre attaqu.

14

Quatrime partie

Mise en pratique et rsultats

8 La mise en place dun proxy transparent
La premire tape pour intercepter les donnes de golocalisation entre un smartphone et le serveur avec lequel il communique en HTTPS est de mettre en place un proxy HTTPS. Nous voulions rendre la conguration de ce proxy la plus transparente possible pour pouvoir intercepter les donnes de golocalisation sans que cela puisse tre connu de lutilisateur. Nous avons utilis pour toutes les manipulations le proxy sslmeat [12] qui permet dintercepter, enregistrer et dchirer des ux HTTPS et est open source, multiplateforme et trs lger.

8.1

Proxy transparent HTTP

Un proxy transparent est un proxy qui est mis en place sans aucune intervention de lutilisateur et sans que celui-ci ne puisse sen apercevoir. Le dploiement dun proxy HTTP transparent est assez facile, car le HTTP contient des informations redondantes avec les informations contenues dans les paquets IP : le nom dhte permet de connatre ladresse de destination. Il sut donc de faire une redirection en NAT sur le point daccs pour rediriger tous les paquets destination du port 80 (HTTP) sur le port 9999 (le port du proxy) sur lordinateur sur lequel tourne le proxy pour mettre en place un proxy transparent. 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 ladresse IP de lordinateur sur lequel tourne le proxy et br0 linterface sur laquelle arrivent les paquets provenant des clients qui vont passer par le proxy.

8.2

Proxy transparent HTTPS

La premire tape dont on ne peut se passer pour faire fonctionner le proxy HTTPS est dajouter le certicat racine du proxy sur le smartphone. Cela peut se faire trs simplement sur un iPhone en envoyant le certicat par email puis en linstallant. Sur Android, linstallation se fait depuis la carte SD et via le menu "Scurit" (voir Figure 7)

Figure 7 Ajout dun certicat sous iPhone et Android 15

Ensuite, pour mettre en place le proxy transparent HTTPS , notre premire tentative a t dessayer de faire la mme 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 dtablir une connexion avec un serveur HTTPS de cette manire. Nous avons donc analys lintgralit des changes quil y avait au niveau du proxy (voir Figure 8).
Client HTTPS
TCP SYN TCP SYN, ACK TCP ACK TCP ACK HTTP CONNECT clients1.google.com:443 TCP ACK 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 HTTP Connection established SSL Client Hello SSL Server Hello SSL Certificate, Hello Done SSL Client Key Exchange,Encrypted Handshake Message SSL Encrypted Handshake Message Encrypted Data Encrypted Data Encrypted Data Encrypted Data

Proxy HTTPS

Serveur web HTTPS

Figure 8 changes lors de ltablissement dune connexion SSL via un proxy SSL (congur sur le client) Grce lanalyse de cet change, on a pu voir que la dirence entre le proxy HTTPS transparent et le proxy congur se situe au niveau du paquet envoy par le client au proxy : "HTTP CONNECT clients1.Google.com:443". En eet, avant ltablissement de la connexion 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) an que celui-ci tablisse la connexion de son ct. On atteint ici en eet un problme qui ne se pose pas en HTTP, car le proxy HTTP a tout de suite accs au serveur auquel veut se connecter le client par lintermdiaire de la variable HTTP "Host". Au contraire, en HTTPS, le proxy na pas accs la requte HTTP qui viendra uniquement quand le tunnel chir sera tabli. Il ne sait donc pas sur quel serveur il peut se connecter et ouvrir la deuxime connexion, ni quel certicat il peut envoyer au client. Nous pouvons voir dans la Figure 9 une illustration des problmes de dcision qui se posent au proxy.

Client HTTPS
TCP SYN / 192.168.0.46:10200 ->74.125.230.229:443

NAT

Proxy HTTPS

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 TCP ACK Quel serveur Web contacter ? SSL Client Hello SSL Client Hello SSL Server Hello SSL Server Hello Quel certificat envoyer ? Je ne connais pas lhte qui va tre contact

Figure 9 Tentative dtablissement dune connexion via un proxy HTTPS transparent Ainsi, il nest pas possible dtablir de la mme manire quen HTTP un proxy HTTPS vraiment transparent pour lutilisateur.

8.3

Proxy HTTPS autocongur

Comme nous nous sommes aperus quil ntait pas possible de faire un vrai proxy transparent en HTTPS (en plus de lajout de certicat sur le client qui est toujours ncessaire), nous avons essay de trouver les techniques permettant de congurer le proxy sur le client de la manire la plus simple possible. Cette conguration automatique du proxy seectue en deux tapes. La premire tape est dcrire un chier PAC (Proxy Auto-Cong). Cest un chier de conguration qui contient toutes les instructions ncessaires pour congurer le proxy sur un navigateur ou un poste client. Voici le chier de conguration que nous avons crit.
// Fichier de config automatique des navigateurs function FindProxyForURL(url , host) { return "PROXY 192.168.0.5:9999"; }

Cest un chier trs simple crit en javascript qui doit dnir la fonction "FindProxyForURL" et retourner les paramtres du proxy en fonction de lURL que lon veut atteindre. Ce chier permet donc davoir une gestion plus intelligente du proxy, ce qui ne nous sera pas utile ici.

17

La deuxime tape est dutiliser le protocole WPAD (Web Proxy AutoDiscovery Protocol). Ce protocole permet aux navigateurs congurs sur "dcouverte du proxy automatique" de rcuprer automatiquement le chier "wpad.dat" si ce chier est lURL de la forme suivante : http://wpad.sous-domaine.domaine.fr/wpad.dat. Le domaine et le sousdomaine doivent tre dnis par le DHCP. Ainsi, le navigateur ou le systme compatible avec le WPAD congure automatiquement lutilisation de proxy. Le navigateur Chrome est par exemple congur par dfaut en "conguration automatique du proxy", il est donc par ce moyen trs facile de le faire passer par un proxy de son choix si on est administrateur du rseau sur lequel il se connecte. Les iPhone ne sont pas compatibles avec le WPAD (seulement avec les chiers PAC pour lesquels il faut donner lURL manuellement), cependant, il est possible dutiliser des chiers de congurations trs faciles installer contenant les paramtres du proxy ainsi que des certicats.

18

Protocol Buers

Le protocol buer [13] cr et utilis par Google est un protocole ouvert permettant de coder et normaliser lchange et linterprtation de donnes. Nous nous sommes aperus quil est utilis la fois par les serveurs dApple pour changer des donnes de localisation avec les iPhone et par les serveurs de Google pour changer les informations de localisation avec les smartphones Android. Nous avons donc dcid de ltudier an de pouvoir dcoder ces donnes de localisation.

9.1

Les varints

Le varint est un type de donnes trs utilis dans les protocol buers pour stocker des entiers sur un octet et plus. Pour coder un entier, pour chaque octet, le premier bit est mis 1, sauf pour le dernier octet (an de savoir que cest le dernier octet). Ensuite, pour les bits restants, les octets les moins signicatifs sont mis en premier. Voici un exemple de dcodage dun varint. 1 010 1100 0 000 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

Interprter les protocol buers

Une unit de donne au sein dun ux encod avec en protocol buers est compos de deux parties : une cl key : elle indique le type et la faon dinterprter la donne change une valeur : contenu de la donne qui suit cette cl La cl est un varint et est elle-mme compose de deux lments : le wire type : il est cod sur les trois derniers bits de la cl et indique la longueur de la valeur de la donne. Chaque wire type regroupe plusieurs types qui sont dnis prcisment par Google et permettent de connatre exactement la taille de la donne pour dlimiter une unit avant de passer la suivante. Il existe 6 wire type dirents qui peuvent tre trouvs en Annexe B.1 le tag : il fait rfrence un champ dans un chier ".proto" personnalisable par lutilisateur du protocol buer. Il indique comment vritablement interprter la donne (type exact et signication) aprs avoir rcupr sa taille. Nous pouvons voir sur la gure 10 linterprtation que lon peut faire dune unit de donne o la cl est par exemple code sur 1 octet. Voici lexemple du dchirement de lhexadcimal "08 96 01" laide des protocol buers. Premier bit de 08 0, donc la cl fait 1 octet 0x08 varint key 0000 1000 on enlve le bit de poids fort 000 1000 0001 tag = 1 voir le chier .proto correspondant. Imaginons que le type du tag 1 soit "int32" 0x 96 01 est donc un varint 1001 0110 0000 0001 on enlve les bits de poids forts 001 0110 000 0001 on inverse les groupes de 7 bits puis on les concatne 00000010010110 10010110 on obtient : 2 + 4 + 16 + 128 = 150 19

Figure 10 Interprtation dune unit de donne o la cl fait 1 octet La donne envoye est donc une variable varint (de type int32 comme est dni le tag 1 dans le chier .proto) et dont la valeur vaut 150

9.3

Exemple de dcodage de donnes encodes en Protocol Buer

Nous allons dsormais pour illustrer les parties prcdentes donner lexemple du dcodage de donnes encodes en Protocol Buer. Ces donnes sont extraites de donnes envoyes par Apple et qui seront analyses ensuite en 10.2. Cest une analyse similaire qui a permis de crer le chier .proto que lon peut trouver en Annexe D.1. Voici les donnes que nous allons analyser :
000000: 000010: 000020: 000030: 000040: 000050: 000060: 000070: 000080: 000090: [...] 00 2e 0a 4f 36 10 77 40 49 36 01 39 05 53 3a 0c 79 1d bc 3a 00 42 4e 35 38 18 bb ba 5d 38 05 31 38 2e 37 a0 a6 b6 5b 37 65 37 38 31 3a ff 08 98 54 3a 6e 36 41 2f 32 ff 50 42 3b 32 5f 00 50 39 34 ff 48 2d 6d 34 55 00 12 42 3a ff 40 f3 b5 3a 53 00 12 31 37 ff 11 78 41 37 00 64 69 37 39 ff 64 ac 38 39 00 00 50 36 3a ff 60 42 00 3a 00 00 68 1a 32 ff 0a 35 1a 32 09 2a 6f 4e 61 01 fc fd 4e 61 35 92 6e 0a 3a 22 ce 59 0a 3a 2e 0a 65 11 36 2a 8c e2 11 36 31 1b 20 33 33 09 03 42 33 31 | | | | | | | | | | ....en_US....5.1 .9B176...d..*... ..N88AP..iPhone OS5.1/9B176.N..3 6:87:24:79:2a:63 ............."*. wy...PH@.d..... @....B-.x.B5.Y.B I.][T;m.A8..N..3 6:87:24:79:2a:61

Tout dabord, il faut trouver o commence lencodage en protocol buer. Pour cela, on peut essayer chaque octet et voir si cest cohrent, mais avec un peu dhabitude, on saperoit que souvent, le protocol buer commence avec 0x0A (tag = 1 ; type = 2 ce qui correspond aux lments dont la taille est donne par loctet qui suit tels que les string, les champs rpts ou les messages ) , 0x08 (tag = 1 ; type = 0, un varint) ou 0x09 (tag = 1 ; type = 1, nombre de 64 bits). Ici, le protocol buer parat commencer par exemple loctet no 0x3D. Le premier octet est 0A ce qui signie que le tag est 1 et que loctet qui suit est la taille de la valeur. On arrive lire la suite en ASCII, ce qui veut dire que cest surement une chane de caractre de type string. Elle contient le BSSID et fait en eet 0x11 (= 17) octets. Ensuite, vient 10 (tag = 2, type = varint) un entier de valeur 0x0C =12 . Cela correspond en fait au canal Wi-Fi utilis. Ensuite vient 18 (tag = 3 ; type = varint) cod sur 10 octets, cest la valeur -96 qui correspond la qualit du signal. 22 (Tag = 4, type = 1) reprsente soit une chaine de caractre, soit un message (bloc de donnes protcol buer). Comme ce qui suit na pas lair dtre des caractres intelligibles, cest quil sagit surement dun bloc de donnes de taille 0x2A = 42. La suite, 09 (tag = 1, type = 64 bits) conrme le fait quon soit dans un nouveau bloc, car le numro de tag recommence 1. Le nombre de 64 bits vaut en double 48.6252640167 ce qui correspond une latitude. Ensuite, 11 (tag = 2, type = 64bits) est lentte de la valeur 2.44375416667 code sur un type double. Cela correspond une longitude. Ensuite 20

vient 1D (tag = 3 ; type = 32 bits) qui en oat vaut 359480148.357 ce qui reprsente exactement le nombre de secondes entre le premier janvier 2001 et la mesure. Nous navons pas russi interprter les valeurs qui suivent, mais lavantage du protocol buer est quon peut le dcoder, mme si on ne sait pas ce quoi les donnes correspondent : lentte 2D (tag = 5, type = 32bits) signie que le nombre qui suit prend 4 octets : 0xF3 0x78 0xAC et 0x42. Suivent les enttes suivants : 35 (tag = 6 ; type = 32bits), 49 (tag = 9 ; type = 64bits), 38(tag =7 ;type=varint). On arrive lentte 1A (tag = 3 ; type = 1) qui ne semble pas cohrent avec ce qui prcde. Cest en fait cet endroit quon saperoit quensuite recommence quelque chose de similaire ce que lon a dcod depuis le dbut et que cest 1A 4E tait lentte qui lenglobait. Il aurait donc fallu commencer notre dcodage 2 octets avant pour prendre en compte la structure englobante. Ensuite recommence donc une utilit de donne exactement similaire celle que lon vient de dcoder. Daprs ltude des quelques donnes prcdentes, nous pouvons en dduire le chier .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 quils ne connaissent pas } required Location location = 4; } message BlockBSSIDNocturne { repeated WifiMeasurement wifi = 3; }

Ce chier permettra un script python de dcoder toutes les donnes que nous venons dtudier, et peut-tre mme plus si certains messages se rptent. Il permettra aussi de coder des donnes choisies par lutilisateur suivant le mme format. Sur le site de dveloppeur de Google https://developers.Google.com/protocol-buers/, toute la documentation et les sources sont disponibles pour intgrer le protocole buer ses applications et gnrer les chiers .proto. Il faut par ailleurs noter la prsence dun outil trs pratique (que nous avons dcouvert aprs avoir dcod un grand nombre de ux " la main")
$ protoc --decode_raw < [flux de data encode grce au protocole buffer]

Enn, nous conclurons cette partie sur les Protocol Buer en vous invitant lire cet article trs intressant fourni par une quipe de "Sysdream - IT Security Services" proposant un travail de reverse engineering sur le protocole buer [14]. En eet, le script python tlchargeable la n permet de recrer le chier .proto en analysant une application binaire utilisant le protocole buer pour gnrer des ux de donnes.

21

10

changes des donnes de localisation sur iOS

Sur les smartphones Apple fonctionnant sur iOS, il existe deux types de donnes de localisation qui sont changes entre un serveur dApple et un iPhone : les donnes changes lors de la golocalisation du smartphone et les donnes changes pour permettre Apple de constituer sa base de donnes de BSSID. Nous allons tudier dans les parties suivantes ces deux changes de manire approfondie.

10.1

Donnes envoyes lors de la golocalisation du tlphone

Lorsquun utilisateur veut se golocaliser sur un iPhone, celui-ci peut utiliser trois techniques direntes comme nous lavons vu prcdemment (Golocalisation par GSM, Golocalisation Wi-Fi, Golocalisation GPS). Nous allons voir dans cette partie uniquement les changes eectus avec les serveurs dApple lors de la golocalisation Wi-Fi, car la golocalisation GPS ne ncessite pas dchange avec un serveur dApple et que nous navons jamais vu passer dchange concernant la golocalisation GSM, nous pouvons donc supposer que celle-ci ne seectue que quand il ny a pas de connexion Wi-Fi. Nous avons lu [1] que lorsquun iPhone voulait se connecter un rseau Wi-Fi, il changeait des donnes avec le serveur dApple situ lURL https://gs-loc.apple.com. Ceci sest tout de suite conrm avec nos tests qui montraient plusieurs changes HTTPS entre ce serveur et le tlphone chaque fois quune application voulait utiliser la golocalisation et que le Wi-Fi tait allum. Pour analyser les donnes envoyes lors de cet change, nous avons utilis le proxy sslmeat prsent en 8. Ce proxy enregistre tous les paquets quil transmet dans une base de donnes sqlite avec le numro du paquet, lheure laquelle il a t enregistr, ladresse et le port source et destination, le nom dhost et en binaire (BLOB) toutes les donnes qui taient contenues dans ce paquet. Pour rcuprer les donnes utiles, il y a un outil fourni avec le proxy qui permet en utilisant la commande
./showp packets.db

dacher en console tout le contenu de tous les paquets enregistrs avec les donnes binaires la fois en hexadcimal et en ASCII. Cependant, acher tous les paquets peut renvoyer une quantit de donnes norme assez dicile traiter. Nous avons donc utilis une simple requte sur la base de donnes sqlite pour supprimer tous les paquets dont nous navions pas besoin au moins dans un premier temps :
DELETE FROM packets WHERE hostname NOT LIKE "%gs-loc.apple.com%"

Nous avons donc pu rcuprer facilement grce la commande ./showp les donnes brutes suivantes :
192.168.0.46:53886 17.174.2.27:443 POST /clls/wloc H T /1.1 TP Host: gsloc .apple.com 000000: 000010: 000020: 000030: 000040: 00 2e 0a 3a 70 01 39 11 36 6c 00 42 65 30 65 05 31 30 18 2e 65 37 3a 00 4d 6e 36 39 20 61 5f 00 31 c0 70 55 00 3a 0c 73 53 00 66 2a 00 01 35 0e 00 00 3a 63 00 00 66 6f POST gsloc .apple.com:443

09 00 65 6d

35 2a 3a 2e

2e 12 66 61

31 13 36 70

| | | | |

. . . . en_ . . . 5 . 1 US. .9B1 7 6 . . . . . . . . . . . e0:91: f 5:fe : f6 :60.. . ..com.ap ple .Maps

17.174.2.27:443 192.168.0.46:53886 H T /1.1 200 O TP K Date: Sun, 18 Mar 2012 16:55:40 G T M Content Length: 74784

200 gsloc .apple.com:443

22

000000: 000010: 000020: 000030: 000040: 000050: 000060: 000070: 000080: 000090: 0000a0: 0000b0: 0000c0: 0000d0: 0000e0: 0000f 0: 000100: 000110: 000120: 000130: 000140: [...]

00 3a 16 30 31 08 08 31 9b 28 3a ce 60 63 12 02 61 10 a8 36 d0

01 39 08 05 65 c2 58 3a cf 60 64 9a b0 3a 10 a8 34 bf 01 3a cf

00 31 e0 58 3a c2 2e 64 9a 98 37 12 01 32 d2 01 3a be 01 33 dc

00 3a e6 2c 38 ce 60 37 12 01 3a 10 a8 31 e5 01 36 dc 12 61 6e

00 66 ce 60 63 9a 6e 3a 10 a8 63 f9 01 3a db 12 64 6e 2c 3a 18

01 35 9a 9a 3a 12 a8 37 fb 01 3a b6 0b 65 6e 2d 3a 18 0a 34 2a

00 3a 12 01 34 10 01 33 dd 0b 63 dc 12 3a 18 0a 39 32 10 63 28

01 66 10 a8 63 f5 0b 3a db 12 37 6e 2c 64 2a 10 30 28 30 12 2f

24 65 fe 01 3a cc 12 39 6e 2d 3a 18 0a 64 28 30 12 2e 3a 15 30

16 3a e2 01 32 db 2d 34 18 0a 62 2d 0f 12 2e 3a 16 30 32 08 0c

12 66 db 12 35 6e 0a 3a 2a 10 34 28 30 16 30 31 08 08 32 bb 58

2e 36 6e 2c 3a 18 10 63 28 65 12 2d 3a 08 0a 36 d7 58 3a f1 3e

0a 3a 18 0a 37 2a 65 12 32 30 16 30 31 df 58 3a fc 25 33 ce 60

11 36 2a 10 62 28 30 16 30 3a 08 10 65 9f 3d 63 ce 60 66 9a 7e

65 30 28 30 12 2f 3a 08 0b 61 8f 58 3a cf 60 66 9a d7 3a 12 a8

30 12 31 3a 15 30 61 fc 58 31 e7 25 34 9a 80 3a 12 01 38 10 01

| | | | | | | | | | | | | | | | | | | | |

. . . . . . . . $ . . . . . e0 :91: f 5:fe : f 6:60. . . . . . . . . . . . n.(1 0.X, . . . . . . , . . 0 : 1e:8c:4c:25:7b. . . . . . . . . . . . n.(/0 .X. n.... ..e0:a 1:d7:73:94:c . . . . . . . . . . . . n.(20.X ( ...... .. e0:a1 :d7:c:c7:b4 . . . . . . . . . . . . n.(0.X % . . . . . . , . . 0 : 1 e:4 c:21:e:dd. . . . . . . . . . . .n.(.0.X=. ..... ..0:16: cf : a4:6d: 9 0 . . . . . . . . . . . .n.2(.0.X %.. .... ,..0:22:3 f :8 6:3a:4c . . . . . . . . . . . .n.(/0.X>~..

Ces donnes avaient lair trs intressantes, car on pouvait dj y lire des BSSID en ASCII. Daprs larticle prcdemment cit [1] nous avons dcouvert que ces donnes taient encodes laide des Protocol Buers. Nous avons donc dcod ces donnes de la mme manire que dcrit en 9.3 an de gnrer le chier .proto permettant de dcoder automatiquement toutes les donnes codes de la mme manire. Celui-ci est donn en Annexe C. Enn, pour avoir un rendu facile lire des donnes contenues dans les changes analyss, nous avons crit un script python permettant dune part dacher les donnes en console de manire organise et claire et dautre part de gnrer un chier KML (Keyhole Markup Language) [15] contenant les BSSID et leurs coordonnes gographiques donnant la possibilit dtre ach sur Google Earth ou Google Maps. Ce script python est fourni en Annexe C. Voici lchange prsent plus haut dcod avec le script python et son achage sur une carte Google Maps (voir Figure 11)
POST /clls/wloc H T /1.1 TP Host: gsloc .apple.com Langue : en_ US OS Version : 5.1.9B176 Wifi BSSID : e0:91: f 5:fe : f6:60 APIName : com.apple.Maps H T /1.1 200 O TP K Wifi BSSID : e0:91: f 5:fe : f6:60 Latitude : 48.87655264 Longitude : 2.32190334 Confiance : 42 Wifi BSSID : 0:1e:8c:4c:25:7b Latitude : 48.87650626 Longitude : 2.32187509 Confiance : 42 Wifi BSSID : e0:a1:d7:73:94:c Latitude : 48.87662076 Longitude : 2.32189691 Confiance : 42 Wifi BSSID : e0:a1:d7:c:c7:b4 Latitude : 48.87655311 Longitude : 2.32201081 Confiance : 45 Wifi BSSID : 0:1e:4c:21:e:dd Latitude : 48.87662559 Longitude : 2.32190674 Confiance : 42 Wifi BSSID : 0:16:cf :a4:6d:90 Latitude : 48.87658071 Longitude : 2.32202047 Confiance : 50 Wifi BSSID : 0:22:3f :86:3a:4c Latitude : 48.87656635 Longitude : 2.3220424 Confiance : 42

Nous pouvons constater avec ces changes que le BSSID du point daccs sur lequel 23

Figure 11 Achage des BSSID et de la position exacte sur une carte Google Maps est connect le tlphone (e0 :91 :f5 :fe :f6 :60) est envoy au serveur dApple qui rpond une liste de 201 BSSID avec leurs coordonnes (latitude, longitude) ainsi quun indice de conance sur ces coordonnes. Ce serveur doit donc connatre le BSSID qui lui est envoy par le tlphone et en avoir les coordonnes. Si celui-ci nest pas dans sa base de donnes, le serveur le signale au tlphone qui lui renvoie une liste contenant tous les BSSID des points daccs proximit, ce qui permet au serveur denvoyer une liste similaire celle ci-dessus. Le calcul de la position exacte du tlphone nest donc pas eectu sur le serveur dApple, mais sur le tlphone qui, grce tous les BSSID dont il connat la position pourra calculer sa position exacte en fonction de la puissance des signaux dont il a les coordonnes. Cependant, on peut constater avec la reprsentation graphique de la Figure 11 quavec le seul BSSID envoy par le tlphone, le serveur dApple a une vision do est situ le tlphone (le centre du cercle) trs proche de la ralit (le rond rouge). On peut aussi constater avec la capture prcdente quaucun identiant permettant didentier le smartphone ou lutilisateur nest transmis (si ce nest le BSSID et ladresse IP du point daccs sur lequel il est connect). Il est donc impossible Apple dutiliser ces seules informations pour suivre un utilisateur ce qui est bon pour la protection de la vie prive des utilisateurs.

10.2

Donnes envoyes pour constituer la base de donnes de BSSID dApple

Toujours dans larticle [1] nous avons appris que pour maintenir jour sa base de donnes de BSSID avec leurs coordonnes gographiques, Apple utilise tous les smart24

phones iOS. En eet, ces tlphones enverraient rgulirement la nuit les points daccs Wi-Fi quils ont "rencontrs" avec leurs coordonnes ce moment. Cependant, mme en laissant le tlphone congur sur le proxy pendant plusieurs jours, nous navons pas vu les changes partir du tlphone la nuit. Cest au bout de quelque temps que nous nous sommes aperus quil fallait avoir activ lenvoi des "Diagnostics et utilisations" Apple pour que ces changes se passent. Par ailleurs, larticle ayant du tre eectu sur une version antrieure diOS, il y tait dit que le serveur contact par les iPhone la nuit avait comme adresse https://iphone-services. apple.com. Sur la version diPhone dont nous disposions, les envois se sont en fait eectus vers le serveur https://gsp10-ssl.Apple.com. De plus, ils ne se font pas forcment la nuit, heure rgulire, mais quand le tlphone est branch et connect un rseau Wi-Fi et quil neectue pas de tche particulire. Ce qui est quand mme gnralement souvent la nuit. Nous avons pu rcuprer les donnes brutes suivantes :
192.168.0.46:49163 17.174.2.54:443 POST /hcy/pbcwloc H T /1.1 TP Host: gsp10ssl .apple.com 000000: 000010: 000020: 000030: 000040: 000050: 000060: 000070: 000080: 000090: 0000a0: 0000b0: 0000c0: 0000d0: 0000e0: 0000f 0: 000100: 000110: 000120: 000130: 000140: 000150: 000160: 000170: 000180: 000190: 0001a0: 0001b0: 0001c0: [...] 00 2e 0a 4f 36 10 77 40 49 36 10 77 40 49 34 01 79 1d bc 31 a2 a6 b6 5b 3a ff 08 98 54 01 39 05 53 3a 0c 79 1d bc 3a 0c 79 1d bc 3a 18 bb ba 5d 66 ff 08 98 54 64 ff 50 42 3b 00 42 4e 35 38 18 bb ba 5d 38 18 bb ba 5d 63 a1 a6 b6 5b 3a ff 50 42 3b 34 ff 48 2d 6d 05 31 38 2e 37 a0 a6 b6 5b 37 a0 a6 b6 5b 61 ff 08 98 54 63 ff 48 2d 6d 3a ff 40 f3 b5 65 37 38 31 3a ff 08 98 54 3a ff 08 98 54 3a ff 50 42 3b 36 ff 40 f3 b5 36 ff 11 78 41 6e 36 41 2f 32 ff 50 42 3b 32 ff 50 42 3b 65 ff 48 2d 6d 3a ff 11 78 41 63 ff 64 ac 38 5f 00 50 39 34 ff 48 2d 6d 34 ff 48 2d 6d 35 ff 40 f3 b5 64 ff 64 ac 38 3a ff 60 42 00 55 00 12 42 3a ff 40 f3 b5 3a ff 40 f3 b5 3a ff 11 78 41 3a ff 60 42 00 31 ff 0a 35 1a 53 00 12 31 37 ff 11 78 41 37 ff 11 78 41 61 ff 64 ac 38 32 ff 0a 35 1a 61 01 fc fd 4d 00 64 69 37 39 ff 64 ac 38 39 ff 64 ac 38 63 ff 60 42 00 65 01 fc fd 4d 3a 22 ce 59 00 00 50 36 3a ff 60 42 00 3a ff 60 42 01 3a ff 0a 35 1a 3a 22 ce 59 0a 63 2a 8c e2 00 00 68 1a 32 ff 0a 35 1a 32 ff 0a 35 1a 36 01 fc fd 4c 61 2a 8c e2 10 30 09 03 42 POST gsp10ssl .apple.com:443

09 2a 6f 4e 61 01 fc fd 4e 61 01 fc fd 4d 3a 22 ce 59 0a 66 09 03 42 30 10 77 40 49

35 92 6e 0a 3a 22 ce 59 0a 3a 22 ce 59 0a 34 2a 8c e2 0f 10 77 40 49 3a 0b 79 1d bc

2e 0a 65 11 36 2a 8c e2 11 36 2a 8c e2 10 39 09 03 42 30 06 79 1d bc 32 18 bb ba 5d

31 1b 20 33 33 09 03 42 33 31 09 03 42 66 10 77 40 49 3a 18 bb ba 5d 34 a3 a6 b6 5b

| | | | | | | | | | | | | | | | | | | | | | | | | | | | |

. . . . en_ . . . 5 . 1 US. .9B176...d. . . . . . .N88 .iPhone AP. OS5.1/9B176.N..3 6:87:24:79:2a:63 .............". wy. . .P @.d . . . . . H @. . . .B .x.B5.Y.B I . ] [T;m.A8..N..3 6:87:24:79:2a:61 .............". wy. . .P @.d . . . . . H @. . . .B .x.B5.Y.B I . ] [T;m.A8..M. . f 4:ca:e5:ac:6:49. . . . . . . . . . . . . " .w y. . .P @.d . . . . .@ H . . . .B .x.B5.Y.BI . ] [T;m.A8..L..0: 1f :c6:d:2e: af . . . . . . . . . . . . . " .wy. . .P @.d . . . . .@. . H . .B .x.B5.Y.BI. ] [T;m.A8..M..0:24 :d4:6c:1a:c 0 . . . . . . . . . . . . . " .wy. . .P @.d . . . . .@. . . H .B .x.B5.Y.BI. ] [ T;m.A8..M

Nous avons ensuite procd de la mme manire que dans la partie prcdente pour, gnrer le chier .proto correspondant cet envoi puis avons crit un script dont le code est fourni en Annexe D.1. Pour acher ces donnes de manires claires en console et pouvoir gnrer le chier .kml acher sur une carte. Voici les donnes dcodes et leur achage sur une carte Google Earth :
POST /hcy/pbcwloc H T /1.1 TP Host: gsp10ssl .apple.com Langue : en_ US Version hardware : N88 AP Version OS: iPhone OS5.1/9 Wifi BSSID : 36:87:24:79:2a:61 channel : 12 signal_strength : 96 latitude : 48.6252640167 longitude : 2.44375416667 timestamp : 359480148.357 > 23/05 17:35:48 Wifi BSSID : f 4:ca:e5:ac:6:49

25

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

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

Figure 12 Envoi nocturne ach sur une carte Google Earth Avec les mesures que nous avons faites et les rsultats de cette capture, nous pouvons constater que les donnes qui sont envoyes Apple sont uniquement des identiants de points daccs wi (BSSID et canal), le moment exact de la mesure ainsi que la force du signal et les coordonnes du tlphone au moment o il a capt ces rseaux Wi. On sest aussi aperu que les positions des rseaux Wi ne sont envoyes Apple que si la position du tlphone tait calcule avec le GPS (donc uniquement en extrieur). De plus, comme dans le cas prcdent, il ny a aucune information permettant didentier lutilisateur (mis part la version de son hardware et de lOS). L encore, la vie prive de lutilisateur semble tre prserve et lutilisation de ces envois nocturnes est uniquement pour pouvoir ensuite utiliser la golocalisation beaucoup plus rapidement en ville grce la golocalisation Wi. 26

Lachage sur la carte que nous pouvons voir sur la Figure est assez confus. Cest en fait car le tlphone une fois quil a trouv sa position GPS retient tous les points daccs quil capte. Pour chaque endroit dni par les coordonnes gographiques, il y a donc un grand nombre de points daccs. En essayant de dcoder tous les paquets envoys au serveur https://gsp10-ssl.Apple.com, nous nous sommes aperus que le script marchait trs bien pour certains paquets, mais pas pour dautres. En essayant de crer un autre chier .proto pour le deuxime type denvoi, nous nous sommes aperus quen plus denvoyer des BSSID avec leurs coordonnes, les iPhone envoient aussi de la mme manire que les BSSID les coordonnes des antennes GSM porte comme nous pouvons le voir sur la capture ci-dessous prsente brute puis dcode laide du code fourni en Annexe D.2.
192.168.0.46:51730 17.174.2.54:443 POST /hcy/pbcwloc H T /1.1 TP Host: gsp10ssl .apple.com 000000: 000010: 000020: 000030: 000040: 000050: 000060: 000070: 000080: 000090: 0000a0: 0000b0: 0000c0: 0000d0: 0000e0: 0000f 0: 000100: 000110: 000120: 000130: 000140: 000150: 000160: 000170: 000180: [...] 00 2e 0a 4f 10 ff 17 b6 3c 65 01 12 a7 42 9c 59 ff 01 01 30 40 cc b5 70 72 01 39 05 53 01 ff 6b 98 a3 2e 62 64 ff 2a b7 e2 ff b6 20 bc 11 a5 41 73 65 00 42 4e 35 18 ff 6c 42 7b 4d 04 08 ff 09 02 42 ff 01 b5 54 71 a8 4a 58 65 05 31 38 2e 84 ff 48 2d 76 61 46 d0 ff 33 40 49 ff 88 ce 38 04 42 0e ff 78 65 37 38 31 ea 01 40 2d b5 70 72 01 ff df 1d cd ff 01 2a be 04 35 63 ff 0a 6e 36 41 2f 01 30 11 4c 41 73 65 10 ff 53 ba 51 ff 02 28 03 ce fd 6f ff 80 5f 00 50 39 20 bc ae 2d 4a 58 65 01 ff cb b6 3c 01 12 b7 42 ad 59 6d ff 01 55 00 12 42 b5 54 26 42 0e ff 78 18 ff 68 98 e0 62 74 ff 2a b3 e2 2e ff 84 53 00 12 31 ce 38 bd 35 63 ff 14 84 ff 6c 42 7b 04 08 ff 09 02 42 61 ff 01 00 64 69 37 2a 37 dd fd 6f ff 80 ea 01 48 2d 76 46 d0 ff 35 40 49 70 ff 88 00 00 50 36 28 42 00 59 6d ff 01 01 30 40 2e b5 72 01 ff e0 1d 18 70 ff 01 00 00 68 12 a4 2a b9 e2 2e ff bc 20 bc 11 4c 41 65 10 ff e2 ba 55 6c ff POST gsp10ssl .apple.com:443

09 03 6f 73 ff 09 02 42 61 ff 01 b5 54 74 3d 58 65 01 ff 97 b6 bf 65 01

35 06 6e 08 ff 8b 40 49 70 ff 88 ce 38 6f 42 ff 78 18 ff 30 98 6e 2e 62

2e 0a 65 d0 ff d9 1d 61 70 ff 01 2a be 8f 35 ff 18 84 ff 6c 42 7c 4d 04

31 1b 20 01 ff c9 ba 7d 6c ff 02 28 03 ef fd ff 80 ea 01 48 2d 76 61 46

| | | | | | | | | | | | | | | | | | | | | | | | |

. . . . en_ . . . 5 . 1 US. .9B176...d . . . . . . . .N88 .iPhone AP. OS5.1/9B176.s . . . ...... ..(..... . . . . . 0 .T87B . . . . .klH@. . & . . . . .@. . . .B L B5.Y.BIa} <.{v.AJ.com.appl e.MapsX. . . . . . . . . .b.Freex . . . . . . . . .d . . . . . . . . . ..( . . . . . . . . . . 0 .T8.. B.3.S.hlH@.to . . . . .@. . . .B = .L B5. Y.BI.Q <.{v.A . . X. . . . . . . . b.Freex. . .......t........ . ..(.......... 0.T8..B.5...0lH @.q . . . . . .@. . . .B . . .B5.Y.BI.U.n|v .AJ.com.apple.Ma psX. . . . . . . . . . b.F reex . . . . . . .

POST /hcy/pbcwloc H T /1.1 TP Host: gsp10ssl .apple.com Langue : en_ US Version hardware : N88 AP Version OS: iPhone OS5.1/9B17 M C : 208 C MC: 1 N LAC : 29956 CellID : 698165 Attenuation : 73 Latitude : 48.84523295 Longitude : 2.33773385 Timestamp : 360086638.747 > 30/05 18:03:58 APIName : com.apple.Maps Operateur : Free M C : 208 C MC: 1 N LAC : 29956

CellID : 698165 Attenuation : 65 Latitude : 48.8448654167 Longitude : 2.33759816667 Timestamp : 360086697.899 > 30/05 18:04:57 APIName : Operateur : Free M C : 208 C MC: 1 N LAC : 29956 CellID : 655967 Attenuation : 86 Latitude : 48.8445925667 Longitude : 2.33753441667 Timestamp : 360086750.965 > 30/05 18:05:50 APIName : Operateur : Free [...]

Les donnes envoyes sont assez compltes puisquelles contiennent les informations 27

suivantes permettant didentier les antennes GSM : le MCC (Mobile Country Code) correspondant au pays, le MNC (Mobile Network Code) correspondant loprateur, le LAC, le CellID qui est lidentiant de cellule ainsi que les mmes paramtres que pour les rseaux Wi-Fi : Attnuation, Latitude, Longitude et heure prcise de la mesure. Nous pouvons voir sur la Figure 13 lachage sur Google Earth dun envoi nocturne aprs avoir utilis le GPS dans une rue. On saperoit aisment que lorsque lon utilise le GPS de manire continue, le tlphone mmorise toutes les informations sur les rseaux GSM (et de la mme manire en Wi-Fi) quil capte. Cependant, cela veut dire aussi que lorsque le GPS nest pas actif ou utilis, le tlphone ne fera pas de calcul GPS par lui mme pour enrichir la base de donnes dApple.

Figure 13 Envoi nocturne ach sur une carte Google Earth

28

11

Localisation et Scurit sur Android

Aprs avoir analys le comportement des tlphones Apple et des serveurs correspondants, nous allons eectuer la mme tude pour les tlphones de Google an de comparer lattitude et les objectifs des deux concurrents vis--vis des donnes de localisation. Nous allons donc dbuter la mme procdure laide du proxy pour un tlphone sur OS Android puis voir jusquo nous pouvons pousser lanalyse du systme concernant notre problmatique et comment nous allons devoir adapter cette procdure pour obtenir un maximum de rsultats pertinents.

11.1

Contexte de lanalyse sur OS Android

Avant de nous plonger dans ltude des changes de donnes de localisation sur le systme de Google, nous avons envisag plusieurs moyens dentreprendre nos tests et accder un maximum dinformations. Trois possibilits se prsentent pour travailler sur Android : lmulateur Android propos dans le SDK de Google, les machines virtuelles Android disponibles pour architectures x86, les tlphones OS Android disponibles sur le march. 11.1.1 mulateur Android

Nous allons voir dans la section suivante que Google met disposition des dveloppeurs un kit de dveloppement trs complet ainsi quune documentation disponible en ligne destination des dveloppeurs dapplication pour Google Play (anciennement appel Android Market). Ce SDK, Software Development Kit, disponible cette adresse [16], propose notamment un gestionnaire de priphriques Android virtuels : lAndroid Virtuel Device Manager (voir Figure 14). Lavantage de cet mulateur est que lon peut facilement

Figure 14 Android Virtual Device Manager obtenir les sources et les images de toutes les versions du systme de Google, de la version 1.5 la version 4.0.3 qui a t ajoute trs rcemment. Il sagit donc dun excellent outil 29

pour les dveloppeurs dsirant tester la compatibilit de leurs applications sur les versions de lOS. Cependant, cet outil peut simuler une connexion internet disponible via la machine host par une connexion data 3G mais il sera impossible de simuler une interface Wi (voir Figure 15). Cette solution devient alors peu pertinente pour notre problmatique

Figure 15 Connexions dun Android virtuel de golocalisation, elle pose le mme problme vis--vis de la simulation du GPS et des antennes GSM. 11.1.2 Machine Virtuelle Android

Grce au projet Android-x86 [17], support aussi par la socit Intel [18], des images de toutes les versions du systme Android sont disponible au format iso pour des architectures x86. Il est alors facile dinstaller une VM Android sur une machine et un OS host classique tel que nous pouvons le voir sur la Figure 16 o nous avons utilis Virtual-Box. noter

Figure 16 Android x86 sur VirtualBox quil est donc aussi possible de crer une cl USB bootable Android. Le gros avantage de cette solution est quun simple Alt+F1 permet dobtenir un shell root sur le systme 30

an de ltudier au mieux. Les inconvnients rejoignent ceux de lmulateur : trs peu de pilotes Wi sont supports par le noyau, il faut donc se contenter de la virtualisation de linterface Ethernet et bien quil soit possible de simuler une position GPS, cette solution est trs limite en terme de mobilit et nous ne pouvons tudier la localisation GSM. 11.1.3 Tlphone sous OS Android

La seule solution restante est aussi la plus naturelle : utiliser un tlphone mobile fonctionnant sous Android. Lavantage est que nous pourrons tudier librement tous les moyens de localisation : Wi, GPS, GSM et nous rapprocher au maximum des conditions relles. En contrepartie, nous devons faire face aux contraintes imposes par les constructeurs et des oprateurs dont le plus important est le verrouillage du systme et de son bootloader. Nous avons donc choisi de faire cette tude directement sur des tlphones Android. Pour contrler au mieux notre device et obtenir les rsultats que nous souhaitons, il faudra donc passer dans la prochaine partie - Prambule ltude de la localisation sur Android - par une tape de dverrouillage du tlphone et prendre possession de quelques outils du systme de Google.

11.2

Prambule ltude de la localisation sur Android

Lessentiel du projet est eectu sur un smartphone HTC Desire HD sorti en 2010 sous la version 2.2 Froyo. Il a t mise jour dans le courant de lanne 2011 sous la version 2.3 Gingerbread et devrait accueillir la version 4.0 IceScreamSandwich (ICS) au mois daot 2012. Ce tlphone a t achet desimlock, nous mettons donc de ct toute contrainte logicielle ou matrielle provenant de loprateur. 11.2.1 Choix de la version du systme

Le problme connu concernant les smartphones Android est la fragmentation des versions du systme. En change dune grande libert oerte par Google aux constructeurs et oprateurs sur la manipulation de son systme dexploitation, les utilisateurs sourent dimportants retards concernant la mise jour de leurs smartphones et tablettes. Alors que la version 4.0 a t prsente lors de la confrence Google I/O de juin 2011, celle-ci ne reprsente en mai 2012 que 9% de la rpartition alors que la version 2.3 reprsente toujours 55% de la rpartition et 22% pour la version 2.2 [19]. Nanmoins, la version 4.0 est la plus adapte notre projet, car la possibilit de paramtrer un proxy sur les connexions Wi est nativement installe sur lOS, chose impossible sur les versions 2.3 et antrieure. De plus, le nombre de smartphones et de tablettes vendus aujourdhui tant considrable, la version 4.0 sera sans aucun doute majoritairement rpandue et utilise en 2012-2013. Il est plus intressant et protable dtudier un systme rcent. Ainsi, le coeur de ce prambule ltude de la localisation sur Android va tre de passer le smartphone Desire HD 2.3 sur la version 4.0. Ce portage est rendu (lgalement) possible grce aux communauts de dveloppeurs telles que CyanogenMod [20] qui adaptent les sources du systme Android fournies par Google (ou partir des sources de ROMs fournies par des constructeurs pour leurs produits rcents) aux smartphones non ociellement mis jour par les constructeurs. Nous allons donc remplacer la ROM ocielle 2.3 en ROM "custom" 4.0. Le procd sera dcrit dans ses grandes lignes pour ne pas sortir de notre problmatique, mais il va aussi nous permettre de mieux comprendre larchitecture logicielle du smartphone an de mieux le manipuler plus tard.

31

Note : la version Android 2.3 tant encore largement rpandue nous ajouterons des remarques importantes concernant cette version lors de notre tude de la localisation. En eet, il est trs intressant de voir lvolution concrte de la politique de Google envers les problmes de vie prive que pose la rcolte de donnes de golocalisation. 11.2.2 Installation du SDK et outils du SDK

Installer le SDK Android disponible http://developer.android.com/sdk/index.html est essentiel pour accder 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 asher 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 chiers, changer des applications, obtenir un shell... ADB est lacronyme de Android Debug Bridge [21]. Remarque 1 : pour utiliser loutil adb il faut autoriser le dbogage USB sur le tlphone, sur la version ICS 4.0 : "Paramtres/Section Systme : Options pour les dveloppeurs/cocher dbogage USB" Remarque 2 : dans lanalyse des donnes de localisation nous utiliserons la fois un shell depuis une machine Linux grce la commande "./adb shell" et un terminal directement install sur le smartphone Remarque 3 : la manipulation des outils du SDK est particulirement aise partir dune machine sous Linux, nous avons travaill la plupart du temps depuis une machine Ubuntu. Pour lancer linterface graphique du SDK et, par exemple, manipuler lmulateur Android, AVD manager, il faut lancer : <repertoire-sdk>/tools/android . 11.2.3 "Unlock" et "Rootage" de lHTC Desire HD

Installer une ROM personnalise permettant, entre autres, dobtenir une version Android plus rcente ncessite de dbloquer le verrouillage du smartphone impos par le constructeur. Ceci permet daccder aux direntes partitions du smartphone et de les "asher" avec de nouvelles images logicielles. Un smartphone Android est construit sur 6 partitions principales [22] : la partition Boot : contient le noyau ou kernel du systme, peut tre ashe avec un nouveau noyau la partition System : contient le systme Android dans "/system" bas sur le noyau, peut tre ashe avec une ROM custom la partition Userdata : contient les donnes utilisateurs dans "/data", cette partition est particulirement importante pour la suite de notre projet, car elle va contenir de nombreuses donnes de localisation la partition Hboot : contient le bootloader verrouill par le constructeur et que nous allons "unlocker" dans la premire tape la partition Recovery : contient le systme recovery du device qui permet de restaurer le systme et deectuer des oprations telles que le formatage "wipe" des donnes systmes ou utilisateurs, grer les partitions prsentes sur la carte SD, monter la partition de la carte SD sur une machine... la partition Radio : gre toutes les connexions spciques la tlphonie (connexion GSM, 3G...). Peut tre ashe avec une nouvelle ROM radio. 32

La premire tape du processus de "Rootage" dans sa globalit consiste donc "unlocker" le smartphone an de pouvoir contrler le bootloader et manipuler ces partitions, en particulier le Boot et le Recovery. Devant lenthousiasme provoqu par les communauts de dveloppeurs, HTC et dautres constructeurs permettent aujourdhui de dverrouiller "ociellement" leur device. Cest le cas pour le Desire HD dont la procdure dtaille est disponible sur leur site ddi aux dveloppeurs [23]. Une fois cette procdure eectue nous pouvons redmarrer le smartphone en gardant le bouton VOL- appuy pour accder au bootloader et au mode Fastboot. Il faut alors connecter le smartphone en USB sur une machine qui aura un terminal ouvert sur "<repertoire-sdk>/plateform/tools/", nous sommes alors en mode Fastboot USB. Nous pouvons eectuer la deuxime tape : installer ou "asher" un recovery personnalis sur la partition Recovery nous permettant deacer lancien systme et dinstaller notre nouvelle ROM personnalise et roote Android 4.0. Nous eectuons les commandes suivantes (voir Figure 17) :
sudo ./fastboot devices //permet de vrifier 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 tlcharger une image de rom recovery ClockWorkMod qui est la plus rpandue aujourdhui et disponible sur internet en version 5.0.2.3 . La troisime tape consiste asher le noyau de la Rom custom. Une Rom custom se prsente gnralement sous la forme dun .zip contenant une image du noyau "boot.img" et un rpertoire systme qui sera ash grce au recovery dans ltape suivante. De nombreuses ROMs personnalises sont disponibles sur le site de CyanogenMod rputes pour leur abilit et stabilit. La Rom faite pour le Desire HD utilise ici sera tire du site de la communaut de XDA Developper, elle est base sur le systme Android 4.0 et sur la ROM CyanogenMod9. Il faut extraire limage du noyau boot.img du dossier compress et, par exemple, la placer dans le rpertoire platform-tools du SDK, on peut alors eectuer la commande suivante :
./flashboot flash boot boot.img

Enn, quatrime et dernire tape, nous redmarrons en mode recovery disponible partir du Hboot. La premire chose faire est de nettoyer le systme en faisant un 33

formatage complet "full wipe" : wipe data, wipe cache, wipe battery stats, wipe dalvik cache... Il faut ensuite monter la carte SD sur notre machine Ubuntu pour copier dessus le dossier .zip complet de la rom custom. Nous pouvons alors utiliser le fonction principale du recovery personnalis : "install zip from sdcard" qui va installer notre rom Android 4.0. Ainsi, nous redmarrons le smartphone normalement et nous pouvons utiliser notre nouvel OS. Important : Les deux avantages principaux de cette manipulation sont premirement dobtenir un systme plus rcent et dobtenir les droits root sur notre device grce notre ROM "roote". Nous allons donc pouvoir par exemple, avec loutil ./adb ou un terminal directement sur smartphone, analyser en tant quadministrateur la partition /data indisponible autrement. Obtenir ce droit ncessite de faire trs attention la source de la ROM Android et aux applications installes qui pourraient alors aussi acqurir ces droits de faon malveillante. 11.2.4 Outils de scurit Android et transition la golocalisation

Nous avons dj introduit lutilisation de loutil ./adb du SDK Android pour accder un shell root et analyser notre systme. Bien que les Applications Android fonctionnent sur une machine virtuelle Java nomme Dalvik, ce systme dexploitation est bas sur un noyau Linux. Nous allons donc utiliser tous les outils basiques tels que cp, ls, nd, ps, top... Nous avons en plus install lapplication "Android Terminal Emulator" permettant dmuler un terminal directement sur le device et de passer en Root avec la commande "su", la ROM demande alors la conrmation de lappropriation des droits (voir Figure 18).

Figure 18 Architecture Android Demande de droits root Ainsi en eectuant la simple commande "ps" puis en la ltrant nous obtenons nos premiers rsultats :
root@android:/ # ps | grep Location app_34 4316 1306 199988 44616 ffffffff 4001146c S com.Google.android.apps.maps:NetworkLocationService app_34 4350 1306 192720 41640 ffffffff 4001146c S com.Google.android.apps.maps:LocationFriendService

Nous avons donc en particulier un processus de localisation gr par lapplication Google Maps. 34

Deux autres outils sont utiles pour ltude du systme Android et notamment pour ltude de la scurit sur Android : [24] logcat : fournit des messages de log en temps rel sur tous les vnements interagissant au sein du systme, la quantit dinformation est donc trs importante dumpsys : fournit des informations sur les services en marche sur le systme Les deux outils peuvent tre utiliss directement sur le smartphone ou bien avec adb (plus ecace dans son utilisation avec lhistorique et la compltion des commandes), nous allons 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 quun service "location" fonctionne, nous pouvons donc faire une recherche sur ce mme chier pour arriver la section "DUMP OF SERVICE location". Le rsultat que nous obtenons est la hauteur de nos attentes, il fournit des donnes prcises de golocalisation. Il est donc temps de plonger au coeur de notre tude sur les donnes de localisation sur Android traite dans la partie suivant ce prambule et qui commencera donc par le dtail du rsultat obtenu par le Dump du service de localisation.

35

12

Etude des donnes de golocalisation sur Android et des changes associs

Dans cette partie nous allons commencer par reprendre le dump du service de localisation fonctionnant sur Android et faire une premire analyse du systme dans son ensemble oriente sur la localisation. Ensuite nous tudierons la localisation utilise avec lapplication Google Maps pour des localisations ponctuelles. Comment les donnes sont-elles stockes ? Quelles informations peut-on rcuprer en mettant en place notre architecture avec le proxy ? Enn, notre projet est parti du fait quApple envoyait durant la nuit et en fond de tche des informations de localisation pour optimiser sa base de donnes et peut-tre tablir des prols pouvant atteindre la vie prive des utilisateurs. Quen est-il du systme de Google et de lanonymat de ses donnes ? Nous ajouterons une section rassemblant quelques observations que nous avons faites lors de lancement dapplications tierces telles que les PagesJaunes, la SNCF, Allocine...

12.1

Premiere analyse systme orient sur la localisation

Reprenons notre chier dumpsys_test.txt pour analyser le dump du service de localisation. Ce dump contient plusieurs sous-sections : - La section Location Listeners : elle donne les dernires demandes de localisations faites par des applications au service de localisation du systme et le rsultat retourn. Dans lexemple suivant, extrait de dumpsys_test.txt nous pouvons voir que lapplication Yahoo ! Weather a eectu une requte de ce type. Remarque : En mettant en place le proxy, on observe que cette application, sans avoir t volontairement lance, eectue rgulirement des requtes silencieuses de localisation.
DUMP OF SERVICE location: /* Section Location Listeners: */ network: //indique la source de localisation: rseau 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.0 mSingleShot=false mUid=10110 mLastFixBroadcast: mProvider=network mTime=1339378558391 //date de la requte mLatitude=45.7770824 mLongitude=4.831412 // coordonnes de golocalisation mHasAltitude=false mAltitude=0.0 mHasSpeed=false mSpeed=0.0 mHasBearing=false mBearing=0.0 mHasAccuracy=true mAccuracy=36.0 //coefficient de prcision mExtras=Bundle[mParcelledData.dataSize=148] mLastStatusBroadcast=0

Il est facile de vrier lemplacement correspondant aux coordonnes de golocalisation en les entrant directement sur maps.Google.fr, le rsultat est extrmement prcis, le lieu indiqu tombe sur le btiment o est situ le point daccs sans-l. - La section Records by Provider : les providers tant "passive" pour la localisation GSM et "network" pour la localisation Wi La section Last Known Locations : comme la source "Android Forensics" lindique, il sagit de la section la plus intressante, elle fournit les dernires localisations obtenues et connues par le smartphone.
Last Known Locations: passive:

36

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

La structure des donnes est la mme que pour les autres sections. Remarque : grce la mme source nous remarquons que le service iphonesubinfo fournit le numro IMEI du Desire HD qui lidentie de manire unique sur les rseaux GSM/UMTS. Continuons notre premire analyse du systme avec quelques commandes simples et qui nous permettra de mieux nous orienter. Nous avons dj une bonne ide des services et processus prsents, passons au systme de chiers (les rsultats non pertinents sont supprims) :
~/android-sdk-linux/platform-tools$ ./adb shell find / -iname "*location*" /system/app/NetworkLocation.apk // correspond lapplication Google de localisation Wifi et 3G. // Elle est lorigine du processus NetworkLocation et est nativement installe dans le systme Android. // Ne pas confondre avec lapplication Google Maps. NetworkLocation nest pas Open Source /system/etc/permissions/android.hardware.location.gps.xml // dclaration des permissions de localisation /system/etc/permissions/com.android.location.provider.xml // /system/framework/com.android.location.provider.jar // les classes disponibles pour les dveloppeurs /data/data/com.Google.android.location // contient les donnes //concernant le service "location" de lapplication 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 lapplication Google Maps /system/etc/permissions/com.Google.android.maps.xml /system/framework/com.Google.android.maps.jar // classes de lAPI Google Maps ~/android-sdk-linux/platform-tools$ ./adb shell find /data -iname "*maps*" /data/data/com.Google.android.apps.maps // donnes utilisateurs pour lapplication 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 sintressant aux problmes de vie prive et de golocalisation[25] indiquent la prsence dun chier "cache.wi" et dun chier "cache.cell" contenant les derniers 50 200 identiants GSM et BSSID rencontrs avec leurs coordonnes gographiques. Ce point parait central dans notre projet, mais nous ne trouvons pas ces deux chiers sur notre systme 4.0. Pour vrier lexistence de ces deux chiers selon la version utilise, nous avons eectu la recherche sur deux autres devices : une tablette HP TouchPad roote avec une ROM CM9 (Android 4.0) : mme rsultat, les chiers ne sont pas prsents. un smartphone ZTE root avec une ROM CM7 (Android 2.3) : les deux chiers sont bien prsents. Les deux chiers sont en binaires, pour les dcoder 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.wifi db version: 1 total: 200 key accuracy 00:1f:9d:20:e3:63 64 fe:b1:5c:fa:fa:cb 80 00:21:d8:df:4c:e0 60 f4:ca:e5:ff:cd:a0 235 f4:ca:e5:ff:cd:a2 80 e0:a1:d7:73:00:50 132 f4:ca:e5:da:78:3d 60 00:18:e7:65:45:f0 59 4c:ac:0a:2f:ee:85 75 00:19:70:33:0f:54 137 f0:f0:02:67:6f:32 171 5c:33:8e:be:42:5a 60 conf. 92 87 92 87 92 92 92 92 87 92 92 92 latitude 48.624980 48.619797 49.261889 48.619586 48.619766 48.619185 48.619119 49.269951 49.269633 49.269819 49.269856 49.269905 longitude 2.442601 2.428877 1.198878 2.428148 2.428685 2.428820 2.428704 1.203300 1.203711 1.203684 1.203368 1.203295 time 01/25/12 02/15/12 04/14/12 06/01/12 06/01/12 06/01/12 06/01/12 06/04/12 06/07/12 06/07/12 06/07/12 06/07/12

15:53:23 08:09:54 12:12:26 07:56:09 07:56:09 07:56:09 07:56:09 00:30:21 07:51:47 07:53:17 07:53:17 07:53:17

+0000 +0000 +0000 +0000 +0000 +0000 +0000 +0000 +0000 +0000 +0000 +0000

/media/Shared_Disk/CoursTSP/3A/PFE$ ./parse.py cache.cell db version: 1 total: 50 key 208:20:20181:1181973 208:20:20171:14242710 208:20:20171:14248920 208:20:20181:1181376 208:20:246:3892 208:20:20371:2431877 208:20:20181:1183478 208:20:20081:13634527 accuracy conf. 75 48.941226 75 48.924856 75 48.911108 75 48.914011 75 48.948599 75 48.945660 75 48.904848 75 48.878982 latitude longitude time 2.260738 06/04/12 15:01:19 +0000 2.256506 06/04/12 17:25:04 +0000 2.267676 06/04/12 17:26:15 +0000 2.250000 06/04/12 17:27:06 +0000 2.032179 06/08/12 08:19:40 +0000 2.148444 06/08/12 08:23:58 +0000 2.229808 06/08/12 08:30:03 +0000 2.322230 06/08/12 09:00:15 +0000

943 703 904 897 2151 1358 919 532

Tous les rsultats ne sont pas achs dans ce rapport, mais nous pouvons donc observer 200 BSSID et 50 identiants dantennes GSM avec leurs coordonnes, la prcision, la date du 25 janvier au 8 Juin 2012. Suite la polmique engendre par la cration de tels chiers sur iOS, Google aurait pu dcider de faire voluer aussi son systme et de stopper ce type de cache ou bien le dissimuler dune autre manire. Voici quelques portions de trajets parmi les 200 positions enregistres sur une map

Figure 19 Carte Google Maps dune partie des BSSID enregistrs

38

12.2
12.2.1

Localisation ponctuelle avec Google Maps

Description de la manipulation

Maintenant que nous avons un bon aperu des services de localisation et de lenvironnement des chiers pour la localisation, analysons lchange eectu entre le smartphone Android et les serveurs de Google pour une localisation avec Google Maps. Contrairement Apple qui renvoie une srie de BSSID au tlphone qui eectue les calculs lui-mme, il est dj connu que Google prfre eectuer le calcul sur ses propres serveurs et renvoyer directement la position gographique. Il convient deacer le cache de Google Maps an dobtenir le plus dinformation possible lors de lchange(touche Menu/Grer les applications/Maps/Eacer les donnes). Adresse IP du Desire HD : 192.168.0.13 Adresse IP du proxy sur machine Ubuntu : 192.168.0.17 Adresse MAC du point daccs sans-l (BSSID) : 00 :1A :2B :57 :71 :76 GPS dsactiv : nous nous concentrons sur la golocalisation rseau car lidentication des BSSID peut permettre lidentication des lieux et des utilisateurs. 12.2.2 Observation des changes sur le proxy

1. paramtrage du proxy sur la connexion wi du smartphone 2. lancement du proxy ./proxy 3. lancement de lapplication Google Maps 4. demande de localisation sur lapplication 5. rsultats : Nous observons tout dabord en faisant un ./adb logcat que lApplication Google Maps fait appel au service de localisation rseau
I/ActivityManager( 1414): Start proc com.Google.android.apps.maps:NetworkLocationService for service com.Google.android.apps.maps/com.Google.android.location.internal.server.NetworkLocationService: pid=5178 uid=10034 gids={3003, 1015}

Puis nous observons les ux sur le proxy

./showp packets.db > echanges_lyon_gmaps.txt

De nombreuses requtes apparaissent, mais un change contenant le nom de notre BSSID "NUMERICABLE_MAP" attire notre attention : Requte en SSL du smartphone au serveur mobilemaps.clients.Google.com/glm/mmap depuis le port 43299
[00000102] 06/02/29,23:33:58,464594 192.168.0.13:43299 74.125.230.192:443 POST mobilemaps.clients.Google.com:443 POST /glm/mmap HTTP/1.1 Content-Type: application/binary Content-Length: 1059 Host: mobilemaps.clients.Google.com Connection: Keep-Alive User-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: 000010: 000020: 000030: 00 61 44 2e 17 6e 65 30 f2 64 73 31 b7 72 69 00 24 6f 72 12 ac 69 65 67 49 64 20 6d 90 3a 48 6d 19 48 44 2d 79 54 00 61 00 43 08 6e 02 2d 36 64 66 61 2e 72 72 63 38 6f 00 65 2e 69 19 2d 31 64 | | | | ....$.I..y..fr.. android:HTC-aceDesire HD..6.8.1 .01..gmm-android

39

000040: 2d 67 6f 6f 000050: 38 10 01 18 000060: 53 59 53 54 000070: 39 30 65 65 000080: 41 41 4d 30 000090: 66 37 2d 6f 0000a0: 4d 48 70 47 /* trame coupe */ 000260: 4a 30 63 4d 000270: 73 44 48 70 000280: 05 12 05 46 000290: 0c 31 33 2e 0002a0: 04 18 07 30 0002b0: f0 a8 d3 06 0002c0: ff ff ff 01 0002d0: e0 e0 fd 26 0002e0: 3a 35 37 3a 0002f0: 49 43 41 42 000300: ff ff ff ff 000310: 6f e1 02 40 000320: 80 d5 00 49 000330: 01 01 6c 00 000340: 18 04 20 01 000350: ef 86 02 18 000360: ff ff ff ff 000370: b6 01 20 10 000380: 01 4a 19 08 000390: 00 40 ff ff 0003a0: 10 ee 86 02 0003b0: ff ff ff ff 0003c0: ce b6 01 20 0003d0: ff 01 4a 19 0003e0: 38 00 40 ff 0003f0: 0f 10 f0 86 000400: ff ff ff ff 000410: 18 cc b6 01 000420: ff ff 01

67 d0 45 31 41 34 73 59 70 20 30 0f 18 10 12 37 4c 01 01 ba 00 28 cd ff 38 0f ff 18 ff 10 08 ff 02 ff 20

6c 01 4d 66 41 62 4d 78 77 53 2e 22 0a 8c 2f 31 45 1a 07 5f 00 01 b6 01 00 10 ff cd ff 38 0f ff 18 ff 10

65 20 9a 32 41 74 31 51 2d 46 31 6e 20 e7 0a 3a 5f 0e 02 00 ec 35 01 4a 40 ef ff b6 01 00 10 ff ce ff 38

3e 01 01 64 44 64 35 61 78 52 36 0a d0 e0 11 37 4d 0a ba 10 0a 00 20 19 ff 86 ff 01 4a 40 f0 ff b6 01 00

00 2a 10 64 6d 53 4c 7a 50 20 38 22 01 e0 30 36 41 0a 80 00 12 00 10 08 ff 02 ff 20 19 ff 86 ff 01 4a 40

00 03 36 a2 78 6f 33 63 67 0a 2e 0a 28 fd 30 12 50 0d d5 00 08 c0 38 0f ff 18 ff 10 08 ff 02 ff 20 19 ff

01 47 66 01 71 5a 49 58 52 28 31 19 ff 26 3a 0f 20 54 00 1d 80 3f 00 10 ff cc ff 38 0f ff 18 ff 10 08 ff

f9 4d 33 a0 68 69 39 6f 34 d0 39 08 ff 12 31 4e b5 1f 49 08 02 4a 40 f0 ff b6 01 00 10 ff cc ff 38 0f ff

0a 4d 37 02 31 4c 68 3a 32 01 32 de ff 38 61 55 ff 49 ba 00 10 19 ff 86 ff 01 4a 40 ef ff b6 01 00 10 ff

03 92 32 44 74 68 39 33 32 3a 18 82 ff 08 3a 4d ff 1b 5f 00 00 08 ff 02 ff 20 19 ff 86 ff 01 4a 40 ee ff

34 01 63 51 4f 55 6d 76 0e 10 02 03 ff 8d 32 45 ff 15 02 1a 10 0f ff 18 ff 10 08 ff 02 ff 20 19 ff 86 ff

38 06 32 41 47 53 57 62 08 12 12 10 ff e7 62 52 ff 8e ba 39 0b 10 ff cd ff 38 0f ff 18 ff 10 08 ff 02 ff

| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | |

-Google>......48 8..... .*.GMM... SYSTEM...6f372c2 90ee1f2dd....DQA AAM0AAADmxqh1tOG f7-o4btdSoZiLhUS MHpGsM15L3I9h9mW J0cMYxQazcXo:3vb sDHppw-xPgR422.. ...F SFR .(..:.. .13.0.168.192... ...0."n."....... ...... ..(...... ..........&.8... ...&./..00:1a:2b :57:71:76..NUMER ICABLE_MAP ..... ..........T.I... o..@.......I._.. ...I._.........9 ..l............. .. .(.5...?J.... ....... .8.@.... ......J......... .. .8.@......... .J........... .8 .@..........J... ........ .8.@... .......J........ ... .8.@........ ..J........... . 8.@..........J.. ......... .8.@.. ........J....... .... .8.@.......

La n de la trame semble tre structure pour dlivrer des donnes, il sagit donc probablement de donnes encodes par le protocole buer. Comme lindique ce lien http: //bigbrothermobile.com/blog/?p=83 qui prsente une manipulation semblable sur la version 2.3, seule une partie de la trame semble tre encode en protocole buer. Grce au programme Blob_Sqlite [27], nous exportons donc le payload de cette trame pour eectuer des tests de lecture dessus. Lexport est un binaire que nous ditons avec lditeur hxadcimal GHex. An de trouver o dbute le protocole buer, nous eectuons la commande :
PFE/blob_echanges_lyon_gmaps$ protoc --decode_raw < ./data_from_packets_42

avec un oset (en octet) de dpart incrment de 1 chaque fois et nous obtenons enn un message cohrent :
0: "5\350\001\000\372\001\215\001\n\203\00160=KDmsrqBI6KgBJ1Tq8kv47QnQrCJcTXz2TE4" 15: "-2MctBlW3Loae9rmdxLRMPGzoc55UQceUsEW8wiObkkT9FnUbcW2h40hECyhZ06JXWG_CxJtwJoipn5vw3qj" 10: 0xe81042624b5f6b56 234292661: "\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: 11 3: 4 4: 1 5: 1

40

6: 0x3fc00000 9 { 1: 15 2: 33647 3: 23373 4: 16 7: 0 8: 18446744073709551615 } /* srie de coordonnes GSM */ 9 { 1: 15 2: 33646 3: 23372 4: 16 7: 0 8: 18446744073709551615 }

Nous pouvons voir que seul un BSSID est transfr avec son adresse IP, il correspond au BSSID auquel nous sommes connects. Grce la mme source notons que lentte de ce message contient des tokens et des identiants qui peuvent se retrouver dans des changes dauthentication au compte Google et qui permettraient dassocier un utilisateur une donne de localisation. Rponse du serveur de Google La rponse faite par le serveur est bien plus longue, lanalyse est plus dicile et ne fait pas apparaitre de structure de donnes pouvant tre analyse avec le protocol buer. Nous pouvons supposer que cette rponse contient des images fournies lapplication Google Maps.
[00000103] 08/13/17,21:38:47,097097 74.125.230.192:443 200 mobilemaps.clients.Google.com:443 HTTP/1.1 200 OK Content-Type: application/binary Content-Length: 2061 Date: Mon, 11 Jun 2012 15:10:11 GMT Expires: Mon, 11 Jun 2012 15:10:11 GMT Cache-Control: private, max-age=0 X-Content-Type-Options: nosniff X-Frame-Options: SAMEORIGIN X-XSS-Protection: 1; mode=block Server: GSE 000000: 000010: 000020: 000030: 000040: 000050: 000060: 000070: 000080: 000090: 0000a0: 0000b0: 0000c0: 0000d0: 00 00 0f 12 95 a7 8c c8 8b 98 5c 0d 7f 79 17 00 10 ce 87 3f 62 aa ad 3f 3d 2f c7 97 3e 07 ef 01 39 d4 72 0a d5 b7 1d 6f ec 7d 00 f9 86 44 15 fe 1e 09 36 94 a7 a7 39 44 00 0a 02 52 de 44 c7 c5 ab 67 3b 23 82 16 00 04 18 41 bf 01 f6 45 24 52 ea ef 7d d0 00 08 cd 54 a7 c1 df 81 29 44 d7 b9 31 33 29 39 b6 00 ba da 0e 04 80 72 43 ed a6 a5 00 10 01 09 90 ef 53 a2 64 8d 08 12 01 be 00 00 20 00 2b 06 59 a3 13 85 3b b2 98 10 00 4a 10 00 69 75 07 8a 88 e1 49 e3 fa 04 02 e4 40 00 43 f0 e3 ee 64 a9 65 33 1a 9f 08 01 de b1 71 5b bf 99 43 68 30 8e f2 77 00 0a 81 0c 46 35 0f 2c cc fa ee 88 e6 5f 07 11 b7 88 c0 7e 0b a2 33 91 1b 62 89 29 6c 08 54 a5 8c df f4 6e 1a b8 fd 28 1c 94 | | | | | | | | | | | | | | 192.168.0.13:43299

..>....).......l .......9..J..... ......... .@...T ...DRAT......... ..9......+iCqF.. .?..D.....u.[5~. .br.....SY...... .....E.......,.n ...6.$).d..dC.3. .?..gRDr....h... \=..;..C.;Ie0... ./o.#......3..b( ...9.}1......... y.}D..3.....w_).

Remarque sur lapplication Navigation : le rpertoire de cache de lapplication MapsNavigation contient les dernires maps utilises avec des chiers audios dictant le dernier itinraire.

41

12.3

Localisation priodique et silencieuse avec www.Google.com/loc/m/api

Tout le travail prcdent sur les fonctions et le codage de donnes de localisation sur le systme de Google va nous permettre dtudier aisment notre objectif nal : des donnes sont-elles transfres la manire dApple pour lunique besoin de Google et non de lutilisateur ? Nous allons aussi essayer de comprendre en cas de transferts de donnes, si celles-ci peuvent tre lies lutilisateur et lidentier. Nous avons donc laiss tourner rgulirement et sur de longues priodes le Desire HD connect au proxy an dobserver son comportement. Il napparait pas que des bases de donnes comme celles dApple ou bien de longs chiers tels que cache.wi ou cache.cell soient changs avec les serveurs de Google mais nous observons sans dicult des changes "silencieux", priodiques et aussi eectus lorsque nous sortons le smartphone de veille, avec le serveur de Google : www.Google.com/loc/m/ api. La trame qui est envoye rgulirement est assez lgre, voici ce que nous rcuprons auprs du proxy :
[00000102] 06/23/68,10:28:02,872203 192.168.0.13:49375 POST www.Google.com:443 POST /loc/m/api HTTP/1.1 Content-Type: application/binary Content-Length: 511 Host: www.Google.com Connection: Keep-Alive User-Agent: GoogleMobile/1.0 (ace IMM76D); gzip 000000: 000010: 000020: 000030: 000040: 000050: 000060: 000070: 000080: 000090: 0000a0: 0000b0: 0000c0: 0000d0: 0000e0: 0000f0: 000100: 000110: 000120: 000130: 000140: 000150: 000160: 000170: 000180: 000190: 0001a0: 0001b0: 0001c0: 0001d0: 0001e0: 0001f0: 00 31 6e 00 75 52 00 72 af d0 b4 ad 4d f0 e3 86 5c d4 d7 35 42 10 88 a5 34 80 02 58 b3 10 2d ec 02 36 5f 01 6c 4f 00 4c 4c 33 2a 2c 4f f0 60 89 0a ce 35 38 f2 0a bb d9 fd d2 aa 8a d8 72 c7 74 00 2c 55 c9 00 4f 00 cc cc d2 2d 96 ae f0 15 4b 17 c4 c8 44 40 5e ab f2 30 a4 e3 66 98 80 0c 0b 00 61 53 00 00 54 00 4b ce f7 4e 52 cc ce 62 9a 18 71 d3 61 c5 ec 63 8b 93 9c f1 18 38 4d 4f 45 1f 6e bb 01 00 00 00 29 2a 74 2d 36 73 2b 75 4b 1d f2 d9 cf 9c f8 90 12 90 cc c9 33 98 64 94 00 6c 64 bd 01 04 00 00 ca d5 f6 d2 b2 a9 29 53 88 54 f7 d1 7f 7e ba c2 f3 1a 64 2c d8 94 e4 e0 0c 6f 72 ec 00 50 00 e3 cf cf 31 2f ca b0 2c 08 e3 02 0d c9 28 ae e6 62 d2 50 85 4b 2c 76 58 5a 8b 63 6f ea 01 4f 01 6a 4c 4d 35 4a af f2 d7 76 5e 58 10 c7 60 a1 22 84 53 9a f9 4d 01 30 72 81 ef 61 69 b0 00 53 a1 65 d1 4c 76 cd 08 f6 62 0b 13 05 4b 55 74 6e 8b f4 15 1f 48 ca 24 72 ef 37 13 74 64 39 08 54 00 e4 4f 2f d3 49 08 ca 4d 52 b3 da 9b d7 f8 f1 90 83 96 e4 ea af 7f c9 2f b8 74 69 2c 06 67 6d 01 62 cf 2d 37 4d 34 2d 2b e0 40 1b 8b dc f6 a6 2c fb 20 87 40 d0 41 72 88 56 02 6f 67 e9 3a 72 67 31 cf ca 32 2c 8f 2b 8a d2 db 6e 41 d5 e8 ce 50 ed 64 f0 96 4d bc 89 85 a0 00 6e 6d 00 6c 00 1f 34 4f b7 36 4e 2f 0f 77 b8 e3 6e 48 d8 ee 66 01 97 5f 4c 1c 33 b4 a0 69 59 00 2c 6d 01 6f 00 8b 34 cf 32 35 d5 cd 4a 0b c0 cb fb d4 31 ad 26 bb 1f de b7 31 b2 17 06 f9 72 00 31 2c 67 63 00 08 34 49 d1 34 cd 2a 29 32 a8 6c ab 2f 3e 45 0a 9f 31 fc 4c 11 30 dd 97 32 98 00 31 65 00 2f 04 00 13 d5 33 b7 4e 73 a9 e2 b4 12 26 d4 c4 cc 0b 6b 83 d5 85 52 51 4b 86 22 09 | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 74.125.230.242:443

.....location,11 16,android,gmm,e n_US.....9....g. ..........g:loc/ ul....POSTmr.... ROOT.......g.... .......je.b1444. rL.K)..L.O..O.I. .L..*..ML/-..2.3 .3..t.15v.72654. .*-N-./J.IM,N..N .,.R6.....4./.*s MO..s.....-+.J). ....+),.bM+.w.2. ..buS.v.R...... ..K.K..^..@...l. \....T.X...nn..& ...q....K..AH./. .5......U....1>. 58Da..(t.....E. B.@..~..n...f&.. ..^...."..,P...k ...c..b.......1. .......S.. d_... 4.0...P.....L.L. .....d..H.@..1.R .....,KM...M3.0Q X.f.3.,.$.A....K ...8..v0r.r..... .r.Md.Xr./..i.2" -..O..Z.7.V.Yr.. .t.E.....t.....

Nous ne pouvons distinguer de structure de donnes au premier abord, cependant lentte indique que le payload a t compress (gzip). De la mme manire que pour lanalyse sur Google Maps, nous exportons cette trame laide de loutil Blob_Sqlite an dobtenir un binaire du contenu de la trame. Une 42

recherche rapide nous indique en plus que le format gzip dbute par les octets 0x 1F 8B. laide de GHex, nous ditons donc le chier en hexadcimal an de le faire dbuter cet endroit. Il ne reste plus qu renommer le chier avec une extension .gz et utiliser gzip :
$mv trame_analysee trame_analysee.gz $gzip -d trame_analysee.gz

En ouvrant directement ce chier binaire dcompress avec un diteur de texte, on constate la prsence structure de noms de points daccs, il est donc fort probable que les informations aient t envoyes avec le protocole buer. Utilisons le script pour le dcoder : En commentaire // lanalyse des tags importants
$ protoc --decode_raw < ./data_from_packets_26 1 { 1: "1116" 2: "android/Google/yakju/maguro:4.0.2/ICL53F/235179:user/release-keys" 3: "2:oxPQ7_ujvEgcynDx:KJmvwRdtxHHKntqw" // cl dauthentification de lutilisateur qui fait le lien avec une session gmail 5: "fr_FR" 6 { // Structure de donnes concernant le rseau GSM auquel appartient le tlphone 1: 5 2: "F SFR" 4: 10 5: 208 } } 4 { 1 { 1 { // Strucutre de donnes concernant une antenne GSM/UMTS porte 1: 49502 // Location Area Code 2: 13955462 // Cell ID 3: 10 // Mobile Network Code: SFR 4: 208 // Mobile Country Code : France 8: 36 // Coefficient de prcision 10: 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 dclar en hexadcimal 2: "NUMERICABLE-7E3A_TEST" // Nom du point daccs 4: 18446744073709551548 // Coefficient de puissance du signal reu 8: 112396300662 // Conversion dcimale du BSSID normalement en hexadcimal --> 1A2B577176 --> 00:1A:2B:57:71:76 } 2 { //Mme analyse pour le reste des BSSID 1: "" 2: "NEUF_5C64" 4: 18446744073709551520 8: 159276424296 // 00:25:15:9D:5C:68 } 2 { 1: "" 2: "NETGEAR" 4: 18446744073709551523 8: 129560080352 // 00:1E:2A:61:EF:E0 } 2 { 1: "" 2: "orange" 4: 18446744073709551524 8: 11104375713001 } 2 { 1: "" 2: "SFR WiFi Public"

43

4: 18446744073709551519 8: 231056718257257 } 2 { 1: 2: 4: 8: } 2 { 1: 2: 4: 8: } }

"" "Livebox-f284" 18446744073709551525 109259435241

"" "NUMERICABLE_TEST" 18446744073709551549 112396300662

Nous remarquons alors que ce sont tous les BSSID porte du smartphone linstant o est envoye cette trame. Connaitre tous ces BSSID avec le coecient de puissance permet sans aucun doute Google dtablir une cartographie "rseau" trs complte, mais aussi de savoir o est localis lutilisateur chaque instant t=timestamp. En eet, nous retrouvons en dbut de trame, comme pour lapplication Google Maps (#2 :MpXoJ0cMYxQazcXo :3vbsDHppw-xPgR), une cl "2 :oxPQ7_ujvEgcynDx :KJmvwRdtxHHKntqw" qui pourrait identier un compte gmail associ au smartphone Android. Lanonymat parait donc fortement compromis.

44

Cinquime partie

Vie prive et proposition de solutions

Nous allons nir cette tude par les moyens pour un utilisateur de protger sa vie prive des problmes de condentialit que nous avons pu apercevoir dans les parties prcdentes.

13

Rglages appropris du smartphone

La premire manire de protger sa vie prive peut sembler vidente, mais nest pas forcment si vidente mettre en oeuvre. En eet, rgler de faon approprie son smartphone permet de limiter une grande partie des changes de golocalisation entre le smartphone et un serveur distant. Mais, devant la multitude de paramtres de conguration dun smartphone, il nest pas toujours vident de trouver les rglages eectuer.

13.1

Rglages sur un iPhone

Le premier rglage eectuer pour protger sa vie prive est de dsactiver les envois de "Diagnostic et utilisation". Pour cela, aller dans lapplication Rglages -> Gnral -> Informations -> Diagnostic et utilisation -> Ne pas envoyer (voir Figure 20). On saperoit tout de suite du nombre de sous-menus pour trouver ce paramtre. En cas de mauvais paramtrage au premier dmarrage de lappareil, il est presque impossible quun utilisateur tombe par hasard sur ce rglage. Ce rglage supprime lintgralit des envois nocturnes de liPhone aux serveurs dApple (envois de BSSID et dantennes GSM) ainsi que dautres statistiques dutilisation du tlphone.

Figure 20 Dsactiver lenvoi des donnes diagnostic Services de localisation Le deuxime paramtrage important concernant les envois de donnes de golocalisation se situe dans Rglages -> Service de localisation (voir Figure 20). Il y a ici deux choix possibles, dsactiver compltement les services de localisation sur liPhone. Ainsi, il ny aura plus aucun envoi Apple, mais cette solution ne permet plus dutiliser aucun moyen de golocalisation ni le GPS. La deuxime chose possible est plus intressante, il y est

45

possible de limiter les applications qui peuvent avoir accs aux donnes de localisation. Ainsi, si une application nest pas autorise avoir ces donnes de localisation, elle ne pourra jamais connatre la position du tlphone. Il est prfrable de limiter les applications autorises avoir les donnes de localisation aux applications qui en ont vraiment lutilit. Dans les paramtrages de liPhone, il nest cependant pas possible dinterdire les changes avec le serveur https://gs-loc.apple.com en limitant la golocalisation la golocalisation GPS. Il faudra donc trouver une autre technique pour ceux qui ne dsirent pas quun serveur distant sache quand on est chez soi ou non.

13.2

Rglages sur Android

Nous retrouvons des paramtres similaires sur Android. Dans les menus Paramtres > Services de Localisations (voir Figure 21). Il est possible dactiver ou de dsactiver la localisation rseau ainsi que la localisation GPS. Attention, ces rglages ont un impact sur toutes les applications du tlphone ncessitant 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 dcochant loption "Localisation et Recherche" visant, comme il est indiqu, "amliorer vos rsultats de recherche et autres services de Google". Pour mieux protger sa vie prive, il est essentiel de faire attention, lors du tlchargement dune application, tous les services systme auxquels vont faire appel ces applications (voir Figure 21) an de reprer les appels systmes abusifs (contact du tlphone, data, localisation non ncessaire au fonctionnement...)

14

Filtrage

Nous allons dans cette partie dcrire une autre technique permettant de protger plus ecacement sa vie prive. Cette technique consiste ltrer sur le rewall/point daccs 46

tous les paquets destination dune adresse prcise. Par exemple https://gs-loc.apple.com pour Apple et https://mobilemaps.clients.Google.com pour Google. Ce ltrage peut tre eectu par exemple avec les commandes iptables suivantes :
iptables -A OUTPUT -d gs-loc.apple.com -p tcp --dport 443 -j DROP iptables -A OUTPUT -d mobilemaps.clients.Google.com -p tcp --dport 443 -j DROP

Avec ce ltrage, on supprime donc lintgralit des ux de localisation changs entre le smartphone et le serveur distant, mais on perd aussi forcment ses avantages : la golocalisation en Wi-Fi nest plus possible.

15

Solutions logicielles

Pour remdier aux problmes de vie prive causs par les services de golocalisation sur smartphone sans perdre les avantages de ce type de golocalisation qui est trs ecace en intrieur et en ville, il faut dvelopper des solutions logicielles, permettant de ltrer les informations trop personnelles et laisser passer assez dinformations pour pouvoir utiliser cette golocalisation. Nous allons voquer direntes possibilits dans cette partie, mais seule la premire sera dveloppe, 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 (appartenant soit Google soit Apple) et de rediriger tous les ux permettant la golocalisation venant du tlphone sur le serveur copie (sur lequel on est donc sr quil ny a aucun traage). Bien sr, il faudra rcuprer une copie de la base de donnes de BSSID avec leurs coordonnes prsentes sur le serveur dApple. Pour cela, quand un BSSID ne sera pas dans la base de donnes, il sura de le rcuprer sur la base de donnes dApple, puis ensuite de lajouter une base de donnes locale. Le serveur copie dApple sera hberg sur lordinateur du rseau local. Sur le serveur web Apache install sur ce poste, il est congur un VirtualHost permettant au serveur de se reconnatre sous le nom dhte "gs-loc.apple.com", permettant dactiver ssl et avec ScriptAlias permettant dactiver lexcution de scripts cgi :
<VirtualHost *:443> DocumentRoot "/home/sites/test/" ServerName gs-loc.apple.com SSLEngine on SSLCertificateFile /Applications/MAMP/conf/ssl/server.crt SSLCertificateKeyFile /Applications/MAMP/conf/ssl/server.key ScriptAlias /clls/ /home/sites/test/cgi/clls/ </VirtualHost>

Le script permettant de retourner les BSSID et leur cordonnes au tlphone sera un script python excut via CGI (une interface permettant dexcuter des scripts sur un serveur web). Cela permet de retourner un rsultat dynamique tout en tant crit dans le langage python qui permet dutiliser les Protocol Buers. La page appele sur le serveur dApple est la page "clls/wloc". Elle aura donc la mme adresse sur le serveur copie. Le script python sexcutant quand la page wloc est appele peut tre trouv en Annexe E.1. Nous allons en expliquer les grandes lignes. La premire tape est de lire les donnes envoyes par le smartphone pour trouver le BSSID localiser. Si ce BSSID est dans la base de donnes (stocke en sqlite dans notre script) du serveur copie, alors, on prend 200 BSSID (le nombre gnralement envoy par Apple en zone Wi-Fi dense) de latitude et longitude proche (50 de longitude et latitude 47

croissante et dcroissante). On les encode en protocol buer et les envoie au tlphone. Si le BSSID nest pas dans la base de donnes, on en fait la demande Apple, stocke tous les BSSID renvoys dans la base de donnes et envoie la rponse au tlphone. Ce script nest bien sr pas optimis, mais permet assez simplement de limiter les requtes eectues vers le serveur dApple. La dernire tape pour faire fonctionner ce script est dactiver une redirection NAT des paquets vers https://gs-loc.apple.com vers lordinateur 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 tlphone le certicat gnr sur lordinateur pour le serveur https avec comme nom "*.Apple.com". Pour tester ce serveur, nous avons aussi utilis un script qui peut tre trouv en Annexe E.2 permettant deectuer la mme requte sur le serveur copie et sur le serveur dApple an de comparer ensuite les rponses et voir si celles-ci sont cohrentes. Remarque : Cette technique est videmment possible uniquement dans un endroit o on contrle le rseau, par exemple chez soi. Cela pourrait poser un problme, car ce nest pas le cas la plupart du temps. Cependant, en dehors de chez soi, Apple ne dispose pas dassez dinformations pour identier une personne. Cette solution permet donc de limiter ecacement la possibilit de traabilit depuis les serveurs dApple sans perdre les avantages de la localisation en intrieur et sans avoir besoin de jailbreaker son tlphone.

15.2

Autres solutions envisages

Il y a plusieurs autres solutions logicielles que nous avons envisages pour se protger des envois eectus par les smartphones vers les serveurs distants : Envoyer des informations fausses : la premire est de mettre en place un ltrage qui modie les informations permettant au service distant didentier lutilisateur (par exemple avec les serveurs dAndroid, supprimer ou modier la cl identiant le compte gmail). Ainsi, il serait toujours possible de proter du service, sans donner ses informations personnelles. Il faudrait bien sr vrier que le serveur distant accepte de recevoir des informations fausses. Rduire la taille de la liste envoye : Sil nest pas possible denvoyer des informations fausses au serveur, il est peut-tre possible de rduire les informations envoyes (envoyer par exemple un BSSID un peu plus lointain et toujours le mme) pour que le serveur ne soit plus en mesure de golocaliser prcisment le tlphone. Excuter un programme sur le tlphone : En utilisant un tlphone root sous Android ou jailbreak pour les iPhones, il est possible dexcuter un programme personnalis en tche de fond. Il est ainsi possible de dvelopper un programme qui eectue le ltrage des donnes envoyes depuis le tlphone ce qui permet de pouvoir faire le ltrage en permanence. Nous avons en eet observ lors des changes sur Android avec des applications telles que Allocin des informations sensibles passer tel que le numro de tlphone. Cette solution serait possible mettre en place en partant du projet TaintDroid [28] disponible avec une dmonstration sur le lien http://appanalysis.org/demo/index.html. Dans cette dmonstration, lutilisateur est alert que son IMEI est transfr alors lapplication lance nen aucunement besoin.

48

Conclusion

Cette tude nous a permis de nous plonger au coeur des informations changes entre un smartphone et les serveurs dApple et de Google. Nous avons ainsi pu nous rendre compte de la quantit trs consquente de donnes qui sont envoyes depuis les smartphones sur ces serveurs et qui peuvent contenir des informations personnelles, identiant lutilisateur sans que celui-ci nen soit rellement conscient.

Nous soulignons ici limportance du rle du certicat et de la chane de certication dans les changes SSL pour garantir lauthentication des entits concernes pour viter lattaque du Man-in-the-Middle.

Travailler sur ce projet nous a permis dapprhender de nouvelles comptences techniques, dans la manipulation du Python, du Protocol Buer, du proxy et du systme dexploitation des smartphones iOS / Android.

Lvolution du projet nous a fait modier notre plan de dpart. En eet, nous navons pas pu dvelopper la partie sur les scnarios dattaques comme nous le voulions. En contrepartie, nous avons analyser au maximum les donnes changes sur les deux systmes et proposer des solutions pour garantir une meilleure protection de la vie prive.

Nous esprons que ce rapport participera aussi une certaine sensibilisation des utilisateurs comprendre limpact que peut avoir une mauvaise gestion de son magasin de certicat et de ses navigateurs. De mme, il faut rester conscient que des applications anodines peuvent rcuprer sur leur serveur des informations personnelles.

Enn, ce rapport pourrait constituer une aide ceux qui souhaitent se lancer dans ltude de lchange de donnes encodes en Protocol Buer, commencer manipuler le systme Android/iOS et avoir une vue densemble sur la golocalisation.

49

Annexes
A Certicat AC racine du proxy

Figure 22 Dtails du certicat de lAC racine du proxy

50

B
B.1

Protocol Buer
Tableau des wire type
Signication Varint 64-bit Length-delimited Start group End group 32-bit Utilis pour les types int32, int64, uint32, uint64, sint32, sint64, bool, enum xed64, sxed64, double string, bytes, embedded messages, packed repeated elds groups (deprecated) groups (deprecated) xed32, sxed32, oat

Type 0 1 2 3 4 5

Table 2 Tableau des wire type [29]

C
C.1

Dcodage des donnes interceptes lors de la localisation dun iPhone

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 . bssid print "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 . bssid i 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 H M T L print("\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 H M T L liste_wifi_depuis_apple.ParseFromString(contenu_fichier[89:]) ListWifiDepuisApple(liste_wifi_depuis_apple) generateKML(liste_wifi_depuis_apple,"./bssid.kml")

D
D.1

Dcodage des donnes dutilisations envoye par un iPhone Apple

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 dantennes GSM

message GSMMeasurement { optional int64 M C= 1; C optional int64 M C= 2; N 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 = optional fixed32 valeur_inconnue4 = optional fixed32 valeur_inconnue5 = optional fixed32 valeur_inconnue6 = 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; }

3; 4; 5; 6;

D.3
import import import import

Script python
BSSIDNocturne_pb2 GSMNocturne_pb2 os datetime

def ListWifiNocturne(wifi_list) : for wifi in wifi_list . wifi : print "Wifi BSSID : ", wifi . bssid print "channel : ", wifi .channel print "signal_strength : ", wifi .signal_strength i f wifi .HasField(location) : print "latitude : ", wifi . location . latitude print "longitude : ", wifi . location .longitude print "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.M C C print "MNC : ", gsm.M C N print "LAC : ", gsm.LAC print "CellID : ", gsm. cellID print "Attenuation : ", gsm.attenuation i f gsm.HasField(location) : print "Latitude : ", gsm. location . latitude print "Longitude : ", gsm. location .longitude print "Timestamp : ", gsm. location .timestamp , " --> " , datetime.datetime.fromtimestamp(int(gsm. location .timestamp)) . strftime(%d/%m %H:%M:%S) print "APIName : ", gsm.APIName print "Operateur : ", gsm.operateur print " ------ " liste_gsm = GSMNocturne_pb2.BlockGSMNocturne() fichier = open("./data_from_packets_gsm.dat","r") contenu_fichier = fichier .read() ; print(contenu_fichier[:313]) # en tetes H M T L print("\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 H M T L

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
E.1

Serveur copie dApple

Script python wloc

#!/usr/bin/python import BSSIDApple_pb2 import datetime from struct import pack import binascii import sys import cgi , cgitb import urllib2 import sqlite3 def EnregistreBSSIDDepuisApple(wifi_list ,conn) : i =0 c = conn.cursor() c.execute( C E T A L IF N T EXISTS bssid (bssid text P I A YKEY latitude float , longitude float , R A ET B E O RM R , valeur_inconnue3 integer , valeur_inconnue5 integer , valeur_inconnue6 integer , valeur_inconnue11 integer , 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 +1 conn.commit() def demandeCoordonnees(bssid) : #Interroge la base de donnees dApple pour y prendre les coordonees des 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 = bssid liste_wifi .valeur_inconnue1 = 0 liste_wifi .valeur_inconnue2 = 0 liste_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 : # a pas trouve le bssid en base de donnees = on liste_bssid = demandeCoordonnees(bssid) EnregistreBSSIDDepuisApple(liste_bssid ,conn) else : liste_bssid = BSSIDApple_pb2.BlockBSSIDApple() wifi = liste_bssid . wifi .add() wifi . bssid = bssid wifi . 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] # prends les 50+50+50+50 bssid plus proches dans une direction donnee On for 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 latitude ASC 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 longitude ASC 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 longitude 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] 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 reponse content = "\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:]) + PB sys .stdout.write(content) # On envoit le resultat au telephone

E.2
import import import import

Script de test du serveur

urllib urllib2 BSSIDApple_pb2 sqlite3

def ListWifiDepuisApple(wifi_list) : for wifi in wifi_list . wifi : print "Wifi BSSID : ", wifi . bssid i 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_inconnue1 i f wifi_list .HasField(valeur_inconnue2) : print "Inconnu2 : ", "%X" %wifi_list .valeur_inconnue2 i 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 = bssid liste_wifi .valeur_inconnue1 = 0 liste_wifi .valeur_inconnue2 = 0 liste_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 = bssid liste_wifi .valeur_inconnue1 = 0 liste_wifi .valeur_inconnue2 = 0 liste_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

Rfrences
[1] Alain Pannetrat. Analyser la golocalisation sur iphone grce un proxy de dchirement ssl. MISC, jan 2012. Article sur les interceptions de donnes de golocalisation qui nous a donn lide de notre projet. [2] Frdric GRAPPE. Le systme GPS. http://www.fredericgrappe.com/enseignement/ entrainement/GPS.pdf. [3] Quest-ce que la trilatration ? http://eu.mio.com/fr_be/global-positioning-system_ 4991.htm. [4] Skyhook. http://www.skyhookwireless.com/. Base de donnes propritaire recensant les points daccs wi ainsi que leurs coordonnes. [5] OpenCellID. http://www.opencellid.org/. Base de donnes libre des antennes GSM avec leurs coordonnes. [6] Android developers : Obtaining User Location. http://developer.android.com/guide/ topics/location/obtaining-user-location.html. Documentation Android sur le calcul de la golocalisation. [7] Securing Sockets with OpenSSL. 22078. http://www.informit.com/articles/article.aspx?p=

[8] Maryline Laurent. Authentication, VPN, Chirement. http://www.informit.com/ articles/article.aspx?p=22078, Jun 2012. [9] Google. Utilisation de certicats scuriss. 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 Buers. https://developers.google.com/protocol-buers/. [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] Tlchargement 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 fragmentation.php. [21] Android Debug Bridge. html. Visualized. http://opensignalmaps.com/reports/

[20] CyanogenMod. http://www.cyanogenmod.com/. http://developer.android.com/guide/developing/tools/adb.

[22] Partitions principales Android. http://wiki.cyanogenmod.com/wiki/Fastboot. [23] Dvrouiller 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 dextraire facilement les donnes binaires (BLOB) dune base de donnes sqlite sous forme de chiers spars. [28] TaintDroid. http://appanalysis.org/index.html. [29] Tableau des wire type des protocol buers. protocol-buers/docs/encoding#structure. https://developers.google.com/

Table des gures

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 Trilatration [3] . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Calcul de la localisation sous Android [6] . . . . . . . . . . . . . . . . . . . . Organisation du protocole SSL [8] . . . . . . . . . . . . . . . . . . . . . . . Magasin de certication Android . . . . . . . . . . . . . . . . . . . . . . . . Architecture de base . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Proxy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Ajout dun certicat sous iPhone et Android . . . . . . . . . . . . . . . . . changes lors de ltablissement dune connexion SSL via un proxy SSL (congur sur le client) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Tentative dtablissement dune connexion via un proxy HTTPS transparent Interprtation dune unit de donne o la cl fait 1 octet . . . . . . . . . . Achage des BSSID et de la position exacte sur une carte Google Maps . . Envoi nocturne ach sur une carte Google Earth . . . . . . . . . . . . . . Envoi nocturne ach sur une carte Google Earth . . . . . . . . . . . . . . Android Virtual Device Manager . . . . . . . . . . . . . . . . . . . . . . . . Connexions dun Android virtuel . . . . . . . . . . . . . . . . . . . . . . . . Android x86 sur VirtualBox . . . . . . . . . . . . . . . . . . . . . . . . . . . Fastboot . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . Architecture Android Demande de droits root . . . . . . . . . . . . . . . . Carte Google Maps dune partie des BSSID enregistrs . . . . . . . . . . . . Dsactiver lenvoi des donnes diagnostic Services de localisation . . . . . Services de localisation et Autorisation des applications sur Android . . . . Dtails du certicat de lAC racine du proxy . . . . . . . . . . . . . . . . . . 4 6 10 11 13 14 15 16 17 20 24 26 28 29 30 30 33 34 38 45 46 50

Liste des tableaux

1 2 Comparaison des direntes techniques de golocalisation . . . . . . . . . . 6 Tableau des wire type [29] . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51

59