Autorité de certification distribuée pour des réseaux pair-à-pair structurés

Réseaux pair-à-pair

Dans cette section, nous présentons les différents types de réseaux pair-àpair. Nous ne présentons pas les nombreux réseaux pair-à-pair de manière exhaustive mais nous essayons plutôt de distinguer les familles classiques de réseaux pair-à-pair, à savoir les réseaux avec centre, les réseaux non structurés et les réseaux structurés. Dans chacun des cas, nous décrivons le principe de ce type de réseau et nous présentons certains exemples.

Il est intéressant de distinguer deux phases dans l’évolution des réseaux pair-à-pair. Les premiers réseaux et ceux qui sont encore aujourd’hui les plus connus du grand public sont avec centre ou non structurés. Ils ont été créés par les logiciels qui les utilisent et ont été initiés par des sociétés ou des petits groupes de personnes. Ces réseaux ne sont donc pas tous décrits de manière scientifique ; les éventuels articles scientifiques sont généralement écrits a posteriori. Au contraire, les réseaux structurés qui permettent de meilleures performances pour bon nombre d’applications sont des propositions académiques et ont émergé plus récemment vers des implémentations grand public, avec par exemple le réseau Kademlia utilisé  par eDonkey (Overnet), eMule (Kad) et BitTorrent (DHT BitTorrent).

Réseaux pair-à-pair avec centre

Nous décrivons d’abord les réseaux pair-à-pair avec centre puis nous présentons les exemples de Napster et eDonkey/eMule.

Description 

Les premiers réseaux qualifiés de pair-à-pair ne sont pas entièrement décentralisés. Un serveur est utilisé comme annuaire des ressources disponibles ; chaque pair publie les ressources qu’il possède sur ce serveur et interroge ce serveur pour découvrir les pairs partageant les ressources qu’il recherche. Les transferts de données sont en revanche réalisés directement entre les pairs, sans faire intervenir le serveur, ce qui justifie leur qualification de pair-à-pair. La présence d’un serveur est la limite de ce type de réseau, car le serveur est un point de faiblesse. Ce serveur doit être :
– puissant car, bien que n’intervenant pas dans les transferts de fichiers, le serveur est nécessaire lors de chaque insertion, de chaque recherche, ainsi qu’au fur et à mesure du téléchargement pour actualiser les sources. Son dimensionnement est donc critique pour le fonctionnement du système tout entier ;
– disponible car, étant nécessaire au fonctionnement du réseau, la coupure du serveur rend le réseau tout entier inopérant.

Napster
Napster  , qui est considéré comme le premier réseau pair-à-pair, a été créé en 1999 par Shawn Fanning. Bien que ne reposant pas sur une architecture entièrement distribuée, le transfert de fichiers qui constitue l’essentiel de la charge est effectué directement entre les utilisateurs. Un serveur est utilisé comme annuaire des ressources disponibles, permettant une recherche et une localisation faciles. Chaque pair s’inscrit sur ce serveur et y publie la liste des fichiers qu’il partage. Lors d’une recherche, le serveur est interrogé et retourne la liste des pairs satisfaisant la requête. Napster reposait sur un unique parc de serveurs et a été fermé par la simple déconnexion de ce parc. La présence d’un centre est une faiblesse pour la disponibilité d’un réseau pair-à-pair.

eDonkey / eMule
La première version d’eDonkey [HBMS04] a été distribuée en 2000 par Jed McCaleb. Contrairement à Napster, le réseau eDonkey est basé sur l’agrégation d’un ensemble de serveurs. Le logiciel permettant de mettre en place un serveur est disponible publiquement et un grand nombre de serveurs sont donc proposés. Chaque utilisateur se connecte sur un seul serveur qui stocke la liste de ses fichiers partagés : les serveurs ne jouent que le rôle d’annuaire et ne partagent aucun fichier. Lors d’une requête, un utilisateur interroge son serveur qui, à son tour, interroge les autres serveurs. À la différence des systèmes à superpairs , les serveurs exécutent un code différent des clients, demandent d’importantes ressources et nécessitent une administration avancée : la relation entre les utilisateurs et les serveurs est donc bien une relation client-serveur et non pair-à-pair.

La multiplication des serveurs ne résout toutefois pas tous les problèmes que pose Napster. Pour accueillir un grand nombre d’utilisateurs, plusieurs centaines de serveurs sont nécessaires, dont les plus populaires doivent être puissants. En 2004, l’association Razorback ouvrait un nouveau serveur accueillant 730.000 pairs, basé sur un bi-processeur AMD Opteron 248 avec 16GO de mémoire vive et connecté à internet à 50Mbps  : à l’époque, il s’agit clairement d’une machine extrêmement puissante et reliée à internet par un lien rapide. Le problème de disponibilité s’illustre ici, comme dans Napster, par la fermeture successive des différents serveurs pour des raisons légales et financières.

Réseaux pair-à-pair non structurés

Les réseaux pair-à-pair non structurés sont entièrement distribués et reposent sur la génération de graphes aléatoires entre les pairs. Chaque nouveau membre doit connaître un pair appartenant déjà au réseau et utilise ce pair pour s’insérer. Les requêtes sont ensuite propagées par inondation (demande à tous les voisins qui demandent à tous leurs voisins, etc.) ou par marche aléatoire (demande à un voisin qui demande à un voisin, etc.).

Les paramètres les plus importants des réseaux non structurés sont :
– les degrés entrant et sortant de chaque pair. En effet, ils conditionnent directement la robustesse aux défaillances et la connectivité du réseau ;
– le nombre de sauts d’un requête (TTL). Plus une requête est propagée, plus elle a de chances de trouver la ressource recherchée, mais plus la charge du réseau augmente ;
– le choix du ou des voisins utilisés pour propager une requête. Plus le nombre de voisins retenus est petit, plus le choix de ces voisins est important pour que la requête atteigne la ressource recherchée.

Le rapport de stage ou le pfe est un document d’analyse, de synthèse et d’évaluation de votre apprentissage, c’est pour cela rapport-gratuit.com propose le téléchargement des modèles complet de projet de fin d’étude, rapport de stage, mémoire, pfe, thèse, pour connaître la méthodologie à avoir et savoir comment construire les parties d’un projet de fin d’étude.

Table des matières

Introduction
1 État de l’art
1.1 Réseaux pair-à-pair
1.1.1 Réseaux pair-à-pair avec centre
1.1.2 Réseaux pair-à-pair non structurés
1.1.3 Réseaux pair-à-pair structurés
1.2 Sécurité des réseaux structurés
1.2.1 Attaque sybile
1.2.2 Intégrité et confidentialité des ressources
1.3 Infrastructures à clé publique
1.3.1 Catégories d’infrastructures à clé publique
1.3.2 Signature distribuée
2 Modèle de l’autorité de certification distribuée
2.1 Partage de la clé secrète
2.1.1 Décomposition de la clé secrète
2.1.2 Distribution des fragments
2.1.3 Affectation des fragments
2.2 Obtention d’une signature
2.3 Évolution du réseau et maintenance du partage
2.3.1 Division d’un groupe
2.3.2 Rafraîchissement de deux fragments
2.3.3 Fusion de deux groupes
2.3.4 Connexion d’un pair
2.3.5 Déconnexion d’un pair
2.4 Génération de la clé du réseau
2.4.1 Une entité unique génère la clé du réseau
2.4.2 Un groupe génère la clé du réseau
2.5 Analyse de la sécurité du modèle
2.5.1 Obtention de la clé secrète du réseau
2.5.2 Destruction du partage de la clé
2.6 Applications
2.6.1 Protection contre l’attaque sybile par contrôle d’admission
2.6.2 Nommage sécurisé des ressources
3 Signature distribuée
3.1 Algorithme de signature distribuée
3.2 Tolérance aux pairs malveillants
3.2.1 Principe de la redondance
3.2.2 Mise en œuvre
3.3 Probabilité de succès de l’algorithme de signature distribuée
3.4 Format des signatures et des fragments
3.4.1 Format des signatures
3.4.2 Format des fragments de clé
4 Maintenance de la fragmentation de la clé
4.1 Opération de division
4.1.1 Arbre de fragmentation initial
4.1.2 Protocole de division
4.1.3 Cohérence des arbres de fragmentation
4.1.4 Concurrence avec un processus de signature
4.2 Opération de rafraîchissement
4.2.1 Arbres de fragmentation modifiés
4.2.2 Protocole de rafraîchissement
4.2.3 Cohérence des arbres de fragmentation
4.2.4 Concurrence avec un processus de signature
4.2.5 Utilisation
4.3 Opération de fusion
4.3.1 Téléchargement des arbres de fragmentation
4.3.2 Protocole de fusion
4.3.3 Cohérence des arbres de fragmentation
4.3.4 Concurrence avec un processus de signature
4.4 Opération de connexion
4.4.1 Protocole de connexion
4.4.2 Cohérence des arbres de fragmentation
4.4.3 Concurrence avec un processus de signature
4.5 Opération de déconnexion
4.5.1 Protocole de déconnexion
4.5.2 Cohérence des arbres de fragmentation
4.5.3 Concurrence avec un processus de signature
4.6 Preuve de la confidentialité et de l’intégrité
4.6.1 Confidentialité des fragments
4.6.2 Intégrité du partage
5 Implémentation et résultats expérimentaux
Conclusion

Rapport PFE, mémoire et thèse PDFTélécharger le rapport complet

Télécharger aussi :

Laisser un commentaire

Votre adresse e-mail ne sera pas publiée. Les champs obligatoires sont indiqués avec *