Luận văn thạc sĩ VNU agrégation fiable de données d’activité sur l’internet préservant l’anonymat

Introduction

Problématique

Sur l‟Internet aujourd‟hui, nous avons beaucoup d‟activités Dans le cadre de notre projet, les activités sur l’Internet peuvent être définies comme les visites des sites Web, les soumissions des requêtes sur un moteur de recherche

Si nous pouvons agrộger ces activitộs et les stocker de faỗon efficace pour traiter et exploiter, cela donnera des résultats intéressants pour les utilisateurs Il s‟agit d‟une notion de suivi de l’activité sur l’internet , cela veut dire intercepter l‟activité effectuée par des groupes d‟utilisateurs et l‟agréger en une activité moyenne Par exemple, pour le cas des visites de sites web, cela revient à calculer le nombre moyen de visites reỗues par un site au cours du temps

Figure 1: Exemples d’activités sur l’Internet

En observant les exemples ci-dessus, nous trouvons qu‟il y a quelques grandes questions posées:

?) Les différentes données agrégées fournies (e.g fréquences de visites ou votes) sont-elle fiables ?

?) L‟anonymat des contributions individuelles est-il préservé ?

Notre recherche sert à résoudre complètement ce problème La solution efficace de ce problème est très importante car si l‟on peut avoir confiance en ces données, à partir de cela, on peut construire un grand nombre des systèmes (en particulier, des applications) de types différents qui rendre des choses très utiles pour les grands publiques sur l‟Internet

Un autre aspect difficile du problème est que ces systèmes de suivi doivent être acceptables pour les utilisateurs Pour cela, l‟activité de suivi doit essentiellement :

Préserver l'anonymat (i.e qu'il ne soit pas possible de reconstruire les activités individuelles à partir des informations échangees et stockées dans le système)

Donner des résultats raisonnablement fiables, en particulier qu'il ne soit pas trop facile de biaiser les résultats produits en générant artificellement de l'activité (par exemple en visitant un site que l'on veut favoriser plusieurs fois) L'idee dans le projet pour éviter de telles manipulations est d'utiliser la notion d'authentification, permettant de garantir qu'une activité n'est prise en compte qu'une seule fois par utilisateur

Un exemple simple de ces systèmes est de traiter ces données brutes et de les visualiser (sur une carte) A la fin de mon projet du stage, j‟ai implémenté un tel système qui accumule tous les “votes” (une nouvelle conception sera définie dans deuxième chapitre) des utilisateurs sur l‟Internet et les visualise dans une carte du monde (Google Maps)

D‟autre type de système sera prochainement implémenté à partir de ces données est un système de recommandation (un tel système sera effectué à l‟EPFL par Tran Huu Duc) En basant sur les fréquences séparées de sites web visties ou les fréquences des co-occurence des sites web visités (visité pendant une période donnée), ce système donne aux utilisateurs des suggestions intéressantes et utiles.

Etat de l‟art

Il existe maintenant des systèmes de presque même fonctionnalité que nous espérons, parmi entre eux on peut citer comme Tor or FreeNet Ces deux systèmes nous permettent de

Site Web officiel du projet : http://www.torproject.org/index.html.fr

FreeNet est un autre projet dans ce domain dont l‟idée est de contruire un réseau informatique anonyme et décentralisé sur l‟internet Il vise à permettre une liberté d‟expression et d‟information totale fondée sur la sécurité de l‟anonymat, et permet donc à chacun de lire comme de publier du contenu Il offre la plupart des services actuels d‟internet (courriel, téléchargement, web, etc.)

Site Web officiel du projet : http://freenetproject.org/index.html

Mais notre but dans le projet DistriNet est différent que celui de Tor et de FreeNet Notre but essentiel est de rendre grands publiques des données agrégées sur l’activité sur l’Internet en tout garantissant des caractéristiques:

La capacitộ de raisonner de faỗon fiable à partir de ces donnộes agrộgộes Autrement dit, le système doit garantir le non manipulabilité

L‟anonymat des contributions individuelles utilisées pour produire les données agrégées.

Context

Dans le cadre du projet DistriNet, on cherche à résoudre plusieurs questions différentes posées comme abordé ci-dessus et à construire un système réel sur l‟Internet Il s‟agit d‟un très grand projet à long terme et besoin beaucoup de contributions de toute l‟équipe Après des discussions sérieuses avec mon supervieur Nous nous concentrons d‟abord sur deux grands points: préservation de l’anonimat et non manipulabilité Ce sont deux points cruciaux et difficiles à résoudre et sont aussi mon sujet de stage

Ce projet est effectué en collabaration entre l‟Ecole Polytechnique Fédérale de Lausanne – EPFL et les partenaires de l‟Université de Neuchatel et de l‟ISTI Pisa

Je travaille plein temps dans laboratoire LIA (Artificial Intelligence Laboratory) à l‟EPFL

C‟est une de deux grandes écoles polytechniques prestigieuses de la Suisse Ca me donne un environnement de travail très sérieux et du niveau international.

Objectives du projet DistriNet

Nous allons construire un système ayant les caratéristiques comme suivant :

1 Permettant de produire des données agrégées d’activité sur l’Internet librement accessibles (système ouvert)

C‟est parce que la plupart des systèmes existants aujourd‟hui n‟est pas gratuite et assez fermée pour les grands publiques Grâce à ce système ouvert, tout le monde

DistriNet 2009 peut construire pour soi-même des applications libre qui exploitent les données agrégées et servent aux différents buts

2 Garantissant l’anonymat des contributions individuelles

Cette caractéristique est pour but de garantir que personne hors d‟utilisateur puisse savoir ces contributions individuelles ce qui, quelques fois est trop importants dans certains systèmes statistiques informatiques

3 Garantissant une fiabilité raisonnable pour les données agrégées fournies

Cette caractéristique nous permet de traiter les données pour extraire les informations nécessaires dans les différents buts

4 Stockant les données dans un réseau P2P (pas de serveur centralisé nécessaire)

Nous choisissons le réseau P2P pour stocker les données agrégées parce que deux raisons principales

Premièrement, nous voulons que toutes les données soient distribuées dans tout le réseau et tous les pairs dans le réseau jouent le même rôle que les autres Autrement dit, aucun pair peut contrôler soi-même tout ou bien la plupart des données agrégées dans le réseau

Deuxiốmement, ces donnộes stockộes sont ộnormes, si elles sont stockộes de faỗon centralisée, nous deviendrons résoudre au problème du cỏt de la resource (la resource matérielle demandée)

5 Permettant le développement d’applications utiles exploitant les données disponibles (par exemple des applications de visualisation)

Notre système est ouvert, c‟est la raison pour laquelle que le système doit permettre aux gens (les développeurs) d‟exploiter les données pour sa diversité de buts.

Présenter précisément mon sujet de stage

Comme abordé tout d‟abord, dans mon cas, je dois résoudre deux problèmes principaux: l'anonymat et non-manipulabilité Pour chaque problème, je dois chercher les techniques disponibles ainsi que concevoir les techniques spéciales pour atteindre les buts posés

Pour comprendre exactement ce que je dois faire, je les définis comme suivant:

Préservation de l’anonymat des contributions individuelles:

Le mécanisme de construction des données agrégées ne doit pas permettre de reconstruire l‟identité des utilisateurs fournissant les données indiviuelles

Dans la partie “Test & Résultats” je vais prouver ces points en utilisant et en expliquant que mon système fonctionne correctement comme ces définitions

Solution

Métaphore du vote

Théoriquement, un vote de notre sens est défini comme:

Les contributions individuelles sont modélisées comme des votes

La procédure d’agrégation est modélisée comme une votation (système de vote)

On utilise une image de vote normal existe dans la vie courante pour facilement comprendre les conceptions utilisées dans ce projet Un vote, en général, c‟est-à-dire une activité sur l‟internet comme un utilisateur appuie sur un lien d‟Internet, compléter un sondage ou bien soumettre une requête de recherche avec des mots-clés sur une machine de recherche

On peut imaginer une activité mentionnée comme un vote dans la vie courante (après ceci, appellé “vote”) Ici, nous vous donnons une comparaison étape par étape les correspondances entre un vote dans la vie courante et un vote dans notre sens: (3 étapes) Mais il faut d‟abord comprendre les concepts essentiels utilisés dans le système:

Vote : recensement d‟une activité d‟un utilisateur sur l‟Internet (ex : la visite d‟un site web, le click sur un lien URL après une recherche); on s‟intéresse prioritairement à des activités pour lesquelles il existe un historique (historique de navigation, de recherche, bookmarks, )

Votant : utilisateur inscrit dans le système DistriNet

Bulletin de vote : mécanisme d‟authentification des votes, appellé aussi jeton de vote

Bureau de vote : machine connectée au réseau DistriNet chargée de prendre en compte (i.e agréger, compter) les votes pour un type d‟activité donné (e.g les visites d‟un site Web)

Je distingue concrètement les 3 étapes :

Inscription

Figure 2: Métaphore du vote - Etape 1 : Inscription

Dans cette étape, un utilisateur doit s‟inscrire auprès d‟un “Master Peer” (un pair institutionnel dans le réseau DistriNet et son explication détaillée sera abordée plus tard) pour avoir le droit de voter Le fait n‟est exécuté qu‟une fois (la première fois d‟accès au réseau)

Le système demandera aux utilisateurs une identité, dans notre système c‟est une adresse email valide

La technique de filtrage spécique captcha est utilisée pour éviter les inscriptions automatiques par robots La version utilisée dans le système est recaptcha , une version gratuite, populaire et destiné spécifiquement pour les logicielles source ouvert

Après cette étape, l‟utilisateur peut obtenir un login/password, cela est considéré comme

“carte d’électure” pour voter dans les fois suivantes

Afin d‟éviter les gens qui veulent tricher le système, un email de confirmation sera envoyé à cette adresse email dans le but de validation.

Validation du votant

Figure 3: Métaphore du vote - Etape 2 : Validation du votant

Chaque fois un votant veut voter, il doit présenter l‟identité (email dans ce cas-là) L‟étape correspondante dans notre système est de faire un login avec l‟identification d‟utilisateur et le mot de passe reỗus de l‟ộtape prộcedante

Vote

Modélisation de la procédure de vote

Une architecture générale du système DistriNet fonctionne comme dans la figure suivante :

Figure 5: Architecture générale du système DistriNet

• Volatile Peer (VP) : un utilisateur de l‟Internet (en fait, un plug-in dans le navigateur

• Contact Peer (CP) : une machine dans le réseau DistriNet (i.e un pair institutionnel) qui permet aux utilisateurs d‟accéder au réseau

• Access Peer (AP) : un pair institutionnel (aléatoirement choisi par le Contact Peer) qui permet aux utilisateurs d‟accéder aux réssources du réseau DistriNet

• Master Peer (MP) : le pair institutionnel (aléatoirement choisi par le Contact Peer) qui permet a un nouvel utilisateur de s‟inscrire dans le réseau, gère son information spécifique (adresse mail, login/password), lui fournit des jetons de vote et authentifie ses votes

Un Volatile Peer sur l‟Internet ne connait que Contact Peer Autrement dit, Contact Peer est un seul pair institutionnel connu pour les utilisateurs dans le réseau Après avoir bien

DistriNet 2009 contacté, Contact Peer va choisir aléatoirement un autre pair institutionnel (c‟est Master Peer si Volatile Peer veut s‟inscrire dans le réseau DistriNet, et Access Peer dans le cas d‟accéder au rộseau DistriNet) C‟est aussi une faỗon de garantir l‟ộquilibrage de charge pour le rộseau Pair-à-Pair.

Procédure d‟inscription

Tout d‟abord, Volatile Peer contacte avec Contact Peer pour recevoir l‟IP de Master Peer choisi aléatoirement par ce Contact Peer En suite, Volatile Peer transfère directement à ce Master Peer reỗu: email, password, recaptcha pour l‟inscription et Master Peer confirmera l‟utilisateur par email donné

Procédure d‟accès

1) D‟abord, Volatile Peer contacte Contact Peer et reỗoit IP(AP) comme la procộdure présentée plus tôt

2) Dès que la réception de l‟IP de Access Peer, Volatile Peer submittera son userID et password à Access Peer

3) L‟IP de Master Peer de cet utilisateur sera extrait à partir d‟userID, Access Peer utilise IP(MP) afin de transmettre les informations de l‟utilisateur à Master Peer pour les authentifier et attendre la réponse de Master Peer

4) La réponse de Master Peer sur l‟authentification d‟accès de Volatile Peer

5) Access Peer permet à Volatile Peer d‟accéder au réseau DistriNet

Procédure de vote

Implémentation

Figure 10: Architecture d'un pair institutionnel

Dans le réseau DistriNet, tous les pairs institutionnels ont la même fonction (il joue le rôle comme Master Peer, Access Peer ou peut-être Contact Peer dans certains cas) C‟est pourquoi tous les pairs institutionnels ont la même architecture (détaillée dans la figure 10)

Toutes les fonctions de base sont développées en Lua Lua est un langage de programmation de script libre, réflexif, impératif et fonctionnel Mais Lua se pose certaines difficultés rencontrées pendant l‟implémentation du projet notamment les difficultés du développement de web

Une de deux parties principales de cette architecture est un “job” Splay Splay est un environnement pour le prototypage et le déploiment d’applications distribuées de grande taille

Plus précisément, ce “job” Splay qui tourne tout le temps (temps réel) afin de traiter les donnộes reỗues, traiter les messages (transmettre, crypter, dộcrypter) Il est dộployộ automatiquement à partir d‟un pair institutionnel unique dans le réseau (qui joue le rôle contrôller dans le réseau) pour tous les pairs institutionnels dans le réseau DistriNet

La partie de web serveur permet au système d‟interagir avec les utilisateurs

Dans tout le développement, nous nous appuyons sur plusieurs projets et bibliothèques supportées Lua dans les domains de web, base de données, cryptage, recaptcha La plupart de ces modules se trouve dans le projet Kepler : http://www.keplerproject.org/

Il s‟agit d‟une plate-forme open source pour le développement d‟applications web en LUA

La partie de web qui tourne de manière séparée et indépendante sur chaque pair institutionnel dans le réseau DistriNet Pour chaque pair institutionnel, cette partie doit être déployé manuellement à partir du code source et configuré par l‟adminitrateur de ce serveur (pair institutionnel) Les descriptions de déploiment et de configuration se trouvent dans la partie d‟annexe IV

Nous listons tous les codes des messages transmis pour que tous les pairs institutionnels puissent se connecter, ainsi que toutes les informations techniques concernant la mise en oeuvre du sysème dans la partie d‟annexe

Tout le code source et ainsi que les modifications du projet se trouvent sur l‟Internet sur le lien : http://code.google.com/p/distrinet/

2 Diverses techniques spécifiques appliquées dans le projet

Le protocole de transmission des messages dans le réseau DistriNet maintenant est TCP/IP (Transmission Control Protocol/Internet Protocol) A cause que la manque du protocol de routage dans le réseau pair-à-pair (La connection effective au réseau P2P va être intégrée dans la nouvelle version du système) Nous devons donc utiliser le protocole TCP/IP pour transmettre les messages

Le système de gestion de base de données MYSQL a été utilisé afin de gérer les informations de chaque pair institutionnel comme les informations d‟utilisateur, les données d‟activité agrégées fiables, les paramètres de configuation du système

Le serveur web Xavante est utilisé pour être mieux compatible avec le langage de progammation LUA selon les suggessions des auteurs de LUA Xavante fait partie du projet Kepler : http://www.keplerproject.org/xavante/

Test & Résultats

Dans cette partie, nous vous présentons quelques principaux screenshots et ses explications de notre système.

Screenshot de Contact Peer

Figure 11 : Screenshot de Contact Peer

La première connection avec le réseau DistriNet est l‟interface de Contact Peer

Une petite fenêtre qui liste les pairs institutionnels existants dans le réseau

Login (accộder) : de mờme faỗon, un autre pair institutionnel sera choisi aléatoirement pour devenir Access Peer qui permet à l‟utilisateur d‟accéder au réseau

Unregister () : supprimer l‟inscription existant dans le réseau Distrinet.

Screenshot de Master Peer

Figure 12 : Screenshot de Master Peer

Comme explications avant, dans cette interface un utilisateur remplit toutes les informations nécessaires pour s‟inscrire au système Les informations à fournir sont :

Email (valide) : considéré comme l‟identité pour l‟utilisateur

Password (re password aussi) Re-captcha: pour éviter les inscriptions automatiques par robots

Mail de confirmation de DistriNet

Figure 13 : Screenshot de mail de confirmation du réseau DistriNet

Le système va confirmer l‟utilisateur par email fourni

L‟utilisateur appuie sur le lien dans l‟email pour confirmer avec le système A partir de ce moment-là, l‟utilisateur peut accéder au réseau en utilisant login/password

Screenshot d‟Access Peer

L‟interface d‟Access Peer qui nous permet d‟accéder au réseau DistriNet en authentifiant login/password fourni

Screenshot de l‟interface de Vote

Validation

Figure 16: Exemple d’un fichier de log

Un message entre deux pairs institutionnels commence toujours par un Message Code et suivi par le contenu de ce message

Première colonne : le temps, exacte 0.1ms Ex : [16:45:59:7946] c‟est-à-dire: 16h 45m 59s 794.6ms

Message Code : Code de message, chaque message a un code particulier qui a été cité dans la partie Annexe 1 from : l‟expéditeur du message

(r) : receive, recevoir un champ du message (s) : send, envoyer (par défaute au pair institutionnel d‟expéditeur) (s:xxx.xxx.xxx.xxx) : send, envoyer au pair institutionnel cité après deux points

(p) : print, afficher les informations après le traitement Par exemple, afficher le contenu du message aprốs avoir dộcryptộ de faỗon croisộe

Nous analysons étape par étape des fichiers de logs comme ci-dessous pour prouver le fonctionnement du système et la préservation de l‟anonymat

A cause qu‟il n‟y pas assez de machines nécessaires (les pairs institutionnels nécessaires)

Nous sommes obligés de faire le test avec 5 pairs institutionnels Dans notre cas, Volatile Peer et Master Peer sont le mờme, ỗa ne perd pas la gộnộralitộ du problốme

Pour mieux comprendre l‟analyse, consultez les figures 9, 18 et la description de la solution dans le deuxième chapitre ainsi que les fichiers de log dans la partie d‟annexe

Volatile Peer - VP: 128.178.155.80 Pair institutionnel P1 : 128.178.155.105 Pair institutionnel P2 : 128.178.155.38 Pair institutionnel P3 : 128.178.155.100

VP (128.178.155.80) envoie à P1 (128.178.155.105), P2 (128.178.155.38) les deux messages TRANSFER_VOTE et à P3 (128.178.155.100) le message TRANSFER_TO_INTERMEDIATE

[14:31:49:6558]: MESSAGE CODE : TRANSFER_VOTE [14:31:49:6561]: from: 128.178.155.80

[14:31:49:7258]: (r) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46 [14:31:49:7261]: (r) code: #$2ea17a12-d2b4-11de$#

[14:31:49:7263]: (r) messageCrypt: Salted 2dfìỵưóẵđỚđẳĂẦỵÔvậÙ¡UJÔÉỪ/DƯấỹ ỨụỲmẳ\3 ô-ÔŠv [14:31:49:7346]: (s:128.178.155.92) MESSAGE CODE: SEND_VOTE [14:31:49:7349]: (s:128.178.155.92) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46 [14:31:49:735]: (s:128.178.155.92) code: #$2ea17a12-d2b4-11de$#

Salted 2dfìỵưóẵđỚđẳĂẦỵÔvậÙ¡UJÔÉỪ/DƯấỹỨụỲmẳ\3 ề-ấẾv

[14:31:49:7958]: (r) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46 [14:31:49:7959]: (r) code: #$-80d7-00301baef1b2$#

[14:31:49:796]: (r) messageCrypt: Salted ộửéWa\è k !Ù›ÙLsa ¤„³ [14:31:49:798]: (s:128.178.155.92) MESSAGE CODE: SEND_VOTE [14:31:49:7981]: (s:128.178.155.92) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46 [14:31:49:7982]: (s:128.178.155.92) code: #$-80d7-00301baef1b2$#

[14:31:50:1696]: MESSAGE CODE : TRANSFER_TO_INTERMEDIATE [14:31:50:1697]: from: 128.178.155.80

BV(S) (128.178.155.92) reỗoit les deux messages contenant le vote à partir de deux pairs institutionnels P1 (128.178.155.105) et P2 (128.178.155.38) Et puis BV(S) (128.178.155.92) dộcrypte de faỗon croisộe ces deux messages et affiche les rộsultats

[14:31:49:634]: MESSAGE CODE : SEND_VOTE [14:31:49:6341]: from: 128.178.155.105

[14:31:49:6344]: (r) messageCrypt: Salted 2dfìỵưóẵđỚđẳĂẦỵÔvậÙ¡UJÔÉỪ/DƯấỹỨụỲmẳ\3 ề-ấẾv [14:31:49:6998]: MESSAGE CODE : SEND_VOTE

[14:31:49:7]: from: 128.178.155.38 [14:31:49:7001]: (r) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46 [14:31:49:7001]: (r) code: #$-80d7-00301baef1b2$#

[14:31:49:7002]: (r) messageCrypt: Salted ộửéWa\è k !Ù›ÙLsa ¤„³ [14:31:49:7868]: (p) p3: 128.178.155.100 [14:31:49:7869]: (p) url: url-url: www.epfl.ch www.mmaline.org

BV(S) (128.178.155.92) demande à P3 (128.178.155.100) de vérifier le vote

P3 (128.178.155.100) transmet le vote à MP (128.178.155.80) pour le vérifier

[14:31:50:2734]: (s:128.178.155.80) MESSAGE CODE: REQUEST_VERIFICATION_TO_MP [14:31:50:2736]: (s:128.178.155.80) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46 [14:31:50:2737]: (s:128.178.155.80) c1: #$2ea17a12-d2b4-11de$#

[14:31:49:8034]: MESSAGE CODE : REQUEST_VERIFICATION_TO_MP [14:31:49:8036]: from: 128.178.155.100

MP (128.178.155.80) répond à P3 (128.178.155.100) OK ou NOT_OK pour le vote

[14:31:49:8063]: (s) msg: OK_VOTE_SESSION_ID

[14:31:50:2739]: (r:128.178.155.80) answerFromMP: OK_VOTE_SESSION_ID

P3 (128.178.155.100) transmet la vérification du vote à BV(S) (128.178.155.92)

[14:31:50:2762]: (s:128.178.155.92) MESSAGE CODE: ANSWER_TRANSFER_TO_INTERMEDIATE [14:31:50:2763]: (s:128.178.155.92) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46

[14:31:50:2764]: (s:128.178.155.92) answerFromMP: OK_VOTE_SESSION_ID

[14:31:49:8178]: MESSAGE CODE : ANSWER_TRANSFER_TO_INTERMEDIATE [14:31:49:8179]: from: 128.178.155.100

[14:31:49:818]: (r) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46 [14:31:49:8181]: (r) answerFromMP: OK_VOTE_SESSION_ID

Après avoir analysé les fichiers de log de tous les pairs concernants le vote Nous trouvons que la procédure du vote fonctionne correctement en respectant la solution détaillée dans le deuxième chapitre Comme expliqué avant la solution que nous proposons préserve l’anonymat

Non manipulabilité signifie que les utilisateurs ne peuvent pas “trop” fausser les fréquences des sites web votés

Nous proposons deux critères pour garantir non manipulabilité:

Tout vote doit être authentifié par un jeton de vote valide (unicité des jetons de votes) Tout utilisateur ne peut obtenir qu‟un nombre limite de jetons de vote par unité de temps (unicité de l‟identité)

3 Exemple d’exploitation des données agrégées (Google Maps)

Voici un exemple d‟application de visualisation des informations brutes des “urls” votés

Cette exemple vous monte que le système DistriNet fournit une infrastructure ouverte et à partir de cela, on peut l‟exploiter pour construire les applications qui rend au grands publiques des choses intéressantes

Sur ce site on peut voir tous les “urls” votés par les Volatile Peers dans le réseau DistriNet

Un tableau tout simple liste les sites web et son nombre de votes, grâce à une bibliothèque spéciale, on peut générer les ips de ces “urls” et puis on utilise une autre bibliothèque pour générer les autres informations concernant ces ips comme: la longitude, la latitude, la location géographique afin de visualiser dans la carte de Google Maps

Sur la carte, vous voyez bien géographiquement les sites web votés et son nombre de votes

Grâce à notre système DistriNet, il s‟agit des résultats anonymes et non manipulables

De plus, sur le tableau vous pouvez ordonner (trier) les sites web et ne visualiser que les sites déjà triés (en choisissant les checkbox)

+) Un prototype pleinement opérationnel permettant de stocker des données d‟activité agrégées (plus précisément, les fréquences de visite de site Web ou de sélection d‟une URL dans la liste de résultats produits par un moteur de recherche) a été produit

+) Les mộcanismes implộmentộs garantissent de faỗon raisonnable l‟anonymat des contributions individuelles et la non-manipulabilité des données stockées

-) L‟architecture actuelle est trop monolithique (ensemble du prototype écrit en LUA) ce qui a posé de nombreux problèmes techniques

-) Au début, l‟architecture du système n‟est pas clairement distinguée entre les modules De plus, à cause que le serveur Web Xavante ne soit pas très suffisament fort Nous avons donc rencontré assez des difficultés

Grâce au travail en collaboration avec Tran Huu Duc (ancien étudiant de l‟IFI, mon collègue maintenant dans le projet DistriNet) Une architecture amộliorộe a ộtộ conỗue et le systốme est en cours de réimplémentation

Dans les premier temps du projet, l„architecture et les techniques ne sont pas très claires

Mais l‟architechture a été maintenant déterminée (comme l‟image dans la page suivante)

Cette architerture contient trois parties distinguées :

- Tout ce qui concerne la fonctionalité d‟un réseau P2P (le protocole de routage, l‟équilibrage de charge, le stockage des données agrégées fournies dans le réseau P2P) appartiendra au côté de Neuchâtel

- Le développement des applications pour exploiter les données stockées dans la base des données du réseau est le travail à côté de l‟EPFL

- Des plug-ins/add-ons qui tournent sur le navigateur pour collecter les activités des utilisateurs vont être effétué par l‟EPFL

La connection effective au réseau P2P va être intégrée dans la nouvelle version du système

Des techniques de gestion automatique de confiance entre pairs institutionnels vont être développées (collaboration prévue avec l‟IFI en 2010)

GET_IPS : message qui demande à l‟Access Peer les ips des pairs institutionnels existants dans le réseau DistriNet

CHANGE_PASSWORD : message qui demande au Master Peer de changer le mot de passe

UNREGISTRATION : message qui demande au Master Peer de supprimer un utilisateur existant dans le réseau DistriNet

LOGOUT : Demander de déconnecter du système DistriNet

EXPIREDSESSION : le message envoyé par Access Peer qui informe à Master Peer les sessions expirées

CHECK_ACCESS : demander au Master Peer de vérifier l‟identification d‟utilisateur et le mot de passe

CREATE_TOKEN : demander au Master Peer de créer les nouveaux jetons

TOKENS : demander au Master Peer tous les jetons encore valable

TRANSFER_VOTE : Message envoyé par Volatile Peer aux deux pairs intermédiaires P1 &

SEND_VOTE : Message envoyé par les pairs intermédiaires P1 & P2 au bureau de vote

TRANSFER_TO_INTERMEDIATE : Message envoyé au pair intermédiaire P3 par le bureau de Vote BV(S) ou bien par Volatile Peer

ANSWER_TRANSFER_TO_INTERMEDIATE : le pair intermédiaire P3 répond au bureau de vote BV(S)

REQUEST_VERIFICATION_TO_MP : Demander à Master Peer de vérifier le jeton de vote

Figure 18 : Le trafic des messages d’une procédure de vote

Il y a une interface spéciale pour configurer les paramètres du système accédée seulement par l‟administrateur du système (en général la personne qui déploie le pair institutionnel)

Nous fournissons deux possibilités de configuration des paramètres du système : modifier – sauvegarder (modify – save), restaurer (reset) les paramètres par défaut Ces paramètres sont stockés dans la base des données

Dans la même interface, nous pouvons aussi initialiser la base des données (initialize database)

Les paramètres sont divisés en groupes différents Ce sont :

TOKEN_TIME_OUT (s) : time out de jeton de vote, après cette période de temps, le jeton sera expiré Autrement dit, nous ne pouvons plus utiliser ce jeton pour voter

TOKEN_GET_PERIOD (s) : unité de temps pour demander de nouveaux jetons

TOKEN_GET_NUMBER : le nombre de jetons générés pour une fois demandée

WEB_PORT : le port du serveur web

WEB_SESSION_DIR : le chemin du répertoire qui contient les informations concernantes les sessions contrôlées par le serveur web

WEB_SESSION_TIME_OUT : après cette période de temps, s‟il n‟y avait aucune action de l‟utilisateur, la session serait fermée

MYSQL_PASSWORD : le mot de passe de l‟utilisateur ci-dessus

MYSQL_HOSTID : le nom de seuveur MYSQL

MYSQL_PORT : le port de serveur MYSQL

SMTP_SERVER_NAME : le nom de serveur SMTP

SMTP_SERVER_PORT : le port de serveur SMTP

SMTP_USER : l‟email utilisé pour envoyer le message de confirmation du système

Défaut : huuduc.tran@epfl.ch

SMTP_PASSWORD : le mot de passe de l‟utilisateur

RECAPTCHA_PUBLIC_KEY : la clé publique utilisée dans le cryptage du challenge entre le système DistriNet et le serveur de Recaptcha

Défaut : 6Ld5QwcAAAAAAAUWGG53Jkk3WZ3Ji8PjV8crXZmd

RECAPTCHA_PRIVATE_KEY : la clé privée utilisée dans le cryptage du challenge entre le système DistriNet et le serveur de Recaptcha

Défaut : 6Ld5QwcAAAAAADIPTofkjda8wa67A961l9dAGzz8 Google

GOOGLE_MAP_KEY : la clé servit à utiliser le service de Google Maps

ABQIAAAAtQgjkzML9HvC0NJ3Y6lEehRr65xaCOqEfdnEVKzW7YqQaV_5KBQapvyLCtFCBwQKq6SBwf6EQa4lnA

SPLAY_PORT : le port pour communiquer avec Splay de chaque pair institutionnel

VOTE_PEER_IP : l‟IP du pair institutionnel qui fournit le service de “vote” abordé dans la rubrique IV.4 (Exploitation des données agrégées)

[14:26:17:9301]: MESSAGE CODE : GET_IPS [14:26:17:9304]: from: 128.178.155.80

[14:26:17:9305]: (s) ip: 128.178.155.80 [14:26:17:9306]: (s) ip: 128.178.155.38 [14:26:17:9309]: (s) ip: 128.178.155.92 [14:26:17:9311]: (s) ip: 128.178.155.100 [14:26:17:9313]: (s) ip: 128.178.155.105 [14:27:47:4036]: MESSAGE CODE : CHECK_ACCESS [14:27:47:4038]: from: 128.178.155.80

[14:27:47:4077]: (s) msg: AUTHORISED [14:27:47:408]: (s) msg: OK_CHECK_ACCESS [14:27:47:408]: (s) email: huuduc.tran@epfl.ch [14:27:47:4482]: (r) IPAP: 128.178.155.80 [14:27:47:4503]: (r) sessionID: 862281406

[14:27:50:1429]: (s) ip: 128.178.155.80 [14:27:50:143]: (s) ip: 128.178.155.38 [14:27:50:1433]: (s) ip: 128.178.155.92 [14:27:50:1435]: (s) ip: 128.178.155.100 [14:27:50:1437]: (s) ip: 128.178.155.105 [14:28:18:1896]: MESSAGE CODE : GET_IPS [14:28:18:1899]: from: 128.178.155.80

[14:28:18:19]: (s) ip: 128.178.155.80 [14:28:18:1902]: (s) ip: 128.178.155.38 [14:28:18:1904]: (s) ip: 128.178.155.92 [14:28:18:1906]: (s) ip: 128.178.155.100 [14:28:18:1908]: (s) ip: 128.178.155.105 [14:30:18:5724]: MESSAGE CODE : CREATE_TOKEN [14:30:18:5726]: from: 128.178.155.80

[14:30:18:5727]: (r) userID: 632167955 [14:30:18:5981]: (s) msg: CREATED_NEW_TOKENS [14:30:18:726]: MESSAGE CODE : TOKENS

[14:30:18:7262]: from: 128.178.155.80 [14:30:18:7276]: (s) userID: 632167955 [14:30:18:7292]: (s) tokenID: 2ea14eac-d2b4-11de-80d7-00301baef1b2&1258378218 [14:30:18:7295]: (s) tokenID: 2ea17a12-d2b4-11de-80d7-00301baef1b2&1258378218 [14:30:18:7296]: (s) msg: FINISH&FINISH

[14:31:49:6165]: (s) ip: 128.178.155.80 [14:31:49:6167]: (s) ip: 128.178.155.38 [14:31:49:6169]: (s) ip: 128.178.155.92 [14:31:49:6171]: (s) ip: 128.178.155.100 [14:31:49:6173]: (s) ip: 128.178.155.105 [14:31:49:8034]: MESSAGE CODE : REQUEST_VERIFICATION_TO_MP

[14:31:49:7263]: (r) messageCrypt: Salted 2dfìỵưóẵđỚđẳĂẦỵÔvậÙ¡UJÔÉỪ/DƯấỹỨụỲmẳ\3 ề-ấẾv [14:31:49:7346]: (s:128.178.155.92) MESSAGE CODE: SEND_VOTE

[14:31:49:7349]: (s:128.178.155.92) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46 [14:31:49:735]: (s:128.178.155.92) code: #$2ea17a12-d2b4-11de$#

[14:31:50:1709]: (r+p) IPMP: 128.178.155.80 [14:31:50:2624]: MESSAGE CODE : TRANSFER_TO_INTERMEDIATE [14:31:50:2626]: from: 128.178.155.92

[14:31:50:2637]: (r+p) IPMP: 128.178.155.80 [14:31:50:2734]: (s:128.178.155.80) MESSAGE CODE: REQUEST_VERIFICATION_TO_MP [14:31:50:2736]: (s:128.178.155.80) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46 [14:31:50:2737]: (s:128.178.155.80) c1: #$2ea17a12-d2b4-11de$#

[14:31:50:2739]: (r:128.178.155.80) answerFromMP: OK_VOTE_SESSION_ID [14:31:50:2762]: (s:128.178.155.92) MESSAGE CODE: ANSWER_TRANSFER_TO_INTERMEDIATE [14:31:50:2763]: (s:128.178.155.92) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46

[14:31:49:7953]: (s:128.178.155.100) MESSAGE CODE: TRANSFER_TO_INTERMEDIATE [14:31:49:7954]: (s:128.178.155.100) voteSessionID: 64e60d36-d2b4-11de-8f9c-000c29d0bd46 [14:31:49:7955]: (s:128.178.155.100) c1: #$2ea17a12-d2b4-11de$#

4 Introduction de déploiement d’un pair institutionnel

Voici les étapes essentielles et nécessaires pour déployer et configurer le système DistriNet:

Les parquets essentiels o build-essential

OpenSSL libraries o libssl-dev o libssl0.9.8 Référencer: http://www.openssl.org/docs/

LuaSocket 2.x shared library o liblua5.1-socket2 o liblua5.1-socket-dev Référencer : http://www.tecgraf.puc-rio.br/~diego/professional/luasocket/

LuaSec 0.2+ shared library o luasec-0.3.3.tar.gz (télécharger, faire la compilation et l'installation manuellement)

Attention : modifier les paths appropriés LUAPATH, CPATH et INCDIR (le répertoire contient le fichier lua.h, peut-être localisé par la commande “locate lua.h” après avoir fait l‟update par la comande : “updatedb” )

Référencer : http://www.inf.puc-rio.br/~brunoos/luasec/

Référencer: http://www.splay-project.org/index.php?page=download

CONTROLLER (seulement pour le pair qui veut jouer le rôle)

KEPLER (rocks, xavante) o Faire attention d'installer d'abord : libreadline-dev Référencer : http://www.keplerproject.org/en/UNIX_Installation

Référencer : http://spu.tnik.org/lib/recaptcha/

MYSQL o mysql-server-5.0 ou bien plus Référencer : http://www.mysql.com/

LuaSQL (luasql.mysql) o liblua5.1-sql-mysql-2 o liblua5.1-sql-mysql-dev Référencer : http://www.keplerproject.org/luasql/

Aller au répertoire racine de SPLAY

Ouvrir le fichier setting.lua et modifier les paramètres comme suivant: splayd.settings.key = " votre clé personnelle "

DistriNet 2009 splayd.settings.name = " votre nom personnel " splayd.settings.controller.ip = " référencer le controller défaute sur le side web de

DistriNet: http://code.google.com/p/distrinet/ "

Aller au répertoire racine de Serveur Web

Télécharger ou bien faire le check-out le code source sur : http://code.google.com/p/distrinet/ pour le pair institutionnel et le copier au répertoire racine de serveur de web

Accéder à MYSQL et exécuter les commandes: create database distrinet;

GRANT ALL PRIVILEGES ON distrinet.* TO 'distrinet'@'localhost' IDENTIFIED

BY 'distrinet' WITH GRANT OPTION;

Aller au répertoire racine du serveur web et puis exécuter la commande: lua init_config.lua

Afin d'être un pair institutionnel dans le réseau, on doit lancer à la fois tous les deux :

Splayd et serveur de web Xavante

Aller au répertoire racine de SPLAY et lancer en saisissant la commande:

Lancer en tant que root le serveur web : sudo xavante

Pour le pair joue le rôle de contrôller, il faut aller au répertoire racine de contrôler et lancer comme suivant :

Non manupulabilité

Exemple d‟exploitation des données agrégées (Google Maps)