Conception Et Realisation Dun Reseau Social Distribue

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE
UNIVERSITE ABOU BAKR BELKAID TLEMCEN

FACULTE DES SCIENCES
DEPARTEMENT DINFORMATIQUE
Mmoire de fin dtudes
pour lobtention du diplme de Master en Informatique

Option: Rseaux et systmes distribus (R.S.D)
Thme
Conception et ralisation
Dun rseau social distribu

Ralis par :
Abderrezzaq Khatir
Imane Labbas
Prsent le 29 Juin 2013 devant le jury compos de :
Mme. Amel Halfaoui (Prsidente)

Mr. Mohamed Tadlaoui (Encadreur)
Mr. Amine Boudefla (Examinateur)
Mr. Badr Benmammar (Examinateur)
Anne universitaire : 2012-2013

La multiplication des moyens de communication au premier rang desquels les

rseaux sociaux permettent aux socits de progresser vers une universalit des
changes constructifs tant individuels que collectifs. Nanmoins, la communication
mal gre ou manipule se dtruit elle mme. La ncessit d'une gestion humaniste
des changes internet devient une imprieuse ncessit pour un quilibre global et
une vision d'avenir collective.
Pascal Monsolve
I
REMERCIEMENT
Il est dusage parce que normal en fin de mmoire deffectuer les remerciements
des personnes sans lesquelles tout ce projet naurait pu voir le jour.
Tout dabord nos plus sincres remerciements vont notre encadreur Mr.
Mohamed Tadlaoui sans qui le prsent projet naurait jamais pu voir le jour. Son aide
prcieuse et sa patience ont t dun secoure remarquable afin de mener ce travail bien.
Nous tenons remercier tout particulirement Mr. Badr Benmammar qui nous a
fait lhonneur de prsider le jury qui va avoir se prononcer sur la qualit du travail
prsent. Son enseignement de haute qualit a form puis nourrit notre rflexion.
Nous remercions galement Mr. Amine Boudefla dont les remarques pertinentes
ont permis lorientation correcte du projet que nous venons de dvelopper et de prsenter
par ce mmoire. Notre intrt pour la recherche, nous la lui devons. Son acceptation
valuer notre travail a donn une chance relle ce projet.
Nos remerciements galement Mme. Amel Halfaoui qui na eu de cesse que de

nous encourager et de nous conseiller dans ce projet. Sans elle notre motivation
participer la startup weekend d'Alger lanne dernire n'aurait pas t si grande et nous
naurions pu gagner le 2e prix du meilleur projet. Mme. Halfaoui a accept galement
dvaluer notre projet.
Nous remercions lensemble de nos professeurs dont le savoir prcieux ont enrichi
nos parcours respectifs ainsi que toutes les personnes non cites ici mais qui ont
contribu de prs ou de loin l'accomplissement de notre travail.
II
DEDICACES
Je ddie ce modeste travail aux personnes qui me sont chres et sans la prsence
desquelles il ne maurait pas t possible dtre prsents devant vous aujourdhui :
Tout dabord mes chers parents qui mont soutenu tout au long de mon parcours
et dont tous les sacrifices justifient eux seuls ma tnacit achever ce projet et avoir
travaill avec autant dacharnement. Puissent-ils tre fiers de voir leur benjamin mener
bien ses tudes.
Mes chers frres Boumediene et Mustapha dont la prsence mes cts fut un
soutien dans les moments de doutes et une force dans laquelle jai puis.
A mes surs Fatiha et Souhila pour leur Amour sans lequel aucun projet neut pu
aboutir.
A mes neveux Salim, Amira, el Hadi, Nadir et le petit Nassim qui me rappellent
chaque jour que nous ne menons pas nos projets pour nous mme mais galement pour sa
famille et au-del de celle-ci, nous lesprons, pour un plus grand nombre.
A mon binme et amie Narymen pour nos changes parfois mouvements qui
furent une stimulation de chaque instant avancer et russir.
A mes amis Ilhem, Ryad, Djamel, Salah ainsi qu tous mes autres amis qui me
font me souvenir que le travail prend aussi appui sur lamiti comme force vivifiante.
A ma trs chre amie Birgit et son fils Stphan qui mont beaucoup aid dans la
vie et qui continuent de maider.
A toi Pascal pour des choses qui remplissent les pages de ce mmoire et encore
plus.
A toutes celles et ceux que je porte en mon cur et que je nai pas cit sans qui un
tel projet naurait pas vritablement eu de sens.
ZaQ
III
DEDICACES
Je ddie ce mmoire de fin dtudes :
Mon trs cher pre et ma trs chre mre qui mont paul tout au long de mes
tudes.
mon frre Ryad et ma princesse Nihad.
mon grand pre, que dieu te garde.
toute ma famille.
Un grand merci tous mes amis, principalement ZaQ, Ilou, Oussama, Manel,
Nawal, Nadi, Djamel, Kika, Dido, Mimi, Bouchra, Hafsa, Ilyass, Zineb, Mehdi, Chakib,
Asma, Assia, Hakim, Khero, Reda, Otman & Zyad
Pour finir, je remercie toutes les personnes qui ont fait entrer de la couleur dans ma
vie.
Narymen
IV
RESUME
Ce travail sinscrit dans le cadre de recherche concernant la problmatique du
contrle et de lutilisation des donnes au sein des rseaux sociaux centraliss.
Lobjectif de ce mmoire est de faire une tude et un comparatif des architectures

de quatre rseaux sociaux dcentraliss que nous avons slectionn, de proposer une
nouvelle architecture distribue et de dvelopper un prototype qui repose sur cette
architecture.
Nous proposons un nouveau modle des rseaux sociaux distribus baptis DisNet.
Afin de valider notre modle nous proposons un prototype nomm DisNet Prot. La
problmatique que nous essayons de rsoudre est le stockage de donnes.
De plus nous apportons une solution nouvelle nayant pas encore t implment
dans les rseaux sociaux actuels ni mme dans les approches dtudes consistant en la
suppression des profils utilisateurs.
V
ABSTRACT
This work tries to establish a scop of research concerning the problems of control
and use of the data in the centralized social networks.
The objective of this memory is to make a study and comparative architectures of

four decentralized social networks which we selected, to propose a new distributed
architecture and to develop a prototype which rests on this architecture.
We propose a new model of the distributed social networks baptized DisNet. In

order to validate our model we propose a prototype named DisNet Prot. The problems that
we try to solve are data storage.
Moreover we bring a new solution not having been implemented yet in the current
social networks nor even in the approaches of studies consisting of the suppression of the
user profiles.
VI
TABLE DES MATIERES
Remerciement ........................................................................................................................... II
Ddicace ZaQ ............................................................................................................................ III
Ddicace Narymen ................................................................................................................. IV
Rsum ......................................................................................................................................... V
Abstract ...................................................................................................................................... VI
Introduction Gnrale ............................................................................................................. 1
Chapitre I Les rseaux distribus ................................................................................. 4
I. Le Peer to Peer : .................................................................................................................. 4
II. Les rseaux sociaux distribus : .................................................................................. 5
III. Les tables de hachages distribues : ......................................................................... 5

III.1. Kademlia : ................................................................................................................................ 6
III.2. OpenDHT : ............................................................................................................................... 7
III.3. FreePastry : ............................................................................................................................. 8
IV. La sauvegarde Friendstore : ......................................................................................... 8
Chapitre II Etat de l'art .......................................................................................................... 10
I. Introduction : ....................................................................................................................... 9
I.1. Confidentialit : ........................................................................................................................ 9
I.2. Intgrit : ................................................................................................................................. 10
I.3. Disponibilit : ......................................................................................................................... 10
II. Dfinition et conception : ............................................................................................. 10

II.1. PeerSon: .................................................................................................................................. 10
a - Le chiffrement des donnes : ............................................................................................................... 11
b - La dcentralisation de larchitecture : ............................................................................................. 11
c - Echange directe entre les utilisateurs : ........................................................................................... 11
II.2. Safebook : ............................................................................................................................... 11
a - Confidentialit de bout en bout : ........................................................................................................ 12
b - Lauthentification : ................................................................................................................................... 12
c - La vie prive : .............................................................................................................................................. 12
d - L'intgrit des donnes : ....................................................................................................................... 12
VII
II.3. Decent ..................................................................................................................................... 13
II.4. Cachet : .................................................................................................................................... 14
III. Architecture des rseaux sociaux distribus : ..................................................... 14

III.1. Architecture de PeerSon : ............................................................................................... 14
a - 1er tiers : (Le look up service) ............................................................................................................ 15
b - 2e tiers : (Les peers) ................................................................................................................................ 15
III.2. Architecture de Safebook : .............................................................................................. 16
a - Matryoshka : ............................................................................................................................................... 17
b - Le systeme P2P: ........................................................................................................................................ 18
c - Service dindentification de confiance : ........................................................................................... 18
III.3. Architecture de Decent et Cachet : ............................................................................... 19
IV. Prototypes des rseaux sociaux distribues : ........................................................ 20

IV.1. Protocole de PeerSon : ..................................................................................................... 20
a - Identifiant globale unique (GUID) : ................................................................................................... 20
b - La procdure de connexion : ............................................................................................................... 20
c - La rcupration d'un fichier: ............................................................................................................... 21
d - Les messages asynchrones : ................................................................................................................ 21
IV.2. Prototype de Safebook : ................................................................................................... 21
IV.3. Prototype de Decent et Cachet : .................................................................................... 22
a - Recherche dun contact social : ........................................................................................................... 23
b - Suppression ET Annulation : ............................................................................................................... 23
c - Protocole de prsence : .......................................................................................................................... 23
V. Stockage des donnes : .................................................................................................. 24
VI. Diagramme de squence ............................................................................................. 24

VI.1. Diagramme de PeerSon : ................................................................................................. 24
a - Cration dun nouveau profil : ............................................................................................................ 25
b - Connexion au rseau : ............................................................................................................................ 25
c - Gestion des messages : ........................................................................................................................... 26
d - Ajout dun nouveau contact : ............................................................................................................... 29
VI.2. Diagramme de Safebook : ................................................................................................ 29
a - Cration dun nouveau profil : ............................................................................................................ 29
b - Se connecter au rseau : ........................................................................................................................ 32
c - Gestion des messages .............................................................................................................................. 32
d - Ajout dun nouveau contact : ............................................................................................................... 35
VI.3. Diagramme de Decent et Cachet : ................................................................................. 35
VIII
a - Inscription dans le rseau : .................................................................................................................. 36
b - Se connecter au rseau : ........................................................................................................................ 36
c - Gestion des messages : ........................................................................................................................... 37
d - Lajout dun contact : ............................................................................................................................... 38
VII. Synthse : ........................................................................................................................ 40
Chapitre III "Proposition DisNet " ..................................................................................... 43
I. Objectifs de DisNet ........................................................................................................... 43
II. Architecture de DisNet : ................................................................................................ 43

II.1. Le 1er tiers : ............................................................................................................................ 44
II.2. Le 2e tiers : ............................................................................................................................. 44
III. Prototype de DisNet (DisNet Prot) .......................................................................... 45

III.1. Rejoindre DisNet : .............................................................................................................. 45
III.2. Se connecter DisNet : ..................................................................................................... 46
III.3. Gestion des messages : ..................................................................................................... 47
III.4. Ajout dun contact : ............................................................................................................ 49
III.5. Suppression dun compte et destruction des donnes ......................................... 50
IV. Simulation ........................................................................................................................ 51
Conclusion et perspective .................................................................................................... 53
VIII
LISTES DES FIGURES
Figure I.1 : Structure du rseau P2P ................................................................................... 4
Figure II.1 : Architecture de PeerSon ............................................................................... 15
Figure II.2 : Couches de Safebook et principaux composants .................................. 16
Figure II.3 : Structure dune Matryoshka ........................................................................ 18
Figure II.4 : Architecture de Decent et architecture de Cachet ............................... 20
Figure II.5 : PeerSon Inscription ..................................................................................... 25
Figure II.6 : PeerSon Connexion au rseau .................................................................. 26
Figure II.7 : PeerSon Localisation et statut du peer ................................................. 26
Figure II.8 : PeerSon Mode synchrone et asynchrone en ligne ........................... 27
Figure II.9 : PeerSon Mode asynchrone hors ligne .................................................. 28
Figure II.10 : PeerSon Mode synchrone hors ligne .................................................. 28
Figure II.11 : PeerSon ajout dun contact ..................................................................... 29
Figure II.12 : Rejoindre Safebook - Cration de lidentit ........................................ 30
Figure II.13 : Rejoindre Safebook - Cration de la Matryoshka .............................. 31
Figure II.14 : Safebook - se connecter au rseau .......................................................... 32
Figure II.15 : Safebook mode asynchrone en ligne ................................................. 33
Figure II.16 : Safebook mode asynchrone hors ligne .............................................. 33
Figure II.17 : Safebook mode synchrone en ligne .................................................... 34
Figure II.18 : Safebook mode synchrone hors ligne ................................................ 34
Figure II.19 : Safebook demande dajout dun contact ............................................ 35
Figure II.20 : Decent / Cachet Inscription .................................................................... 36
Figure II.21 : Decent Se connecter .................................................................................. 36
Figure II.22 : Cachet Se connecter .................................................................................. 37
Figure II.23 : Decent gestion des messages ................................................................. 38
Figure II.24 : Cachet gestion des messages ................................................................. 38
Figure II.25 : Decent ajout dun contact ........................................................................ 39
Figure II.26 : Cachet ajout dun contact ........................................................................ 39
IX

Liste des figures

Figure III.1 : Architecture de DisNet ................................................................................. 45

Figure III.2 : Rejoindre DisNet Prsence du parrain ................................................ 46
Figure III.3 : Rejoindre DisNet Challenge/rponse .................................................. 46
Figure III.4 : DisNet Se connecter ................................................................................... 47
Figure III.5 : DisNet Communication en ligne ............................................................. 47
Figure III.6 : DisNet Message instantan hors ligne ................................................. 48
Figure III.7 : DisNet communication asynchrone Friendstore .......................... 49
Figure III.8 : DisNet Ajout dun contact ......................................................................... 49
Figure III.9 : DisNet suppression dun compte utilisateur ..................................... 50
Figure III.10 : DisNet Prot crer un profil peer ...................................................... 51
Figure III.11 : DisNet Prot crer un profil DHT ...................................................... 51
Figure III.12 : DisNet envoi message peer ................................................................ 52
Figure III.13 : DisNet envoi message DHT ................................................................ 52
Figure III.14 : DisNet suppression profil peer ......................................................... 52
Figure III.15 : DisNet suppression profil DHT ......................................................... 52
X
LISTE DES TABLEAUX
Table II .1 : Comparatif des quatre architectures ....................................................... 42
XI
INTRODUCTION
Il existe actuellement de fortes prsomptions dutilisations non autorises des

donnes personnelles des utilisateurs au sein des rseaux sociaux centraliss.
La rcente affaire reprise par la presse internationale de cette utilisation

frauduleuse par certaines agences gouvernementales amricaines de premier plan incite
une prudence grandissante et la proposition de solutions novatrices dans le champ de
protection des donnes. Selon la chaine dinformation LCI [1] concernant le systme
PRISM [2] : grce lui la National Security Agency, NSA, est au courant de tous les
changes sur Internet ; toutes les compagnies, Google, Facebook, Appel y participent.
Selon le prsident Obama, lAmrique na pas le choix .
Le prsident Obama a dclar : Vous ne pouvez pas avoir 100% de scurit et en

mme temps 100% de respect de la vie prive.
En effet ces rseaux sociaux centraliss ont construit leur accessibilit sur la
gratuit daccs, en contre partie lutilisateur se doit de fournir des renseignements
personnels consquents que les rseaux non seulement stockent mais semblent fournir
des demandeurs extrieurs sous couvert de la mention scurit nationale.
Mark Zuckerberg [ 3 ], le fondateur de Facebook a dclar : Quand les

gouvernements demandent des renseignements Facebook, nous examinons chaque
requte minutieusement afin de nous assurer quils suivent un processus correct et en
conformit avec les lois, et que seules les informations lgales sont demandes.

Introduction

Nombreux sont les utilisateurs qui smeuvent de telles pratiques en violation

flagrante des liberts fondamentales dont chaque individu jouit selon les lois
internationales sur les liberts individuelles.
Ladhsion un rseau social implique un contrat de confiance entre lutilisateur

de celui-ci et les acteurs du rseau social lui-mme. Ce contrat de confiance devrait
stipuler que lutilisation des donnes personnelles ne peut se faire quaprs accord tacite
de lutilisateur ou que lutilisation des donnes personnelles par le rseau social fait partie
intgrante de laccs celui-ci.
Or, ce jour, le contrat de confiance entre lutilisateur et les rseaux sociaux

centraliss nest pas respect pour plusieurs raisons :
La premire est que la majorit des utilisateurs nest pas avertie de lutilisation des
donnes personnelles stockes des fins mercantiles et commerciales ;
Les rseaux sociaux centraliss se rfugient derrire la demande des
gouvernements de transmission des donnes personnelles stockes afin de protger
les liberts collectives.
De nombreux cas travers le monde sur divers rseaux sociaux centraliss ont fait
apparatre ces dernires annes lincapacit de gestion des donnes personnelles par ces
rseaux aprs leur divulgation. Les utilisateurs ont pu se retrouv dans des situations
personnelles dlicates la suite de lutilisation sans accord pralable de tout ou partie des
donnes personnelles stockes par les rseaux au premier rang desquels Facebook.
Certains pays ont pour objectif le durcissement de la lgislation en vue de la

protection des donnes personnelles, il est difficile nanmoins dquilibrer la notion de
libert individuelle ou dentreprise avec la cadre lgislatif pouvant obliger les rseaux
sociaux tablir un contrat de confiance avec les utilisateurs dans un cadre de visibilit
totale.
Gnralement lutilisateur des rseaux sociaux centraliss est dpossd par ceux-
ci de leur capacit grer leur accs par exemple dans le cadre de la suppression de celui-
ci. Les profils ne sont en dfinitives pas supprims mais mis en sommeil, lutilisation des
donnes personnelles est toujours accessible par le rseau social mme en labsence de
2

Introduction

connexion de lutilisateur comme certaines affaires lont dmontr ces dernires annes
dans divers pays.
La problmatique actuelle peut galement dpasser le simple cadre de lutilisation

des donnes personnelles ; par exemple lajout par certains rseaux sociaux de
fonctionnalits additionnelles laisse envisager le transit par ces fonctionnalits de
problmatiques diverses : piratage, virus, Or, ces ajouts mis en place par les rseaux eux
mme ne sont pas assums par ces derniers qui dclinent toutes responsabilits
dutilisation par les usagers.
Nous sommes donc face un problme majeur pouvant se rsum au droit la vie
prive face la divulgation des donnes personnelles.
Si le cadre lgislatif semble tre dficient actuellement, dautres solutions mme

imparfaites permettent pourtant de proposer une alternative technique ce qui vient dtre
voqu. Parmi ces solutions se trouve celle des rseaux sociaux dcentraliss, que nous
nous proposons dtudier dans ce mmoire qui a t organise comme suit :
Le chapitre I prsente la gnralit sur les rseaux distribus.
Le chapitre II sorganise autour dune tude dtaille et comparative de
quatre rseaux sociaux distribus.
Le chapitre III propose une solution retenant les atouts des rseaux sociaux
distribus examins au chapitre II amliors par des fonctionnalits
novatrices.
Une conclusion gnrale clturera ce mmoire en mme temps que nous
aborderons quelques perspectives sur le futur des rseaux sociaux
distribus.
3
CHAPITRE I :
LES RESEAUX DISTRIBUES
I. LE PEER TO PEER :
Le terme peer-to-peer abrg en P2P est un modle de rseau informatique proche du

modle client-serveur mais qui est distribu de manire ce que les entits appeles peers
jouent le double rle client et serveur. Tous les ordinateurs rcuprent de linformation et
la retransmettent, en fait ils interagissent afin doffrir une communaut un service de
manire dcentralis comme montr dans la figure I.1.
Figure I.1 : Structure du rseau P2P
4

Chapitre I : Les rseaux distribus

Par ailleurs, contrairement aux ides admises, ce systme nest pas seulement
utilis pour le partage des fichiers tel que la musique, les vidos ou les logiciels. De
nombreuses entreprises en font un usage au quotidien et de diverses manires. Citons
titre dexemple :
La plate forme de calcul distribu BOINC [4] se base sur le P2P pour accder la
puissance de calcul supplmentaire, quatre fois plus que le plus puissant des
superordinateurs, dans le but de faire avancer la science, lconomie, lart
Le service de stockage en Cloud dAmazon [5] est bas sur un systme de
stockage de donnes en P2P.
Le distributeur de musique libre Jamendo [6] transmet ses 36 000 albums travers
le rseau P2P BitTorrent [7].
La technologie Flash [8] dveloppe par Adobe Systems intgre maintenant un
systme dchange P2P de flux vido.
Le logiciel de tlphonie par Internet Skype utilise son propre rseau peer-to-peer.
La plate forme du micro blogging Twitter utilise le P2P pour ses mises jours.
II. LES RESEAUX SOCIAUX DISTRIBUES :
Les services de rseaux sociaux sont des plateformes dont le but est de regrouper des
utilisateurs qui se connaissent et de partager de l'information (nouvelles, photos, vidos,
hyperliens, ) entre eux, selon le type de relations entretenues.
la diffrence d'un service de rseau social centralis (Facebook, MySpace ou

LinkedIn), o toutes les informations sont gres par une seule entit, les rseaux sociaux
distribus (Diaspora [9], Movim [10] ou Lorea [11]) offrent un stockage et une diffusion
flexible des informations. Ceci apporte une scurit accrue, un meilleur contrle de la vie
prive et moins de contraintes quant la libert d'expression : lutilisateur nest plus
seulement l'diteur des informations, il en est aussi le diffuseur.
III. LES TABLES DE HACHAGES DISTRIBUEES :
Une table de hachage est une structure de donnes qui permet dassocier une cl chaque
lment. Laccs chaque lment dans la table se fait via sa cl qui est hache via la
fonction de hachage. Le hachage est un nombre qui permet la localisation des lments
5


dans un tableau. En fait cest lindex de llment dans le tableau. Les tables de hachages
sont nommes ainsi parce quelles se basent sur une fonction de hachage.
Une table de hachage distribue abrge en DHT quant elle est une technologie
qui permet lidentification et lobtention dune information dans un rseau P2P. Elle se
constitue des nuds qui sont rpartis sur tout le rseau et qui agissent comme des sceaux
dinformations car chacun deux possde une partie des donnes de la DHT.
La DHT fournit un algorithme de recherche efficace intitul lookup service qui

permet un nud participant de dterminer rapidement quelle machine est responsable de
la dlivrance dune donne en faisant un routage dans le rseau. En effet, la DHT grce
ces nuds agit pour trouver les nuds qui contiennent les donnes et trouver o stocker
les donnes.
De ce fait, les DHTs sont trs utiles lorsque le nombre dentres est important.
Elles sont utilises notamment dans les protocoles des rseaux P2Ps tel que le protocole
Chord [12], le protocole P2P CAN [13], . En effet, les DHTs peuvent tre utilises dans
plusieurs applications comme par exemple :
Le systme en rseau de forums Usenet [14]

Le systme de mailing sans serveur ePost [15]
Le stockage de donnes OceanStore [16]
Le back web anonyme FreeNet [17]
Il existe actuellement plusieurs DHTs sur le march, certaines sont accessibles

publiquement et gratuitement, dautres sont restreintes aux personnes affilies aux
entreprises ou tablissements accueillant des nuds, nous en avons slectionns trois
permettre notre prsentation :
III.1. KADEMLIA :
Kademlia [18] abrge en KAD est parmi les premires tables de hachages distribues qui
fit son apparition en 2002. Elle spcifie la structure du rseau et lchange de
linformation travers le lookup des nuds. Ses nuds communiquent entre eux pour
former un rseau virtuel en utilisant le protocole UPD.
6


Chaque nud est identifi par un nombre intitul node ID . Cet identifiant est
utilis aussi par lalgorithme de Kademlia afin de localiser les fichiers hachs. En effet, le
node ID fournit un mapping directe des fichiers hachs et stocke des informations sur
lendroit o obtenir les fichiers et les sources.
Afin dexplorer le rseau la recherche dune certaine valeur, lalgorithme KAD

besoin de connatre la cl associe cette valeur. Lexploration seffectuera en plusieurs
tapes et dans chaque tape, lalgorithme trouvera les nuds les plus proches de cette cl
jusqu' ce que le nud contact renvoi la valeur recherche si elle existe ou une requte
pour dire quil ny a plus de nud proximit qui contient la valeur recherche.
Lun des avantages de Kademlia est lefficacit de son algorithme qui ne contacte
que (()) nud pendant sa recherche sur un total de nud dans le systme.
Dautres avantages se trouvent surtout dans sa structure dcentralise qui augmente la
rsistance contre les attaques par dnis de services. En effet, mme si un ensemble de
nuds est atteint cela naura quun effet limit sur la disponibilit du rseau. De plus le
rseau est capable de reconstruire le nud perdu.
III.2. OPENDHT :
OpenDHT [19] est une table de hachage distribue accessible publiquement, qui est
apparue en 2005 et qui appartient Planet-lab [20], qui lui est un rseau dordinateurs
utilis en tant que plateforme dessais pour de la recherche oriente rseaux et systmes
distribus.
Aucune information didentification ou de cration des comptes nest requise pour

utiliser le service. De plus le stockage de donnes est rparti quitablement entre tous les
clients actifs. Par consquent, put et get peuvent tre mises nimporte quel nud
de la DHT.
Ce model de service de la DHT simplifie considrablement le dploiement des

applications clientes. En effet, en utilisant OpenDHT pour le lookup et le stockage des
donnes, les clients peuvent ignorer la complexit du dploiement et le maintien de la
DHT pour se concentrer sur le dveloppement des applications rparties.
7


La simple interface de put and get est accessible via les protocoles SUN RPC
[21] et XML RPC [22]. En tant que tel, le service a un accs facile partir de
pratiquement tous les langages de programmation et peut passer derrire presque tous les
pare-feu.
III.3. FREEPASTRY :
FreePastry [23] est une implmentation open source du protocole P2P Pastry [24]. Ce
dernier est une couverture du routage du rseau Internet pour la mise en uvre dune
DHT. Les paires cl-valeur sont stockes sur un rseau P2P redondant de serveur connect
Internet.
Le protocole est amorc en lui fournissant des adresses IP des peers qui sont
toujours dans le rseau. Cet amorage permet la reconstruction et la rparation dune table
de routage dynamique.
En raison de sa nature dcentralise et redondante, il ny a pas de point de

dfaillance. Ainsi, un nud peut quitter le rseau tout moment sans avertissement avec
peu ou pas de risque de perte de donnes.
Le protocole est aussi capable dutiliser une mtrique de routage fournie par un
programme extrieur tel que le Ping afin de dterminer les meilleurs itinraires stocker
dans sa table de routage.
IV. LA SAUVEGARDE FRIENDSTORE :
Friendstore [25] est un mcanisme de sauvegarde coopratif des donnes en ligne

avec les nuds de confiance tant gnralement les amis de la vie relle, facile
d'utilisation pouvant servir pour des raisons diverses comme par exemple :
Il ny a aucun besoin de payer pour un service de sauvegarde en ligne.

La coopration entre les amis en ligne et les donnes sauvegardes pour chacun.
Si lutilisateur est hors ligne, les amis qui gardent une copie de ses donnes
peuvent servir les demandeurs de ses informations.
De plus, ce mcanisme est gratuit et open source, il peut tre rajout a dautres
applications en extension comme nous allons le voir dans ce le chapitre II.
8
CHAPITRE II :
ETAT DE LART
I. INTRODUCTION :
Les rseaux sociaux distribus en ligne sont apparus afin de riposter au problme majeur
des rseaux sociaux centraliss voqu dans lintroduction savoir la protection des
donnes des utilisateurs. Il en existe plusieurs tel que : Diaspora, Persona [26], LotusNet
[27], SuperNova [28], .
La particularit que ces rseaux ont en commun ce compose de trois contraintes :

La confidentialit, la disponibilit et lintgrit. Certains essayent de respecter au moins
deux de ces contraintes, dautres au contraire les respectent toutes, du moins selon eux,
mais est-ce vraiment le cas ? Cest ce que nous allons voir la fin de ce chapitre. Parmi
l'ensemble des rseaux disponibles, nous en avons slectionns quatre majeurs en fonction
de leur capacit permettre notre prsentation mais voyons dabord ce que signifient ces
contraintes.
I.1. CONFIDENTIALITE :
Les informations de lutilisateur ne doivent tre vues que par lutilisateur lui mme et les
personnes avec qui il les a partag. Aucune autre partie interne ou externe ne doit pouvoir
consulter le contenu de ces informations.
9

Chapitre II : Etat de lart

I.2. INTEGRITE :
Les donnes et lidentit de lutilisateur doivent tre protges contre les modifications
non autorises et les falsifications. La cration de faux profils est facile au sein des
rseaux sociaux, donc lauthentification doit sassurer de lexistence des personnes relles.
I.3. DISPONIBILITE :
La disponibilit des donnes doit tre assure pour que les donnes existent en
permanence, ainsi la disponibilit des profils utilisateurs doit tre protge contre les
censures (La suppression autoritaire dinformation) et le Hijacking [29] (dtournement ou
possession illgale dune donne).
II. DEFINITION ET CONCEPTION :
II.1. PEERSON:
PeerSon [30] est une approche peer-to-peer distribue et couple avec un systme de
chiffrement. Son infrastructure est faite justement pour supporter les caractristiques les
plus importantes des rseaux sociaux en ligne (telles que : la messagerie instantane, le
mur, le fil dactualit,) dans un environnement distribu. Il vise maintenir les
caractristiques des rseaux sociaux en ligne en surmontant deux limitations : La question
de confidentialit et lexigence dune connectivit internet pour toutes les transactions.
Pour rsoudre le problme de confidentialit, un systme de cryptage et de contrle

daccs est utilis en couplage avec une approche P2P pour remplacer lautorit
centralise des rseaux sociaux en ligne classiques. Ces mesures empchent les violations
de la vie prive des utilisateurs par les fournisseurs de ces systmes, les annonceurs et
mme les utilisateurs eux mme.
Sa conception rpond principalement trois exigences : Le chiffrement des donnes,

la dcentralisation de larchitecture et lchange direct entre les utilisateurs. En un mot, le
chiffrement assure la confidentialit pour les utilisateurs, la dcentralisation base sur
lutilisation dune infrastructure P2P permet quant elle lindpendance des fournisseurs
des rseaux sociaux en ligne, ce qui rend plus facile lintgration de lchange direct des
donnes entre les appareils des utilisateurs dans le systme.
10


a - LE CHIFFREMENT DES DONNEES :
Le moyen de protection de la vie prive dans ce contexte est de permettre aux utilisateurs
de crypter et contrler laccs leurs donnes. Laccs ces donnes se fait travers le
partage de la cl approprie, cependant, les considrations de la scurit incluent
lamorage, la distribution et la rvocation des cls.
b - LA DECENTRALISATION DE LARCHITECTURE :
Pour mieux protger la vie prive, les donnes des utilisateurs sont cryptes et accessibles
uniquement ceux qui ont les cls de dchiffrement. Cest lutilisateur lui mme qui
dtermine avec qui partager les cls de dcryptages des donnes quil publie.
Par ailleurs, il nest pas ncessaire de faire valoir le fait que mme si les donnes
sont cryptes et centralises, le prestataire du service central pourrait tre en mesure de
dcrypter ces donnes et de les utiliser.
c - ECHANGE DIRECTE ENTRE LES UTILISATEURS :
Puisque le service du rseau social est dcentralis et nest pas bas sur un serveur web,
les utilisateurs nont pas besoin dtre constamment en ligne pour lutiliser. Ils peuvent
donc changer des informations directement entre eux quand ils se connectent.
Ainsi, les utilisateurs peuvent stocker les donnes des autres utilisateurs et diffuser
les informations travers le rseau social physique ou retarder le tlchargement des
donnes jusqu' ce que quelquun dispose dune connectivit en ligne.
II.2. SAFEBOOK :
Safebook [31] a pour but la protection de la vie prive en se basant sur les relations de
confiance de la vie relle. Cest une nouvelle approche des rseaux sociaux en ligne qui
selon Refik Molva et .al [32] est base sur deux principales raisons :
La dcentralisation via une architecture peer-to-peer, afin dviter le contrle

de donnes des utilisateurs et leur comportement sur le rseau par une seule entit
tel que le fournisseur du service.
11


Lexploitation de la confiance relle de la vie via la gestion de confiance et de

protection de la vie prive des donnes des utilisateurs et les communications dans
le systme du rseau social en ligne en exploitant les relations de confiance
partir de ce mme rseau social.
Sa conception rpond un large ventail dexigences de scurits dont la

pertinence est recueillie partir d'une srie d'tudes, on distingue : la confidentialit de
bout en bout, lauthentification, le contrle daccs, la vie prive, lintgrit des donnes et
la disponibilit des donnes.
a - CONFIDENTIALITE DE BOUT EN BOUT :
Elle a pour but de garantir quaucune autre partie en dehors des deux peers communicant
ne pourra avoir accs aux donnes changes en rendant galement impossible lcoute.
Parce que dans les systmes peer to peer les messages changs par les peers peuvent
contenir un contenu malveillant post par une attaque de man in the middle [33]. Il est
important ddifier un centre spcial contre ces attaques qui peuvent facilement tre
monter dans un tel environnement.
b - LAUTHENTIFICATION :
Une authentification particulire des membres est requise afin dachever le contrle
dapproche. La politique Fine-Grained Policy [34] du contrle daccs base sur les
attributs du profile et les donnes prives peut tre utilise pour garantir la divulgation de
donnes en fonctions de lintgrit du requrant.
c - LA VIE PRIVEE :
La vie prive vise l'anonymat, la non traabilit et lincapacit suivre des

communications d'utilisateurs aussi bien que le respect de la confidentialit des
informations personnelles vis--vis des intrus et du fournisseur du systme.
d - L'INTEGRITE DES DONNEES :
L'intgrit des donnes vise empcher la falsification des donnes des profils car la
proprit de disponibilit de ces donnes reprsente une exigence permettant une facilit
principale d'utilisation. Cela garantit laccs aux profils tout moment ainsi que la
12


dlivrance des messages tout utilisateur dans les mmes conditions en empchant des
attaques de dni de service [35] et les attaques Sybil [36].
Bien que Safebook respecte ce qui a t mentionn ci-dessus, la faisabilit dune

approche dcentralise en terme de disponibilit des donnes ainsi que la ractivit du
systme restent une question ouverte.
II.3. DECENT :
Decent [37] est un rseau social en ligne dcentralis, qui emploie une DHT pour stocker
et rcuprer des objets de donnes crs par leurs propritaires. Chaque objet est crypt
pour fournir la confidentialit. L'avantage principal de cette architecture est sa modularit,
c'est--dire, les politiques daccs, les mcanismes cryptographiques et la DHT sont trois
composants spars, interagissant l'un avec l'autre par des interfaces bien dfinies.
Pour la mise en uvre du prototype, la conception modulaire fournit la capacit

d'utiliser n'importe quel type de DHT et nimporte quel type de plan cryptographique.
Cest une conception concernant les rseaux sociaux dcentraliss mettant laccent sur la
scurit et la vie prive.
Les utilisateurs de Decent utilisent un mcanisme cryptographique efficace pour la

confidentialit, combinant des plans cryptographiques traditionnels et avancs pour
lintgrit et la disponibilit. La simulation et les expriences avec le prototype
prliminaire de Decent montrent que le respect de la vie prive a t amlior.
Larchitecture Decent fournit la flexibilit pour la direction de donnes dans une

conception oriente objet. Elle utilise un plan cryptographique appropri et avanc qui
soutient une rvocation d'accs efficace et des politiques Fine-Grained Policy sur
chaque pice de donnes.
Les autres architectures se concentrent seulement sur un ou deux des trois

contraintes des rseaux sociaux distribus cites dans lintroduction. La nouveaut de cette
architecture se trouve dans l'intgration d'existants primitifs qui sont adapts pour
amliorer la scurit et la vie prive des rseaux sociaux en ligne. Ces existants primitifs
sont entre autre la politique daccs, le mcanisme de chiffrement et les algorithmes
utiliss dans les DHTs.
13


II.4. CACHET :
Cachet [38] est une approche dun rseau social distribu, base sur Decent, qui donne une
scurit optimale ainsi que le respect de la vie prive. En particulier cachet protge la
confidentialit, lintgrit et la disponibilit des donnes des utilisateurs, aussi bien que
lintimit de leurs relations via le rseau.
Cachet utilise un rseau distribu de nuds pour le stockage des donnes et assure
la disponibilit de ces derniers. Mais ces nuds ne sont pas dignes de confiance, donc, le
niveau de cryptographie a t augment par rapport Decent pour protger les donnes.
Le contenu des donnes des utilisateurs est stock dans un groupe de nuds distribus
bas sur la DHT FreePastry.
Une cryptographie adapte est utilise pour le stockage des donnes dans les
nuds pour une authentique mise jour des requtes. Un cryptage bas sur les attributs
des objets changs dans le rseau est utilis pour diminuer le temps de cryptage et de
dcryptage qui tait important dans larchitecture de Decent.
Cachet est en ralit une volution de Decent. Le rsultat obtenu montre

limportance dutiliser le rseau de Cachet, qui rduit la latence de la visualisation dune
page dactualit de 100s en moins de 10s. Cette architecture dmontre que la combinaison
de plusieurs systmes distribus et les techniques cryptographiques peuvent tre utilises
pour avoir une alternative de protection de vie prive convaincante par rapport aux
rseaux sociaux centraliss.
III. ARCHITECTURE DES RESEAUX SOCIAUX DISTRIBUES :
Nous avons tudi soigneusement les architectures et les composants de ces quatre
rseaux sociaux, et nous les avons simplifi afin de les prsenter comme suit :
III.1. ARCHITECTURE DE PEERSON :
Sonja et .al [39] ont dfinit une approche P2P distribue couple avec un systme de
chiffrement et une extension de lapproche dcentralise par lchange directe des donnes
entre les utilisateurs.
Pour valider cette approche, Doris Schiberg [40] a conu une architecture 2 tiers
14


avec des protocoles qui recrent les caractristiques fondamentales des rseaux sociaux
classiques de manire dcentralise.
a - 1ER TIERS : (LE LOOK UP SERVICE)
Il sagit dun systme de consultation des DHT, qui stocke les mtadonnes telles que :
Les adresses IP, les informations sur les fichiers, des informations sur les utilisateurs,
Ces mtadonnes sont ncessaires afin de pouvoir trouver les utilisateurs, leurs statuts et
les donnes quils stockent.
PeerSon utilise OpenDHT, donc si lutilisateur est hors ligne, alors la DHT pourra
stocker les donnes quelle reoit pour une dure limite. Plus de dtails peuvent tre
retrouvs sur OpenDHT dans le chapitre I.
b - 2e tiers : (LES PEERS)
Ce tiers est constitu des peers et contient les donnes des utilisateurs. Chaque
utilisateur qui se connecte au rseau contactera dabord le lookup service pour le prvenir
de sa connexion. Un utilisateur qui souhaite communiquer avec un autre de manire
synchrone ou asynchrone interroge dabord le lookup service pour obtenir toutes les
informations ncessaires. Les peers se connectent directement entre eux aprs cela et
interrompent leur lien de conversation directement aprs lchange des messages
asynchrones.
Une reprsentation simplifie de larchitecture de PeerSon est montre dans la figure II.1.
Figure II.1 : Architecture de PeerSon.
15


III.2. ARCHITECTURE DE SAFEBOOK :
Leucio Antonio et .al [41], ont propos une nouvelle approche pour sattaquer aux
problmes de scurit et de confidentialit lis aux rseaux sociaux centraliss. Le
prototype [42] de cette approche est crit en python et peut tre excut sur de multiples
systmes dexploitation. Il est compos de quatre gestionnaires diffrents :
Le gestionnaire de communication qui soccupe de lenvoi et de la rception des

paquets sur le rseau.
Le gestionnaire de S2S qui sappuie principalement sur la couche de la DHT.
Le gestionnaire de la Matryoshka qui se base sur la couche du rseau social.
Le gestionnaire de lutilisateur qui implmente linterface utilisateur.
Afin d'assurer la confidentialit des utilisateurs face d'ventuelles violations de la

vie prive par le fournisseur, l'approche propose adopte une architecture 3tiers. Cette
approche est dcentralise avec un mapping directe entre les trois couches qui constituent
le rseau social, en s'appuyant sur la coopration entre un certain nombre de parties
indpendantes qui sont galement des utilisateurs de l'application de ce mme rseau.
Figure II.2 : Couches de Safebook ( droite) et principaux composants ( gauche)
Les couches et principaux composants de Safebook sont reprsents dans la figure

II.2 [43] et dtaills comme suit :
La couche du rseau social centre sur lutilisateur implmente le niveau du rseau

social qui est la reprsentation numrique des membres et leurs relations dans les
rseaux sociaux en ligne.
16


Le service de management offert par le fournisseur du rseau social est

implment dans la couche du support P2P afin de grer linfrastructure de
lapplication.
Internet qui, elle, reprsente la couche de communication et de transport.
Dans Safebook, chaque partie est reprsente par un nud considr comme un
nud hte dans la couche Internet, un nud peer dans la couche P2P et un membre dans
la couche du rseau social. Ces nuds forment deux types de couche :
a - MATRYOSHKA :
Un ensemble de Matryoshka est une structure concentrique dans la couche du rseau

social, elle fournit le stockage des donnes et la confidentialit des communications autour
de chaque nud.
Les Matryoshkas sont construites autour de chaque nud de membre afin de

fournir un stockage de donnes fiable, une possibilit de rcupration de donnes et un
brouillage des communications.
Chaque Matryoshka, comme reprsente dans la figure II.3 [43], protge le centre
du nud qui est appel noyau, ce qui, dans la couche du rseau social est adress par son
identificateur de nud. Ce noyau est encercl par des nuds. Ces nuds sont relis par
des chemins radiaux sur lesquels les messages peuvent tre relays de manire rcursive
partir de la couche externe vers le noyau et vice versa. Tous les chemins sont bass sur des
relations de confiance apparentes au rseau social. Chaque saut connecte une paire de
nud appartenant des utilisateurs lis par une relation de confiance dans la vie relle.
Les nuds qui sont les plus interne et, ceux les plus externe ont un rle particulier.
Le cercle le plus interne est compos des contacts directes du noyau, chacun de ses
contacts stocke chez lui les donnes de ce noyau sous forme crypte. Ces nuds sont donc
appels miroir. Quand aux nuds du cercle le plus externe, ils sont considrs comme une
passerelle pour toutes les demandes adresses ce noyau. Ils sont appels des points
dentres.
Toute demande vers un noyau, lui est adresse en utilisant son identificateur, qui
peut tre retrouv dans la DHT. Cependant la communication en temps rel est transmise
17


par le noyau lui mme, par contre les communications en mode hors ligne peuvent tre
desservies par un de ces miroirs.
Le nombre de miroirs et de points dentre dans chaque voie est fix. Par contre, le
nombre de nud entre eux peut tre variable ce qui conduit des chemins de longueur
variable dans la mme Matryoshka.
Figure II.3 : Structure dune Matryoshka
b - LE SYSTEME P2P:
Afin de fournir un service de localisation pour trouver les points dentrs vers une
Matryoshka dun utilisateur, les nuds crent un support P2P. Actuellement ce support
ressemble KADMELIA cit dans le chapitre I ; ainsi les pseudonymes sont utiliss
comme identifiants pour la DHT. Les cls de recherche qui sont enregistres sont la
proprit des membres participants ainsi que leurs identifiants de nuds.
Cependant la communication travers la couche P2P ne repose pas sur des liens de
confiance contrairement la voie travers une Matryoshka. Toutefois, lutilisation des
pseudonymes permet la protection des membres contre la violation des droits de la vie
prive fonde sur lidentification et le traage des nuds via des liens P2P non fiables.
c - SERVICE DINDENTIFICATION DE CONFIANCE :
Ce service garantit que chaque utilisateur de Safebook obtient au plus un identifiant

unique dans chaque catgorie didentifiants. Il est bas sur une procdure
dauthentification nomme out-of-band [44]. Ce service didentification de confiance
accorde chaque utilisateur une paire unique didentifiants de nud et de pseudonyme.
18


Cette paire est une cl rsultante du calcul dune fonction de hachage sur lensemble des
proprits qui lidentifient de faon unique dans la vie relle telles que : nom, prnom,
date de naissance, lieu de naissance,
Il est noter que ce service didentification de confiance est utilis comme une
troisime partie qui est centralise et semble sopposer au but de la dcentralisation.
Cependant, il ne constitue aucune menace la vie prive car il ne peut pas tracer les
utilisateurs ou leurs messages changs.
III.3. ARCHITECTURE DE DECENT ET CACHET :
Decent comme montr dans la figure II.4 est bas sur une architecture 2 tiers o les
donnes sont stockes comme des objets dans une DHT qui utilise un object ID
comme cl en plus dun standard push and get operation ; la DHT supporte aussi une
opration additionnelle au stockage dans les nuds avec la WritePolicy [45] sur les objets.
La disponibilit des donnes est assure par leur rplication. Le lookup service
utilise le protocole de la WritePolicy pour empcher les utilisateurs malveillants de
modifier ou supprimer les donnes disponibles dans la DHT parce quils nont pas la
bonne signature. Celle-ci est gnre par le hachage de la cl publique de la WritePolicy et
le cryptage des donnes. Elle fera partie de lobjet mtadonne galement crypt. Donc le
nud de stockage refusera de rcrire lobjet stock sauf si la nouvelle donne est signe
proprement par la cl WritePolicy.
La cl publique de la WritePolicy est alatoire pour chaque objet afin dempcher

la liaison d'un objet son propritaire.
Cependant, vu que Cachet est une volution de Decent alors il se base bien
videmment sur son architecture mais en rajoutant un tiers, l ou dans Decent il ny avait
que les peers et les DHT, Cachet a rajout des DHT pilotes comme montr dans la figure
II.4. Ces DHTs contiennent lannuaire globale du rseau, parce quelles ont connaissance
de contacts appartenant quelle DHT. Cela facilitera la recherche et optimisera le temps.
19


Figure II.4: Architecture de Decent gauche et architecture de Cachet droite
IV. PROTOTYPES DES RESEAUX SOCIAUX DISTRIBUES :
IV.1. PROTOCOLE DE PEERSON :
Cette section dcrit comment l'architecture de PeerSon est implmente et quoi

ressemblent les diffrents protocoles. Le dtail de toute la syntaxe du protocole
peut tre retrouv dans . 14
a - IDENTIFIANT GLOBALE UNIQUE (GUID) :
Le systme du rseau social distribu doit rsister des attaques importantes

comme les attaques Sybil et les dnis de services tout en s'assurant que les
identits des utilisateurs sont uniques.
Cette rsistance peut tre facilement deployable dans un environnement

centralis, hormis le fait que dans un environnement dcentralis le dploiement
est trs difficile. PeerSon assume qu'aujourd'hui chaque utilisateur possde une
adresse email qui est unique et donc utilisable comme identifiant. Mais pour
empcher les nuds malicieux dans les DHT de collecter les adresses emails, un
hash de chaque mail est calcul et utilis comme identifiant unique.
b - LA PROCEDURE DE CONNEXION :
Se connecter au rseau signifie qu'un certain utilisateur annonce quil est

actuellement en ligne avec les mtadonnes ncessaires pour le joindre, ainsi
qu'une liste des fichiers que ce peer stocke.
20


Cette annonce est envoye l'OpenDHT qui son tour prvient les autres
utilisateurs. C'est ce qui permet aux utilisateurs de suivre le statut de leurs amis.
c - LA RECUPERATION D'UN FICHIER:
Les messages sur PeerSon sont traits comme des fichiers. La dcouverte de ces
fichiers est traite par des requtes envoyes la DHT pour trouver quel peer
contient le fichier recherch. Le rsultat renvoi le nom du fichier si celui-ci existe,
le numro de la (les) version (s) existante(s) ainsi que le nom du peer contenant ce
fichier. C'est l'utilisateur demandant qui dcidera quelle version il souhaite obtenir
et depuis quel peer.
d - LES MESSAGES ASYNCHRONES :
PeerSon permet les messages asynchrones tel que le mur de Facebook ou la

messagerie instantane mme lorsque l'utilisateur est dconnect. La rception en
mode hors ligne est gre par le stockage des messages au sein de la DHT jusqu'
ce que le rcepteur se reconnecte.
IV.2. PROTOTYPE DE SAFEBOOK :
Safebook a implment diffrentes oprations des rseaux sociaux en ligne telles que : la
cration des comptes, la publication des donnes, la rcupration des donnes, les requtes
de demande de contact et dacceptation ainsi que la gestion des messages.
Lors de lajout dun nouveau contact, une confiance particulire lui est attribue de
la part de celui qui lajoute. Ce niveau de confiance ne peut tre connu que par lutilisateur
lui mme et non pas par ses contacts. Donc ses contacts ne peuvent savoir dans quel cercle
de confiance ils se trouvent. Cest ce niveau de confiance qui permet de dterminer qui de
ces contacts va tre utilis comme miroir pour rpliquer ses donnes.
Pour garantir la confidentialit dans Safebook, les donnes peuvent tre prives,
protges ou publiques.
Prives : les donnes ne sont pas publies

Protges : les donnes sont publies mais cryptes.
Publiques : les donnes sont publies.
21


Toutes les donnes publies sont rpliques dans les miroirs de lutilisateur ;
cependant, dans Safebook si un utilisateur et tous ses miroirs sont hors ligne alors son
contenu sera inaccessible.
IV.3. PROTOTYPE DE DECENT ET CACHET :
Decent et Cachet ont implment diffrentes parties dans leurs prototypes propre eux et
qui font leurs points forts tel que l ABE Policy [46] et la Cryptography Policy
[47], o ils sont passs de quelques centaines de seconde de cryptage et dcryptage chez
Decent quelques dizaine de seconde seulement chez Cachet.
Pour leur prototype, Decent et Cachet ont dvelopp un mur et une page dactualit
qui pour un utilisateur est une collection des derniers statuts mise jour par chacun de ses
contacts (amis) pour avoir une page dactualit pour chaque utilisateur ;
LABE format contient la politique ncessaire pour le chiffrement des donnes, les
utilisateurs peuvent savoir sils seront aptes dcrypter lobjets ou non et sils seront
autoriss lire les informations ou pas donc ils ne perdront pas de temps dcrypter des
informations sils nont pas le droit de les lire.
Dans larchitecture de Decent, le dcryptage des donnes ncessitait beaucoup de

temps sans aucune performance de caching pour gnrer la page dactualit. Par
ailleurs, lutilisateur navait pas besoin de lire toutes les actualits de ses contacts, une
slection devenait donc ncessaire, elle fut introduite dans l'architecture de Cachet.
De plus, Cachet adopte le social caching , car tant donn l'utilisation de la

dcentralisation et la cryptographie dans larchitecture prcdente qui est Decent,
tlcharger et reconstruire le mur d'un contact social ou la page dactualit est un long
processus exigeant les tapes suivantes :
Dcrypter des objets de mise jour, qui sont ABEncrypted suivant la ABE Policy;
Rapporter des mtadonnes comme une mise jour ;
Indexer la cl de dcryptage symtrique dans la DHT;
Accder des petits objets multiples situs dans diffrents nuds de stockage
utilisant la DHT fournie dans l'tape prcdente ;
Dcrypter des objets de mise jour avec leurs cls symtriques correspondantes.
22


a - RECHERCHE D UN CONTACT SOCIAL :
Pour permettre aux utilisateurs de rechercher leurs contacts, Cachet propose un service
centralis dadministration qui maintient le mapping entre les contacts et leurs racines
(profile). Pour permettre ce service de connatre les relations des utilisateurs, cette
architecture utilise :
Un canal de communication anonyme ;

Afin de cacher les noms des utilisateurs dans lannuaire de la DHT, il est
ncessaire daugmenter le niveau du protocole de scurit concernant la vie prive.
Il est dusage de croire que cachet garantit le respect de la vie prive et surpasse
tous les autres systmes existant dans ce domaine mais, beaucoup de changements
afin de lamliorer sont encore mettre en place tels que:
lalgorithme de social caching transmet des informations sur les identits des
utilisateurs.
le mur dactualit rvle si un utilisateur est en ligne ou hors ligne.
b - SUPPRESSION ET ANNULATION :
Quand un utilisateur efface un objet ou modifie la politique daccs celui-ci, ces

changements sont affects immdiatement aux donnes. Le protocole de modification
nest pas spcifi dans ce travail, lutilisateur peut donc envoyer une requte de rvocation
pour effacer des objets sur Cachet.
c - PROTOCOLE DE PRESENCE :
En gnrale dans un rseau centralis le serveur garde la trace de la prsence de ses

utilisateurs. Cependant, dans Cachet une approche distribue est applique quand chaque
nud enregistre sa prsence dans la DHT afin que la prsence des utilisateurs dans le
rseau soit effective.
La prsence de cet utilisateur en ligne a la mme structure que les objets et est
crypte avec ABEncryption pour empcher la DHT de lire le contenu de cet objet. Cette
structure est dfinie par une adresse IP et un numro de port. Ce qui permet lutilisateur
deffectuer des modifications son profil en ajoutant ou supprimant des informations
23


quand il le dsire. La DHT met jours ces informations qui sont similaires au remplissage
de la page dactualit.
V. STOCKAGE DES DONNEES :
Pour le prototype actuel de PeerSon, la meilleure faon pour stocker les donnes est de le
faire chez leurs propritaires ainsi que sur lespace de stockage de leurs amis en suivant
lalgorithme Friendstore [48]. Dans ce cas l, ces donnes ne sont disponibles que lorsque
le propritaire et/ou ses amis sont en ligne. Ceux qui veulent les consulter doivent avoir
les permissions ncessaires.
Quant Safebook, les donnes sont stockes dans les machines appeles miroirs,
cest lutilisateur qui attribue un certain niveau de confiance chacun de ses contacts et
cest ce niveau de confiance qui va permettre de choisir les contacts chez qui il stockera
ses donnes.
Cependant, Decent et Cachet utilisent un autre systme de stockage, ils stockent les
donnes dans des DHTs distribues afin dassurer une disponibilit permanente tout en
augmentant le niveau de cryptage de donnes pour assurer lintgrit et la confidentialit.
VI. DIAGRAMME DE SEQUENCE
Aprs avoir fait une analyse de larchitecture et du prototype de chacun des rseaux
slectionns, nous avons ralis des diagrammes simplifis pour une meilleure
comprhension des comportements de ces rseaux sociaux. Nous avons trait dans chacun
deux quatre cas : cration dun nouveau profil, connexion au rseau, gestion des
messages et lajout dun nouveau contact.
VI.1. DIAGRAMME DE PEERSON :
Dans larchitecture de PeerSon il y a diffrentes parties :
Tout dabord, PeerSon est ralis de telle manire que nous puissions accder au
rseau social depuis diffrents appareils et divers endroits. Afin de savoir sur quel appareil
lutilisateur est disponible, lquipe de PeerSon a dfini trois modes de connexion, le
24


mode en ligne, le mode actif et le mode hors ligne. Par ailleurs il existe un point spcifique
dans cette architecture :la possibilit daccder au rseau mme en mode hors ligne.
Le mode en ligne signifie que lordinateur de cet utilisateur se trouve connect au

rseau sans que lutilisateur ne soit ncessairement prsent.
Le mode actif, dfinit que lutilisateur est connect et disponible sur le rseau.
Le mode hors ligne est utilis pour prvenir la DHT que cet utilisateur a quitt le
rseau pour qu son tour elle puisse prvenir les autres utilisateurs.
a - CREATION D UN NOUVEAU PROFIL :
Quand un nouvel utilisateur voudra sinscrire sur le rseau PeerSon, il devra tlcharger
dabord une application qui lui permettra lutilisation de PeerSon et le stockage des
fichiers.
Lors de la premire utilisation, le nouvel utilisateur crera un profil comme montr

dans la figure II.5, la DHT utilisera le hashage de son email pour gnrer un identifiant
globale unique (GUID). Lutilisateur doit alors confirmer son GUID, et au final la DHT
ajoutera alors les mtadonnes ncessaires pour sa localisation et son statut. Il est noter
aussi que dans PeerSon lutilisateur peut se connecter depuis plusieurs endroits, cest la
combinaison GUID/statut qui permet justement ce genre de connexion.
Figure II.5 : PeerSon Inscription
b - CONNEXION AU RESEAU :
Quand un utilisateur rejoint le rseau, comme montr dans la figure II.6 il envoi une
requte la DHT afin de la prvenir quil vient de rejoindre ledit rseau. La DHT lui
renvoie alors le statut des autres appareils depuis lesquels il a lhabitude de se connecter et
si lun dentre eux est en mode actif, alors le mode en ligne se mettra sur cet appareil et le
25


mode actif apparatra sur lappareil avec lequel il vient de se connecter. Si aucun appareil
nest en mode actif, alors ce dernier recevra ce mode par dfaut.
Nous dnommons cette procdure par le mot login, ces trois tapes ne changent
pas pour les autres utilisateurs lorsquils se connectent au rseau.
Figure II.6 : PeerSon Connexion au rseau
c - GESTION DES MESSAGES :
PeerSon permet lutilisation du rseau en mode en ligne et hors ligne, de plus en labsence
de lutilisateur, son contenu peut tre prsent en fonction de ses amis. Cependant, avant
quun utilisateur communique avec un autre il doit le localiser.
Localisation et statut du peer :
Quand un peer veut communiquer avec un autre peer alors il doit demander la DHT de
localiser le peer dsir ainsi que son statut comme montr dans la figure II.7. La
localisation permet de savoir sur combien dappareils ce peer lhabitude de se connecter.
Le statut permet de dfinir tout dabord si lutilisateur est en ligne ou hors ligne. Sil est
en ligne, le statut permet de vrifier le mode actif sur un appareil ou simplement le mode
en ligne.
Figure II.7 : PeerSon Localisation et statut du peer
26


Mode synchrone et asynchrone en ligne :
Aprs le rsultat de la localisation et le statut, si le peer recherch (dans notre cas cest le
peer B) est en ligne, alors que se soit pour la communication en mode synchrone
(messagerie instantane) ou asynchrone (publication sur le mur) la communication
seffectuera directement entre les peers (expditeur et destinataire) comme montr dans la
figure II.8. Cependant, il est noter quune dconnexion immdiate se fera aprs
lchange des messages asynchrones.
Figure II.8 : PeerSon Mode synchrone et asynchrone en ligne
Mode asynchrone hors ligne :
Quand un peer A annonce quil voudrait consulter le mur dun peer B, la DHT vrifie sil
est en ligne ou hors ligne ; sil est en ligne, il passe par ltape que nous venons de voir
la figure II.8. Mais sil est hors ligne comme dans la figure II.9, alors la DHT vrifiera
dabord si les amis du peer B qui stockent ses donnes sont en ligne, si oui, elle donnera
ladresse IP des peers contenant les donnes de B ainsi que la version disponible. Le peer
A peut alors consulter le mur du peer B ou mme effectuer des publications,
commentaires, .
Lors de la connexion ultrieure du peer B au rseau, il effectuera dabord la requte login

ensuite il demandera une actualisation de son profil. La DHT annoncera ses amis quil
sest connect et ceux qui ont la dernire version de son statut procderont son
actualisation.
27


Figure II.9 : PeerSon Mode asynchrone hors ligne
Mode synchrone hors ligne :
Quand un peer A dsire envoyer un message instantan au peer B et dtecte que celui-ci
nest pas connect, il peut lui laisser un message qui sera stock dans la DHT comme
montr dans la figure II.10, mais lOpenDHT ayant quelques limites le message sera
stock pendant sept jours et ne devra pas dpasser 800 caractres. Toutefois quand le
message est stock sur la DHT, si le peer destinataire se connecte au rseau en utilisant la
procdure login, puis demande une actualisation de son profil, sans avoir dpass les sept
jours requis, la DHT lui enverra une mise jour de ce quil aura pu rater ainsi que les
messages qui ont t stocks chez elle pendant son absence. Aprs cela le message sera
effac de la DHT et sera stock chez son destinataire.
Figure II.10 : PeerSon Mode synchrone hors ligne
28


d - AJOUT DUN NOUVEAU CONTACT :
Dans PeerSon quand un utilisateur A veut ajouter un utilisateur B sa liste dami, il

enverra une requte la DHT pour rechercher dabord si ce dernier existe et si tel est le
cas de le localiser comme montr dans la figure II.11. Une fois que le peer A aura reu
ladresse du peer B, il lui envoi une demande dajout dans la DHT et cest elle qui
soccupera de lui envoyer la requte de lajout lorsquil sera enligne, sil accepte la
demande alors la DHT mettra jour leurs listes damis respectives. Il ne leur reste plus
que dchanger leurs cls de dcryptage respectives et commencer communiquer.
Figure II.11 : PeerSon ajout dun contact
VI.2. DIAGRAMME DE SAFEBOOK :
Aprs avoir fait une analyse de larchitecture et du prototype de Safebook, nous proposons
des diagrammes simplifis pour une meilleure comprhension du comportement de ce
rseau social.
Tout dabord nous allons voir les tapes de cration dun nouveau profil, ensuite
nous verrons comment un utilisateur peut se connecter au rseau, nous aborderons par la
suite la communication synchrone et asynchrone entre deux utilisateurs en mode en ligne
et en mode hors ligne.
a - CREATION D UN NOUVEAU PROFIL :
Pour rejoindre le rseau Safebook, un nouveau membre doit tre invit par un de ses amis
de la vie relle dj membre enregistr dans le rseau. Le compte de ce nouveau membre
29


est donc cr lors de deux tapes : cration de lidentit et cration de la Matryoshka.

Nous avons simplifi ces tapes de cration et nous vous les prsentons sous forme de
diagramme de squence comme suit :
Cration de lidentit :
Nous avons suppos que lutilisateur A est dj enregistr sur le rseau Safebook. Cet
utilisateur va alors envoyer une invitation par email un de ses amis (amis, famille, ) de
la vie relle. Si cette personne dcide de rejoindre le rseau, elle se connecte sur ce dernier
et cre un profil. Le profil est cr dans la machine de lutilisateur et rfrenc dans la
DHT, cette dernire ajoutera les mtadonnes du nouveau profil et prviendra le service
didentification de confiance (S.I.C). Le S.I.C va donc demander une fourniture de preuve
pour sassurer quil sagit bien de cette personne en fournissant par exemple des
informations telles que le nom, le prnom, la date et le lieu de naissance.
Cette preuve est prsente sous forme de processus out-of-band et consiste

rajouter une pice didentit, un passeport ou encore une runion en face face entre le
nouvel utilisateur et la reprsentation du S.I.C. Cette tape est primordiale car elle permet
dviter les attaques dusurpation didentit et les attaques Sybil.
Aprs la vrification de la certitude des informations, le S.I.C calcule lidentifiant

du nud de ce membre qui sera unique dans le rseau. Une fois que lutilisateur aura reu
son identifiant il pourra alors rejoindre le systme P2P en utilisant le contact quil la
invit comme un nud damorage et peut donc commencer la cration de sa Matryoshka.
La figure II.12 montre les tapes cites ci-dessus en un diagramme de squence :
Figure II.12: Rejoindre Safebook - Cration de lidentit
30


Cration de la Matryoshka :
Le nouveau membre a seulement son invitant comme contact pour commencer. Il lui
envoi une requte pour crer le chemin qui contient les cls de la recherche quil souhaite
enregistrer dans la DHT, le temps de vie de cette requte (TTL) et le nombre de membres
qui son invitant doit transmettre la demande. Ce nombre sera appel facteur de porte
par la suite.
Linvitant slectionne un intervalle de porte des sauts suivants et leur transmet ce

message denregistrement. Ce processus est rpt de manire rcursive jusqu' ce que le
TTL expire. A son expiration, le dernier nud qui aura reu le message denregistrement
lenregistre dans la DHT en utilisant son identifiant et son adresse lui et commence
agir comme tant son premier point dentre.
La DHT renvoi alors ce nouvel utilisateur la confirmation de la cration de sa

Matryoshka ainsi que ladresse de son premier point dentre. Cependant parce que le
facteur de porte peut tre diffrent dun chemin lautre, plusieurs points dentres
peuvent tre dfinis et ne pas appartenir la mme couche.
La figure II.13 montre les tapes de cration de la Matryoshka avec un seul point dentre.
Il sagit de la mme procdure pour les autres points dentres vers le mme utilisateur.
Figure II.13 : Rejoindre Safebook - Cration de la Matryoshka
31


b - SE CONNECTER AU RESEAU :
Quand un utilisateur se connecte au rseau, il envoie une requte de connexion la DHT,

cette dernire diffuse linformation que le peer A sest connect sur le rseau P2P, ses
amis qui se trouvent en ligne ce moment vont tre informs de sa connexion et si ses
miroirs sont en ligne alors ils synchroniseront avec lui les donnes asynchrones publies
en son absence comme montr dans la figure II.14.
Figure II.14 : Safebook - se connecter au rseau
c - GESTION DES MESSAGES
En dehors de ses amis appels miroirs, dans Safebook, chaque utilisateur qui veut
consulter les donnes dun autre utilisateur envoie dabord une requte rcursive dans le
systme P2P.
En fonction de la structure de la DHT, le nud responsable de la cl de recherche

rpond avec une liste des points dentres qui constituent le cercle le plus externe vers cet
utilisateur. Dans ce cas, lutilisateur qui veut consulter les donnes dun autre, pourra
demander un des points dentres de cet utilisateur de lui transmettre la requte travers
la Matryoshka.
Nous avons distingu quatre modes de dlivrance de cette requte :
Mode asynchrone en ligne :
Dans ce mode, la requte est envoye dans le systme P2P travers la Matryoshka en saut
par saut jusqu' ce quelle arrive chez lutilisateur cibl. Ce dernier chiffre ses donnes
avec la cl publique du demandeur et les renvoie travers le chemin inverse comme
montr dans la figure II.15.
32


Le protocole de Safebook utilise la rcursivit pour cacher la source des demandes,

et le cryptage pour sassurer que seul lmetteur de la requte est lgitime regarder ses
donnes. Bien videmment ces donnes sont aussi cryptes et signes par leur propritaire
et seul les membres qui auront une cl de dcryptage pourront en voir le contenu. Les
attaquants dans ce cas nauront aucun moyen didentifier une source de demande car, il
nest pas possible de faire la distinction entre les requtes gnres et transmises.
Figure II.15 : Safebook mode asynchrone en ligne
Une tude de faisabilit prliminaire ralise avec une approche prcdente moins
performante7 a montr que la rcupration de donnes fonctionne bien mme si les
messages sont achemins le long de plusieurs sauts dans la Matryoshka.
Mode asynchrone hors ligne :
Dans ce mode la requte est aussi envoye dans le systme P2P travers la Matryoshka en
saut par saut jusqu' ce quelle arrive chez les amis miroirs de lutilisateur demand. Si un
de ces miroirs est en ligne alors il chiffre les donnes demandes avec la cl publique du
demandeur et les renvoie travers le chemin inverse comme montr dans la figure II.16.
Figure II.16 : Safebook mode asynchrone hors ligne
33


Mode synchrone en ligne :
La messagerie instantane est transmise et manipule par le noyau et son interlocuteur

uniquement. Comme la montre la figure II.17.
Figure II.17 : Safebook mode synchrone en ligne
Mode synchrone hors ligne :
Dans Safebook la messagerie instantane nest pas gre dans le mode hors ligne, et si un
utilisateur envoie ce genre de message un autre utilisateur alors que ce dernier est
dconnect, un message derreur lui est envoy par la DHT comme montr dans la figure
II.18.
Figure II.18 : Safebook mode synchrone hors ligne
Nous avons aussi constat lors de notre tude que tout au long des changes entre
les utilisateurs, les donnes qui transitent sont toujours cryptes mme si elles sont
publies sans tre cryptes. Aussi il est noter que lutilisateur qui reoit une requte de
34


rcupration de ses donnes peut choisir entre la signer, la republier sil sagit dune
publication sur son mur ou lignorer.
Ainsi, dans Safebook, certains utilisateurs ont des privilges appropris et peuvent
donc accder et mettre jour les profils des autres membres. Cependant, lentit et
lauthentification des donnes sont fournies par des signatures communes et des
programmes de cryptage.
d - AJOUT DUN NOUVEAU CONTACT :
Un membre A enregistr sur le rseau social qui veut ajouter un autre membre C aussi
enregistr sur le rseau social dans sa liste de contact, envoie un message de demande de
contact suivant les mmes tapes que dans le cas de rcupration de donnes.
Nous avons suppos que lutilisateur C a accept lutilisateur A comme un

nouveau contact. Le peer C associe avec le peer A un certain niveau de confiance qui nest
connu que par C lui mme et personne dautre. Il envoie au peer A une cl lui permettant
de dcrypter les donnes publies et cryptes par C. La figure II.19 montre ces tapes en
diagramme de squence.
Figure II.19: Safebook demande dajout dun contact
VI.3. DIAGRAMME DE DECENT ET CACHET :
Parce que Cachet est une volution de Decent, nous avons analys le comportement de
chaque rseau et nous vous les prsentons sous forme de diagramme de squence qui
35


comporte diffrente partie : inscription au rseau, connexion au rseau, gestion des

messages et lajout dun nouveau contact.
a - INSCRIPTION DANS LE RESEAU :
Dans Cachet comme dans Decent, la procdure dinscription est la mme comme le
montre la figure II.20. Un nouvel utilisateur sur le site du rseau, crera un nouveau
profil, la DHT lui demandera alors de dfinir son ABE Policy, quand cest fait, la DHT
ajoutera son profil sur le rseau et pourra donc commencer lutiliser.
Figure II.20: Decent / Cachet Inscription
b - SE CONNECTER AU RESEAU :
Quand un utilisateur A se connecte dans Decent comme montre la figure II.21, la DHT
ou il stocke ses donnes propage linformation quil sest connect aux DHT voisines,
toutes les DHTs font pareil jusqu' ce que tout le rseau soit au courant, les DHTs qui
contiennent lannuaire de ses amis les notifieront. De son ct, lutilisateur sera notifi des
ventuelles publications le concernant effectues en son absence.
Figure II.21: Decent se connecter
36


Toutefois, le principe de connexion sur Cachet diffre un peu de celui de Decent,

en effet, quand un utilisateur se connecte comme montr dans la figure II.22, sa DHT
notifiera seulement la DHT pilote la plus proche et cest cette dernire qui soccupera de
propager linformation vers tout le rseau. Le reste du principe est le mme que celui de
Decent.
Figure II.22 : Cachet se connecter
c - GESTION DES MESSAGES :
Decent et Cachet dans leurs travaux actuels nont pas encore gr la messagerie
instantane, leur travail consiste seulement aux changes sur les murs et les pages
dactualits. Par ailleurs, le problme de disponibilit ne se pose plus car les donnes sont
stockes dans les DHT et elles seront donc toujours disponibles.
Dune part, la consultation du mur dun utilisateur dans Decent comme le montre la figure
II.23 seffectuera par une requte envoye la DHT o sont stockes les donnes du
demandeur, cette DHT enverra une requte de recherche de la DHT qui contient le profil
du mur demand aux DHTs voisines. La requte de recherche est propage dans le rseau
dune DHT une autre jusqu' ce que la DHT qui contient lutilisateur recherch soit
trouve, une liaison directe entre ces deux DHTs stablira.
Sil sagit dune consultation sur le mur dun utilisateur B par exemple, la DHT B
recherchera linformation demand, si elle existe, elle la dcryptera, vrifiera ensuite si le
demandeur dispose de lautorisation ncessaire pour voir le contenu en utilisant la cl de
dcryptage envoye avec la demande. Si tel est le cas, elle donnera son accord la DHT
du peer qui a demand la consultation, il pourra donc aller consulter directement dans la
DHT B. Sil effectue un commentaire alors la DHT B notifiera lutilisateur B du nouveau
commentaire.
37


Figure II.23 : Decent gestion des messages
Dune autre part, la consultation du mur dun utilisateur dans Cachet a t

amliore, du coup, lorsquun utilisateur A veut consulter le contenu dun utilisateur B, il
demandera sa DHT de trouver ou est stock le contenu de B comme montr dans la
figure II.24. La DHT A enverra cette requte de recherche la DHT pilote qui contient
dans son annuaire la liste des DHTs et les contacts de chaque DHT et fera une liaison
directe entre la DHT A et la DHT B.
Une fois la liaison faite, la DHT A demandera la DHT B lautorisation de consultation

pour son client en envoyant sa cl de dcryptage. La DHT B vrifiera alors la cl de
dcryptage et si cest la bonne alors elle dcryptera les donnes et laissera lutilisateur A
consulter le mur de lutilisateur B. Sil effectue un commentaire alors B en sera notifi.
Figure II.24: Cachet gestion des messages
d - LAJOUT D UN CONTACT :
Pour lajout dun nouveau contact dans Decent, un utilisateur A demandera sa DHT de
rechercher ce contact, sa DHT propagera cette demande dans le rseau jusqu' ce que cet
38


utilisateur soit retrouv comme le montre la figure II.25, la DHT qui contient ce profil
dans son annuaire informera la DHT du demandeur de la prsence de cet utilisateur. Le
peer A peut dcider dajouter cet utilisateur, une demande dajout lui sera envoye depuis
la DHT A vers sa DHT qui le notifiera de cette demande quand il sera prsent sur le site.
Sil accepte la demande dajout, alors les DHTs mettront jour leurs listes damis
respectives dans leurs annuaires et les peers changeront leurs cls de dcryptages
respectives. Il ne leur reste plus que de commencer communiquer.
Figure II.25 : Decent ajout dun contact
En outre, lajout dun nouveau contact dans Cachet a t amlior comme le

montre la figure II.26. En effet quand un utilisateur A veut rechercher un utilisateur X il
enverra une requte de recherche sa DHT, son tour la DHT A transmettra cette requte
la DHT pilote qui pourra faire le lien directement et vrifiera si cet utilisateur existe, si
tel est le cas elle tablira une liaison entre les deux DHTs. Le peer A peut donc choisir
ajouter le peer X, les tapes qui restent sont les mmes que pour Decent.
Figure II.26: Cachet Ajout dun contact
39


VII. SYNTHESE :
Lors de lanalyse de PeerSon nous avons constat que, en cas de dconnection soudaine,
la DHT ne pourra plus savoir quel est le mode de connexion de cet utilisateur. De plus
sinscrire sur un rseau social en ligne aujourdhui est possible, se dsinscrire nest pas
possible et cela quel que soit le type de rseau social en ligne. Seule la dsactivation des
profils est permise. Les rseaux sociaux distribus ont justement pour but principal la
protection des donnes des utilisateurs, mais jusqu prsent la suppression des donnes
des utilisateurs qui se dsinscrivent na pas encore t gre.
Lune des plus grandes limitations de lopendht est le fait quelle ne peut stocker
les informations chez elle que pendant une dure limite et que les utilisateurs doivent se
connecter rgulirement. PeerSon quant lui, permet les messages asynchrones mme en
mode hors ligne, en stockant sur la DHT les messages envoys jusqu' ce que le receveur
se connecte, mais bien sur condition que ce dernier se connecte avant une semaine, car
sinon le message qui lui aura t envoy sera tout simplement effac de la DHT.
Lexpditeur naura donc aucun accus de rception du message envoy. Ainsi le
rcepteur sera port disparu, son GUID sera effac de la DHT et ne pourra plus tre
retrouv. Seules ses donnes peuvent ltre si elles ont t stockes chez ses amis.
Quant Safebook le premier manque que nous avons constat est le fait de ne pas
pouvoir se connecter au rseau que depuis un seul terminal, Il sagit du premier terminal
avec qui lutilisateur sest enregistr au rseau la premire fois.
La messagerie instantane quant elle nest gre quen mode en ligne, donc si un
utilisateur veut laisser un message un autre utilisateur dconnect, il ne pourra pas le
transmettre car les messages synchrones ne sont enregistrs que sur la machine de
lutilisateur et non pas sur les autres machines miroirs.
Nous avons aussi remarqu que pour contacter un utilisateur de Safebook, en

dehors de ses amis miroirs, tout autre utilisateur devra passer imprativement par lun des
points dentre vers un utilisateur A par exemple pour le contacter. Sachant que ces points
dentre sont aussi des utilisateurs enregistrs dans le rseau social, alors si un moment
donn, tous ces utilisateurs/points dentre sont dconnects ,lutilisateur A ne pourra pas
tre retrouv et donc ne pourra pas tre contact.
40


Si un utilisateur et tous ses amis miroirs sont hors ligne, alors son profil ne sera pas
disponible et donc Safebook nassure pas une disponibilit totale.
Lapproche de Decent et de Cachet quant elle assure une disponibilit totale par
le stockage des donnes dans des DHT, mais nous revenons notre problme de dpart, le
regroupement des donnes chez un seul fournisseur et mme si cest donnes sont cryptes
et distribues dans des DHTs, il ne faut pas oublier que ces DHTs ne forment en ralit
quune seule entit.
Par ailleurs, Decent et Cachet ont mis beaucoup plus sur le cryptage des donnes,
ils lont certes lev pour gagner en scurit mais ils ont beaucoup perdu en terme de temps
de chiffrement et dchiffrement, ce qui empche malheureusement lutilisateur dtre en
mesure dutiliser le systme beaucoup plus rapidement.
Le tableau ci-dessous reprsente un comparatif entre les quatre rseaux sociaux

tudis. Les critres de comparaison que nous avons slectionn sont les types
darchitectures, le type du client, les DHTs et leurs services, le mode de connexion et le
mode de gestion de la messagerie. Ces critres nous ont permis de proposer notre modle
dtaill dans le Chapitre III.
41


Rseaux sociaux
PeerSon Safebook Decent Cachet
Caractristiques
Architecture 2 tiers 3 tiers 2 tiers 3 tiers
Type du client Client lourd Client lger
DHT OpenDHT Kademlia FreePastry
Capacit de Moyenne Petite Grande

stockage
DHT
- Lookup service - Lookup service - Lookup service

- Routage - Routage - Routage
Service DHT - Stockage pendant - Stockage des
une dure de 7 jours donnes
Mode en ligne Oui Oui Oui
Mode hors Oui si Friendstore en Oui si miroir en Oui toujours

ligne ligne ligne
Oui : en ligne et hors Oui : en ligne Non : la messagerie

Messagerie
ligne seulement instantane nest pas
instantane
encore gre
Mode Avec ou sans Connexion Internet requise

connexion Internet
42
CHAPITRE III
PROPOSITION DISNET
I. OBJECTIFS DE DISNET
Le but principal de notre mmoire est la gestion du stockage des donnes dans les rseaux
sociaux distribues. Pour cela nous avons pris le meilleur de chaque approche vue dans la
Chapitre II soit PeerSon, Safebook, Decent et Cachet pour proposer un nouveau modle de
rseaux sociaux distribus que nous avons baptis DisNet.
Notre modle consiste non seulement apporter des solutions quelques

problmes rencontrs par ces approches mais aussi un problme qui na pas encore t
ajout aucun rseau social et na pas figur non plus dans les approches tudies dans le
chapitre II, soit la suppression dun compte utilisateur.
Afin de valider notre modle architectural DisNet, nous avons dvelopp un prototype
intitul DisNet Prot que nous allons prsenter dans ce chapitre. DisNet Prot a pour but de
montrer quelques tapes du fonctionnement du rseau DisNet.
II. ARCHITECTURE DE DISNET :
43

Chapitre III : Proposition de DisNet

Notre proposition adopte la solution du stockage distribu chez les utilisateurs en se basant
sur lalgorithme de Friendstore qui est adopt aussi par PeerSon. Nous avons trouv que
cet algorithme est abouti et rpond au besoin de notre proposition.
Par ailleurs, nous allons assurer une disponibilit optimale des donnes mais pas
totale. Car nous ne voulions pas tomber dans le problme de regroupement des donnes
chez un seul fournisseur comme le cas de Decent et Cachet.
Lintgrit des donnes quant elle est assure par le protocole dauthentification
out-of-band inspir de Safebook et qui permet de protger les donnes ainsi que lidentit
de lutilisateur contre les modifications non autorises et les falsifications.
Au final, la protection de la vie prive de lutilisateur et la confidentialit de ses

informations sont assures par un systme de chiffrement afin de ne permettre la
consultation de ces donnes que par lutilisateur lui mme et les contacts avec qui il les
partage.
En outre, notre proposition se base sur une architecture 2 tiers montre dans la
figure III.1, semblable celle de PeerSon.
II.1. LE 1ER TIERS :
Il sagit du service de consultation des DHTs ou sont stockes les mtadonnes

ncessaires pour trouver les utilisateurs, leurs statuts ainsi que les donnes quils stockent.
La DHT que nous avons dcid dutiliser est FreePastry, donc, la mme que celle utilise
par Decent et Cachet. Cette DHT permet de contourner le problme de stockage de
donnes pendant seulement sept jours rencontr dans OpenDHT qui est la DHT utilise
par PeerSon.
De plus, FreePastry utilise plus de 100 nuds rpartis dans le monde contrairement
OpenDHT qui nutilise que des nuds rpartis au sein du laboratoire Planet-lab aux usa.
II.2. LE 2E TIERS :
Ce sont les machines des utilisateurs. Les utilisateurs qui souhaitent rejoindre le rseau
DisNet devront tlcharger une application que nous allons mettre dans notre site pour
pouvoir lutiliser. Grce cette application ils pourront se connecter au rseau mais aussi
44


stocker leurs donnes et les donnes de leurs amis slectionns par le protocole
Friendstore. Grce ce protocole, notre application permettra de scuriser les donnes en
les cryptant mais aussi permettra la propagation et la rplication des donnes stockes sur
au moins trois machines. Des dtails supplmentaires pourront tre retrouvs au chapitre I.
Figure III.1 : Architecture de DisNet
III. PROTOTYPE DE DISNET (DISNET PROT)
Dans cette section nous allons prsenter les diffrentes parties que nous avons
implmentes dans DisNet Prot ainsi que les amliorations abordes dans nos objectifs.
III.1. REJOINDRE DISNET :
Lors de la premire utilisation de DisNet, le nouvel utilisateur devra sinscrire. Pour une
meilleure convivialit au sein du rseau, nous avons dcid de rajouter quelques
contraintes pour prouver quil sagit dune personne relle et quelle na pas usurp
lidentit de quelquun dautre.
Lorsquun nouvel utilisateur aura rempli les champs de renseignements demands

tels que le nom, prnom, adresse email, date et lieu de naissance, et aura cliqu sur le
bouton crer un compte la DHT lui demandera alors didentifier le parrain. Sil
dispose dun parrain enregistr dans le rseau comme montr dans la figure III.2, il
lidentifiera. La DHT vrifiera alors si ce parrain connat lutilisateur qui vient de
demander son parrainage et sil souhaite le parrainer. Si ce dernier confirme son
parrainage, la DHT crera alors les mtadonnes ncessaires pour ce nouvel utilisateur et
lajoutera lannuaire des utilisateurs enregistrs. Lutilisateur pourra donc commencer
utiliser le rseau.
45


Figure III.2 : Rejoindre DisNet Prsence du parrain
Cependant, si lors de linscription lutilisateur na pas de parrain dans le rseau

comme dans la figure III.3, la DHT lui propose un dfit de challenge/rponse dfinit
pas le protocole dauthentification out-of-band, sil le russit alors la DHT validera son
profil.
Figure III.3 : Rejoindre DisNet Challenge/rponse
III.2. SE CONNECTER A DISNET :
Quand un utilisateur se connecte DisNet comme dans la figure III.4, la DHT enverra une
requte dactualisation ses amis qui stockent ses donnes pour les inviter synchroniser
46


avec lui les messages asynchrones publis en son absence. De son cot, lutilisateur
recevra une requte pour voir les amis qui sont en ligne ce moment.
Par ailleurs la DHT effectuera une autre mise jour et diffusera sur le rseau que
cet utilisateur vient de se connecter, Ses amis qui se trouvent en ligne ce moment
recevront une notification les prvenant de sa connexion.
Figure III.4 : DisNet se connecter
III.3. GESTION DES MESSAGES :
Si un utilisateur A veut communiquer avec un autre utilisateur B, il envoie dabord une

requte la DHT pour lui demander ladresse IP du peer B, si ce dernier est en ligne et
que le peer A est habilit le contacter, alors la DHT tablira un lien de communication
directe entre eux comme montr dans la figure III.5, les peers peuvent donc communiquer
par des messages instantans, une publication. un commentaire sur le mur.
Figure III.5 : DisNet Communication en ligne
Toutefois, si le peer A veut envoyer un message instantan au peer B et dcouvre

que ce dernier est hors ligne comme dans la figure III.6, le message quil enverra sera
47


stock dans la DHT jusqu ce que le peer B se reconnecte au rseau. Le message stock
lui sera retransmis, effac de la DHT et le peer A sera acquitt de la transmission de son
message.
Nous avons prfr un stockage des messages instantans envoys en mode hors
ligne dans la DHT pour que linformation reste frache. Il devient vident que ds que le
peer B se reconnectera DisNet et mme en labsence de ses Friendstores, il recevra le
message qui lui a t envoy de la part du peer A en son absence directement depuis sa
DHT.
Ainsi nous avons rajouter une requte qui sera envoye au peer A si jamais le
message qui a t envoy na pas encore t lu en moins dune semaine ; comme cela
linformation restera fraiche et A pourra donc choisir entre garder le message dans la DHT
ou leffacer sil nest plus dactualit.
Figure III.6 : DisNet Message instantan hors ligne
Par ailleurs, si le peer A veut consulter le mur du peer B alors que ce dernier est
hors ligne, il demandera la DHT si le contenu de B est tout de mme disponible, la DHT
vrifiera dabord si A est habilit consulter les donnes de B et si un des Friendstores de
B est en ligne, si tel est le cas alors elle tablira un canal de communication comme
montr dans la figure III.7. A pourra donc consulter le profil de B, publier un statut ou un
commentaire sur le mur de B via la Friendstore. Ce dernier recevra une synchronisation de
la mise jour de son mur ds la prochaine connexion en mme temps que ses amis
Friendstore.
48


Figure III.7 : DisNet communication asynchrone Friendstore
III.4. AJOUT DUN CONTACT :
Quand un utilisateur A voudra ajouter un utilisateur X sa liste damis, il demandera la

DHT de rechercher dans son annuaire si cet utilisateur existe, si tel est le cas, la DHT
enverra une demande dajout au peer X. Dans le cas dacceptation comme montr dans la
figure III.8, la DHT effectuera une mise jour des amis de A dans son annuaire en
ajoutant X et une autre mise jour des amis de X en ajoutant A. Les nouveaux amis
changeront ensuite leurs cls de dcryptage respectives pour dcrypter les donnes quils
cryptent selon lABE Policy adopt aussi par Decent et Cachet.
Figure III.8 : DisNet ajout dun contact
49


III.5. SUPPRESSION DUN COMPTE ET DESTRUCTION DES DONNEES
Comme dernier cas, nous avons rajout une nouvelle solution qui na t traite par aucun
rseau social ni aucune des approches vues dans le chapitre II jusqu' prsent et qui
consistent la suppression dun compte utilisateur et la destruction de ses donnes avec
possibilit de rcupration de son profil.
Quand un utilisateur veut supprimer son compte dfinitivement de DisNet comme

montr dans la figure III.9, il enverra une requte de suppression du compte la DHT.
Aprs confirmation de la requte pour sassurer quil ne sagit pas dune erreur de sa part,
la DHT soccupera tout dabord par propager la requte de destruction de ses donnes.
Des la rception de la requte par les machines des Friendstore de cet utilisateur,
les donnes commenceront se dtruire jusqu' ce quil ne reste aucune trace de cet
utilisateur. Quand tout cela est fait, la DHT enlvera de son annuaire les relations que cet
utilisateur avait, les mtadonnes qui taient ncessaires sa connexion, lui enverra un
fichier nommer DisNet Resuc et rompra le contact avec lui. Les donnes ce cet
utilisateur resteront stockes dans sa machine.
Par ailleurs, si cet utilisateur veut sinscrire de nouveau dans le rseau et rcuprer
son profil, il utilisera le fichier DisNet Resuc pour cela. Ce fichier permet la DHT de
rtablir le contact avec lui car il contient les mtadonnes autrefois ncessaires sa
connexion. L'utilisateur pourra galement rtablir le lien avec ses amis.
Figure III.9 : DisNet suppression dun compte utilisateur
50


IV. SIMULATION
Afin de valider notre travail nous avons effectu une simulation en Java pour montrer les
diffrentes interactions entre les utilisateurs et la DHT ou entre les utilisateurs eux mme.
Nous avons implment la plus part des tapes de DisNet Prot, lorsquun
utilisateur se connecte comme le montre la figure III.10, lapplication lui propose alors de
choisir entre se connecter sil dispose dun profil ou den crer un sil nen pas encore.
Quant la figure III.11, elle montre le fonctionnement de la DHT si lutilisateur choisit de
crer un nouveau profil. En effet lorsquil aura choisi de crer un nouveau profil, il devra
alors remplir ses coordonnes. Ces coordonnes seront stockes dans lannuaire provisoire
de la DHT jusqu' ce quil sauthentifie. Dans le cas de ces deux figures, lutilisateur a
choisi une authentification par un parrain, donc aprs confirmation du parrainage la DHT
enregistrera le profil dans lannuaire dfinitif et crera les mtadonnes qui seront
ncessaires aux prochaines connexions de cet utilisateur.
Figure III.10 : DisNet Prot crer un profil peer Figure III.11 : DisNet Prot crer un profil DHT
La connexion dun utilisateur et lenvoi dun message sont montrs dans la figure
III.12 car lorsque lutilisateur aura choisi de se connecter, il devra fournir son adresse
email et son mot de passe, la DHT qui est montre dans la figure III.13 synchronisera avec
lui les messages envoys en son absence, prviendra Friendstore de sa connexion et
actualisera sa liste dami en ligne, sil choisit denvoyer un message un autre utilisateur
51


qui est en ligne alors une liaison seffectuera entre les deux peers et pourra donc
communiquer.
Figure III.12 : DisNet envoi message peer Figure III.13 : DisNet envoi de message DHT
Quand un utilisateur souhaite donc supprimer son profil comme montrer dans la
figure III.14, lapplication lui demande dabord de vrifier sil ne sagit pas dune erreur,
ensuite aprs confirmation, la DHT comme montre dans la figure III.15, procde la
destruction de ses donnes chez ses Friendstore, elle gnre ensuite le fichier DisNet
Resuc pour lui permettre de rcuprer son profil sil le souhaite, elle le lui envoi et rompe
le contact avec lui. Lutilisateur aura ses donnes chez lui et pourra donc rcuprer son
profil avec le fichier DisNet Resuc, qui lui permettra aussi de rcuprer tous ses contacts.
Figure III.14 : DisNet suppression profil peer Figure III.15 : DisNet suppression profil - DHT
52
CONCLUSION ET
PERSPECTIVES
Le service des rseaux sociaux aujourdhui est lun des services prdominant du
web. Ces rseaux visent un large ventail dutilisateurs de toutes tranches dges et de
sexes et cela pour diverses raisons tant personnelles que professionnelles.
Lavantage quoffre ces rseaux est leur facilit dutilisation pour publier des
informations personnelles et communiquer avec aisance, mme par des utilisateurs aux
comptences techniques limites.
La motivation principale pour un membre joindre un tel rseau est la facilit de

crer un profil, dutiliser les diffrentes applications offertes par le service ainsi que la
possibilit de partager facilement des informations avec des contacts slectionns ou le
public et cela des fins personnelles ou professionnelles.
Les donnes que lutilisateur publie sont en fait stockes dans les serveurs du
fournisseur du rseau social utilis afin de permettre une disponibilit totale du contenu
stock. Cependant, lutilisation frauduleuse des donnes personnelles commises par les
diffrents rseaux sociaux centraliss des fins commerciales et mercantiles ou sous
couvert de la demande de certains gouvernements ncessite une rponse innovante et
forte. Cest dans cette perspective que le prsent mmoire a t labor.
La mise en scurit des donnes personnelles et le respect de la vie prive sont

deux priorits essentielles sur lesquelles peut se construire une rponse pertinente comme
53

Conclusion et Perspectives

le cas de PeerSon, Safebook, Decent et Cachet, quatre approches de rseaux sociaux

distribus que nous avons tudi en dtail.
Cette tude nous a permis dtudier minutieusement leurs architectures et de

comprendre le prototype de chaque approche, ensuite nous avons simplifi leur
fonctionnement en proposant des diagrammes de squences montrant chaque tape du
fonctionnement de ces approches. Ce qui nous a permis de dcouvrir les manques existant
dans ces approches pour proposer un nouveau model de rseau social distribu que nous
avons baptis DisNet.
Notre model a repris les points forts des approches voques ensuite nous avons
apport plusieurs amlioration concernant les manques dcouverts dans la synthse. Ces
amliorations touchent entre autre la gestion du stockage des donnes, le mode
denregistrement, lassurance de la disponibilit des donnes mme en mode hors ligne.
Nous avons propos une solution nouvelle un problme nayant pas t trait par aucun
rseau social actuel et ne figurant pas non plus dans les approches tudies savoir : la
suppression dun compte utilisateur avec destruction de ses donnes tout en sassurant que
lutilisateur pourra rcuprer son profil avec toutes ses donnes et ses relations comme il
les avait autrefois sil le souhaite et cela dune manire innovante.
Pour valider notre model, nous avons propos une simulation de notre prototype
que nous avons baptis DisNet Prot. Cette simulation nous permet d'apprhender les
divers problmes auxquels nous pourrions tre confronts dans limplmentation dun
produit fini.
Les perspectives de ce travail consiste finaliser le prototype DisNet Prot et

lamliorer, parmi les amliorations possibles citons :
Essayer de trouver une solution pour assurer la disponibilit des donnes des
utilisateurs mme en labsence de ces derniers tout en restant dans la
dcentralisation.
Dcentraliser le service de lookup qui pour le moment est considr comme un
service centralis, afin de respecter une architecture 100% dcentralise.
Automatiser le service dauthentification de challenge/rponse qui pour le moment
est considr comme un service centralis collectant les donnes des utilisateurs.
54
REFERENCES
BIBLIOGRAPHIQUES
55

Rfrences bibliographiques

[1] http://lci.tf1.fr/chaine-lci/
[2] http://www.washingtonpost.com/wp-srv/special/politics/prism-collection-documents/
[3] https://www.facebook.com/zuck
[4] http://boinc.berkeley.edu/
[5] Giuseppe DeCandia and .al, Dynamo: Amazons Highly Available Key-value Store,
SOSP '07 Proceedings of twenty-first ACM SIGOPS symposium on Operating systems
principles, Pages 205-220, October 2007
[6] http://www.jamendo.com/fr/
[7] http://www.bittorrent.com/
[8] http://www.beet.tv/2010/05/adobes-big-peertopeer-plans-.html
[9] https://joindiaspora.com/
[10] http://movim.eu/
[11] https://lorea.org/
[12] Robert Morris and .al, Chord: A scalable peer-to-peer look-up protocol for internet
applications, Saarland University, Department of Computer Science, November 2003.
[ 13] Sylvia Ratnasamy and .al, A Scalable Content-Addressable Network, Saarland

University, Department of Computer Science, 2002.
[14] http://fr.usenet.nl/
[15] http://www.epostmail.org/
[16] http://oceanstore.cs.berkeley.edu/
[17] https://freenetproject.org/
[18] http://kademlia.scs.cs.nyu.edu/
[19] http://opendht.org/
[20] http://www.planet-lab.org/
[21] http://www.iss.net/security_center/advice/Services/SunRPC/default.htm
[22] http://xml-rpc.net/
[23] http://www.freepastry.org/
56


[24] http://research.microsoft.com/en-us/um/people/antr/pastry/
[25] http://friendstore.news.cs.nyu.edu/
[26] Randy Baden and .al, Persona: An Online Social Network with User-Defined
Privacy, conference on Data communication, Proceedings of the ACM SIGCOMM ,2009.
[27] Luca Maria Aiello and Giancarlo Ruffo, LotusNet: tunable privacy for distributed
online social network services, Preprint submitted to Computer Communications,
December 19, 2010.
[28] Rajesh Sharma and Anwitaman Datta, SuperNova: Super-peers Based Architecture
for Decentralized Online Social Networks, Fourth International Conference on
Communication Systems and Networks (COMSNETS), 2012.
[29] Cashion, Protocol for mitigating the risk of hijacking social networking sites, 7th
International Conference on Collaborative Computing: Networking, Applications and
Worksharing (CollaborateCom), 2011.
[30] www.peerson.net
[31] www.safebook.us
[32] Refik Molva and .al, Safebook: Feasibility of Transitive Cooperation for Privacy on a
Decentralized Social Network, World of Wireless, Mobile and Multimedia Networks &
Workshops,IEEE, 2009.
[33] Alberto Ornaghi and Marco Valleri, Man in the middle attacks demos, Blackhat
Conference USA, 2003.
[34] Yanchao Zhang, A Fine-Grained Reputation System for Reliable Service Selection in
Peer-to-Peer Networks, Transactions on Parallel and Distributed Systems, IEEE, August
2007.
[35] Vadivu, G.S, Protecting peer-to-peer networks from the denial of service attacks, 3rd
International Conference on Electronics Computer Technology (ICECT), 2011.
[ 36] Xu Xiang, Defeating against sybil-attacks in peer-to-peer networks, IEEE 26

International Parallel and Distributed Processing Symposium Workshops & PhD Forum
(IPDPSW), 2012.
[37] Nikita Borisov and .al, DECENT: A Decentralized Architecture for Enforcing
Privacy in Online Social Networks, IEEE International Conference on Pervasive
Computing and Communications Workshops (PERCOM Workshops), 2012.
[38] Nikita Borisov and .al, Cachet: A Decentralized Architecture for Privacy Preserving
Social Networking with Caching, CoNEXT '12 Proceedings of the 8th international
conference on Emerging networking experiments and technologies, Pages 337-348, 2012
57


[39] Sonja Buchegger and .al, PeerSoN: P2P Social Networking Early Experiences and
Insights, SNS '09 Proceedings of the Second ACM EuroSys Workshop on Social Network
Systems, 2009.
[40] Doris Schiberg, A Peer-to-peer Infrastructure for Social Networks, Diplomarbeit in

Informatik, Technische Universitt Berlin Fakultt IV, Dezember 2008.
[41] Leucio Antonio et .al, Safebook: A Privacy-Preserving Online Social Network

Leveraging on Real-Life Trust, CONSUMER COMMUNICATIONS AND
NETWORKING, IEEE Communications Magazine, December 2009.
[42] http://www.safebook.us/prototype.html
[43] Refik Molva and .al, Safebook: A Distributed Privacy Preserving Online Social
Network, IEEE International Symposium on World of Wireless, Mobile and Multimedia
Networks (WoWMoM), 2011.
[44] http://www.authentify.com/solutions/out-of-band-authentication.html
[ 45 ] Goldfarb, Writing policies and procedures manuals, IEEE Transactions on

Professional Communication, 2013.
[ 46 ] Jinguang Han, Privacy-Preserving Decentralized Key-Policy Attribute-Based

Encryption, IEEE Transactions on Parallel and Distributed Systems, 2012.
[47] Hoffman, Cryptography policy, Communications of the ACM, Pages 109-117, 1994.
[48] Dinh Nguyen and .al, Friendstore: cooperative online backup using trusted nodes,
Proceedings of the 1st Workshop on Social Network Systems Pages 37-42, 2008.
58

Conception Et Realisation Dun Reseau Social Distribue

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Conception Et Realisation Dun Reseau Social Distribue

Uploaded by

Copyright:

Available Formats

REPUBLIQUE ALGERIENNE DEMOCRATIQUE ET POPULAIRE

UNIVERSITE ABOU BAKR BELKAID TLEMCEN

Mmoire de fin dtudes

pour lobtention du diplme de Master en Informatique

Dun rseau social distribu

Prsent le 29 Juin 2013 devant le jury compos de :

Mme. Amel Halfaoui (Prsidente)

Anne universitaire : 2012-2013

La multiplication des moyens de communication au premier rang desquels les

Nos remerciements galement Mme. Amel Halfaoui qui na eu de cesse que de

mon frre Ryad et ma princesse Nihad.

mon grand pre, que dieu te garde.

Lobjectif de ce mmoire est de faire une tude et un comparatif des architectures

The objective of this memory is to make a study and comparative architectures of

We propose a new model of the distributed social networks baptized DisNet. In

Ddicace ZaQ ............................................................................................................................ III

Ddicace Narymen ................................................................................................................. IV

Introduction Gnrale ............................................................................................................. 1

Chapitre I Les rseaux distribus ................................................................................. 4

I. Le Peer to Peer : .................................................................................................................. 4

II. Les rseaux sociaux distribus : .................................................................................. 5

III. Les tables de hachages distribues : ......................................................................... 5

IV. La sauvegarde Friendstore : ......................................................................................... 8

Chapitre II Etat de l'art .......................................................................................................... 10

II. Dfinition et conception : ............................................................................................. 10

III. Architecture des rseaux sociaux distribus : ..................................................... 14

IV. Prototypes des rseaux sociaux distribues : ........................................................ 20

V. Stockage des donnes : .................................................................................................. 24

VI. Diagramme de squence ............................................................................................. 24

VII. Synthse : ........................................................................................................................ 40

Chapitre III "Proposition DisNet " ..................................................................................... 43

I. Objectifs de DisNet ........................................................................................................... 43

II. Architecture de DisNet : ................................................................................................ 43

III. Prototype de DisNet (DisNet Prot) .......................................................................... 45

IV. Simulation ........................................................................................................................ 51

Conclusion et perspective .................................................................................................... 53

Figure III.1 : Architecture de DisNet ................................................................................. 45

Il existe actuellement de fortes prsomptions dutilisations non autorises des

La rcente affaire reprise par la presse internationale de cette utilisation

Le prsident Obama a dclar : Vous ne pouvez pas avoir 100% de scurit et en

Mark Zuckerberg [ 3 ], le fondateur de Facebook a dclar : Quand les

Nombreux sont les utilisateurs qui smeuvent de telles pratiques en violation

Ladhsion un rseau social implique un contrat de confiance entre lutilisateur

Or, ce jour, le contrat de confiance entre lutilisateur et les rseaux sociaux

Certains pays ont pour objectif le durcissement de la lgislation en vue de la

La problmatique actuelle peut galement dpasser le simple cadre de lutilisation

Si le cadre lgislatif semble tre dficient actuellement, dautres solutions mme

Le terme peer-to-peer abrg en P2P est un modle de rseau informatique proche du

Figure I.1 : Structure du rseau P2P

II. LES RESEAUX SOCIAUX DISTRIBUES :

la diffrence d'un service de rseau social centralis (Facebook, MySpace ou

III. LES TABLES DE HACHAGES DISTRIBUEES :

La DHT fournit un algorithme de recherche efficace intitul lookup service qui

Le systme en rseau de forums Usenet [14]

Il existe actuellement plusieurs DHTs sur le march, certaines sont accessibles

Afin dexplorer le rseau la recherche dune certaine valeur, lalgorithme KAD

Aucune information didentification ou de cration des comptes nest requise pour

Ce model de service de la DHT simplifie considrablement le dploiement des

En raison de sa nature dcentralise et redondante, il ny a pas de point de

IV. LA SAUVEGARDE FRIENDSTORE :

Friendstore [25] est un mcanisme de sauvegarde coopratif des donnes en ligne

Il ny a aucun besoin de payer pour un service de sauvegarde en ligne.

La particularit que ces rseaux ont en commun ce compose de trois contraintes :

II. DEFINITION ET CONCEPTION :