Définition D'une Infrastructure De Sécurité Et De Mobilité Pour Les Réseaux Pair-À-Pair Recouvrants

THÈSE

PRÉSENTÉE À

UNIVERSITÉ DE BORDEAUX

COLLÈGE SCIENCES & TECHNOLOGIES

ÉCOLE DOCTORALE DE MATHÉMATIQUES ET D’INFORMATIQUE

LABORATOIRE BORDELAIS DE RECHERCHE EN INFORMATIQUE (LaBRI)

par DAOUDA AHMAT MAHAMAT POUR OBTENIR LE GRADE DE : DOCTEUR

SPÉCIALITÉ : INFORMATIQUE

F Déﬁnition d’une Infrastructure de Sécurité et de Mobilité pour les Réseaux Pair-à-Pair Recouvrants

Soutenue publiquement le : 29 septembre 2014

Après avis des rapporteurs : Anne Fladenmuller, UPMC - LIP6, Maître de Conférences HDR Philippe Owezarski, CNRS - LAAS, Directeur de Recherche HDR

Devant la commission d’examen composée de : Présidente du jury : Francine Krief, ENSEIRB - LaBRI, Professeur des Universités Directeur de thèse : Damien Magoni, UB - LaBRI, Professeur des Universités Examinateur : Gwendal Simon, Telecom Bretagne - IRISA, Maître de Conférences ii Abstract — Securing communications in distributed dynamic environments, that lack a central coordination point and whose topology changes constantly, is a major challenge. We tackle this challenge of today’s P2P systems. In this thesis, we propose to define a security infrastructure that is suitable to the constraints and issues of P2P systems. The first part of this document presents the design of SEMOS, our middleware solution for managing and securing mobile sessions. SEMOS ensures that communication sessions are secure and remain active despite the possible disconnections that can occur when network configurations change or a malfunction arises. This roaming capability is implemented via the definition of a new addressing space in order to split up addresses for network entities with their names ; the new naming space is then based on distributed hash tables (DHT). The second part of the document presents a generic and distributed mechanism for a key exchange method befitting to P2P architectures. Building on disjoint paths and end-to-end exchange, the proposed key management protocol consists of a combination of the Diffie-Hellman algorithm and the Shamir’s (k, n) threshold scheme. On the one hand, the use of disjoint paths to route subkeys offsets the absence of the third party’s certified consubstantial to Diffie-Hellman and reduces, at the same time, its vulnerability to interception attacks. On the other hand, the extension of the Diffie-Hellman algorithm by adding the threshold (k, n) scheme substantially increases its robustness, in particular in key splitting and / or in the case of accidental or intentional subkeys routing failures. Finally, we rely on a virtual mobile network to assess the setup of secure mobile sessions. The key management mechanism is then evaluated in an environment with randomly generated P2P topologies. Index terms— P2P, DHT, mobile VPN, disjoint paths, Diffie-Hellman, (k, n) threshold scheme

Résumé — La sécurisation inhérente aux échanges dans les environnements dynamiques et distribués, dépourvus d’une coordination centrale et dont la topologie change perpétuel- lement, est un défi majeur. Dans le cadre de cette thèse, on se propose en effet de définir une infrastructure de sécurité adaptée aux contraintes des systèmes P2P actuels. Le premier volet de nos travaux consiste à proposer un intergiciel, appelé SEMOS, qui gère des sessions sécurisées et mobiles. SEMOS permet en effet de maintenir les sessions sécurisées actives et ce, même lorsque la configuration réseau change ou un dysfonctionnement se produit. Cette faculté d’itinérance est rendue possible par la définition d’un nouveau mécanisme de découplage afin de cloisonner l’espace d’adressage de l’espace de nommage ; le nouvel espace de nommage repose alors sur les tables de hachage distribuées (DHT). Le deuxième volet définit un mécanisme distribué et générique d’échange de clés adapté à l’architecture P2P. Basé sur les chemins disjoints et l’échange de bout en bout, le procédé de gestion des clés proposé est constitué d’une combinaison du protocole Diffie-Hellman et du schéma à seuil (k, n) de Shamir. D’une part, l’utilisation des chemins disjoints dans le routage des sous-clés compense l’absence de l’authentification certifiée, par une tierce partie, consubstantielle au protocole Diffie-Hellman et réduit, dans la foulée, sa vulnérabilité aux attaques par interception. D’autre part, l’extension de l’algorithme Diffie-Hellman par ajout du schéma à seuil (k, n) renforce substantiellement sa robustesse notamment dans la segmentation des clés et/ou en cas de défaillances accidentelles ou délibérées dans le routage des sous-clés. Enfin, les sessions sécurisées mobiles sont évaluées dans un réseau virtuel et mobile et la gestion des clés est simulée dans un environnement générant des topologies P2P aléatoires.

Mots-clés— P2P, DHT, VPN mobile, chemins disjoints, Diﬃe-Hellman, schéma à seuil (k, n)

iii iv Dédicace

Je dédie cette thèse à ma défunte mère Mariam Haroun Moustapha et à mon défunt père Ahmat Mahamat Koulibaly pour l’amour parental qu’ils nous ont procuré et pour les immenses sacriﬁces qu’ils ont consentis pour l’éducation et la réussite de leurs enfants. Puisse Allah les accueillir en son Paradis Éternel ! Amine.

v vi Remerciements

Je remercie chaleureusement les rapporteurs, Anne Fladenmuller et Philippe Owezarski, qui ont accepté de relire ma thèse et qui, subséquemment, ont émis un avis favorable au déroulement de ma soutenance. J’adresse également mes remerciements appuyés à Francine Krief et Pierre Simon qui ont aimablement accepté de faire partie du jury. Je tiens à adresser mes vifs remerciements à mon directeur de thèse Damien Magoni avec qui j’ai travaillé sur quatre différents projets depuis 2010. Ces travaux m’ont en effet permis non seulement d’acquérir plus de rigueur mais aussi d’enrichir considérablement mes connaissances techniques et scientifiques ; ce serait un euphémisme de dire que j’ai beaucoup bénéficié de ces encadrements respectifs. Aussi, je ne peux perdre de vue les qualités humaines manifestes de Damien ni faire abstraction de la bonne humeur qu’il répand à profusion au cours de nos différentes entrevues ; nos réunions sont toujours ponctuées par des échanges cordiaux. Le dernier encadrement en date, sous sa direction, se traduit donc par l’aboutissement de cette thèse dont le déroulement s’était inscrit naturellement dans la même dynamique que des projets précédemment encadrés. Je n’aurais jamais fait des études en Informatique sans les conseils affectueux et bienveillants du Dr Mahamat Barka. En effet, mon baccalauréat en poche et alors que je me destinais à des études de Mathématiques ou de Physique pour lesquelles j’avais une certaine prédisposition inhérente à mon cursus scolaire et à ma série, le début de mon parcours universitaire avait soudainement pris une tout autre tournure lorsque j’avais décidé de me placer, volontairement mais irrésistiblement, sous le parrainage du Dr Mahamat Barka. Ce dernier a ainsi eu la perspicacité de m’orienter. Tout au long de mon parcours universitaire, Dr Mahamat Barka n’a eu de cesse de suivre mon évolution avec intérêt et de m’apporter, dans la foulée, un soutien tout aussi ininterrompu que précieux. Je ne vous remercierai jamais assez d’être aussi présent à mes côtés ! Je vous dis seulement merci car parmi les mots qui peuplent mon vocabulaire aucun d’eux ne pourrait exprimer avec exactitude toute ma gratitude pour vous. Aussi, me faudrait-il des pages entières pour décrire tout ce que je vous dois. Mes remerciements s’adressent également à mes frères et sœurs Adoum, Moussa, Adamou, Hissein, Khadidja, Amina, Hadjé Fatimé, Zamzam, Hadjé Mariam et Mahboub (décédé en 2013) pour leur soutien et leurs encouragements qui ne se sont jamais essouflés durant toute la durée de ma thèse. Je n’oublie pas également, dans cette page où le cœur s’exprime, tous les proches, amis et connaissances qui ne se privent pas d’occasion pour m’encourager dans mes études. Je remercie ma fiancée Haoua Brahim pour sa grande patience et son soutien qui l’est tout autant ; elle comprendra un jour que le temps et l’énergie consacrés aux études n’étaient pas vains. Je tiens à remercier Serge Chaumette, Arnaud Casteigts et Colette Johnen de m’avoir adopté dans leur thème MUSE (Mobility Ubiquity SEcurity), en m’associant à leurs différentes activités. Je remercie vivement Sébastien Bindel et Dramane Ouattara avec qui j’échange régulièrement sur nos travaux respectifs et sur divers autres sujets. Comment mettre fin aux remerciements sans pour autant avoir une pensée pour les anciens et actuels membres de l’environnement, appelé la CVT, dans lequel j’avais préparé ma thèse. Je les remercie tous ! Il s’agit, dans un ordre qui ne suit aucune logique, de : Sébastien Bindel, Hugo Balacey, Telesphore Tiendrebeogo, Tegawendé Bissyandé, Cyril Cassagnes, Jonathan Ouoba, Vincent Autefage, Rémi Laplace, Damien Dubernet, Jigar Solanki, Matthieu Barjon, Mohammed Y. Neggaz et Jonathan Saludas.

vii viii Symboles utilisés

ix x

tableau 1 – Liste de symboles utilisés

Symbole Description ⊥ Valeur vide ou nulle d’une variable f l Polynôme utilisé dans l’interpolation de Lagrange fb Point d’interpolation équivalent à (x, f l(x)) V Liste de nœuds parcourus dans la recherche des chemins disjoints Vb Liste de nœuds parcourus stockée localement P Chemin p Nombre premier de valeur supérieure ou égale à 2048 bits s / t Nœud source / nœud destination dans une transmission hi Saut constituant un chemin à l’étape i H Espace hyperbolique ⊕ Opérateur appliqué sur les sous-clés dans la reconstitution d’une clé S/Σ Secret / clé secrète τ Taille d’un secret Σ ∆ Donnée / secret ∆i Sous-donnée / sous-secret ∆t Variation du temps g Générateur d’un groupe cyclique q Degré de l’arbre d’adressage ou d’un nœud du réseau recouvrant HL Horloge de Lamport fh Fonction de hachage ← / → Affecte / retourne une valeur x mod y Donne le reste de la division de x par y s − t Indique le sens d’un chemin : trajet allant de s à t L Combinaision linéaire des polynômes de base de Lagrange l Polynôme de base de Lagrange k-chemins Ensemble de k chemins frayés dans le réseau (k, n) le seuil k requis pour la reconstitution d’une clé parmi n pièces générées G Graphe quelconque V / E Ensemble de sommets / Ensemble d’arcs d’un graphe G donné E− Ensemble des arcs sortants d’un nœud E+ Ensemble des arcs entrants vers un nœud deg Degré d’un nœud : nombre de ses voisins (nœuds adjacents) Src @ / Dst @ Adresse source / adresse destination Src ID / Dst ID Identifiant du nœud source / identifiant du nœud destination PSess ID Identifiant du nœud source / identifiant du nœud destination AD OV Adresse d’un nœud du réseau recouvrant ICV Valeur de vérification d’intégrité (de l’anglais Integrity Check Value) SEQ NBR Numéro de séquence d’un paquet du réseau recouvrant CXT Contexte d’une session Table des matières

Abstract / Résumé iii

Dédicace v

Remerciements vii

Symboles utilisés ix

Introduction générale 1

I État de l’art 5

1 Terminologie et définition des concepts de base 7 1.1 Taxonomie des systèmes informatiques ...... 7 1.2 Architecture client/serveur ...... 8 1.3 Systèmes pair-à-pair (P2P) ...... 8 1.3.1 Vue d’ensemble ...... 9 1.3.2 Variantes du système P2P ...... 9 1.4 Notions cryptographiques ...... 12 1.4.1 Définition des concepts de sécurité ...... 12 1.4.2 Échange de clés Diffie-Hellman et ses dérivés ...... 14 1.4.3 Secret réparti ...... 15 1.4.4 Réseau Privé Virtuel ou Virtual Private Network (VPN) ...... 16 1.5 Mobilité : principe et étude conceptuelle de quelques protocoles ...... 16 1.6 Conclusion ...... 18

2 Systèmes VPN mobiles 19 2.1 Systèmes VPN mobiles basés sur les protocoles p2p ...... 19 2.2 VPN mobiles nés de la combinaison IPSec + Mobile IP ...... 21 2.3 Protocole HIP (Host Identity Protocol)...... 21 2.4 VPN mobiles basés sur l’extension du protocole SIP ...... 22 2.5 VPN mobiles basés sur l’extension de SSH, SSL ou TLS ...... 24 2.6 Autres modèles de systèmes VPN mobiles ...... 24 2.7 Étude comparative de systèmes VPN mobiles ...... 24 2.8 Conclusion ...... 26

3 Recherche de chemins s-t disjoints 27 3.1 Solution déductible du problème du ﬂot maximal ...... 28 3.1.1 Réduction problème sommet-disjoint ; problème arc-disjoint ...... 28 3.1.2 Réduction problème arc-disjoint ; problème sommet-disjoint ...... 29

xi xii TABLE DES MATIÈRES

3.1.3 Équivalence entre les problèmes arc-disjoint et ﬂot maximal ...... 29 3.2 Approche basée sur la topologie en anneau ...... 31 3.3 Autres propositions algorithmiques et leurs corollaires ...... 31 3.4 Classiﬁcation des problèmes ...... 33 3.5 Applications ...... 33 3.6 Conclusion ...... 33

4 Gestion distribuée de clés 35 4.1 Échange de clés via des chemins multiples ...... 36 4.1.1 Échange de clés multi-chemin sur une topologie circulaire ...... 36 4.1.2 Échange de clés à chemins multiples sur les MANETs ...... 37 4.1.3 Échange de clés à chemins multiples sur les réseaux de capteurs ...... 37 4.2 PKI distribuée sur les réseaux P2P ...... 38 4.3 Distribution de clés basée sur le schéma à seuil (k, n) ...... 38 4.4 Taxinomie de paradigmes distribués de gestion de clés ...... 39 4.5 Conclusion ...... 39

II Conception de l’infrastructure 43

5 Découplage entre l’espace d’adressage et l’espace de nommage 45 5.1 Vue globale de l’architecture ...... 45 5.2 Infrastructure sous-jacente ...... 46 5.2.1 Adressage géométrique hyperbolique ...... 46 5.2.2 Protocole du routage glouton ...... 48 5.3 Modèle de tables de hachage distribuées (DHT) ...... 49 5.3.1 Principe du fonctionnement ...... 49 5.3.2 Mécanisme de nommage ...... 49 5.3.3 Stockage des couples dans CLOAK ...... 50 5.3.4 Coûts liés aux opérations dans CLOAK ...... 52 5.4 Modélisation du protocole de mobilité ...... 52 5.4.1 Cloisonnement entre l’espace d’adressage et l’espace de nommage ...... 53 5.4.2 Gestion distribuée de la mobilité ...... 54 5.4.3 Résilience et reprise de session ...... 55 5.4.4 Analyse de mobilité et comparatif technique ...... 56 5.5 Conclusion ...... 57

6 Sessions virtuelles sécurisées et mobiles 59 6.1 Motivations ...... 59 6.2 Architecture de l’intergiciel SEMOS ...... 60 6.2.1 Module de sécurisation de session ...... 61 6.2.2 Gestion de résilience de session ...... 62 6.2.3 Interfaçage entre SEMOS et les processus applicatifs ...... 66 6.2.4 Module de redirection de port ...... 66 6.3 Contraintes d’Internet ...... 67 6.4 Analyse de sécurité ...... 68 6.4.1 Protection contre les attaques par rejeu et les attaques DoS ...... 68 6.4.2 Autres propriétés ...... 69 6.5 Conclusion ...... 69 TABLE DES MATIÈRES xiii

7 Paradigme multi-chemin d’échange de clés 71 7.1 Motivations ...... 71 7.2 Recherche des k−chemins s-t disjoints ...... 72 7.2.1 Contexte d’étude ...... 72 7.2.2 Chemins disjoints : concepts et principes ...... 72 7.2.3 Modes et politiques du routage multi-chemin ...... 73 7.2.4 Algorithme du routage multi-chemin ...... 76 7.3 Protocole d’échange de clés et ses corollaires ...... 79 7.3.1 Méthodes de segmentation des clés en sous-clés ...... 79 7.3.2 Échange bout-à-bout de clés ...... 83 7.3.3 Concept de proxy de conﬁance et délégation de négociation de clé ...... 83 7.4 Analyse de sécurité ...... 86 7.4.1 Forces et faiblesses de l’utilisation des chemins disjoints ...... 86 7.4.2 Considérations sécuritaires ...... 87 7.4.3 Comparaison de notre approche avec deux protocoles connexes ...... 88 7.5 Conclusion ...... 89

III Mise en œuvre et expérimentations 91

8 Simulations/évaluation de CLOAK / SEMOS 93 8.1 Introduction ...... 93 8.2 Évaluation des performances de CLOAK ...... 93 8.2.1 Outils et paramètres utilisés ...... 94 8.2.2 Résultats de simulation ...... 94 8.3 Évaluation de SEMOS ...... 96 8.3.1 Prototypage du système SEMOS ...... 96 8.3.2 Environnement d’expérimentation ...... 97 8.3.3 Résultats d’évaluation ...... 97 8.4 Conclusion ...... 99

9 Simulations du modèle d’échange de clés 101 9.1 Introduction ...... 101 9.2 Outils et paramètres ...... 102 9.2.1 Étapes du processus d’échange de clés ...... 102 9.2.2 Cartographie des réseaux virtuels utilisés ...... 103 9.2.3 Diﬀérentes politiques du routage ...... 103 9.3 Résultats des simulations ...... 104 9.3.1 Simulations par nature de réseau ...... 104 9.3.2 Simulations par taille de réseau ...... 104 9.3.3 Impact du nombre de chemins disjoints sur l’échange de clés ...... 105 9.3.4 Interception des chemins disjoints ...... 106 9.3.5 Simulations par type de routage ...... 108 9.3.6 Nombre de sauts et longueur moyenne de transmission ...... 109 9.3.7 Distribution de probabilités par rapport au nombre de chemins ...... 110 9.4 Écart-type des taux de réussite ...... 111 9.5 Récapitulatif des résultats ...... 112 9.6 Conclusion ...... 112

Conclusion et perspectives 113 xiv TABLE DES MATIÈRES

Annexe 115

A Contributions issues de cette thèse 115 A.1 Journaux ...... 115 A.2 Articles ...... 115

B Preuves et algorithmes 117 B.1 Théorèmes et preuves ...... 117 B.2 Algorithmes ...... 118

C Quelques résultats complémentaires 119 Glossaire

CCDF Fonction de Distribution Cumulative Complémen- 110 taire (ou de l’anglais Complementary Cumulative Distribution Function) chemins s-t Un chemin s-t est un chemin qui va du sommet 33 source s au sommet destination t. chemins s-t arc-disjoints Deux chemins s-t sont dits arc-disjoints lorsqu’ils 27–33 n’ont aucun arc en commun. chemins s-t arête-disjoints Deux chemins s-t sont dits arête-disjoints lorsqu’ils 27, 29, n’ont aucune arête en commun. 33 chemins s-t sommet-disjoints Deux chemins s-t sont dits sommet-disjoints lors- 27–30, qu’ils n’ont aucun sommet en commun en déhors 33, 34 de s et t . client/serveur Le modèle client/serveur est un modèle composé 23 de deux entités dont l’une est passive, appelée serveur, et l’autre est active, appelée client. Le serveur fournit un service et attend les éventuelles requêtes émanant de clients qui le sollicite.

DHT Une DHT (Distributed Hash Table) ou une Table 11, 12, de Hachage Distribuée est une technologie utilisée 20 dans les systèmes P2P pour indexer et retrouver des informations disséminées à travers un réseau.

HDM L’attaque HDM (ou Homme Du Milieu) est la 15, faculté pour un attaquant d’usurper les identités 19, 36, de deux hôtes honnêtes H1 et H2 impliqués dans 59, 72, un échange réseau et de se faire passer à H1 pour 86–89 H2 et vice versa.

IPSec Internet Protocol Security est le protocole de sécu- 21, 24 rité le plus populaire de la couche IP. Il permet de fournir de tunnels de sécurité entre hôtes distants.

Mobile IP Mobile Internet Protocol est un protocole permet- 21 tant de fournir le service de mobilité aux nœuds mobiles d’un réseau.

xv xvi Glossaire

P2P Un système pair-à-pair (ou p2p) est un réseau dans 1, 8– lequel chaque pair joue, de façon alternée, le rôle 12, 19, du client, serveur ou transitaire - routeur -, ou une 20, 26, combinaison de ces rôles. 38–40, 54, 57, 67–69, 71, 72, 74, 79, 83, 93, 102, 104, 113 PKI Une PKI (Public Keys Infrastructure) ou une Infra- 14, 20, structure à Clés Publiques est une entité centrale 35, 38, réseau permettant de coordonner la gestion des 39 certificats cryptographiques. point d’articulation En théorie des graphes, Un sommet dont la sup- 83 pression disloque un graphe en deux sous-graphes séparés est appelé point d’articulation proxy de confiance Est appelé proxy de confiance, tout nœud avec 83, 84 lequel un échange de clés a eu lieu avec succès.

remous Le remous (ou churn en anglais) correspond aux 93 départs/arrivées intempestifs des nœuds stockeurs d’une DHT.

VPN mobile Un VPN mobile est un système VPN dont les 19–21 tunnels peuvent survivre aux perturbations et/ou aux changements d’emplacement réseau opérés par des hôtes mobiles qui forment les extrémités de ces mêmes tunnels. Introduction générale

En raison des propriétés fondamentales et inhérentes à leur architecture telles que l’auto- organisation, la disponibilité, l’absence du goulot d’étranglement, la tolérance aux pannes, le passage à l’échelle, le changement dynamique de topologie, l’autonomie des entités ou l’équilibrage de charge, les réseaux pair-à-pair (P2P) offrent une solution privilégiée afin de fournir des services précieux tels que le partage de fichiers, l’échange d’information, le calcul distribué ou simplement la possibilité de rester en contact avec le reste du monde à travers l’Internet. En l’absence d’une coordination centralisée et figée, les réseaux P2P permettent une interaction extensible entre les nœuds qui les constituent. Cette extensibilité est rendue encore plus robuste grâce à l’introduction de Tables de Hachage Distribuées (DHT) dans les systèmes P2P. Lorsqu’il est muni de cette technique d’indexation repartie sur l’ensemble de nœuds, le réseau P2P est alors désigné sous le vocable de système structuré. Portés nativement par les caractéristiques fondamentales énoncées ci-dessus et autres propriétés subsidiaires, les systèmes P2P connaissent actuellement une expansion sans précédent et suscitent de plus en plus d’engouement ces dernières années à la fois de la part des chercheurs [1–11] et du côté des internautes. Les statistiques relevées sur les activités et le trafic sur Internet plaident en effet dans ce sens : en moyenne, entre 18 et plus de 50 % du trafic total sur Internet est issu des systèmes P2P [12–16]. Dépourvus de tout point individuel de défaillance ou des goulots d’étranglement, les systèmes distribués, notamment les réseaux P2P, évoluent sans encombre dans des environnements dynamiques jalonnés par des changements perpétuels de topologie dûs aux départs et arrivées fréquents des nœuds ; les systèmes traditionnels basés sur l’architecture client/serveur, dont le serveur en constitue l’entité névralgique, échouent cependant à passer à l’échelle et/ou à évoluer sans incident dans de tels environnements. Les propriétés susmentionnées procurent un réel avantage aux réseaux P2P par rapport aux systèmes conçus sur la base du modèle client/serveur dont la coordination et les services essentiels et critiques sont exclusivement confinés au niveau du serveur. Cependant, force est de constater que certaines propriétés intrinsèquement liées aux systèmes P2P, qui sont pourtant d’une importance notable, pourraient se révéler comme une faille de sécurité ; cette vulnérabilité pourrait ainsi exposer les utilisateurs aux différentes menaces d’attaques, actives ou passives, qui sévissent sur Internet [17– 20]. Celles-ci sont d’autant plus préoccupantes que les politiques de sécurité traditionnelles basées sur une entité tierce de confiance centrale, comme l’infrastructure à clés publiques (PKI), ne peuvent être efficacement appliquées dans le cadre d’un système totalement distribué formé autour d’une topologie dynamique ; aussi évidente, l’incompatibilité structurelle qui existe entre les systèmes entièrement distribués et les infrastructures de sécurité destinées aux architectures centralisées. À défaut donc d’une coordination centrale, sur laquelle les infrastructures centralisées de sécurité sont basées, la mise en œuvre de la sécurité dans les systèmes distribués, notamment les réseaux P2P, demeure un défi majeur que le monde de la recherche tente de relever avec plus ou moins de succès [21–24]. De par leur spécificité conceptuelle et les caractéristiques qui y sont attachées telles que la décentralisation, l’auto-organisation du réseau ou l’autonomie des nœuds, les systèmes P2P requièrent

1 2

des solutions de sécurité appropriées. En effet, des travaux d’analyse de sécurité relativement récents ont permis de mettre en évidence la vulnérabilité des réseaux P2P [17–19]. Afin de prémunir ces systèmes contre des menaces manifestes d’attaque prévalant sur Internet [25], nous nous proposons, dans le cadre de cette thèse, d’une part, de définir une nouvelle politique de sécurité adaptée aux réseaux P2P, et, d’autre part, de proposer un nouveau protocole permettant de rendre les tunnels robustes à la mobilité. En d’autres termes, les travaux de la présente thèse consistent à définir une infrastructure de sécurité bâtie sur les réseaux P2P et constituée essentiellement de deux modules fondamentaux qui en forment la pierre angulaire : (1) le premier module définit un intergiciel proposant des sessions sécurisées et mobiles et (2) le second module propose, pour sa part, une nouvelle approche de gestion distribuée de clés basée sur des chemins nœud-disjoints. Aussi, nos travaux précédents ont-ils déjà permis de concevoir un nouveau protocole P2P qui, basé sur la géométrie hyperbolique, fournit des services d’adressage et de routage [6] ; un nouvel espace de nommage, bâti au-dessus du réseau recouvrant et permettant de découpler les identifiants d’entités communicantes de leurs adresses, est donc nécessaire pour disposer de la mobilité [7]. Dès lors, le but principal de cette thèse est de fournir une sécurité accrue, avec en toile de fond un mécanisme robuste d’échange de clés basé sur l’utilisation des chemins disjoints, et un service de mobilité qui est tout aussi robuste. Ces services sont destinés aux réseaux recouvrants P2P, et plus particulièrement à l’infrastructure sous-jacente de notre modèle. Afin de répondre aux problèmes liés à l’incompatibilité triviale entre les méthodes employées dans les infrastructures traditionnelles de gestion de clés et les systèmes P2P totalement décentralisés, nous proposons une nouvelle approche distribuée de gestion des clés fondée sur une négociation de bout-à-bout basée sur l’utilisation des chemins nœud-disjoints. Le protocole proposé est une extension de l’algorithme cryptographique Diffie-Hellman (DH) ; bien qu’il soit une approche cryptographique intéressante d’échange de clés, il n’en demeure pas moins que le protocole DH soit sensible aux attaques par l’homme du milieu (HDM). À la lumière de ce qui précède, nous proposons un nouveau procédé qui se veut être invulnérable aux attaques par HDM. En effet, la nouvelle méthode consiste à garantir à la fois l’authentification du correspondant et l’échange d’un secret entre deux pairs en s’appuyant sur l’utilisation de plusieurs chemins nœud-disjoints : au cours d’une négociation de clé secrète, chaque transmission de sous-clé est effectuée à travers un chemin séparé sur le réseau, ce qui garantit simultanément la robustesse et l’authentification. Certes, les attaques par HDM isolées orchestrées par des nœuds malveillants pourraient être déjouées mais les attaques par HDM coordonnées pourraient réussir à intercepter les différentes composantes d’une clé. Cependant, nous montrons par des expérimentations que ces attaques sont difficiles à mettre en œuvre et quand bien même lorsqu’elles seraient menées, le taux moyen d’échanges réussis de clés est très élevé. Mieux, l’utilisation du mécanisme de pair de confiance, introduit dans notre approche, permet d’avoir un taux de réussite encore plus élevé. Le mécanisme de fragmentation de clé proposé s’appuie sur une méthode robuste : le schéma à seuil (k, n) de Shamir. Le procédé consiste à subdiviser une clé en plusieurs composantes virtuelles, appelées sous-clés : ces dernières sont constituées essentiellement des points d’interpolation de Lagrange et ne sont pas consitutées des fragments proprement dits de la clé de départ. Cette propriété recèle une grande robustesse par rapport à la méthode naïve qui consiste à segementer littéralement une clé. Par ailleurs, nous procéderons aux expérimentations basées sur diverses topologies P2P, aléatoires ou circulaire, qui permettent de donner une distribution des taux de réussite par rapport au pourcentage des attaquants coordonnés présents sur le réseau. De façon analogue, nous évaluerons également notre approche sur différents cartes topologiques dont BGP4, MP [26], Erdős-Rényi [27] et une topologie construite à l’image d’Internet. De nos jours, les réseaux P2P, les équipements mobiles et les réseaux sans fil ont progressivement gagné en popularité ; ces technologies de communication permettent de fournir la mobilité et/ou une haute connectivité à leurs usagers. Ces propriétés pourraient néanmoins être propices aux intrusions malveillantes. En effet, les ondes radio, dans le cas des réseaux sans fil, et l’autonomie organisationnelle, dans le cas des réseaux P2P, pourraient potentiellement rendre ces systèmes Introduction Générale 3

perméables aux infiltrations par des hôtes pernicieux. L’intégration de la mobilité dans les réseaux privés virtuels (VPN) tradionnels est un véritable défi. En effet, lorsqu’une extrémité d’un tunnel change de point d’attachement réseau alors le tunnel se rompt et une renégociation de clés est nécessaire pour le rétablir. Aussi, lorsque les extrémités de tunnel tournent dans un environnement dynamique (voire mobile) alors il s’en suit que les renégociations de clés deviennent fréquentes sur le réseau. Ce phénomène pourrait non seulement être source d’attaques, notamment des attaques HDM, mais il également a un coût : c’est lors de la phase de négociation et/ou de renégociation de clés que les nœuds impliqués dans ces opérations sont le plus vulnérables aux attaques ; c’est aussi durant ces étapes qu’une latence plus ou moins importante est engendrée. Afin de remédier aux problèmes décrits, nous proposons un intergiciel, appelé SEMOS (de l’anglais SEcured MObile Session), capable de fournir des sessions sécurisées et mobiles aux utilisateurs. Techniquement, cette infrastructure s’intercale entre les applications utilisateur et notre système P2P ; elle exploite notre mécanisme de nommage afin de fournir le service de mobilité aux utilisateurs. Aussi, un prototype de cette infrastructure est proposé et comparé, par expérimentations, à d’autres protocoles VPN mobiles tels que N2N [28], HIP [29] ou MOBIKE [30]. Il en ressort que notre approche présente des performances assez satisfaisantes, notamment sur la latence induite lors de reprise de session consécutive à une défaillance du réseau.

Le reste du mémoire de thèse se décline principalement comme suit : — la partie I décrit essentiellement la terminologie utilisée, les définitions de concepts de base nécessaires et propose un état de l’art détaillant quelques modèles notables et connexes à différents éléments structurants de nos travaux de thèse ; — la deuxième partie se compose principalement de l’étude conceptuelle de l’architecture de notre système : elle décrit d’abord la méthode basée sur les DHT permettant le découplage, nécessaire pour la mobilité, entre les identifiants de pairs et leurs adresses réseau, elle fournit ensuite une étude détaillée de l’intergiciel SEMOS capable de founir des sessions sécurisées et mobiles en se servant du modèle de mobilité introduit précédemment, et enfin, cette deuxième partie traite largement la technique d’échange de clés de bout-à-bout basée sur l’utilisation des chemins disjoints entre deux pairs et ses corollaires ; — la troisième partie consiste en expérimentation et évaluation de principaux modules qui constituent notre infrastructure de sécurité : elle contient en effet les détails sur les para- mètres, outils et environnements utilisés ainsi que les simulations réalisées et les résultats obtenus, et dont certains sont comparés avec les résultats des autres modèles existants évalués. 4 Première partie

État de l’art

CHAPITRE 1

Terminologie et déﬁnition des concepts de base

Sommaire 1.1 Taxonomie des systèmes informatiques ...... 7 1.2 Architecture client/serveur ...... 8 1.3 Systèmes pair-à-pair (P2P) ...... 8 1.3.1 Vue d’ensemble ...... 9 1.3.2 Variantes du système P2P ...... 9 1.4 Notions cryptographiques ...... 12 1.4.1 Déﬁnition des concepts de sécurité ...... 12 1.4.2 Échange de clés Diﬃe-Hellman et ses dérivés ...... 14 1.4.3 Secret réparti ...... 15 1.4.4 Réseau Privé Virtuel ou Virtual Private Network (VPN) . . . . . 16 1.5 Mobilité : principe et étude conceptuelle de quelques protocoles 16 1.6 Conclusion ...... 18

1.1 Taxonomie des systèmes informatiques

Systemes` informatiques

Systemes` repartis´ Systemes` centralises´ ex: Mainframe, station de travail

Systemes` P2P Systemes` Client/Serveur

P2P totalement decentralis´ es´ Systemes` Hybrides Plats Hierarchiques´ ex: CAN, Cloak, Chord,Viceroy ex: N2N, Skype ex: SSL/TLS ex: Grilles de calcul

figure 1.1 – Classification simplifiée des systèmes informatiques

7 8 1.2. ARCHITECTURE CLIENT/SERVEUR

La figure 1.1 décrit la taxinomie simplifiée des systèmes informatiques qui existent actuellement. Cette classification se compose principalement de deux grandes familles des systèmes informatiques : les systèmes répartis et les systèmes centralisés. Aussi, les systèmes répartis se divisent à leur tour en deux importantes familles : les systèmes P2P et les architectures client/serveur. Dans ce mémoire de thèse, nous allons nous beaucoup plus focaliser sur les systèmes distribués, plus particulièrement sur les systèmes P2P - mis en exergue sur la figure 1.1 par l’encadré verdâtre. Fort du potentiel qui caractérise leur architecture, les systèmes P2P constituent en effet la pierre angulaire de nos travaux. Nous allons faire, dans les deux premières sections suivantes, un petit rappel sur l’architecture client/serveur et mener ensuite une étude descriptive du protocole P2P. Aussi, nous introduisons les éléments qui servent à comprendre les concepts qui seront étudiés dans la suite du document.

1.2 Architecture client/serveur

Client requ connexion eteˆ reponse´ Serveur

reponse´ connexion eteˆ requ

reponse´ eteˆ connexion requ

connexion requ eteˆ reponse´

ﬁgure 1.2 – Modèle client/serveur : cas de quatre clients

L’architecture client/serveur est un modèle constitué essentiellement de deux types d’entités : l’entité centrale et passive est appelée serveur et l’entité active est appelée client. Comme l’illustre la ﬁgure 1.2, le serveur oﬀre un service aux clients et ceux-ci sollicitent le service proposé par le serveur selon le schéma suivant : connexionclient → requêteclient → réponseserveur → requêteclient. Le modèle client/serveur est l’une des architectures les plus utilisées actuellement en dépit du fait qu’il soit notamment sensible aux pannes et inapte à passer à l’échelle. Aussi, comme le serveur concentre la coordination de toutes les activités du réseau, il y a un risque qu’il soit débordé des requêtes : lorsque cette saturation est intentionnelle, on parle alors de l’attaque DoS (Denial-of-Service) ou attaque par déni de service.

1.3 Systèmes pair-à-pair (P2P)

Dans cette section, nous étudions le système P2P et ses principales variantes ; nous procédons également à une analyse comparative portant sur les caractéristiques et/ou les performances des protocoles P2P existants. CHAPITRE 1. TERMINOLOGIE ET DÉFINITION DES CONCEPTS DE BASE 9

1.3.1 Vue d’ensemble Définition : Un système pair-à-pair ou peer-to-peer (ou simplement P2P) est un réseau informatique constitué essentiellement d’une collection d’entités autonomes et homologues, appelées pairs. Tous les pairs du réseau jouent en effet les mêmes rôles : ils font, alternativement ou simultanément, office de client, de serveur et de relais (forwarder). De par son architecture distribuée, le protocole P2P se distingue donc d’avec le modèle client/serveur. Ce contraste permet aux systèmes P2P de combler beaucoup de limitations constatées sur l’architecture client/serveur.

Avantages : L’architecture inhérente aux systèmes P2P leur procure des facultés permettant de satisfaire les propriétés suivantes : la résistance aux pannes, l’équilibrage de charge, l’auto- organisation, la disponibilité, le passage à l’échelle (i.e, l’absence des goulots d’étranglement dans le réseau), etc. Ces caractéristiques, renforcées par l’utilisation des tables de hachage distribuées (DHT), permettent aux systèmes P2P d’atteindre un niveau des performances rarement égalé par les autres formes de systèmes informatiques existants.

1.3.2 Variantes du système P2P

Nous étudions dans cette section quelques P2P familles du système et leurs spéciﬁcités conceptuelles.

1.3.2.1 Réseaux P2P décentralisés & semi-décentralisés (ou hybrides)

ﬁgure 1.3 – Exemple d’une topologie P2P ﬁgure 1.4 – Exemple d’une topologie P2P totalement décentralisée semi-décentralisée

Les systèmes P2P sont par définition des systèmes distribués. Il existe cependant deux principaux types de topologie P2P : la topologie totalement décentralisée, dont un exemple est représenté par la figure 1.3, et la topologie sémi-décentralisée, qui peut être illustrée par la figure 1.4. Dans le cas des systèmes semi-décentralisés, la topologie est organisée en communautés formées autour de nœuds spéciaux, appelés super pairs, qui coordonnent les activités des membres de leurs communautés (ex : N2N [28] et ELA VPN [31]). Contrairement à ces systèmes, les systèmes P2P totalement distribués n’assignent aucun rôle particulier à aucun pair spécial : les nœuds possèdent exactement le même stattut et donc les mêmes fonctionnalités (ex : Chord [4] et CLOAK [6, 32]). En outre, la topologie des protocoles P2P décentralisés est dépourvue de tout point critique dont le dysfonctionnement pourrait altérer tout le fonctionnement du système. 10 1.3. SYSTÈMES PAIR-À-PAIR (P2P)

1.3.2.2 Systèmes P2P recouvrant (overlay) Définition : Un système P2P recouvrant est un réseau P2P virtuel basé sur une topologie virtuelle et construite au-dessus d’une topologie réseau existante. En général, le réseau sous-jacent est un réseau IP. Les pairs d’un système P2P recouvrant sont unis par une relation d’adjacence logique. Tout en faisant en effet abstraction de la complexité du réseau sous-jacent, un nœud du réseau recouvrant peut communiquer avec un autre soit directement comme étant son voisin réel, soit via des nœuds relais du réseau recouvrant à l’aide d’un routage de proche en proche. Cependant, comme l’illustre la figure 1.5, il peut exister une asymétrie entre la topologie du réseau sous-jacent et la topologie virtuelle projetée sur le plan du réseau recouvrant. Topologie virtuelle

mzs,gml,elzmg,mgf,,mezlegmze,gf Topologie sous-jacente

ﬁgure 1.5 – Exemple d’une topologie des systèmes P2P recouvrants

Remarques : L’utilisation des réseaux recouvrants n’exige pas le déploiement de nouveaux équipements ni la modiﬁcation d’applications et protocoles existants. Un nœud du réseau de base n’est, de surcroît, sollicité que lorsque sa projection sur la topologie logique est assignée à un traﬁc, ce qui permet alors d’économiser des ressources (bande passante, temps CPU, mémoire, etc). Cependant, l’ajout d’une couche réseau supplémentaire aboutirait forcément à l’utilisation de nouveaux en-têtes additionnels, ce qui augmente donc mécaniquement la complexité du traitement et du routage.

1.3.2.3 Systèmes P2P non-structurés Les protocoles P2P non-structurés sont des systèmes P2P ad hoc qui utilisent la diffusion à des fins de découverte de pairs et/ou de ressources. Les performances du routage de ces protocoles sont donc tributaires du TTL (Time-To-Live) qui possède une valeur bornée. L’utilisation du TTL permet ainsi d’éviter que les paquets ne circulent indéfiniment dans le réseau. Cependant, la technique basée sur le TTL empêche les systèmes non-structurés de passer à l’échelle. Le principe de découverte de pair utilisé généralement est le suivant : initialement, chaque pair contacte ses voisins et rapatrie leurs tables de routage, ensuite il répète le même processus avec les pairs nouvellement découverts et ainsi de suite. Ainsi, de proche en proche, les pairs parviennent à se découvrir mutuellement par inondation (flooding). Typiquement, les systèmes P2P non-structurés sont organisés de façon anarchiquement indéterministe, la topologie qui en résulte est donc un graphe aléatoire. Le tableau 1.3 compare les caractéristiques de trois protocoles P2P qui font partie des systèmes P2P non-structurés les plus populaires. CHAPITRE 1. TERMINOLOGIE ET DÉFINITION DES CONCEPTS DE BASE 11

tableau 1.3 – Comparatif de systèmes P2P non-structurés

Systèmes P2P non-structurés Caractéristiques FastTrack(KaZaA) [33] Freenet [8] Gnutella [34] Paramètres TTL ; na TTL ; n TTL Performance du routage < TTL < TTL < TTL Taille de la table du routage O(log n) O(log n) O(1) Coût d’insertion/suppression O(log n) O(log n) O(1) a Nombre d’hôtes dans le réseau

1.3.2.4 Systèmes P2P structurés Les systèmes P2P structurés sont des systèmes P2P basés fondamentalement sur les Tables de Hachage Distribuées (Distributed Hash Tables ou DHT). Les tables de hachage distribuées, dont les entrées sont constituées des correspondances entre les clés et les valeurs, permettent d’indexer les ressources sur le réseau ; elles sont réparties, de façon redondante, sur plusieurs pairs du réseau. La redondance permet en effet d’éviter la perte de données consécutive au départ ou aux défaillances de certains nœuds. Contrairement à la technique précédente basée sur l’inondation, la recherche sur les réseaux P2P structurés est efficace et elle s’opère, pour la plupart de ces systèmes, en temps logarithmique (O(log n)). L’approche permet en effet de répartir une table de hachage sur plusieurs nœuds dont chacun s’occupe d’un sous-ensemble redondant de l’annuaire des ressources (DHT). Le mécanisme de partitionnement de l’espace d’adressage permet de segmenter l’annuaire en sous-espaces de nommage dont chacun est désigné par un préfixe de sous-ensemble de clés.

Sous-espace de nommage : ABC Sous-espace de nommage: DEF cle´ ressource cle´ ressource f h(R1) ABC701 R1 f h(R4) DEFA20 R4 → → f h(R2) ABC986 R2 f h(R5) DEFD86 R5 → → f h(R ) ABCB12 R 3 → 3

pairs Reseau´ P2P structure´ fh: fonction de hachage

Sous-espace de nommage: 456 Sous-espace de nommage: 123 cle´ ressource cle´ ressource f h(R7) 456AD4 R7 → f h(R6) 123EF8 R6 f h(R ) 456F2D R → 8 → 8 ﬁgure 1.6 – Représentation simpliﬁée d’un réseau structuré

Les DHTs permettent une indexation efficace des ressources réparties sur les nœuds du réseau ; chaque nœud/ressource est identifié(e) de façon unique par un identifiant global qui lui est assigné à son arrivée sur le réseau. L’invocation d’une ressource stockée sur un réseau DHT (lookup), 12 1.4. NOTIONS CRYPTOGRAPHIQUES

comprenant n nœuds, s’effectue en général en temps O(log n). Par ailleurs, les opérations de base sur une DHT sont : ajouter(clé, ressource), extraire(clé) → ressource et supprimer(clé). La valeur de la clé est une donnée retournée par une fonction de hachage qui prend en argument le nom de la ressource à publier. La figure 1.6 illustre de façon simplifiée la répartition des tables de hachage sur les nœuds du réseau. Les procédés de nommage introduits par les systèmes DHT résolvent définitivement les problèmes de passage à l’échelle qui, faut-il le rappeler, sont intrinsèques aux architectures de systèmes P2P non-structurés. Le tableau 5.9 dresse un comparatif technique de quelques systèmes P2P structurés que nous estimons à la fois notables et intéressants.

tableau 1.4 – Comparatif de quelques systèmes DHT avec CLOAK

Systèmes DHT Caractéristiques CAN [1] Chord [4] CLOAK [35, 36] Kademlia [10] Pastry[2] Viceroy[9] Paramètre(s) d a, n b n n n n n √ Nombre de sauts O( d n) O(log n) O(log n) O(log n) O(log n) O(log n) Taille table du r. O(d) O(log n) O(1) c O(log n) O(log n) O(1) Insert./supp. O(d) O(log2 n) O(1) ou O(n) O(log n) O(log n) O(log n) Espace d’adress. tore multid. circulaire p. hyperbolique arborescente circulaire papillon a Dimension du plan considéré b Nombre d’hôtes dans le réseau c Routage glouton basé sur les distances virtuelles hyperboliques

1.4 Notions cryptographiques

1.4.1 Déﬁnition des concepts de sécurité

1.4.1.1 Attributs de sécurité

Les attributs de base de la sécurité informatique sont succintement décrits dans les points suivants.

1. Intégrité. L’intrégrité de données permet de s’assurer si les données reçues n’ont été altérées durant leur transport. L’algorithme MAC(Message Authentication Code), basé sur MD5 ou SHA, implémente cette fonctionnalité.

2. Authentification. L’authentification est un mécanisme permettant d’identifier une entité réseau qui peut être un processus, un utilisateur ou un équipement. L’authentification permet en effet de garantir qu’une entité est bel bien ce qu’elle prétend être.

3. Confidentialité. La confidentialité est un procédé cryptographique servant à rendre un message inintelligible aux personnes non autorisées. Le module ESP (Encapsuling Security Payload) de IPSec est un exemple d’implémentation de la confidentialité.

4. Non-répudiation. La non-répudiation est un procédé permettant de garantir qu’une transaction approuvée et eﬀectuée par des partenaires ne peut être remise en cause par l’une des parties. CHAPITRE 1. TERMINOLOGIE ET DÉFINITION DES CONCEPTS DE BASE 13

1.4.1.2 Chiffrement / Déchiffrement Afin d’assurer la confidentialité d’un message ou l’extraction du message original à partir d’un message confidentiel, l’utilisation de deux opérations fondamentales suivantes est réquise : — Chiffrement. Le chiffrement est une opération cryptographique qui consiste de prendre en entrée un texte en clair et de produire en sortie un texte chiffré : chiffrement (clé, texte en clair) → texte chiffré. En d’autres termes, le chiffrement consiste à rendre inintelligible des données aux entités tierces.

— Déchiffrement. Le déchiffrement est une opération réciproque de chiffrement : il permet en effet d’extraire un texte en clair à partir d’un texte chiffré donné en entrée : déchiffrement (clé, texte chiffré) → texte en clair.

1.4.1.3 Cryptographie symétrique et asymétrique Il existe principalement deux types de cryptographie servant à chiffrer et déchiffrer les messages : — Cryptographie symétrique. La cryptographie symétrique est une technique permettant d’utiliser la même clé cryptographique ks pour chiffrer et déchiffrer : chiffrer (ks, texte en clair) / déchiffrer (ks, texte chiffré). L’algorithme AES est actuellement l’algorithme symétrique le plus utilisé et le plus robuste qui existe.

— Cryptographie asymétrique. La cryptographie asymétrique consiste à utiliser un couple de clés (ks, kp) dont kp sert à chiffrer et ks permet de déchiffrer : chiffrer (kp, texte en clair) / déchiffrer (ks, texte chiffré). De nos jours, l’algorithme RSA est l’un des algorithmes asymétriques les plus populaires et les plus puissants.

1.4.1.4 Clé privée / clé publique La cryptographie asymétrique utilise un couple de clés pour les opérations de chiffrement et de déchiffrement ; cette paire de clés est constituée de : — Clé privée. Une clé privée est une clé utilisée dans le cadre de la cryptographie asymétrique afin de déchiffrer et/ou de signer des messages ; elle n’est pas publiée et n’est connue que de son propriétaire.

— Clé publique. Une clé publique est une clé utilisée dans le cadre de la cryptographie asymétrique et qui sert à chiﬀrer et/ou à vériﬁer les signatures ; elle est accessible à tous les correspondants potentiels du détenteur de la clé privée associée. La propriété de la clé publique est telle qu’il serait impossible d’en déduire la clé privée correspondante.

1.4.1.5 Certificat / Signature Afin de garantir l’authenticité de la clé publique d’une entité ou l’authenticité d’un message transmis sur le réseau, les mécanismes suivants sont proposés : — Certificat numérique. Un certificat numérique permet de vérifier l’apartenance d’une clé publique. Typiquement, un certificat est constitué d’une clé publique ayant motivé sa création, des informations sur son propriétaire (nom, adresse, mail, organisme d’affiliation, ...), des signatures des entités réseau reconnaissant son authenticité ainsi que des informations additionnelles (date de création, date d’expiration, ...). L’étape de la vérification de l’authenticité d’une clé publique est cruciale dans le processus de la sécurisation d’une 14 1.4. NOTIONS CRYPTOGRAPHIQUES

transaction.

— Signature numérique. La signature numérique est un condensé cryptographique permettant de s’assurer de l’authenticité d’un message ; elle garantit qu’aucune modiﬁcation ne peut être opérée sur un message sans que le destinataire ne s’en aperçoive.

1.4.1.6 Infrastructure à clés publiques (Public Key Infrastructure ou PKI) Définition : Une PKI est un dispositif cryptographique permettant de faire correspondre, à l’aide d’une authorité de certification (CA), les utilisateurs aux clés publiques qui leur sont associées. Aussi, la PKI assure toutes les opérations relatives à la gestion des certificats : génération des certificats, publication des certificats, révocation des certificats, recouvrement des certificats, stockage des certificats, etc.

Motivations : L’authentication des paramètres cryptographiques et des utilisateurs est un élément fondamental dans la sécurisation d’une communication. Ainsi, la nécessité d’avoir un arbitrage central s’est vite avéré indispensable. Afin d’éviter des attaques par usurpation d’identité qui sévissent sur Internet, la PKI a été en effet proposée et investie d’une mission qui consiste notamment à garantir l’authenticité des données cryptographiques. Il est à noter que les transactions bancaires et autres trafics critiques sur Internet sont pour la plupart effectués à l’aide d’une PKI.

1.4.2 Échange de clés Diffie-Hellman et ses dérivés Le protocole Diffie-Hellman [37] est l’un des premiers algorithmes cryptographiques qui avaient jeté la base de la politique d’échange de clés. Le mécanisme d’échange de clé proposé par cet algorithme est d’autant plus intéressant qu’il est utilisé dans beaucoup de protocoles de sécurité utilisés actuellement tels que SSH, SSL et IPSec. Le procédé Diffie-Hellman est en effet un algorithme asymétrique basé sur le Problème du Logarithme Discret(PLD) et qui consiste à déterminer une clé commune dérivée des clés privées respectives de deux correspondants et d’un certain nombre d’informations publiques.

Fondement algorithmique : L’algorithme 1 décrit le mécanisme d’échande de clés proposé par Diﬃe et Hellman.

Algorithme 1 : Échange de clés Diﬃe-Hellman paramètres publics : paramètres secrets : p : un nombre premier Alice : clé secrète sa g : un générateur Bob : clé secrète sb

sa 1. Alice sélectionne un nombre aléatoire sa et calcule Ka = g (mod p) ;

2. Alice envoie ensuite Ka à Bob ;

3. Bob reçoit Ka de Alice ; s 4. Bob choisit un nombre aléatoire sb et calcule Kb = g b (mod p) ;

5. Bob envoie ensuite Kb à Alice ;

6. Alice reçoit Kb envoyé par Bob ;

sa sa·s 7. Alice calcule ﬁnalement K = Kb = g b (mod p) ;

sb sa·s 8. Bob détermine ﬁnalement K = Ka = g b (mod p) ; CHAPITRE 1. TERMINOLOGIE ET DÉFINITION DES CONCEPTS DE BASE 15

Fondement mathématique : Soit un groupe fini (G, ⊗) noté multiplicativement, d’ordre ω et de cardinalité k. S’il existe g ∈ G tel que ∀e ∈ G, e = gn, où n ∈ N∗, alors G est dit groupe cyclique et g est appelé un générateur de G. La robustesse du procédé Diffie-Hellman (DH) s’appuie sur l’utilisation du logarithme discret ∗ dans le groupe multiplicatif Z/pZ , avec p un nombre premier assez grand [38]. Formellement, soit v un entier donné, calculer l’entier 1 ≤ u ≤ ω − 1 tel que gu = g ⊗ ... ⊗ g = v est un problème très | {z } u termes difficile à résoudre actuellement, surtout lorsque u et v sont suffisamment grands. L’utilisation des nombres premiers de taille supérieure à 1024 bits est recommandée, faute de quoi les attaques par recherche exhaustive ou par l’algorithme de Silver-Pohlig-Hellman [39] sont à redouter. Cependant, il n’existe pas, en effet, à ce jour une solution polynomiale pour calculer u et v à partir des informations publiques (g, p, gu, gv). Techniquement, le problème Calculatoire de Diffie-Hellman (CDH) repose sur la difficulté de calculer gu.v à partir de la connaissance de gu et gv. Le problème CDH peut-être réduit au problème DH et donc au problème PLD[40]. Cependant, la difficulté réside toujours au niveau du problème PLD. Étant donnés v1, v2 et v3, le problème Décisionnel de Diffie-Hellman (DDH) consiste à répondre u1 u2 u1.u2 par oui ou non s’ils s’écrivent sous les formes respectives : v1 = g , v2 = g et v3 = g , avec u1 et u2 quelconques. Le problème DDH est réductible au problème CDH. Vulnérabilité : 1. Attaques actives : — L’absence de l’authentification de la clé publique crée une faille de sécurité qui peut être exploitée par une attaque HDM ; — L’attaque par rejeu est possible et peut-être exécutée pour la même raison. 2. Attaques passives : — Lorsque les entiers ne sont pas assez grands, il existe une vulnérabilité inhérente au Problème du Logarithme Discret mise en évidence par Silver-Pohlig-Hellman [39] ; — Le risque d’une attaque par recherche exhaustive est aussi élevé lorsque la taille des entiers choisis est faible ; —L’ écoute du canal de transmission est possible car la négociation est en clair.

1.4.3 Secret réparti

1.4.3.1 Secret fractionné en n composantes (σ1, ..., σn) ∗ L’approche consiste à scinder un secret Σ = {0, 1} , où |Σ| = τ, en n morceaux σ1, ..., σn ; chaque τ sous-secret σi, où |σi| = n , est ensuite stocké/envoyé séparément. La récomposition ultérieure de Σ requerra la réunion de tous les sous-secrets σi.

Point faible : Cette subdivision n’est pas eﬃcace car elle permet de réduire, pour un dépositaire τ τ(n−α) de α sous-secrets, la diﬃculté d’exécuter une attaque par force brute en τ − α n , soit n .

1.4.3.2 Schéma à seuil (k, n) Déﬁnition : Le schéma à seuil (k, n), où k ≤ n, inventé par Shamir en 1979 [41], consiste à subdiviser une donnée ∆ en n sous-données ∆1, ..., ∆n telles que celles-ci satisfassent les deux conditions suivantes : — la connaissance d’au moins k données détermine ∆ : ∆ = ∆u ⊕ ... ⊕ ∆v ; | {z } ≥ k termes — la connaissance d’au plus k − 1 données ne reconstitue pas ∆ : ∆ 6= ∆x ⊕ ... ⊕ ∆y. | {z } < k termes 16 1.5. MOBILITÉ : PRINCIPE ET ÉTUDE CONCEPTUELLE DE QUELQUES PROTOCOLES

La méthode proposée s’appuie sur l’interpolation L’interpolation de Lagrange.

Motivations : La segmentation d’une donnée cryptographique en plusieurs sous-données dis- séminées à travers des entités séparées empêche, par exemple, aux entités isolées de procéder à une opération sensible : il faut réunir un quorum avant de pouvoir exécuter l’opération. Aussi, la perte de π sous-données, avec n − π ≥ k, due aux défaillances de routage, par exemple, n’a pas d’incidence dans le calcul de la donnée principale.

1.4.4 Réseau Privé Virtuel ou Virtual Private Network (VPN) Un Réseau Privé Virtuel ou VPN est un concept abstrait qui relie des sites distants, séparés par un réseau potentiellement infesté par des entités malveillantes - Internet, par exemple -, à l’aide des tunnels de sécurité (voir la figure 1.7). La sécurisation des données circulant entre des sites distants est réalisée par le biais du module appelé protocole de tunnelisation. Basé sur des algorithmes cryptographiques et la communication point-à-point, le protocole de tunnelisation fournit généralement aux extrémités d’un tunnel de sécurité des services comme la confidentialité, l’intégrité de données et l’authentification des correspondants.

Site A Internet Site B

Tunnel

ﬁgure 1.7 – Système VPN traditionnel

Il existe une extension du système VPN appelée Réseau Privé Virtuel Mobile ou Mobile Virtual Private Network (MVPN). Contrairement aux tunnels proposés par l’infrastructure VPN traditionnelle qui sont basés sur des extrémités ayant des adresses IP fixes, les tunnels du système MVPN sont flexibles et supportent le changement de configuration réseau sans avoir recours à une renégociation pour leur restauration : les tunnels sont maintenus actifs lorsque des perturbations se produisent sur le réseau. Cette aptitude permet en effet aux tunnels de sécurité de survivre à l’itinérance de leurs extrémités mobiles. Le chapitre 2 décrit amplement les techniques utilisées par les différents systèmes VPN mobiles existants afin de leur permettre de concilier la mobilité et la sécurité.

1.5 Mobilité : principe et étude conceptuelle de quelques protocoles

La mobilité peut être déﬁnie comme une technique permettant aux entités de changer de conﬁguration ou de gérer les perturbations réseau de façon transparente aux couches supérieures et aux entités avec lesquelles des sessions de communication ont été déjà établies. Il existe beaucoup de protocoles qui proposent une implémentation de la mobilité ; dans cette section, nous allons brièvement étudier quelques-uns. CHAPITRE 1. TERMINOLOGIE ET DÉFINITION DES CONCEPTS DE BASE 17

Mobile IP

Le Mobile IP [42] est un protocole standard défini par l’IETF. Techniquement, le dispositif Mobile IP est une infrastructure complexe constituée de quatre entités principales : le Home Agent (HA), le Foreign Agent (FA), le nœud itinérant ou Mobile Node (MN) et le Correspondent Node (CN). Le HA permet d’intercepter les paquets en provenance du réseau local envoyés par CN et à destination de NM (les messages et de la figure 1.8). Il route ensuite les paquets interceptés vers MN en se servant de l’adresse IP, appelée Care-of-address (CoF), acquise par celui-ci sur le réseau visité. Le HA tient en effet à jour une table de correspondance entre les adresses fixes et les CoF lui permettant de s’assurer de la validité de l’emplacement du MN. Ce mécanisme de routage triangulaire permet de rendre tranparents les changements de réseau opérés par un MN et offre ainsi au MN la possibilité d’être constamment en contact avec son CN distant (voir l’échange ). De son côté, le FA est chargé d’enregistrer, auprès de leur HA, les informations réseau relatives aux nœuds itiérants qui visitent son réseau (voir les requêtes et ). La figure 1.8 illustre en effet la séquence de messages nécessaire pour la gestion de la mobilité proposée par Mobile IP. Il faut préciser en outre que le protocole Mobile IPv6, correspondant à l’implémentation du protocole pour la version 6 de IP, est conceptuellement un peu différent du Mobile IPv4, mais il suit cependant les mêmes principes énoncés précédemment.

2 Réseau extérieur Intranet Internet FA HA 3 CN 1 4 MN

ﬁgure 1.8 – Architecture du protocole Mobile IP

Protocole SCTP

Le Stream Control Transmission Protocol (SCTP) est un protocole unicast permettant de supporter le multi-homing à des ﬁns de redondance [43]. L’utilisation de ce mécanisme permet au protocole SCTP de mieux être résistant aux pannes ; des chemins alternatifs sont en eﬀet utilisés pour remplacer les chemins défectueux dans une transmission. Ainsi, la session établie entre deux utilisateurs survit lorsque certaines liaisons sont hors service. Typiquement, chaque extrémité d’un canal de communication maintient une table de correspondance entre les adresses source et les adresses destination qui, à leur tour, sont associées à un même numéro de port. Lorsqu’une liaison de transmission tombe en panne alors la communication est automatiquement basculée sur un autre canal. 18 1.6. CONCLUSION

Protocole SIP L’utilisation de Session Initiation Protocol (SIP) est très répandue sur la VoIP (Voix sur IP)[44]. Nous renvoyons le lecteur au chapitre 2 pour plus de détails sur ce protocole.

Système HIP Une étude détaillée du protocole HIP (Host Identity Protocol)[29] est proposée dans le chapitre 2. Nous invitons le lecteur à s’y référer pour une description plus en détails de ce protocole.

1.6 Conclusion

Dans ce chapitre, nous avons mené une étude préalable des concepts qui serviront de base dans la suite du document et, plus particulièrement, dans la description de notre architecture. Les notions cryptographiques passées en revue jettent la base d’une compréhension ultérieure de notre modèle d’échange de clés et des systèmes existants qui seront abordés à la suite de la partie I. L’accent particulier a été mis sur le protocole Diﬃe-Hellman et le schéma à seuil (k, n) qui constituent, par ailleurs, les pivots autour desquels gravite notre modèle distribué d’échange de clés. Aussi, l’étude analytique du système P2P et de ses variantes permet de mieux appréhender l’environnement dans lequel notre infrastructure est destinée à opérer. En outre, nous avons aussi analysé quelques protocoles standards qui présentent des mécanismes intéressants de gestion de mobilité. CHAPITRE 2

Systèmes VPN mobiles

Sommaire 2.1 Systèmes VPN mobiles basés sur les protocoles p2p ...... 19 2.2 VPN mobiles nés de la combinaison IPSec + Mobile IP . . . . 21 2.3 Protocole HIP (Host Identity Protocol)...... 21 2.4 VPN mobiles basés sur l’extension du protocole SIP ...... 22 2.5 VPN mobiles basés sur l’extension de SSH, SSL ou TLS . . . . 24 2.6 Autres modèles de systèmes VPN mobiles ...... 24 2.7 Étude comparative de systèmes VPN mobiles ...... 24 2.8 Conclusion ...... 26 De nos jours, la flexibilité fournie par la connectivité sans fil et les avantages procurés par des procédés liés à l’utilisation des équipements/environnements mobiles/dynamiques suscitent un intérêt sans précédent ; l’expansion récente de réseaux ad hoc, réseaux P2P et divers équipements et mécanismes mobiles intensifie davantage cet élan d’enthousiasme. Cependant, la connectivité élevée, l’itinérance et/ou la mobilité pourraient être source de diverses intrusions et attaques. Ces dernières sont d’autant plus préoccupantes que les systèmes VPN traditionnels échouent à s’opérer efficacement dans un environnement mobile/dynamique. En effet, dans les systèmes VPN conventionnels, le changement de réseau - ou d’adresse IP - implique une renégociation systématique de clés afin d’établir de nouveaux tunnels de sécurité en lieu et place de tunnels rompus consécutivement à l’acquisition d’une nouvelle adresse IP ou à une perturbation réseau. Pendant les phases de négociation et de renégociation de clés cryptographiques que les systèmes sont le plus vulnérables : interception des échanges, attaques par HDM, attaques par rejeu, etc. Il va sans dire aussi que les renégociations engendrent une latence dans la reprise de communication. Afin de pallier à ces difficultés, des systèmes VPN mobiles ont été proposés ; ces systèmes ont la faculté de tenir, de façon transparente, actifs les tunnels de sécurité lors de changement de configuration réseau ou pendant un dérèglement qui affecte le réseau. Au cours de ce chapitre, nous allons étudier les différents systèmes VPN mobiles existants tout en nous focalisant sur leurs spécificités techniques et conceptuelles.

2.1 Systèmes VPN mobiles basés sur les protocoles p2p

En général, les systèmes P2P évoluent dans des environnements dynamiques dans lesquels la topologie du réseau change perpétuellement : changement dû au départ/arrivée fréquent de pairs qui constituent le réseau. La mise en œuvre de la sécurité dans ces systèmes devrait prendre en compte cette caractéristique qui leur est intrinsèque. Dans cette section, nous allons étudier quelques

19 20 2.1. SYSTÈMES VPN MOBILES BASÉS SUR LES PROTOCOLES P2P

protocoles VPN mobiles conçus pour les réseaux P2P. Basés sur une topologie organisée en communautés formées chacune autour d’un Super Node (voir la ﬁgure 2.9), ELA VPN [31] et N2N [28] sont des systèmes P2P implémentant un mécanisme de sécurité qui supporte la mobilité. Outre les propriétés intrinsèquement liées aux réseaux P2P comme le passage à l’échelle ou l’auto-organisation, ces systèmes présentent d’autres propriétés additionnelles telles que la traversée des NAT et la mobilité ; ils fournissent également de connexions sécurisées aux pairs communicants à travers un réseau non sûr - Internet. L’utilisation de Super Nodes réduit cependant leur extensibilité car ces nœuds assurent un rôle particulier et déterminant dans l’organisation du réseau et la gestion de la mobilité. Par ailleurs, les topologies et concepts de ces deux systèmes présentent beaucoup de similitudes en déhors du fait que N2N est implémenté au niveau de la couche 2 du modèle OSI alors que ELA VPN est implémenté au niveau de la couche 3 de ce modèle abstrait.

Edge Super Edge Node Node Node

Edge Node Super Super Edge Node Node Node

Edge Edge Node Node

ﬁgure 2.9 – Topologie du système N2N

La technique de mobilité utilisée repose essentiellement sur les Super Nodes. En effet, les Edge Nodes utilisent des adresses IP virtuelles et permanentes comme identifiants, et les Super Nodes tiennent à jour une table de correspondance entre ces adresses et les adresses IP réelles de Edge Nodes. Ainsi, lorsqu’un Edge Node change d’adresse IP, un message de notification contenant la nouvelle adresse IP est en envoyé aux Super Nodes afin qu’ils mettent à jour leur table de correspondance. Aussi, avant chaque communication impliquant les Edge Nodes, ceux-ci invoquent les Super Nodes pour récupérer les adresses IP les plus fraîches de leurs correspondants. Par conséquent, le départ accidentel ou volontaire de Super Node ou le changement de sa configuration réseau rendraient toute connectivité mobile impossible pour les Edge Nodes de sa communauté. Si les Super Nodes sont indispensables à tout point de vue pour la mobilité, il n’en demeure pas moins que la sécurité pourrait se négocier directement entre Edge Nodes sans leur implication. Freelan est un système VPN P2P, open-source et multi-plateforme [45] ; il permet de créer un LAN virtuel et sécurisé sur Internet. Basé sur le protocole UDP, le module principal FreeLAN Secure Channel Protocol (FSCP) est conçu pour fournir la sécurité à ce système P2P. Freelan peut être configuré suivant le mode client/serveur ou le mode P2P ou encore dans un mode hydride, issu de la combinaison de deux premiers modèles. Wolinsky et al. proposent un système VPN basé sur les réseaux P2P structurés et une PKI distribuée et sémi-automatisée [46]. En effet, l’infrastructure proposée est organisée en groupes de pairs qui gèrent la PKI à travers une interface web. Cette dernière offre aussi la possibilité de répudiation des utilisateurs suspectés de malveillance. En outre, l’amorce de ce système - bootstrapping - se fait par le biais d’un système P2P privé de confiance qui ne contient que les membres d’un groupe qui assurent un routage sécurisé entre eux et offrent un stockage DHT. CHAPITRE 2. SYSTÈMES VPN MOBILES 21

2.2 VPN mobiles nés de la combinaison IPSec + Mobile IP

Le protocole IPSec est nativement conçu pour être utilisé comme une infrastructure VPN et non pour fournir la mobilité. Cependant, des solutions VPN mobiles, basées sur l’extension du protocole IPSec, sont proposées dans divers travaux de recherche relativement récents[47–51]. L’objectif étant de résoudre les problèmes de mobilité inhérents aux systèmes VPN conventionnels. Ces systèmes VPN mobiles sont essentiellement conçus à partir de la combinaison IPSec + Mobile IP : la fonctionnalité de sécurité est fournie par IPSec [52] tandis que celle de la mobilité est assurée par Mobile IP [42]. Toutefois, l’union entre les deux protocoles pourrait provoquer de problèmes de compatibilité dont certains sont décrits dans la RFC 4093 proposée par Adrangi et al. [53]. En effet, considérons le scénario illustré par la figure 2.10, où le Foreign Agent (FA) et le Home Agent (HA) se trouvent sur deux réseaux séparés dont celui de HA est protegé par une passerelle IPSec. Les informations chiffrées, périodiquement transmises par un Mobile Node (MN) à HA via FA, seraient inintelligibles à FA, car elles étaient chiffrées à l’intention de la passerelle IPSec. Étant incapable de les interpréter, FA rejette illico les requêtes chiffrées reçues de MN. Par conséquent, le MN ne réussirait jamais à notifier le HA de sa position courante, ce qui entraine l’échec de cette technique pour le scénario considéré.

Réseau extérieur 11. Données chiffrées Intranet 221. Notification d’échec HA 2 FA Internet

MN 1 Tunnel Passerelle IPSec

ﬁgure 2.10 – Scénario d’un problème de compatibilité entre IPSec et Mobile IP

Aﬁn de régler ce problème, Vaarala et al. proposent un modèle basé sur l’utilisation de deux HA - HA-externe et HA-interne - et de deux FA - FA-externe et FA-interne - (voir la ﬁgure 2.11) [54]. Cependant, la communication entre un MN et le HA-interne réquiert l’utilisation de trois tunnels imbriqués : {MIP − x{GW {MIP − i{paquet original}}}}. Les trois tunnels sont indispensables pour communiquer, car le Mobile IP exige nativement un routage triangulaire. Lorsqu’il existe n sauts de passerelles IPSec et d’infrastructures Mobile IP entre le source et la destination, alors il est nécessaire d’utiliser 3*n tunnels superposés, ce qui cause un surcoût considérable sur le réseau. Les problèmes signalés dans l’article [53] et bien d’autres encore sont largement traités par le système MOBIKE basé sur l’extension du protocole IPSec [30, 55]. Plus intéressant encore, la solution proposée par Karbasioun et al. combinant connectivité sécurisée et Mobile IP est basée justement sur l’extension de MOBIKE [56]. Cependant, les problèmes liés au passage à l’échelle et le surcoût induit par la combinaison de deux protocoles subsistent.

2.3 Protocole HIP (Host Identity Protocol)

Le protocole HIP définit une infrastructure de sécurité qui fournit la mobilité et le multihoming [29]. HIP introduit un nouvel espace de nommage permettant de découpler l’identité de l’hôte, appelée Host Identity Tag (HIT), de sa localisation - adresse IP - (voir la figure 2.12, dans laquelle ID représente la clé publique). Chaque hôte HIP est identitfié de façon unique par sa clé publique 22 2.4. VPN MOBILES BASÉS SUR L’EXTENSION DU PROTOCOLE SIP

figure 2.11 – Mobile VPN proposé par RFC 5265 (source : RFC 5265) extraite du couple (clé privée, clé publique). Lorsqu’un hôte HIP mobile change de réseau - et donc d’adresse IP -, sa nouvelle adresse IP est alors transmise à ses correspondants. Contrairement à la mobilité proposée par N2N qui repose essentiellement sur les Super Nodes, la mobilité utilisée par HIP est totalement distribuée : elle est entièrement gérée par les deux hôtes impliqués dans une communication ponctuée par un changement de leurs adresses IP. Cependant, lorsque deux correspondants changent d’emplacement simultanément et essaient, en même temps, de transmettre l’un à l’autre leurs nouvelles adresses IP respectives, alors cet échange échoue inélutablement. Les deux anciennes adresses IP utilisées respectivement par les deux correspondants pour se joindre mutuellement ne seraient plus valides pour communiquer. Ce phénomène est appelé interblocage. Afin d’éviter d’éventuels interblocages lors d’un changement simultané d’adresses IP, un nouveau mécanisme appelé rendezvous est ajouté au protocole HIP. En effet, le rendezvous permet de synchroniser la mobilité et de garantir ainsi la validité des adresses IP. Le protocole HIP assure donc une continuité de sessions sécurisées même en cas de changement simultané d’adresses IP. Aussi, il faut préciser que le mécanisme de rendezvous basé sur l’utilisation des serveurs spéciaux porte un coup au caractère distribué du système. Bien qu’il présente des propréités qui pourraient susciter l’enthousiasme, le protocole HIP reste toujours au stade expérimental depuis son apparition en 2006 et son utilisation nécessite une modification critique de la pile TCP/IP comme le montre techniquement la figure 2.12.

2.4 VPN mobiles basés sur l’extension du protocole SIP

Basé sur une transmission point à point, le protocole SIP (Session Initiation Protocol) est un standard de gestion de sessions utilisé généralement pour la Voix sur IP ; SIP permet alternativement la communication unicast et multicast [44]. Le système SIP est composé de trois entités principales : user agent (UA), proxy server (PS) et redirect server (RS). Un utilisateur SIP est identiﬁé par une URL de la forme : user@domain, où user est un nom ou un numéro de téléphone et domain est un nom de domaine. Le SIP PS stocke une table de correspondance entre les URLs pérennes des utilisateurs et les URLs logiques liées à leur localisation courante. Lorsqu’un utilisateur mobile (UM) SIP change de réseau, son URL logique et son adresse IP changent mécaniquement ; le SIP UA, qui CHAPITRE 2. SYSTÈMES VPN MOBILES 23

processus

Transport

HIP ID hôte

IP Adresse(s) IP

Liaison de données

figure 2.12 – Couche HIP dans la pile TCP/IP constitue une extrémité dans une session SIP, enregistre alors l’UM avec ces nouvelles informations sur le PS. Ensuite, l’UM envoie une requête, appelée INVITE, contenant les informations mises à jour à son correspondant distant sans passer par une entité SIP intermédiaire (voir la figure 2.13). Cependant, en cas de changement concomitant d’adresses IP de deux correspondants et au bout de 30 secondes de tentatives infructueuses de reprise de session, les deux correspondants s’en remettent in fine à PS pour récupérer, à l’aide de l’identifiant de session, les informations sur la nouvelle localisation de l’autre. Dépourvu d’une entité centrale comme le PS, le protocole HIP résout ce problème par l’utilisation de la technique du rendezvous (voir la section 2.3).

Intranet Enregistrement / Notification 1.a/b. – SIP INVITE 2.a/b. – SIP 200 OK

Serveur de Redirection Changement d’adresse IP: mise à jour 1.c. – SIP INVITE 2.c. – SIP 302 message

Echange bidirectionnel de données 3. – transmission de données 1.c

Réseau extérieur 2.c Internet

Serveur Proxy 1.a CN MH 1.b

2.b 2.a

ﬁgure 2.13 – Mécanisme de gestion de mobilité du protocole SIP

Motivés par la mobilité et gestion de sessions oﬀertes par le protocole SIP, des systèmes VPN mobiles basés sur ce dernier ont fait leur apparition dans la littérature de recherche [54, 57]. Cependant, SIP souﬀre nativement du problème de passage à l’échelle lié à son architecture basé sur le modèle client/serveur. En outre, le protocole est beaucoup plus adapté aux applications temps réel qu’aux autres applications tierces. Par conséquent, les systèmes VPN mobiles basés sur l’extension du protocole SIP héritent tous de son incommodité conceptuelle. 24 2.5. VPN MOBILES BASÉS SUR L’EXTENSION DE SSH, SSL OU TLS

2.5 VPN mobiles basés sur l’extension de SSH, SSL ou TLS

Le protocole TLS (Transport Layer Security) ou SSL 3.1 est un protocole de sécurisation des échanges implémenté au niveau Transport du modèle OSI. Ce protocole permet la reprise d’une session intérropue sans que le serveur TLS n’ait besoin de stocker l’état de la session qui précède cette intérruption [58]. Cependant, les protocoles TLS/SSL et SSH ne permettent pas, nativement, de supporter la mobilité. Aﬁn de pousser les limites des protocoles SSH et TLS/SSL, des extensions à ces systèmes sont proposées pour leur permettre de supporter la mobilité de TLS/SSL client et de SSH client [59, 60]. En plus d’une mobilité réduite à TLS/SSL ou SSH client, les systèmes VPN mobiles considérés sont tributaires de tous les autres incovénients liés à ces protocoles : l’impossibilité de passer à l’échelle, l’existence d’un point unique de défaillance, etc. En outre, un simple changement d’adresse IP du serveur provoque l’échec de la communication sécurisée et semi-mobile.

2.6 Autres modèles de systèmes VPN mobiles

OpenVPN est une solution VPN open-source, robuste et dotée des fonctionnalités intéressantes dans la sécurisation des échanges. Zuquete et al. proposent un modèle étendu de ce système afin de lui permettre de supporter l’itinérance des clients [61]. En effet, ce modèle de VPN mobile repose sur une reconfiguration à la volée de tunnels OpenVPN ; ce mécanisme procède par une mise à jour transparente de l’adresse IP du client OpenVPN dans le contexte relatif à une session sécurisée. De prime abord, cette solution s’avère intéressante mais la mobilité proposée ne concerne que les clients OpenVPN : mobilité du client OpenVPN vis à vis de son serveur. Shu et al. mettent au point un système VPN mobile basé sur le proxy SOCKS V5 et le protocole SSL [62]. En effet, cette infrastructure VPN fournit la mobilité aux clients externes et permet à ceux-ci de communiquer de façon sécurisée avec une passerelle SSL. Comme pour beaucoup de systèmes VPN mobiles proposés, la mobilité de ce système est située du côté des clients SSL. Benenati et al. proposent une architecture du système VPN mobile pour le système de codage des transmissions CDMA2000 [63]. La solution proposée est une combinaison classique entre les protocoles Mobile IP et IPSec. Basé sur l’architecture NEMO (NEtwork MObility)[64], le modèle du VPN véhiculaire proposé par Chen et al. permet de fournir une connectivité sécurisée et mobile entre diffférents véhicules de transport public [65]. En effet, le système assure à la fois une communication V2V (vehicle-to-vehicle) mobile sécurisée entre différents véhicules et des échanges qui le sont tout autant entre les passagers d’un même véhicule ou de différents véhicules. Techniquement, le système VPN mobile mis au point associe les protocoles Mobile IP et MOBIKE. Cette association est d’autant plus intéressante que MOBIKE était proposée, à l’origine, pour combler, entre autre, les manquements issus de la combinaison entre les protocoles Mobile IP et IPSec. En outre, bien qu’ils ne soient pas destinés nativement pour fournir de la sécurité, d’autres systèmes proposent de modèles de mobilité intéressants [66–69]. Les modèles de mobilité proposés dans ces travaux pourraient ouvrir de nouvelles perspectives notamment en matière de conception des systèmes VPN mobiles.

2.7 Étude comparative de systèmes VPN mobiles

Chacun de VPN mobiles présentés dans ce chapitre possède ses propres caractéristiques conceptuelles et ses spécificités techniques. Alors que certains systèmes VPN mobiles proposent des sessions sécurisées et semi-mobiles, d’autres mettent au point de mécanismes qui offrent à la fois la sécurité et la mobilité. Nous récapitulons, dans le tableau 2.5 de synthèse, les systèmes VPN mobiles étudiés qui nous paraissent les plus pertinents, et nous y faisons ressortir leurs différences. CHAPITRE 2. SYSTÈMES VPN MOBILES 25

Le tableau 4.8 associe à chaque index du tableau 2.5, la nature du système correspondant et sa (ses) référence(s).

tableau 2.5 – Comparatif technique de solutions VPN mobiles

Système VPN mobile 1 2 3 4 5 6 7 8 9 10 √ √ √ √ √ √ √ √ Mobilité partielle limitée a √ Mobilité mutuelleb limitée √ √ √ √ √ √ √ √ Traversée des NAT limitée limitéec √ √ √ √ √ √ √ √ Itinérance transparente √ √ √ √ √ √ PKI centralisée √ √ √ Passage à l’échelle √ √ Authentication utilisat. √ √ Découverte en broadcast √ √ √ √ √ √ √ √ √ Intégrité de données partielled √ √ √ √ √ √ √ √ √ Compression de données faculta. √ √ √ √ √ √ √ √ √ √ Compatible avec DHCP e √ √ √ Architecture décentralisée √ √ √ √ Déploiement complexe Niveau implémentation util. util. noyau noyau noyau noyau util. util. util. noyau a Restreint aux réseaux domestiques. b Toutes les deux extrémités d’un tunnel et tous les hôtes peuvent être mobiles de façon concomitante ou pas. c Connexion directe impossible entre deux pairs se trouvant chacun derrière un NAT symétrique. d Seul le paquet encapsulé est authentiﬁé. e Les modes tunnel et transport IPSec supportent les techniques d’adressage dynamique. Ce mécanisme, appelé road-warrior, permet de supporter les utilisateurs semi-mobiles.

tableau 2.6 – Index et références de systèmes VPN mobiles du tableau comparatif 2.5

Index Système VPN mobile Référence(s) 1 Extension de SSL/TLS [59] 2 Extension de SSH [59] 3 Combinaison IPsec + Mobile IP [52], [70] 4 protocole HIP [29] 5 N2N [28] 6 ELA [31] 7 FAST VPN [61] 8 Extension SIP [57] 9 Extension SOCKSV5 [62]

10 MOBIKE [55], [30], [56] 26 2.8. CONCLUSION

2.8 Conclusion

La plupart des systèmes décrits dans ce chapitre proposent un système VPN mobile qui ne supportent que la mobilité partielle : seul le client peut passer d’un réseau à un autre tout en bénéﬁciant de la continuité de sessions sécurisées établies. Cependant, le système N2N garantit la mobilité aux pairs placés aux deux extrémités d’un tunnel de sécurité, même si le changement de réseau, par inadvertance ou volontaire, d’un Super Node pourrait être problématique. Aussi, le mode de découverte de pairs basé sur le broadcast crée une sollicitation massive du réseau et empêche ainsi le passage à l’echelle du système N2N. En outre l’utilisation de Super Node par ELA VPN et N2N réduit substantiellement à la fois leur extensibilité et leur mobilité. Le protocole HIP introduit un mécanisme de mobilité distribué et eﬃcace des hôtes. Mieux, HIP supporte le changement simultané d’adresses IP consécutif au déplacement concomitant de deux hôtes formant les extrémités d’un tunnel. Cette faculté est rendue possible par la technique du rendezvous. L’architecture du système VPN mobile, basée sur un système P2P, que nous proposons dans ce mémoire de thèse partage beaucoup de caractéristiques avec le protocole HIP et les systèmes N2N et ELA VPN. CHAPITRE 3

Recherche de chemins s-t disjoints

Sommaire 3.1 Solution déductible du problème du flot maximal ...... 28 3.1.1 Réduction problème sommet-disjoint ; problème arc-disjoint . . 28 3.1.2 Réduction problème arc-disjoint ; problème sommet-disjoint . . 29 3.1.3 Équivalence entre les problèmes arc-disjoint et flot maximal . . 29 3.2 Approche basée sur la topologie en anneau ...... 31 3.3 Autres propositions algorithmiques et leurs corollaires . . . . . 31 3.4 Classification des problèmes ...... 33 3.5 Applications ...... 33 3.6 Conclusion ...... 33

Formalisation du problème Données : Soit un graphe G = (V,E) et deux sommets distincts s et t (voir ﬁgure 3.14). Question : Existe-t-il k chemins deux à deux disjoints P1, ..., Pk reliant s à t ? Propriété : Cas arête-disjoints : il ne doit pas exister une relation d’adjacence entre s et t.

Ce chapitre propose une étude analytique des solutions algorithmiques sur le problème de recherche de chemins disjoints ; l’analyse porte aussi bien sur la recherche de chemins s-t arc-disjoints et la recherche de chemins s-t sommet-disjoints, que sur la recherche de chemins s-t arête-disjoints. Aussi, nous étudierons des procédés basés sur la réduction polynomiale de certains problèmes à d’autres possédant un temps d’exécution polynomial.

α1 δ1

s t

αp δq

ﬁgure 3.14 – Graphe quelconque contenant deux sommets distincts s et t

27 28 3.1. SOLUTION DÉDUCTIBLE DU PROBLÈME DU FLOT MAXIMAL

3.1 Solution déductible du problème du ﬂot maximal

Dans cette section, nous décrivons une méthode qui procède par une double réduction afin de passager du problème de chemins s-t sommet-disjoints au problème du flot maximal (voir la figure 3.15). En effet, nous montrerons que le premier problème sur la figure est réductible au second et le second au troisième. Ainsi, par transition, nous pourrons réduire le problème de k chemins s-t sommet-disjoints au problème du flot maximal.

Existe-t-il k chemins sommet-disjoints?

(1)

Existe-t-il k chemins arc-disjoints?

(2)

Quel est le ﬂot maximal dans le graphe?

ﬁgure 3.15 – Double réduction : passage du problème sommet-disjoints au problème arc-disjoints (1) et passage du problème arc-disjoints au problème du ﬂot maximal (2)

3.1.1 Réduction problème sommet-disjoint ; problème arc-disjoint

La réduction, illustrée par les ﬁgures 3.16 et 3.17, permet de passer du problème de recherche de chemins s-t sommet-disjoints au problème de recherche de chemins s-t arc-disjoints. Cette transformation consiste, tout en conservant les relations d’adjacence, à remplacer chaque sommet v de degré supérieur ou égal à 2, à l’exception de s et t, par deux sommets v− et v+ reliés par un unique arc (v−, v+). Plus formellement, le graphe résultant de la transformation du graphe G est G0 = (V 0,E0), où l’ensemble de sommets est représenté par : V 0 = {s, t} ∪ {v−, v+ | v ∈ V \{s, t}, deg(v) ≥ 2} ∪ {u | u ∈ V \{s, t}, deg(u) < 2} ; et l’ensemble des arcs est déﬁni par : 0 − + E = {(v , v ) | v ∈ V \{s, t}, deg(v) ≥ 2} ∪ {(uo, vi) | (u, v) ∈ E} ∪ {(u, v) | u, v ∈ V \{s, t}, deg(u) < 2 et deg(v) < 2}. Il est à noter que la réduction dans l’autre sens est également possible et est décrite dans la section suivante.

+ v ; v− v

ﬁgure 3.16 – Chemin sommet-disjoints ﬁgure 3.17 – Chemin arc-disjoints CHAPITRE 3. RECHERCHE DE CHEMINS S-T DISJOINTS 29

3.1.2 Réduction problème arc-disjoint ; problème sommet-disjoint Comme illustrée par les figures 3.18 et 3.19, cette réduction procède par la duplication de sommets de degré 1 supérieur ou égal à 2. Subséquemment, de nouveaux arcs sont érigés afin de relier les copies de sommets créées. Plus formellement, le graphe induit par la transformation du graphe G = (V,E) est représenté par G0 = (V 0,E0), tels que l’ensemble des sommets est défini par : 0 V = {s, t}∪{vi | vi ∈ V \{s, t} avec 1 ≤ i ≤ q et deg(v) ≥ 2}∪{u | u ∈ V \{s, t}, deg(u) < 2} ; et l’ensemble des arcs est déterminé par : E0 = {(u, v) | u, v ∈ V \{s, t}, deg(u) < 2, deg(v) < 1} ∪ {(u0, v0) | u0, v0 ∈ V 0; u0, v0 ∈/ V } .

;

ﬁgure 3.18 – Graphe arc-disjoints ﬁgure 3.19 – Graphe sommet-disjoints

Comme la réduction peut s’opérer dans les deux sens en temps linéaire ou polynomial, alors on peut en conclure que les deux problèmes sont équivalents. Par ailleurs, lorsque le graphe est non-orienté, la recherche de chemins s-t arête-disjoints ne peut pas s’eﬀectuer en temps polynomial : le problème est dit alors NP-complet [71]. Néanmoins, lorsque les paramètres sont déﬁnis (par exemple, le nombre k de chemins disjoints recherchés est borné), alors le problème devient résoluble en temps polynomial avec une complexité égale à O(|E|3) [72].

Remarque : Dans le cas d’un graphe non-orienté, la réduction du problème de chemins s-t arête-disjoints au problème problème de chemins s-t arc-disjoints s’eﬀectue par remplacement de chaque arc (u, v) par deux arcs (u, v) et (v, u). Ainsi, trouver les chemins s-t arête-disjoints revient simplement à déterminer les chemins s-t arc-disjoints après une réduction du premier problème au second. Il s’ensuit que la réduction du problème de chemins s-t arête-disjoints au problème de chemins s-t sommet-disjoints s’obtient de façon analogue.

3.1.3 Équivalence entre les problèmes arc-disjoint et flot maximal 3.1.3.1 Recherche du flot maximal : algorithme de Ford-Fulkerson Définitions préalables 1. Soit ζ : E → R une fonction qui, à tout arc (u, v), associe une valeur réelle x, appelée capacité ; soit ψ(u, v) la quantité de données qui circulent sur (u, v), appelée flot. Un flot ψ est dit réalisable ou compatible lorsqu’il satisfait les conditions suivantes (où S représente l’ensemble de successeurs et P l’ensemble de prédécesseurs) :

— 0 ≤ ψ(u, v) ≤ ζ(u, v) (contrainte de capacité) ;

— P ψ(i, j) = P ψ(j, k), ∀j ∈ E \{s, t} (contrainte de conservation du ﬂot) ; i∈P(j) k∈S(j)

1. Le degré est déterminé par deg = min{nombre d0arcs entrants, nombre d0arcs sortants} 30 3.1. SOLUTION DÉDUCTIBLE DU PROBLÈME DU FLOT MAXIMAL

P P — ψs = ψ(s, j) = ψt = ψ(j, t) (contrainte d’égalité du flot entre s et t). j∈S(s) j∈P(t) 2. Une chaîne améliorante est un chemin qui va de s à t et dont la valeur du flot peut s’augmenter (flot < capacité). La valeur d’augmentation du flot est déterminée par : δ = min{δ+, δ−}, où δ+ = min{ζ(u) − ψ(u), u ∈ E+}, δ− = min{ψ(u), u ∈ E−} et E+ est l’ensemble des arcs se trouvant sur le chemin améliorant et orientés vers la destination, et E− est l’ensemble des arcs utilisés dans la chaîne améliorante mais qui sont dans le sens opposé du chemin menant à la destination (arcs ortientés vers le sommet source).

Algorithme de Ford-Fulkerson [73]

Algorithme 2 : Algorithme Ford-Fulkerson Input : G, s, t Output :f augmenter (chemin : P, ﬂot : f) : ﬂot s ← saturer (P) ; foreach e ∈ P do if e ∈ E+ then f(e+) ← f(e) + s ; else f(e−) ← f(e) − s ; f ←return0 ; f ; foreach e ∈ E do f(e) ← 0 ; while ∃ un chemin s-t améliorant P do fmax ← augmenter (P, f) ; mise_a_jour (G, fmax); return f ;

L’algorithme 2 de Ford-Fulkerson permet de calculer le ﬂot maximal circulant entre un sommet source s et un sommet puits t [74].

3.1.3.2 Parité entre la valeur du flot maximal et le nombre maximum de chemins s-t arc-disjoints Il sera prouvé dans cette partie que le problème de recherche de chemins s-t arc-disjoints est réductible au problème du flot maximal. Mieux, le théorème 1 prouve formellement qu’il existe une parité entre le nombre de chemins s-t arc-disjoints et la valeur du flot maximal. La deuxième réduction après la première qui a permis de réduire le problème de recherche de chemins s-t sommet-disjoints au problème de recherche de chemins s-t arc-disjoints, sera donc validée par ce théorème. Cette étape boucle la démontration par double réduction illustrée précédemment par la figure 3.15. Théorème 1. Il existe k chemins s-t arc-disjoints entre deux sommets distincts s et t si et seulement si le flot maximal a pour valeur k.

Preuve. Conjoncture : La capacité unitaire est assignée à chaque arc du graphe (voir la ﬁgure 3.20)

⇒) CHAPITRE 3. RECHERCHE DE CHEMINS S-T DISJOINTS 31

1. Supposer qu’il existe k chemins s-t arc-disjoints P1, ..., Pk de s vers t 2. Soit α un arc quelconque du graphe, et Φ(α) le ﬂot qui circule sur cet arc tels que :  k  S 0, si α∈ / Pk  j=1 Φ(α) = k  S 1, si α ∈ Pk  j=1

3. Comme les chemins s-t P1, ..., Pk sont deux à deux arc-disjoints alors le ﬂot maximal est : P Φ(v, t) = k, où ϕ est l’ensemble des prédécesseurs de t dans le graphe v∈ϕ(t)

⇐) 1. Supposer que la valeur du flot maximal dans le graphe est k ; V ← ∅ et k0 ← 0 2. Choisir v ∈ ψ(s), où ψ est l’ensemble de successeurs de s, et v∈ / V tel que Φ(s, v) = 1 — Par contrainte de conservation du flot, ∃ (v, w) et w 6= t tel que Φ(v, w) = 1 — Retourner à l’étape précédente jusqu’à ce que t soit atteint 3. V ← V ∪ {v} ; k0 ← k + 1 4. Aller à l’étape 2 jusqu’à ce que |V | = |ψ(s)|, avec Φ(s, v) = 1 où v ∈ ψ(s) 5. Finalement, on a k0 = k et donc le nombre de chemins s-t arc-disjoints est égal à la valeur du flot maximal k sur le graphe.

Exemple :

1 1 4 1 4

1 1 1 1 1

s 1 2 1 5 1 t s 2 5 t 1 1 1 1 1 1 3 6 3 6

figure 3.20 – Exemple d’un graphe avec un figure 3.21 – Trois (03) chemins s-t flot maximal entre s et t égale à trois (03) arc-disjoints obtenus du graphe 3.20

3.2 Approche basée sur la topologie en anneau

La technique d’échange multi-chemin basée sur une topologie circulaire consiste à utiliser deux chemins principaux : l’un est orienté selon le sens des aiguilles d’une montre et l’autre dans le sens trigonométrique [21]. La figure 3.22 est une représentation simplifiée de cette technique. En effet, elle met en évidence l’existence de deux chemins à la fois arc-disjoints et sommet-disjoints entre le sommet source s et le sommet destination t.

3.3 Autres propositions algorithmiques et leurs corollaires

Recherche de chemins s − t 32 3.3. AUTRES PROPOSITIONS ALGORITHMIQUES ET LEURS COROLLAIRES

ﬁgure 3.22 – Deux chemins disjoints sur une topologie circulaire

Théorème 2 (Menger, 1927 [75]). 2. Étant donné un graphe orienté G et deux sommets distincts s et t, le nombre maximum de chemins s-t arc-disjoints est égal au nombre minimum des arcs dont la suppression de G déconnecte s de t (la preuve du théorème est donnée dans l’annexe B, section B.1). Le théorème 2 de Menger permet de résoudre le problème de recherche de k-chemins s-t arc-disjoints. Mieux, la variante de ce théorème basée sur les chemins sommet-disjoints permet de résoudre directement le problème sans avoir à passer par une réduction préalable entre le problème de chemins arc-disjoints et le problème de chemins sommet-disjoints. Ce théorème était, faut-il le rappeler, une des bases du problème de recherche de chemins disjoints dans les graphes. Le théorème de Menger a une complexité O(mn), où m est le nombre des arcs dans le graphe G et n est le nombre de sommets dans le même graphe. Dinneen et al. proposent une approche totalement distribuée de recherche de chemins s-t arc- disjoints et sommet-disjoints dans les P systems 3 [76]. En effet, le modèle proposé est une extension des algorithmes de recherche du flot maximal. Contrairement aux algorithmes traditionnels de recherche du flot maximal dans les graphes qui ne tiennent compte que de capacité des arcs, la variante sommet-disjoint de l’algorithme présenté dans cet article tient aussi compte de la capacité assignée à chaque sommet du système.

Recherche de chemins s1 − t1, ..., sk − tk

En 1975, Richard Karp démontra que le problème de recherche de chemins disjoints est NP- complet, c’est à dire qu’il n’existe pas une solution sous forme d’un algorithme de complexité polynomiale à ce problème [77]. Cependant, Robertson et Seymour prouvèrent en 1995 que le problème de recherche de chemins disjoints pourrait se résoudre en temps polynomial lorsque certains paramètres sont ﬁxés [72]. Il peut s’agir notamment des sommets source (s1, ..., sk), des sommets destination (t1, ..., tk) et par-dessus tout le nombre k de chemins recherchés reliant si à ti (1 ≤ i ≤ k) . Ils parvinrent alors à proposer une solution avec un temps d’exécution polynomial égale à O(|V |3) 4. Finalement, en 2000, Perkovic et Reed améliorèrent le temps d’exécution à O(|V |2) [78]. Ils détiennent alors le meilleur résultat obtenu jusqu’ici dans le problème de recherche de chemins sommet-disjoints dans les graphes non-orientés. En 1978, Perl et al. proposèrent un algorithme de recherche de chemins arc-disjoints et sommet- disjoints dans un graphe orienté et non orienté [79]. L’article discute de plusieurs versions du problème de recherche de chemins disjoints dans les graphes orientés acycliques, les graphes 3- connexes planaires et les graphes cordaux, et propose des algorithmes de complexité polynomiale pour certains problèmes.

2. Le théorème est pratique lorsqu’un attaquant tente de déconnecter deux sites distants. En eﬀet, il lui suﬃrait seulement de déterminer le nombre minimum de liaisons qu’il faudra mettre hors service. 3. Un p system est un modèle de calcul inspiré du fonctionnement des phénomènes biologiques. 4. La preuve de ce théorème s’étale sur 46 pages environ, nous orientons donc le lecteur vers l’article [72] CHAPITRE 3. RECHERCHE DE CHEMINS S-T DISJOINTS 33

En 2005, Torsten Tholey réussit à résoudre le problème de recherche de 2-chemins arc-disjoints ou sommet-disjoints en temps linéaire[80]. Il considéra alors que pour quatre sommets distincts s1, s2, t1 et t2, il est possible de trouver deux chemins s1 − t1 et s2 − t2 disjoints par un algorithme de complexité linéaire. Plus récemment encore, en 2012, Ken et al. proposaient un algorithme capable de résoudre le problème de recherche de chemins disjoints en temps quadratique [81]. A l’opposé de l’algorithme de Torsten Tholey qui s’arrête à deux chemins, le modèle proposé dans ce papier considère k-chemins disjoints et parvient à un résultat en temps O(n2).

3.4 Classiﬁcation des problèmes

Le tableau 3.7 récapitule les diﬀérents problèmes relatifs à la recherche de chemins disjoints dans les graphes et leurs classes de complexité respectives. Cette classiﬁcation découle, entre autres, des théorèmes 2, 3 et 4 énoncés dans l’annexe B, section B.1.

tableau 3.7 – Classes de complexité de diﬀérents problèmes de chemins disjoints

Nombre de chemins k borné Nombre de chemins k indéﬁni Chemins Graphe non-orienté Graphe orienté Graphe non-orienté Graphe orienté arc-disjoints P NP-complet NP-complet NP-complet arête-disjoints NP-complet − NP-complet − sommet-disjoints P NP-compet NP-complet NP-complet

3.5 Applications

Les domaines d’application du problème de recherche de chemins disjoints sont énumérés dans la liste non exhaustive suivante : 1. Équilibrage de charge et ﬁabilité dans les réseaux ; 2. Problèmes de routage ; 3. Intégration à très grande échelle (VLSI) ; 4. Segmentation d’images ; 5. Modélisation de transports ; 6. Circuits électriques ou hydrauliques ; 7. etc.

3.6 Conclusion

La recherche de k chemins s-t disjoints dans le graphe G consiste à déterminer l’existence d’un sous-graphe k-connexe H ⊆ G entre s et t. Il existe en eﬀet trois principales variantes de ce problème : le problème de chemins s-t arc-disjoints, le problème de chemins s-t arête-disjoints et le problème de chemins s-t sommet-disjoints. En plus, ces problèmes peuvent porter aussi bien sur les graphes orientés que sur les graphes non-orientés ; la recherche de chemins peut porter sur un seul sommet source et seul sommet destinaion (on parle alors de chemins s-t) ou plusieurs sources (s1, ..., sk) et plusieurs destinations (t1, ..., tk). Ainsi, chaque problème dispose de sa propre classe de complexité en rapport avec ses spéciﬁcités. 34 3.6. CONCLUSION

Dans le cadre de ce mémoire de thèse, nous considérons le problème de recherche de chemins s-t sommet-disjoints dans un graphe non-orienté. Car ce problème présente à bien des égards plusieurs similitudes avec le problème de recherche de chemins pair-disjoints dans un réseau P2P. CHAPITRE 4

Gestion distribuée de clés

Sommaire 4.1 Échange de clés via des chemins multiples ...... 36 4.1.1 Échange de clés multi-chemin sur une topologie circulaire . . . . 36 4.1.2 Échange de clés à chemins multiples sur les MANETs ...... 37 4.1.3 Échange de clés à chemins multiples sur les réseaux de capteurs . 37 4.2 PKI distribuée sur les réseaux P2P ...... 38 4.3 Distribution de clés basée sur le schéma à seuil (k, n) ...... 38 4.4 Taxinomie de paradigmes distribués de gestion de clés . . . . . 39 4.5 Conclusion ...... 39

Formalisation du problème Données : Soit deux hôtes désirant négocier leurs clés via un réseau distribué non sûr. Question : Existe-t-il une solution distribuée et ﬁable pour cette opération ?

La sécurité est un service crucial pour une communication sûre et fiable à travers les réseaux actuels et futurs. La sécurisation des échanges sur les réseaux passe impérativement par une gestion efficace et robuste des clés cryptographiques. Les procédés conventionnels de gestion des clés reposant sur une entité centrale de confiance, comme la PKI, constituent une solution puissante pour les architectures basées sur une coordination centralisée. En effet, l’authenticité des clés publiques ainsi que toutes les opérations sous-jacentes sont exclusivement garanties par l’entité tierce de confiance. Cependant, la mise en œuvre effective de la sécurité sur un réseau autonome et distribué est un immense défi que la solution centralisée ne peut, en l’état, le relever. Bien que des algorithmes cryptographiques robustes comme AES (Advanced Encryption Stan- dard)[82] ou RSA (Rivest Shamir Adleman)[83], servant à rendre les informations échangées inintelligibles aux parties tierces, existent, la gestion distribuée de clés cryptographiques et les opérations subsidiaires y afférentes demeurent un grand défi. En effet, privés d’une coordination centrale dont bénéficient les architectures centralisées, les systèmes distribués peinent à intégrer les infrastructures de sécurité destinées aux réseaux centralisés. Cet état de fait s’est traduit par une ouverture des perspectives vers de nouveaux procédés de gestion des clés adaptés aux infrastructures décentralisées. Afin de répondre aux impératifs de sécurité liés aux systèmes distribués, des approches décen- tralisées de gestion de clés sont proposées dans la littérature de recherche. Nous allons mener une étude analytique de ces systèmes au cours de ce chapitre.

35 36 4.1. ÉCHANGE DE CLÉS VIA DES CHEMINS MULTIPLES

4.1 Échange de clés via des chemins multiples

Le problème de communication utilisant plusieurs cannaux de transmission disjoints afin de garantir l’authenticité du message reçu s’était posé depuis l’antiquité avec le célèbre problème des généraux byzantins [84]. L’utilisation des chemins disjoints n’est pas seulement utile pour la résistance aux pannes mais elle sert aussi à vérifier l’authenticité des échanges émis à travers des voies dont la fiabilité est douteuse. Nous étudions, dans cette section, quelques modèles de gestion de clés s’appuyant sur l’utilisation des chemins disjoints à travers un réseau non sûr.

4.1.1 Échange de clés multi-chemin sur une topologie circulaire Takano et al. proposent une méthode d’échange de clés basée sur une extension du protocole cryptographique Diﬃe-Hellman [21]. La technique d’échange de clés mise au point consiste à utiliser une stratégie de routage basée sur une topologie circulaire et une politique de routage probabiliste et bidirectionnel : certains paquets sont routés dans le sens trigonométrique tandis que d’autres sont transmis suivant le sens anti-trigonométrique, comme l’illustre la ﬁgure 4.23.

sous-cl´ex

sous-cl´ey

ﬁgure 4.23 – Algorithme de routage utilisée dans [21]

Censée être capable de déjouer des attaques par HDM, la technique d’échange de clés proposée repose sur une version étendue de l’algorithme Diffie-Hellman. En effet, comme illustrée par la figure 4.23, la technique d’échange de clés proposée consiste à fractionner une clé principale en plusieurs sous-clés. Les différentes composantes de la clé principale sont subséquemment routées dans deux sens différents. Cependant, cet algorithme d’échange de clés ne marche qu’avec des systèmes basés sur une topologie circulaire comme Chord [85] ou Symphony [86]. Aussi, le routage d’au moins deux sous-clés pourrait exiger de faire un tour complet du cercle et donc... du réseau.

E+ = {p(r cos α; r sin α) | α ∈ ]0, θ[} (4.1)

E− = {p(r cos β; r sin β) | β ∈ ]θ, 2π[} (4.2) En plus du coût dû à la maintenance de la topologie circulaire qui est de l’ordre de O(log2 n), la vulnérabilité de ce modèle pourrait être mise en évidence par des attaques HDM coordonnées. En eﬀet, il suﬃrait de placer deux attaquants coordonnés 1 de par et d’autre d’un pair impliqué

1. Les attaquants pourraient pré-partager, par exemple, une clé aﬁn de chiﬀrer leur échange sur le réseau. CHAPITRE 4. GESTION DISTRIBUÉE DE CLÉS 37

H+ • M1 • θ M • 2

H− •

figure 4.24 – Scénario d’une attaque HDM coordonnée dans un échange de clés et l’attaque pourrait se produire inévitablement. Plus formellement, la figure 4.24 illustre deux hôtes malveillants M1 et M2 situés sur la topologie circulaire du réseau et dont les positions forment un angle θ, et deux hôtes quelconques H+ ∈ E+ et H− ∈ E− désirant échanger leurs clés (voir les équations 4.1 et 4.2 définissant les deux ensembles). Pour tout h+ ∈ E+ − − + − et h ∈ E , les échanges passés entre h et h devraient être interceptés par M1 et M2. Ces derniers devraient en effet pouvoir empêcher toute communication sécurisée entre les hôtes faisant partie de l’ensemble E+ et ceux appartenant à l’ensemble E−. Ainsi, les deux horizons E+ et E− sont virtuellement coupés pour une communication sécurisée. Il s’ensuit que plus les attaquants coordonnés sont nombreux, moins il existe de chances que les négociations de clés via de chemins disjoints aboutissent. Les scénarios des attaques HDM coordonnées sur une topologie en anneau seront expérimentés et évalués dans la partie III de ce mémoire de thèse.

4.1.2 Échange de clés à chemins multiples sur les MANETs J. Sen présente un protocole multi-chemin de gestion de certificats sur les MANETs [87]. L’algorithme définit en effet une technique d’échange de clés qui consiste à procéder par une première diffusion (broadcast) pour calculer les clés publiques. Une deuxième diffusion est ensuite lancée sur tout le réseau pour retrouver les certificats correspondants à ces clés. Afin d’obtenir une authentification robuste et indépendante des clés publiques, les certificats sont reçus de différentes sources et à travers de différents chemins. Cette solution, qui procède par broadcast, n’est évidemment pas adaptée pour un réseau d’une taille conséquente.

4.1.3 Échange de clés à chemins multiples sur les réseaux de capteurs Huange et al. proposent un système de gestion de clés pour les réseaux de capteurs basé sur le routage nœud-disjoint et le Code de Reed-Solomon [88]. Cependant, dans les réseaux de capteurs, il n’existe pas des chemins physiquement nœud-disjoints puisque tous les capteurs partagent le même cannal de communication. Ainsi, aﬁn de pallier à ce problème, les auteurs proposent, dans un premier temps, une politique de pré-partage de clés qui servent à distinguer individuellement chaque capteur. Les clés partielles sont ensuite transmises via des chemins nœud-disjoints vers le capteur récepteur ; celui-ci pourrait enﬁn les réassembler pour en reconstituer la clé originale. Wu et al. présentent une infrastructure de gestion de clés dédiée aux réseaux de capteurs [89]. Basé sur une technique de transmission sécurisée à travers des nœud-disjoints proposée par Dolev et al. [90] et le Code de Reed-Solomon, le modèle proposé se veut être plus robuste par rapport aux systèmes de gestion de clés antérieurs utilisés sur les réseaux de capteurs. La technique d’échange 38 4.2. PKI DISTRIBUÉE SUR LES RÉSEAUX P2P

de clés déﬁnie permettrait de mieux résister aux attaques actives qui pourraient se produire lors de communication entre des correspondants. En plus des modèles précédents, divers autres modèles d’échange de clés à travers des chemins disjoints sur les réseaux de capteurs sont proposés. Shehadeh et al. présentent une technique de recherche de multi-chemins basée sur les caractéristiques physiques des capteurs [91]. Jing Deng et al., de leur côté, proposent un paradigme de gestion de clés qui permet, lors de la négociation, de se protéger contre les attaques à la fois passives et actives [92].

4.2 PKI distribuée sur les réseaux P2P

Lesueur et al. mettent au point une PKI ditribuée basée sur les réseaux P2P strcuturés [93]. L’approche proposée est très similaire à celle employée précédemment par Hongmei Deng et al. dans les réseaux de capteurs [94]. Cependant, ce modèle utilise la notion de groupes de partage qui composent le réseau ; chaque composante de la clé privée du réseau est assignée de façon unique à un groupe de partage, et donc à tous les membres dudit groupe. Ainsi, la signature d’un certificat requiert obligatoirement le concours de tous les groupes ou la collaboration d’au moins un membre de chaque groupe. Bien que l’idée semble intéressante, les conditions qu’exige une signature de clé publique sont difficilement tenables dans un environnement totalement distribué et extensible. Dans un article séparé [24], les mêmes auteurs proposent un paradigme de certification distribué dont l’article précédent en est une extension. Basé sur une topologie circulaire, Chord est l’un des systèmes P2P structurés les plus connus. Avramidis et al. proposent une infrastructure PKI distribuée sur le système P2P Chord[22]. La solution consiste à distribuer la fonctionnalité d’une PKI sur les pairs du réseau et à utiliser le schéma à seuil (k, n) afin de réunir le nombre de signatures requis pour une authentification d’une clé publique. En effet, Les fonctionnalités de base d’une PKI comme la certification, la révocation, le stockage et l’extraction sont assurées de façon distribuée par le protocole lookup de Chord. Ainsi, le modèle de PKI proposée offre une infrastructure de gestion de clés autonome et totalement distribuée. Schanzenbach et al. proposent une PKI distribuée pour les réseaux P2P [95]. En effet, très similaire à l’infrastructure définie dans [93] par Lesueur et al., la méthode proposée reprend les grandes lignes de cet article. Huang et al. proposent un système de gestion de clés réposant sur un mécanisme de négociation de clés de bout en bout entre deux pairs appartenant au même cluster [96]. En effet, la fonctionnalité de la génération des clés privées/publiques est assignée à un pair particulier de confiance qui supervise les activités de cluster P2P. Pecori R. propose une extension de l’algorithme cryptographique Diffie-Hellman pour l’échange de clés et une gestion décentralisée des certificats pour l’authentification des pairs [97]. Basé sur les infrastructures P2P, le modèle de gestion de clés proposé est orienté applications VoIP.

4.3 Distribution de clés basée sur le schéma à seuil (k, n)

Déﬁnition : Le schéma à seuil (k, n), où k ≤ n, inventé par Shamir en 1979 [41], permet de fractionner une donnée ∆ en n sous-données ∆1, ..., ∆n, avec ∆ = ∆1 ⊕ ... ⊕ ∆n, telles que celles-ci satisfassent les deux conditions suivantes : — la connaissance d’au moins k données détermine ∆ ; — la connaissance d’au plus k − 1 données ne permet pas de reconstituer ∆.

Hongmei Deng et al. proposent une approche de gestion de clés et d’authentiﬁcation de bout en bout basée les identités des hôtes [94]. Ce protocole s’appuie en eﬀet sur la technique cryptographique introduite par Shamir permettant de dériver les clés publiques à partir des identités des hôtes [98]. CHAPITRE 4. GESTION DISTRIBUÉE DE CLÉS 39

Aussi, le schéma à seuil (k, n), toujours inventé par Shamir [41], est employé afin de réunir un nombre suffisant d’authentifications d’une clé publique. En outre, le modèle suggère l’utilisation d’un couple de clés < P K, SK > dont la clé publique PK est connue de tout le monde et la clé privée SK est partionnée en morceaux et ceux-ci sont répartis sur les n nœuds du réseau de sorte qu’aucun nœud ne peut reconstituer à lui seul cette clé. La reconstitution de la clé SK nécessite le concours d’au moins k nœuds. La clé privée de chaque nœud est déduite de son identité, mais elle réquiert la contribution d’au moins j voisins qui constituent un service de génération de clés privées. La gestion de certificats par une entité centrale, appelée Autorité de Certification (AC), n’est pas adaptée aux environnements distribués. Ainsi, Lesueur et al. proposent une technique de certification distribuée [93]. L’approche exige en effet la collaboration de k nœuds pour effectuer une signature d’un certificat. L’une des nouveautés de ce protocole est d’avoir la faculté de réajuster dynamiquement la valeur du nombre k par rapport à la taille du réseau. Cependant, la difficulté réside dans la détermination de la taille d’un réseau surtout lorsque celui-ci peut passer à l’échelle comme peuvent l’être les réseaux P2P structurés. Samreen et al. proposent un système qui utilise les identités d’hôtes comme clés publiques [99]. Basé sur un schéma de signature à seuil (k, n), le modèle présenté fournit une gestion d’authentification décentralisée. Les identités de pairs sont utilisées comme leurs clés publiques, celles-ci sont préalablement authentifiées par un groupe constitué pour la circonstance. La méthode mise au point est destinée pour les systèmes P2P ayant des caractéristiques de MANETs : les systèmes P2P considérés sont censés évolués dans des environnements mobiles. Jiang et al. suggèrent un mécanisme de génération des clés publiques et privées réparti sur les réseaux P2P [100]. Basé sur la cryptographie à base des identités et le schéma à seuil (k, n), le protocole proposé, procédant par broacast, permet la génération de clés privées et publiques par une entité distribuée du réseau. Cependant, l’utilisation de broadcast dans un réseau P2P, susceptible de passager à l’échelle, n’est pas une meilleure approche pour aborder la problématique de gestion distribuée de clés.

4.4 Taxinomie de paradigmes distribués de gestion de clés

Dotées des caractéristiques adaptées à leur spécificité conceptuelle, les infrastructures distribuées de gestion de clés étudiées se distinguent par leur efficacité, leur robustesse et l’environnement décentralisé dans lequel ils sont destinés à évoluer. Les systèmes distribués de clés proposés sont en général dérivées des algorithmes cryptographiques ayant fait leur preuve. La gestion distribuée de clés peut être mise en œuvre par plusieurs procédés cryptographiques : le schéma à seuil (k, n), l’infrastructure PKI distribuée, l’échange basé sur les k-chemins disjoints, l’extension de l’algorithme Diffie-Hellman, les techniques qui utilisent les identités des hôtes comme clés publiques, et bien d’autres modèles encore. En outre, d’autres techniques de gestion de clés, utilisées dans les systèmes distribués, sont nées de la combinaison de ces algorithmes cryptographiques. La figure 4.25 met en effet en exergue les modèles, que nous estimons notables, de gestion distribuée de clés et les architectures décentralisées issues de leur combinaison. Le tableau 4.8 décrit les systèmes de gestion décentralisée de clés illustrés par la figure 4.25, leurs environnements d’évolution et les références des travaux dans lesquels ils sont proposés.

4.5 Conclusion

Basée sur une architecture centralisée, la PKI traditionnelle souffre à la fois du problème de passage à l’échelle, du problème lié au coût de vérification et de gestion des certificats, et de la confiance accordée à l’Autorité de Séquestre (key escrow). Afin de pallier à ces problèmes, des systèmes décentralisés de gestion de clés, destinés à être déployés dans les environnements distribués comme les systèmes P2P, sont proposés dans la 40 4.5. CONCLUSION

Gestion distribuee´ de cles´

Identite´ hoteˆ comme ´ ´ PKI distribuee´ Schema´ a` seuil (k,n) Echange de cles´ base´ Echange Extensions cle´ publique sur broadcast multi-chemin Difﬁe-hellman

1 2 3 4 5 6

Combinaison: Combinaison: Combinaison: Combinaison: Combinaison: Combinaison: 1 + 2 1 + 3 2 + 3 2 + 3 + 4 4 + 5 5 + 6

7 8 9 10 11 12

ﬁgure 4.25 – Répartition des approches distribuées de gestion de clés

tableau 4.8 – Index et références de systèmes de gestion distribuée de clés représentés dans la ﬁgure 4.25

Index Description Environnement(s) Référence(s) 1 PKI distribuée P2P [22, 24, 93, 97] 2 Identité hôte comme clé publique MANET [94, 99, 101] 3 Schéma à seuil (k, n) P2P, Fixe/Mobile ad hoc [41, 93, 94, 99, 102, 103] 4 Échange de clés basé sur broadcast P2P, MANET [87, 100, 101] 5 Échange multi-chemin P2P, Fixe/Mobile ad hoc [21, 87–89, 91, 92] 6 Extension de Diﬃe-Hellman P2P [21, 97] 7 Combinaison 1 + 2 P2P [99] 8 Combinaison 1 + 3 P2P [22, 24, 93] 9 Combinaison 2 + 3 P2P, MANET [94, 99, 100]

10 Combinaison 2 + 3 + 4 P2P [100]

11 Combinaison 4 + 5 MANET [87]

12 Combinaison 5 + 6 P2P [21]

littérature de recherche. La conception et la mise en œuvre de ces systèmes de gestion de clés sont réalisées à l’aide de diverses techniques cryptographiques illustrées par le tableau 4.8 et la figure 4.25. En général, l’efficacité de chaque système étudié au cours de ce chapitre est tributaire de l’environnement dans lequel il évolue : un système de gestion de clés efficace dans les réseaux de capteurs ne l’est pas forcément dans les réseaux P2P, par exemple. Dans le cadre de nos travaux de thèse, nous proposons un système totalement distribué d’échange de clés basé sur les k-chemins nœud-disjoints. Techniquement, le procédé proposé combine une extension de l’algorithme Diffie-Hellman [37] et un schéma à seuil (k, n) introduit par Shamir [41]. Basée sur les réseaux P2P, la méthode présentée procède par une négociation de bout en bout de CHAPITRE 4. GESTION DISTRIBUÉE DE CLÉS 41

clés sans intervention d’une entité tierce. 42 4.5. CONCLUSION Deuxième partie

Conception de l’infrastructure

CHAPITRE 5

Découplage entre l’espace d’adressage et l’espace de nommage

Sommaire 5.1 Vue globale de l’architecture ...... 45 5.2 Infrastructure sous-jacente ...... 46 5.2.1 Adressage géométrique hyperbolique ...... 46 5.2.2 Protocole du routage glouton ...... 48 5.3 Modèle de tables de hachage distribuées (DHT) ...... 49 5.3.1 Principe du fonctionnement ...... 49 5.3.2 Mécanisme de nommage ...... 49 5.3.3 Stockage des couples dans CLOAK ...... 50 5.3.4 Coûts liés aux opérations dans CLOAK ...... 52 5.4 Modélisation du protocole de mobilité ...... 52 5.4.1 Cloisonnement entre l’espace d’adressage et l’espace de nommage 53 5.4.2 Gestion distribuée de la mobilité ...... 54 5.4.3 Résilience et reprise de session ...... 55 5.4.4 Analyse de mobilité et comparatif technique ...... 56 5.5 Conclusion ...... 57

5.1 Vue globale de l’architecture

Le cadre opérationnel et l’architecture générale de l’infrastructure sont décrits dans ce chapitre. La description met en effet en exergue les principaux modules du système et les interactions entre le modèle proposé et les infrastructures sous-jacentes. L’architecture globale de l’infrastructure est illustrée, de façon simplifiée, par la figure 5.26. Elle consiste globalement en trois principaux modules structurants qui se déclinent comme suit : 1. le réseau recouvrant ou overlay qui permet de fournir les fonctionnalités de routage et d’adressage basées sur les coordonnées virtuelles prises sur le plan hyperbolique de Poincaré ; 2. le système CLOAK (de l’anglais Covering Layer Of Abstract Knowledge) qui définit une infrastructure DHT permettant d’offrir un service de nommage facilitant une gestion robuste et distribuée des identifiants uniques, même dans le cas d’une mobilité accrue des nœuds ; 3. l’intergiciel SEMOS (de l’anglais SEcure MObile Session) qui offre une gestion abstraite des sessions sécurisées mobiles et propose un échange multi-chemin et de bout en bout de clés basé sur une combinaision du protocole Diffie-Hellman et le schéma à seuil (k, n) de Shamir.

45 46 5.2. INFRASTRUCTURE SOUS-JACENTE

Les travaux de cette thèse portent essentiellement sur les deux derniers modules tout en faisant abstraction du premier qui est lié à l’adressage et au routage. Le présent chapitre met un accent particulier sur le module CLOAK qui offre un mécanisme de découplage entre l’espace de nommage et celui d’adressage. Cette faculté de cloisonner les deux espaces, les techniques d’adressage et de routage relatives au réseau recouvrant ainsi que d’autres propriétés subsidiaires que recèlent ces mêmes mécanismes seront exploitées au cours de ce chapitre ; l’enjeu consiste à définir un protocole de mobilité qui offre des sessions résilientes aux perturbations et/ou aux changements occasionés dans les couches liées au réseau recouvrant (désigné par overlay sur la figure 5.26) et/ou au réseau IP.

Connexion applicative Processus A Processus B

Securit´ e´ & gestion de sessions SEMOS SEMOS

Nommage & mobilite´ CLOAK CLOAK

Adressage & routage Overlay Overlay

Reseau´ IP

ﬁgure 5.26 – Vue générale de l’architecture

5.2 Infrastructure sous-jacente

Les protocoles de routage et d’adressage proposés dans la mise en œuvre du réseau recouvrant sous-jacent ne sont tributaires d’aucune topologie particulière. Le routage et l’adressage s’opèrent en effet dans un environnement virtualisé fondé sur le plan hyperbolique. Les nœuds du réseau recouvrant sont ainsi identifiés par des coordonnées virtuelles pour des fins d’adressage et de routage glouton. Les détails relatifs aux protocoles d’adressage et de routage sont fournis dans les deux articles[6, 32].

5.2.1 Adressage géométrique hyperbolique L’adressage du réseau recouvrant s’appuie sur un arbre d’adressage de racine (0, 0) contruit à l’intérieur d’un cercle unité. Les nœuds du réseau recouvrant sont identifiés, de façon unique, par des coordonnées virtuelles définies dans un plan hyperbolique. On désigne ces adresses par le terme ADov. Les nœuds du réseau recouvrant se servent en effet de ces coordonnées en vue de s’identifier et se joindre mutuellement. La représentation du plan hyperbolique utilisée est celle de Poincaré dont la figure 5.27 en est une illustration. L’algorithme 3 montre comment les coordonnées virtuelles des fils sont calculées par leurs parents. Comme énoncé ci-dessus, le premier nœud qui s’adjuge les coordonnées (0, 0) est la racine de l’arbre d’adressage, et peut ensuite assigner q adresses (i.e, des coordonnées hyperboliques) aux nœuds suivants. Le degré ou l’ordre q de l’arbre d’adressage est défini lors de l’initialisation du CHAPITRE 5. DÉCOUPLAGE ENTRE L’ESPACE D’ADRESSAGE ET L’ESPACE DE NOMMAGE 47

réseau recouvrant. Subséquemment, chaque nœud ayant rejoint le réseau recouvrant peut, à son tour, attribuer q − 1 adresses à ses ﬁls. Cet algorithme exécuté de façon distribuée sur chaque nœud assure que les nœuds ont des coordonnées hyperboliques uniques.

ﬁgure 5.27 – Disque de Poincaré : exemple d’un arbre régulier d’ordre trois

Algorithme 3 : Calcul des coordonnées des ﬁls d’un nœud CalculerCoordonnéesFils(nœud, q) ; begin 1 pas ← arccosh π ; sin q 2π angle ← q ; for i ← 0 to q − 1 do if i = 0 and nœud.Coords 6= (0, 0) then continue ; // nœud 6= racine ⇒ q − 1 fils F ilsCoords.rotationGauche(angle) ; F ilsCoords.translation(pas) ; F ilsCoords.rotationDroite(π) ; if F ilsCoords 6= nœud.P arentCoords then StockerFilsCoords (F ilsCoords);

Lorsqu’un nœud η rejoint l’overlay 1, les nœuds avec qui il entretient des relations d’adjacence, et dont il connait donc les adresses IP, lui proposent des coordonnées hyperboliques dérivées de leurs propres coordonnées. Le nœud choisit ensuite les coordonnés (u, v) parmi la liste de coordonnées proposée ; il sera ensuite identiﬁé, de manière unique, dans le réseau recouvrant par ces coordonnées (u, v) ainsi obtenues. Comme précisé ci-dessus, l’algorithme 3 déﬁnit de façon formelle le mécanisme

1. Cette phase est appelée bootstrap 48 5.2. INFRASTRUCTURE SOUS-JACENTE

utilisé pour déterminer les coordonnées virtuelles proposées à chaque nœud lors de son bootstrap. La connaissance globale du réseau recouvrant n’est pas nécessaire pour garantir l’unicité des adresses ; un nouveau nœud peut obtenir des coordonnées simplement en demandant à un nœud existant d’être son père et de lui donner une adresse. Si le nœud sollicité a déjà épuisé toutes ses adresses, le nouveau nœud doit demander une adresse à un autre nœud du réseau. Au pire des cas, un nœud arrivera toujours à obtenir une adresse en se connectant à un nœud qui est une feuille de l’arbre et qui, par définition, n’a pas encore donné d’adresse. Quand un nouveau nœud obtient une adresse, il calcule ensuite les adresses de ses potentiels futurs fils dans l’arbre d’adressage afin de les proposer à de nouveaux nœuds (cf. l’algorithme 3). L’arbre d’adressage est ainsi incrémentalement construit en même temps que le réseau recouvrant. Au fil du temps, les noeuds quitteront progressivement le réseau recouvrant jusqu’à ce qu’il n’y ait plus de nœud à la fin dans le réseau recouvrant. Un nœud peut se connecter à un ou plusieurs autres à chaque instant dans le but d’obtenir une adresse. Si un nœud a distribué toutes ses adresses, il doit rediriger toute nouvelle demande vers d’autres nœuds du réseau recouvrant, cependant il peut quand même accepter des liens supplémentaires dits liens redondants avec d’autres parents. Afin de maintenir la connectivité des nœuds qui lui sont adjacents et de s’assurer de la validité des connexions établies avec chacun d’entre eux, chaque nœud envoie périodiquement des messages keepalive à ses voisins immédiats.

5.2.2 Protocole du routage glouton

Le routage proposé dans le réseau recouvrant est un routage glouton qui s’eﬀectue par utilisation des distances virtuelles hyperboliques. En d’autres termes, l’algorithme de routage s’exécute sur le réseau recouvrant sans avoir recours à l’utilisation des tables de routage traditionnelles. Les opérations de routage se réalisent à la volée en ne tenant compte que de la distance virtuelle qui sépare chaque nœud voisin par rapport au nœud destination. Typiquement, lorsque le nœud η cherche à joindre le nœud µ, il calcule la distance entre son correspondant µ et chacun de ses propres voisins, et il sélectionne, in ﬁne, le voisin v ayant la distance hyperbolique la plus courte avec le nœud destination µ. Mathématiquement, la distance entre deux points u et v quelconques, pris dans l’espace hyperbolique H, est déterminée par l’équation 5.3 :

dH(u, v) = arccosh(1 + 2λ) (5.3) où : ||v − u||2 λ = (5.4) (1 − ||u||2) × (1 − ||v||2)

Algorithme 4 : Routage glouton dans le réseau recouvrant RouterPaquet(Nœud, Paquet) return Succès/Échec ; begin Nsvt ← Nœud ; while Nsvt 6= P aquet.NœudDestination do Nsvt ← ProchainSaut (Noeud, P aquet) ; // Application de l’algo. 5

return (Nsvt 6= P aquet.NoeudDestination)?Échec : Succès ;

L’algorithme 4, qui est lui-même tributaire de l’algorithme 5, décrit formellement l’acheminement des paquets sur le réseau recouvrant d’un nœud source vers un nœud destination. CHAPITRE 5. DÉCOUPLAGE ENTRE L’ESPACE D’ADRESSAGE ET L’ESPACE DE NOMMAGE 49

Algorithme 5 : Détermination du nœud suivant ProchainSaut(Nœud, Paquet) return Nœud ; begin Nproche ← Nœud ; u ← Nœud.Coordonnees´ ; v ← P aquet.NoeudDestination.Coordonnees´ ; 2||u−v||2 dmin ← arccosh 1 + (1−||u||2)×(1−||v||2) ; foreach V oisin ∈ Nœud.V oisins do v ← V oisin.Coordonnees´ ; 2||v−v||2 d ← arccosh 1 + (1−||v||2)×(1−||v||2) ; if d < dmin then dmin ← d ; Nproche ← V oisin ;

return Nproche

5.3 Modèle de tables de hachage distribuées (DHT)

Dans cette section, nous décrivons notre infrastructure CLOAK qui, à l’origine, était déﬁnie dans les travaux [7, 36] ; nous y détaillons le principe utilisé dans la déﬁnition du modèle de notre DHT ainsi que le mécanisme de nommage proposé. Aussi, la technique de stockage des couples sera abordée.

5.3.1 Principe du fonctionnement Comme pour tout système structuré, l’infrastructure DHT proposée par CLOAK permet d’établir des tables qui, à toute clé, associent une valeur/ressource. En d’autres mots, les tables DHT réservent la colonne des clés aux IDCLOAK et celle des valeurs aux ressources qui leur sont associées. Le processus de création de IDCLOAK sera défini dans la sous-section suivante. Le système DHT proposé s’appuie essentiellement sur le réseau recouvrant précédemment étudié. La table de hachage distribuée sera en effet contruite dans un plan hyperbolique permettant une indexation efficace et robuste aux pannes. Ainsi, le stockage des paires s’opère suivant un procédé qui se repose principalement sur les concepts de géométrie hyperbolique. En outre, l’utilisation des identifiants uniques IDCLOAK , détermintés de façon distribuée sur le réseau recouvrant, offre la possibilité aux nœuds d’être identifiés, de manière unique, tout au long de la durée de vie de l’instance du réseau recouvrant. Cette assertion demeure vraie en dépit de la participation des nœuds au réseau recouvrant pouvant être ponctuée par des disparitions et réapparitions régulières, voire inopinées. Il faut aussi préciser que la réapparition d’un nœud ne se fait pas nécessairement au même point d’attachement du réseau recouvrant auparavant utilisé. Les opérations de base sur le système CLOAK se présentent comme suit : stocker (clé, valeur), modifier (clé, valeur), supprimer(clé) et extraire(clé) → valeur. Les trois premières opérations sont exécutées par des nœuds associés dans un stockage ; seule la dernière opération est du ressort des autres nœuds.

5.3.2 Mécanisme de nommage Le mécanisme de nommage consiste à générer, modifier et mettre à jour les identifiants uniques, permanents et globaux des nœuds. Il existe en effet une parité entre la longévité de ces identifiants 50 5.3. MODÈLE DE TABLES DE HACHAGE DISTRIBUÉES (DHT)

et la durée de vie d’une instance du réseau recouvrant. Une fois généré, un identifiant, appelé aussi IDCLOAK , conserve sa valeur en dépit des départs/retours fréquents de/vers le réseau recouvrant opérés par leurs propriétaires. Formellement, l’identifiant IDCLOAK se compose de 160-bits et se calcule par l’application de l’algorithme SHA-1 : IDCLOAK ← SHA − 1(nom), où nom est une chaîne de caractères introduite par l’utilisateur. Comme décrit par la figure 5.28, lorsqu’une collision est détectée entre la clé nouvellement créée et une clé qui existe déjà sur la DHT, l’utilisateur est, par conséquent, prié d’entrer une nouvelle valeur pour le nom. Ce processus se poursuit jusqu’à ce qu’une valeur valide soit entrée. L’identifiant ainsi créé, appelé clé hachée, ne saurait ensuite être modifié et/ou remis en cause qu’à la demande de son propriétaire. Aussi, lorsqu’une ressource associée à IDCLOAK dans la DHT change de valeur, alors seule la valeur de cette ressource est mise à jour alors que celle de IDCLOAK reste inchangée. En raison de sa pérennité, l’utilisattion de IDCLOAK demeure donc toujours valide durant toute la durée de vie d’une instance du réseau recouvrant. Contrairement aux adresses IP qui servent à la fois pour l’identification et la localisation des hôtes alors que sémantiquement les deux notions sont totalement différentes, le processus de nommage permet seulement d’assigner une identité unique et globale aux nœuds et/ou aux ressources stockées sur ceux-ci. Cependant, les valeurs ADov associées aux IDCLOAK peuvent permettre d’assurer la localisation des ressources stockées ou des nœuds référencés. Nous reviendrons dans la section 5.4 sur la relation qui existe entre les notions d’identification et de localisation dans notre modèle. Typiquement, le processus de génération des IDCLOAK et la technique employée pour leur stockage dans la DHT sont respectivement décrits par les figures 5.28 et 5.29.

nom nouveauNom() ←

SHA-1( ) oui

ID ID existe dans DHT? non stocker(< ID, AD >)

ﬁgure 5.28 – Processus de génération de IDCLOAK

5.3.3 Stockage des couples dans CLOAK Le processus de stockage succède à celui de nommage dans la construction des entrées des tables DHT. Le stockage d’une ressource s’effectue en effet sous forme du couple , comme dans tous les systèmes structurés. La charge du stockage dans une DHT est répartie de façon équitable sur tous les nœuds du réseau recouvrant. La solution que nous proposons n’exige cependant pas le stockage systématique des couples par tous les nœuds du réseau. La profondeur de stockage dans l’arbre est limitée par une valeur pmax assignée au lancement du réseau recouvrant. Cette valeur est définie comme étant le nombre de nœuds ascendants à traverser avant d’atteindre la racine (incluant la racine elle-même). Ainsi, seuls les nœuds ayant une profondeur inférieure ou égale à pmax peuvent être des stockeurs potentiels. La figure 5.29 illustre un processus de stockage de la paire dans CLOAK ; cette figure fixe la profondeur maximale pmax à 3 pour de raison de lisibilité. Les clés hachées sont virtuellement situées sur le cercle unité (cf. figure 5.29). Afin de procéder à un stockage redondant, les clés sont d’abord divisées en rc = 5 2 composantes de 32-bits chacune ; tout diviseur de 160 peut se substituer à la valeur de rc. Le nœud qui cherche à stocker une clé hachée

2. rc = replique circulaire CHAPITRE 5. DÉCOUPLAGE ENTRE L’ESPACE D’ADRESSAGE ET L’ESPACE DE NOMMAGE 51

Stockeur n0 n1 Stockeur le plus éloigné

n4 Stockeur n10 Stockeur le plus proche

Clef hachée

figure 5.29 – Stockage d’un couple dans la DHT sélectionne ensuite une sous-clé et la fait correspondre à un angle à l’aide d’une transformation linéaire. Le nœud calcule en effet un point virtuel v situé sur le cercle unité et défini par :

cos α v (5.5) sin α où Sous-clé de 32-bits α = 2π × (5.6) 0xFFFFFFFF Ensuite, le noeud détermine les coordonnées hyperboliques (i.e., donc l’adresse) du stockeur le plus proche du point virtuel v. Il est important de noter que ce plus proche stockeur du point virtuel (n10 sur la figure 5.29) peut ne pas exister en réalité si aucun noeud actuel du réseau recouvrant ne possède cette adresse. La requête est routée à l’intérieur du réseau recouvrant par l’utilisation de l’algorithme glouton étudié précédemment. Si la requête échoue parce que le stockeur n’existe pas ou à cause de l’échec d’un noeud ou d’un lien, elle est redirigée vers le père du stockeur initialement calculé (n4 sur la figure). Ce processus continue jusqu’à ce que la requête atteigne un stockeur qui existe. En atteignant un stockeur existant, la paire est stockée dans ce stockeur. La requête peut ainsi remonter l’arbre d’adressage jusqu’à sa racine ayant les coordonnées (0, 0) qui est le stockeur le plus éloigné du point virtuel situé à la périphérie du cercle unité. Le chemin pris par la requête du plus proche stockeur au plus éloigné est défini comme étant le rayon de stockage. Ce processus assure que les paires soient toujours stockées prioritairement dans le stockeur le plus proche du cercle unité et en dernier dans le stockeur le plus proche de la racine. On remarquera que la paire sera stockée sur le(s) même stockeur(s) peu importe l’adresse du noeud origine de la requête (condition nécessaire pour que l’algorithme soit correct). Si l’arbre d’adressage est déséquilibré, beaucoup de paires peuvent être stockées dans des noeuds proches du centre et ainsi les surcharger. Dans le but de résoudre ce problème, chaque stockeur sera en mesure de stocker un nombre maximum de paires, toute nouvelle paire sera refusée et la requête sera redirigée vers les 52 5.4. MODÉLISATION DU PROTOCOLE DE MOBILITÉ

ascendants. Enfin, précisons que notre solution possède la propriété du hachage consistant : si un noeud apparait ou disparait, seules les paires stockées par les noeuds adjacents qui changent d’adresse sont affectées. Les clés des autres stockeurs ne sont pas impactées et l’ensemble du système reste cohérent. Comme dans beaucoup de systèmes existants, les paires sont stockées suivant une stratégie de type soft state. Une paire doit être stockée par son créateur à intervalle de temps réguliers ∆t . Ainsi, lorsque la topologie du réseau change et que les adresses de certains noeuds changent, les clés rafraîchies se retrouvent éventuellement stockées dans de nouveaux stockeurs. De plus, tout stockeur purge les clés les plus anciennes, ayant dépassé une durée de stockage de ∆t, lorsqu’il doit stocker de nouvelles clés mais que sa capacité de stockage est saturée. Un message de suppression peut être envoyé par le créateur pour supprimer le couple avant la fin de l’intervalle de temps.

5.3.4 Coûts liés aux opérations dans CLOAK En faisant abstraction des liens redondants qui ne sont pas représentés dans l’arbre d’adressage mais qui offrent des chemins alternatifs, la distance moyenne entre deux nœuds du CLOAK serait égale O(log(log n)), comme formellement prouvé dans [104]. Cependant, en tenant compte des liens redondants, cette même distance deviendrait O(log n). Aussi, lorsqu’un nœud rejoint ou quitte le réseau recouvrant, seuls les nœuds qui lui sont adjacents se mettent à jour. Cette modification locale et circonscrite n’affecte pas l’ensemble du réseau. Le coût lié à cette opération ne dépend pas alors du nombre de nœuds contenus sur le réseau. Cette valeur est donc de l’ordre de O(1). Il faut toutefois préciser que, comme indiqué dans [6], si l’arbre d’adressage se rompt et que certains nœuds deviennent injoignables alors un ré-adressage partiel s’impose. Le coût relatif à l’échange des messages nécessaires pour la restauration de l’arbre d’adressage s’élève alors à O(n), dans le pire des cas. Le tableau 5.9 dresse un compratif entre CLAOK et quelques systèmes structurés populaires.

tableau 5.9 – Comparatif de quelques systèmes DHT avec CLOAK

5.4 Modélisation du protocole de mobilité

L’expansion récente et sans précédent de l’utilisation d’équipements mobiles sur Internet crée un nouveau défi. Cette nouvelle donne est d’autant plus préoccupante que le protocole IP, majoritairement utilisé dans la communication sur Internet, remplit à la fois le rôle de l’identificateur et du localisateur. Dès lors, il est donc évident que ce décloisonnement entre l’identification et la localisation empêche toute continuité de service lorsqu’une modification se produit sur la configuration réseau (i.e, suite à un changement d’adresse IP). CHAPITRE 5. DÉCOUPLAGE ENTRE L’ESPACE D’ADRESSAGE ET L’ESPACE DE NOMMAGE 53

Afin de masquer aux couches supérieures toutes les perturbations induites par un changement majeur ou mineur opéré dans les couches bases, nous proposons une solution distribuée de gestion de la mobilité. Basé en effet sur un découplage entre l’espace d’adressage et l’espace de nommage et s’appuyant sur une infrastructure DHT, le protocole proposé permet d’offrir une mobilité accrue de par son aptitude à identifier chaque nœud de façon unique et pérenne et de par son caractère distribué. Nous étudions dans cette section les détails relatifs au découplage entre l’espace et l’espace de nommage et ses implications sur la mise en œuvre de la mobilité.

5.4.1 Cloisonnement entre l’espace d’adressage et l’espace de nommage Les protocoles IPv4 et IPv6 permettent à la fois d’assurer la localisation et l’identification des hôtes sur un réseau. Par conséquent, le changement d’adresse IP d’un hôte implique systémati- quement un changement de son identification et de sa localisation. Il est en effet difficile dans ces circonstances d’évoluer sans encombre dans un environnement mobile où les adresses IP changement perpétuellement au cours du temps. C’est pourquoi, il est plus que nécessaire de désagréger les deux notions ci-dessus citées. L’enjeu de la décorrélation entre l’espace d’adressage et l’espace de nommage consiste à cloisonner la fonctionnalité de l’identification d’un nœud et celle de sa localisation sur un réseau. Pour ce faire, nous exploitons les propriétés que recele notre infrastructure DHT. Typiquement, il s’agit de substituer le couple par la paire . Plus précisement, chaque entrée de la DHT fait correspondre un identifiant IDCLOAK à une adresse ADov d’un nœud du réseau recouvrant. Chaque nœud du réseau recouvrant se voit ainsi attribuer un identifiant unique, global et dont la longévité est égale à la durée de vie de l’instance de ce réseau. Par conséquent, la localisation d’un nœud du réseau recouvrant est définie par son ADov tandis que son identification est assurée par son IDCLOAK . Il faut donc préciser que l’utilisation de IDCLOAK permet de toujours identifier un nœud indépendamment de sa position courante sur le réseau recouvrant. Pour communiquer avec un nœud, il suffit de connaitre son IDCLOAK puis de s’en servir pour invoquer la DHT afin d’obtenir son ADov nécessaire pour le contacter : extraire(IDCLOAK ) → ADov. Cette étape est cruciale pour la localisation du nœud correspondant et pour les opérations suivantes liées à l’acheminement des paquets. La figure 5.30 montre comment la dissociation entre l’espace d’adressage et l’espace de nommage a lieu dans le système CLOAK.

Processus

ID CLOAK, numero´ de port Espace d’adressage et de nommage Identiﬁcation (cle)´ Espace de nommage ID CLOAK

Decouplage´ DHT ⇒ Localisation (valeur) Espace d’adressage AD overlay

ﬁgure 5.30 – Découplage de l’espace d’adressage avec l’espace de nommage 54 5.4. MODÉLISATION DU PROTOCOLE DE MOBILITÉ

5.4.2 Gestion distribuée de la mobilité

La gestion distribuée de l’itinérance des nœuds dans le réseau recouvrant proposé répose sur l’utilisation d’une DHT. Comme étudié ci-dessus, l’utilisation des couples dans la DHT permet de désagréger les fonctionnalités liées à l’adressage à celles relatives au nommage. Les nœuds sont ainsi toujours identifiés dans l’espace de nommage à l’aide de l’utilisation de leurs identifiants universels uniques IDCLOAK , lesquels identifiants permettent par la suite d’obtenir les adresses ADov correspondantes via la DHT. Il faut noter en effet que ceci est rendu possible grâce à la correspondance qu’il y a, dans la DHT, entre ces les identifiants IDCLOAK et les adresses ADov qui leur sont assocées. D’un autre côté, la redondance de stockage des paires dans la DHT et les autres propriétés inhérentes aux systèmes P2P structurés, citées plus haut dans le document, permettent d’assurer une gestion robuste et efficace de la mobilité des nœuds sur le réseau recouvrant. La figure 5.31 décrit sommairement le principe de fonctionnement du mécanisme de mobilité que nous proposons. Typiquement, comme auparavant expliqué dans la section 5.2, lorsqu’un nœud rejoint le réseau recouvrant, un identifiant ADov lui est délivré par son futur parent dans l’arbre 3 d’adressage. Puis, un autre identifiant universel et immuable IDCLOAK lui est assigné (cf. requête de la figure 5.31). La paire est ensuite stockée sur la DHT pour servir potentiellement plus tard à des fins de mobilité sur le réseau recouvrant(cf. requête ). Ainsi, lorsque la valeur de ADov d’un nœud est modifiée, modification consécutive à un changemet du point d’attachement réseau, un message de notification de mise à jour est envoyé sur la DHT (cf. requête ). La valeur de l’adresse ADov, du couple stocké sur la DHT, est alors rafraîchie. Lorsqu’une tentative d’établissement de contact avec un nœud du réseau recouvrant échoue, le nœud cherchant à établir la communication procède à une invocation de la DHT (cf. requête ) afin d’acquérir l’adresse ADov la plus à jour de son correspondant (cf. requête ). Puis, au terme de l’acquisition de la nouvelle ADov, il recontacte de nouveau son pair ; en cas d’un nouvel échec, ce processus va se poursuivre jusqu’à ce que la communication soit rétablie ou que le nombre maximum de tentatives soit atteint. Il est important de noter que si suite à une consultation de la DHT on s’aperçoit que l’ancienne valeur de ADov est égale à sa nouvelle valeur et que le pair reste toujours injoignable, alors on en déduit donc que celui-ci avait quitté le réseau recouvrant.

1 DHT

2 3 4 5

non AD newAD () ID newID() AD newAD () pair joignable? ´echanges itinerance´ ov ← ov ← ov ← ov oui

ﬁgure 5.31 – Architecture simpliﬁée du mécanisme de mobilité

3. Pour des raisons de simplicité, IDCLOAK est simplement désigné par ID dans la ﬁgure 5.31. CHAPITRE 5. DÉCOUPLAGE ENTRE L’ESPACE D’ADRESSAGE ET L’ESPACE DE NOMMAGE 55

Contrairement aux infrastructures standards de mobilité comme Mobile IP ou le protocole SIP, le caractère distribué de notre modèle assure aux nœuds une mobilité accrue et résiliente à la volatilité des pairs et à la dynamicité de la topologie. Bénéficiant en effet d’une disponibilité élevée caractéristique des systèmes DHT et d’une méthode d’identification distinguant individuellement et durablement chaque nœud, l’approche de mobilité proposée permet aux nœuds du réseau recouvrant d’évoluer dans un environnement fortement mobile et extensible.

5.4.3 Résilience et reprise de session Le concept de mobilité précédemment décrit permet aux sessions utilisateur de survivre aux changements synchrones et/ou asynchrones du point d’attachement réseau de leurs extrémités. Une session créée entre deux extrémités, représentées par π1 et π2, est en eﬀet constituée du quintuplet

(IDCLOAK π1, IDCLOAK π2, Port π1, Port π2, ID sessionπ1↔π2 ) où (IDCLOAK π1, IDCLOAK π2,

Port π1, Port π2) = ID connexionπ1↔π2 . Ce quintuplet est également désigné sous le vocable de contexte de session. Aucune des valeurs qui composent un contexte de session n’est, de toute évidence, susceptible d’être affectée par le changement de ADov π1 ou ADov π2. La validité de ce contexte de session a, par conséquent, une durée de vie allant de l’ouverture d’une session virtuelle jusqu’à sa clôture normale. Il faut noter que ID sessionπ1↔π2 pointe vers une autre structure détaillant les éléments liés à une session - le chapitre suivant fournit des détails sur cette structure. La continuité d’une session établie est donc garantie même lorsque celle-ci est ponctuée par un changement fréquent de l’emplacement de ses extrémités dans le réseau recouvrant. À contrario, le moindre changement dans les sessions tributaires d’adresses IP ou d’identifiants ADov mettrait forcément un terme aux sessions concernées. C’est pourquoi, l’idée d’utilisation des sessions virtuelles, établies à l’aide notamment des identités logiques des nœuds, paraît appropriée pour avoir des sessions résilientes dans un environnement mobile. L’approche de reprise de session est formellement décrite par l’algorithme 6. En effet, lorsqu’un contact est perdu avec un pair associé dans une session virtuelle, le pair correspondant exécute cet algorithme jusqu’à ce que la reprise de la session s’ensuive ou, au pire, jusqu’à la clôture de la session.

Algorithme 6 : Technique de reprise de session RepriseSession(Session) return Succès/Échec ; begin tentative ← 0 ; statut ← Session.statut ; IDsess ← Session.IDsess ; IDCLOAK ← Session.P air.IDCLOAK ; while tentative 6= T max and statut = Échec do IDov ← invoquerDHT(IDCLOAK ) ; disponible ← contacterPair(IDov) ; if disponible = Oui then redémarrerSession(IDsess) ; statut ← Succès ; else pause() ; tentative ← tentative + 1 ; return statut ; 56 5.4. MODÉLISATION DU PROTOCOLE DE MOBILITÉ

5.4.4 Analyse de mobilité et comparatif technique Il faut rappeler que dans le réseau HIP, l’adresse IP ne sert que pour la localisation tandis que chaque nœud est identifié , de façon unique sur le réseau HIP, par sa clé publique. L’approche de mobilité proposée par le protocole HIP consiste pour un nœud donné, après chaque changement de son adresse IP, à notifier son correspondant distant sur sa nouvelle localisation. Cependant, cette technique ne marche que lorsque le changement de localisation est asynchrone. En effet, lorsque deux extrémités d’une session HIP changement simultanément de localisation, alors la stratégie de notification échoue inéluctablement. Afin de pallier à ce problème, la RFC 5204 propose une extension du protocole implémentant le mécanisme de rendezvous [105] basé sur des serveurs spéciaux HIP. Toutefois, il va sans dire que cette ingéniosité porte atteinte au caractère distribué du protocole. Il serait dès lors plus juste de dire que HIP est un protocole semi-distribué. Il faut préciser également que la gestion de mobilité dans les protocoles SIP et Mobile IP, et dans certaines mesures le protocole HIP, est centralisée. Contrairement aux protocoles HIP et SIP, et à l’infrastructure CLOAK, le protocole Mobile IP ne supporte, à l’origine, que la mobilité d’un seul nœud associé à une session tandis que l’autre nœud est supposé fixe. On pourrait néanmoins faire de sorte que les deux bouts d’une connexion/session soient mobiles mais ceci se fait encore avec plus de complexité : il faudrait, par exemple, l’utilisation d’un HA centralisé, de deux FA et deux HA pour arriver à cette fin. C’est qui est un peu absurde car le HA est, par définition, lié à un Intranet, c’est à dire le réseau d’origine des nœuds itinérants. Alors que les protocoles SIP et Mobile IP voire le protocole HIP s’appuient sur une coordination centrale utilisée à des fins de mobilité, le modèle que nous proposons est entièrement distribué et extensible ; tout nœud du réseau recouvrant peut être mobile. En effet, la mobilité ne porte pas uniquement sur une extrémité d’une session/connexion mais elle peut également porter sur les deux pôles. L’indexation basée sur les identités vrituelles offerte par la DHT permet à notre système d’être implémenté au niveau utilisateur, pendant que les autres protocoles standards étudiés s’implémentent au niveau noyau. Du fait de l’utilisation des paquets dont les entêtes ne contiennent ni adresses IP ni numéros de port, l’architecture CLOAK résout ainsi les problèmes de la traversée de NAT (de l’anglais Network Address Translation). Nativement, les protocoles SIP, HIP et Mobile IP ne supportent pas la traversée de NAT. Cependant, l’extension du Mobile IP présentée dans [106] permet aux données issues de la tunnelisation de traverser les NAT sans être filtrées. Il en est de même de l’extension du protocole HIP proposée dans [107] et celle du protocole SIP présentée dans [108]. Le tableau 5.10 met en évidence les spécifités techniques de quelques infrastructures de mobilité analysées précédemment.

tableau 5.10 – Comparatif entre CLOAK et trois autres protocoles standards de mobilité

Infrastructures de mobilité Spéciﬁcations techniques Mobile IP Protocole SIP Protocole HIP SEMOS/CLOAK √ Passage à l’échelle √ √ √ √ Traversée de NAT a √ √ Résistance aux pannes √ Gestion distribuée de mobilité √ √ √ Mobilité simultanée de nœuds b √ Simplicité dans le déploiement Nombre de requêtes de mise à jour 2 2 1 1 Niveau d’implémentation noyau nouyau noyau utilisateur a En tenant compte des extensions respectives du Mobile IP, du protocole SIP et du protocole HIP décrites ci-dessus. b Les nœuds désignent ici les deux extrémités d’une session. CHAPITRE 5. DÉCOUPLAGE ENTRE L’ESPACE D’ADRESSAGE ET L’ESPACE DE NOMMAGE 57

5.5 Conclusion

Dans ce chapitre, nous avons étudié la proposition d’un nouvel espace de nommage permettant de supporter la mobilité des nœuds dans un réseau P2P recouvrant. Typiquement, il s’est agi de proposer un système DHT facilitant un découplage entre l’espace d’adressage et l’espace de nommage afin de cloisonner les fonctionnalités en rapport avec la localisation à celles correspondantes à l’identification. La mobilité des nœuds est en effet garantie par l’utilisation des identifiants virtuels et universels utilisés dans la DHT et ayant une longévité pouvant égaler la durée de vie de l’instance du réseau recouvrant. Les contextes de sessions virtuelles sont ainsi préservés même lorsque les nœuds changent de point d’attachement réseau ou quittent le réseau recouvrant et y reviennent ensuite. En substance, les propriétés que ce modèle de mobilité hérite de l’infrastructure DHT lui procurent des caractères précieux que les systèmes traditionnels de mobilité, comme Mobile IP et le protocole SIP, n’en disposent. En outre, notre analyse montre que notre solution possède des coûts ayant des ordres de grandeur similaires à ceux des DHT existantes. En partant du postulat que le système DHT étudié dans ce chapitre existe, dans le prochain chapitre, nous verrons comment le modèle de mobilité proposé pourra être utilisé dans la mise en œuvre d’un système VPN mobile. L’enjeu du chapitre qui va suivre consiste en effet à proposer une conception détaillée des sessions sécurisées mobiles devant être établies sur un système P2P recouvrant. 58 5.5. CONCLUSION CHAPITRE 6

Sessions virtuelles sécurisées et mobiles

Sommaire 6.1 Motivations ...... 59 6.2 Architecture de l’intergiciel SEMOS ...... 60 6.2.1 Module de sécurisation de session ...... 61 6.2.2 Gestion de résilience de session ...... 62 6.2.3 Interfaçage entre SEMOS et les processus applicatifs ...... 66 6.2.4 Module de redirection de port ...... 66 6.3 Contraintes d’Internet ...... 67 6.4 Analyse de sécurité ...... 68 6.4.1 Protection contre les attaques par rejeu et les attaques DoS . . . 68 6.4.2 Autres propriétés ...... 69 6.5 Conclusion ...... 69

6.1 Motivations

Le boom technologique de ces dernières années, marqué par une miniaturisation incessante, a permis une vulgarisation sans précédent de l’usage des équipements mobiles. Cependant, en raison de leur flexibilité accrue de se mouvoir d’un réseau à un autre et de leur connectivité élevée, les protocoles de mobilité présentent des caractéristiques propices aux attaques malveillantes, comme rapporté dans [109]. Dotés des facultés pouvant déjouer nombre de menaces sévissant sur Internet [110], les systèmes VPN traditionnels échouent cependant à évoluer efficacement dans un environnement mobile ou dans un réseau ayant une topologie qui change perpétuellement. En effet, dans les VPN traditionnels, chaque changement d’adresse IP provoquerait mécaniquement une rupture du tunnel associé à l’adresse IP modifiée. Ensuite, une renégociation des clés entre les parties associées dans la communication est requise pour rétablir un échange sécurisé. Aussi, c’est justement pendant la phase de négociation/renégociation que les utilisateurs sont le plus vulnérables aux diverses attaques dont l’attaque HDM ou l’attaque par rejeu. Il faut également souligner qu’une communcation ponctuée par des renégociations de clés répétées créerait une latence significative dans le réseau. À la lumière de ce qui précède, dans ce chapitre, nous nous proposons de définir un nouveau système VPN mobile, appelé SEMOS (de l’anglais SEcured MObile Session). Contruit sur un réseau recouvrant, l’intergiciel SEMOS permet aux sessions sécurisées des utilisateurs de survivre aux perturbations inopinées produites dans les couches bases et exonère ainsi les pairs aux renégociations de clés consécutives à un changement ou à une inaccessibilité éphémère ou prolongée d’un pair.

59 60 6.2. ARCHITECTURE DE L’INTERGICIEL SEMOS

6.2 Architecture de l’intergiciel SEMOS

Situé à la couche session du modèle OSI, qui est le niveau le plus haut permettant d’implémenter la mobilité, l’intergiciel SEMOS se compose de quatre principaux modules qui peuvent se décliner comme suit :

1. le module SSM (de l’anglais Session Security Module) qui gère les services liés à la sécurité tels que la conﬁdentialité et l’intégrité de données, la protection contre les attaques par rejeu et l’échange de clés basé sur une extension du protocole Diﬃe-Hellman ; 2. le module SRM (de l’anglais Session Reliability Module) qui sert à masquer la mobilité ou les défaillances aux applications en interagissant avec l’architecture CLOAK ; 3. le module LCM (de l’anglais Local Connection Manager) qui organise le dialogue en jouant l’interface entre le système SEMOS et les processus applicatifs ; 4. le module PFM (de l’anglais Port Forwarding Module) qui redirige les données issues des applications en vue de leur sécurisation et il permet également le multplexage de plusieurs sessions sur un même canal de transmission.

Le tableau 1 dresse la liste de symboles qui seront employés dans ce chapitre. De son côté, la ﬁgure 6.32 présente une vue globale de l’architecture SEMOS qui montre comment les interactions ont lieu entre diﬀérents modules. Nous allons décrire de façon approfondie ces modules au cours de ce chapitre.

Bob Alice Processus Exécution en boucle SSM SRM PFM LCM Scrutation Connexion boucle locale Transmission d’un paquet

Vérification de l’authenticité

Vérification de l’intégrité

Déchiffrement du paquet Renvoii de lla ccharrge uttiille Redirection Détection des défaillances Sélection de de port l’application

Délivrance des données Traitement Nottiiffiiccattiion de panne des données Suspension de réception

ﬁgure 6.32 – Vue générale de l’architecture SEMOS CHAPITRE 6. SESSIONS VIRTUELLES SÉCURISÉES ET MOBILES 61

6.2.1 Module de sécurisation de session Comme indiqué en préambule, le module SSM fournit tout le mécanisme nécessaire aux échanges bout-à-bout sécurisés entre deux entités SEMOS distantes. Dans cette section, les concepts essentiels mis en œuvre dans la sécurisation de données dans l’infrastructure SEMOS seront étudiés.

6.2.1.1 Confidentialité de données Un tunnel SEMOS est un canal virtuel permetttant une communication chiffrée de bout-à-bout entre deux instances SEMOS distantes. La confidentialité porte exclusivement sur la charge utile du paquet transporté entre deux extrémités d’une session (cf. la figure 6.33). Cette confidentialité est rendue possible par l’utilisation d’un algorithme cryptographique symétrique (nommément l’algorithme AES [82]). Cependant, seul l’échange de clés s’effectue préalablement à l’aide d’un algorithme asymétrique dont le protocole Diffie-Hellman en est une implémentation. Par conséquent, la robustesse d’une confidentialité est tout à la fois consubstantielle à la méthode d’échange de clés utilisée et à l’algorithme de cryptographie employé. Le choix de la cryptographie symétrique est justifié par son efficacité [111]. La clé symétrique associée à une session SEMOS est appelée clé de session SEMOS.

Paquet SEMOS Entête Entête Localisation Src @ ← Src AD OV Dst @ ← Dst AD OV Entête Identiﬁcation Src ID ← Src ID CLOAK Dst ID ← Dst ID CLOAK Champs Additionnels d’Entête ICV ← signature() Type Paquet ← étiquette(1) SEQ NBR ← incrémenterSeq() ID Session ← concatlexico(PSess ID i, PSess ID j) Charge utile Donnée ← donnéeChiﬀrée()

ﬁgure 6.33 – Structure simpliﬁée d’un paquet SEMOS/CLOAK

6.2.1.2 Authenticité de données et protection contre le rejeu L’intégrité de données échangées entre deux extrémités d’une session est assurée par l’authentification à la fois des champs permanents et de la charge utile chiffrée transportée dans le paquet (cf. la figure 6.33). La valeur obtenue à l’issue de cette opération d’authentification est appelée ICV (de l’anglais Integrity Check Value). L’ICV fait en effet office de signature attachée aux paquets SEMOS. Sur réception d’un paquet, l’intégrité de celuic-i est vérifiée avant que le nœud récepteur ne procède à l’opération de déchiffrement. La procédure de vérification de l’ICV, par le nœud destinataire, consiste tout simplement à faire l’opération analogue à celle exécutée par le nœud source et à vérifier ensuite si la valeur de l’ICV reçue est égale à la celle de l’ICV calculée. En cas d’égalité entre les deux valeurs, l’authenticité du paquet est vérifiée ; sinon, le paquet serait compromis au cours de son transport et il est donc directemment et systématiquement jeté. 62 6.2. ARCHITECTURE DE L’INTERGICIEL SEMOS

L’entête de localisation (ou de routage), constitué de Src @ et Dst @, n’est pas authentifié, car ces deux champs sont susceptibles de changer au cours du temps. Par exemple, lorsque le pair destination change de localisation pendant le processus du routage, la DHT est invoquée à l’aide du champs Dst ID afin de déterminer le nouvel emplacement du pair. Une fois la réponse de la DHT obtenue, une nouvelle valeur est alors affectée au champs Dst @. Subséquemment, le processus du routage se poursuivra en se servant de la nouvelle adresse qui indique une nouvelle localisation dans l’arbre d’adressage du réseau recouvrant. La protection contre le rejeu des paquets est facilitée par la présence du champs numéro de séquence (désigné par NBR SEQ dans la figure 6.33). Ce champs fait en effet partie des champs qui sont pérennes durant le transfert du paquet qui les contient, et est par conséquent authentifié. Ainsi, tout paquet rejoué, en modifiant le champs numéro de séquence ou non, est automatiquement détecté et détruit.

6.2.1.3 Association de Sécurité (AS) L’Association de Sécurité ou AS est un procédé basé sur une table qui, à tout flux lié à une session virtuelle et à toute direction, associe les actions (i.e, chiffrement, déchiffrement, les opérations liées à l’authentification) et les paramètres (i.e, clés cryptographiques, etc.) appropriés. En d’autres termes, dans une session Σ donnée impliquant les pairs π1 et π2, les actions appliquées sur le trafic entrant δ+ dans π sont les réciproques de celles appliquées sur le trafic sortant π2→π1 1 δ− de π . Les opérations et, éventuellement, les paramètres nécessaires à leur exécution sont π1→π2 1 en effet spécifiques à une direction (i.e, δ+ ou δ− ), en dépit du fait que la session Σ soit π2→π1 π1→π2 conceptuellement bidirectionnelle. Le composant AS est particulièrement important lorsqu’un multiplexage de sessions est appliqué sur les trafics entrants et/ou sortant. L’AS permet en effet d’identifier chaque flux individuellement, en tenant compte de sa direction, et de le faire suivre vers l’étape suivante après lui avoir appliqué des traitements sécuritaires singuliers. Dans notre infrastructure sous-jacente, les sockets TCP/UDP utilisées pour connecter les nœuds adjacents dans le réseau recouvrant ainsi que les liens virtuels agissent également comme des supports de multplexage.

6.2.1.4 Échange de clés En plus des composants étudiés ci-dessus, le module SSM implémente également un mécanisme multi-chemin d’échange de clés basé sur une extension du protocole Diﬃe-Hellman et le schéma à seuil (k, n) de Shamir. Le procédé d’échange de clés proposé consiste en eﬀet à subdiviser une clé en plusieurs sous-clés et à envoyer chacune d’elles à travers un chemin séparé. Nous consacrons entièrement le chapitre suivant à la description de ce modèle d’échange de clés et ses corollaires. Nous invitons donc le lecteur désireux d’en savoir plus de s’y référer.

6.2.2 Gestion de résilience de session Dans cette sous-section, nous allons étudier les éléments essentiels permettant de gérer la résilience de sesssion dans l’architecture SEMOS. La ﬁgure 6.36 illustre un scénario de mobilité dans lequel l’action liée au changement du point d’attachement réseau opérée par l’utilisateur Bob provoque une rupture de la connexion sous-jacente reliant deux pairs adjacents du réseau recouvrant (R.R). Cependant, la connexion virtuelle SEMOS/CLOAK (S/C) établie entre Alice et Bob survit à cet évèvement. Il est important de noter que les nœuds intermédiaires SEMOS, représentés par un cercle en pointillé, n’ont pas un rôle réel dans la session bout-à-bout unissant Alice et Bob. Il faut néanmoins préciser que les nœuds du réseau recouvrant, au-dessus desquels évoluent ces nœuds intermédiaires, jouent un rôle déterminant dans l’acheminement du traﬁc lié à cette session. CHAPITRE 6. SESSIONS VIRTUELLES SÉCURISÉES ET MOBILES 63

Alice Nœud intermédiaire Bob Alice Bob Lien virtuel sécurisé Nœud intermédiaire Nouveau chemin sécurisé Nœud intermédiaire S/C S/C

R.R Rupture de la connexion sous-jacente ⇒ R.R

Changement d’emplacement Nouvelle connexion

ﬁgure 6.34 – Mobilité d’utilisateur ponctuée par une continuée de la session sécurisée.

6.2.2.1 Méthode de calcul d’identifiant de session L’identifiant de session Σ est une suite de caractères alphanumériques calculée à base de la concaténation de deux identifiants partiels générés chacun par un pair impliqué dans l’établissement de la session. La figure 6.35 montre la séquence de messages échangés entre un nœud pair1 et son correspondant pair2, afin de déterminer l’identifiant final de session. D’une manière typique, pair1 génère un identifiant partiel Σ1 et l’envoie à pair2. Ensuite, pair2 stocke le contenu du message lexico reçu, détemine à son tour Σ2 et l’expédie à pair1. Enfin, pair2 calcule concat (Σ2, Σ1) et pair1 lexico détermine de son côté concat (Σ1, Σ2). La fonction concatlexico() est une fonction qui permet en effet de concaténer, selon l’ordre lexicographique, deux chaînes de caractères alphanumériques prises en argument. Typiquement, la chaîne la plus petite, selon cet ordre, est placée avant celle la plus grande dans la concaténation. Ainsi, lexico la valeur calculée par pair1 est forcément égale à celle déterminée par pair2 : concat (Σ1, Σ2) = lexico concat (Σ2, Σ1). Cette commutativité permet in fine aux deux correspondants de partager le même identifiant de session Σ.

pair1 pair2

gen´ eration´ de Σ1

Σ1

stockage de Σ1

gen´ eration´ de Σ2

Σ2 Σ concatlexico(Σ , Σ ) ← 1 2

stockage de Σ2

Σ concatlexico(Σ , Σ ) ← 1 2

figure 6.35 – Échange d’identifiants partiels et calcul conjoint de l’identifiant de session 64 6.2. ARCHITECTURE DE L’INTERGICIEL SEMOS

Paquet Hello Paquet Re-Hello Entête Entête Entête Localisation Entête Location Src @ ← Src AD OV Src @ ← Src AD OV Dst @ ← Dst AD OV Dst @ ← Dst AD OV Entête Identiﬁcation Entête Identiﬁcation Src ID ← Src ID CLOAK Src ID ← Src ID CLOAK Dst ID ← Dst ID CLOAK Dst ID ← Dst ID CLOAK Champs Additionnels d’Entête Champs Additionnels d’Entête Type Paquet ← étiquette(2) Type Paquet ← étiquette(3) Charge utile ID Session PSess ID ← generateSessonID() Charge utile Port ← dstSrcPort() CTX ← contextSession()

ﬁgure 6.36 – Structure du paquet Hello/Re-Hello

Ce procédé de calcul d’identifiant de session se déroule pandant la phase d’échange de poignée de main (en anglais handshake) ; cette phase requiert en effet l’échange de deux requêtes dont chacune est émise par un pair associé dans la contruction de la future session. Le paquet contenant l’identifiant partiel est alors appelé Hello (cf. la figure 6.36). Il faut préciser que le paquet Hello ne transporte pas seulement l’identifiant partiel mais également une série d’informations relatives à la future session à établir (numéro de service, identifiant de pair, etc.). Ces paramètres contenus dans le paquet Hello permettent donc à la fois de déterminer l’identifiant de session et d’établir cette même session entre les deux pairs communicants.

6.2.2.2 Association de Mobilité (AM)

Le composant Association de Mobilité (AM) a pour rôle de faire correspondre tout identifiant de session à un contexte caractéristique. Le contexte de session renferme en effet les informations sur l’état de session (actif, suspendu, zombie et terminé), le statut de la connectivié, les numéros de séquence de derniers paquets échangés, les IDCLOAK des pairs raccordés par la session ainsi que d’autres informations additionnelles. Ainsi, pendant la communication, l’AM intercepte d’abord chaque flux sortant, consulte ensuite le contexte de la session en rapport avec le pair auquel le flux est destiné, et traite enfin le flux conformément aux informations contenues dans le contexte de session. Typiquement, lorsque la session est à l’état 1. actif, le flux est transmis à l’étape suivante sans traitement particulier. 2. suspendu ou zombie, la transmission du flux est suspendue et un message de notification d’indisponibilité est envoyée au processus à l’origine du flux. La différence entre l’état suspendu et l’état zombie est très mineure : l’état suspendu désigne la période marquée par des tentatives de reprise de session alors que l’état zombie représente l’état succédant la fin de ces tentatives. Par contre, l’état terminé, qui symbolise une terminaison normale d’une session, indique que la session ne peut plus être invoquée ni restaurée. Techniquement, cet état est désigné par l’absence d’un contexte correspondant au flux reçu.

Comme les sessions sont indépendantes des adresses volatiles ADov et ne sont tributaires que des identifiants pérennes IDCLOAK , l’AM offre la possibilité de conserver un contexte de session suffisamment longtemps même lorsque l’inaccessibilité ponctuelle d’un pair, en raison de son départ, est évidente. Toutefois, le stockage des contextes de session n’est pas systématique : les contextes de sessions normalement clôturées ne sont pas enregistrés. CHAPITRE 6. SESSIONS VIRTUELLES SÉCURISÉES ET MOBILES 65

Alice Bob n o i s s e

s Hello (pSessID-a, …)

e d

n o i t a s i l Hello (pSessID-b, …) a i t i n I Échange sécurisé

Exécution en boucle Intérruption de session e s i

r Re-Hello (SessCTX-a, …) p e r

e d

e s

a Re-Hello (SessCTX-b, …) h P Échange sécurisé

ﬁgure 6.37 – Les diﬀérentes phases d’une communication SEMOS

6.2.2.3 Détection d’échec et restauration de session

La figure 6.38 montre comment le module SRM de l’intergiciel SEMOS agit pour surveiller d’éventuelles défaillances qui pourraient survenir dans les couches inférieures, et comment il pourrait procéder subséquemment aux tentatives de reprise de session. Le module SRM scrute en effet le réseau recouvrant grâce à l’envoi périodique du message keepalive à l’autre bout de la session (cf. l’état q0 de l’automate). L’absence de réponse suite à l’expédition d’une suite de messages keepalive est interprétée par SRM comme une rupture temporaire ou définitive d’un ou de plusieurs maillons du canal de transmission. L’échange de données provenant des processus applicatif et à destination du correspondant injoignable est alors immédiatement intérrompu. Ensuite, SRM poursuit l’expédition de keepalive à intervalle de temps irrégulier jusqu’à k tentatives (τk) : c’est à n dire suivant une suite géométrique de premier terme 1 et de raison 2 (à savoir τn = 2 , avec n ≤ k). Au bout de k tentatives infructueuses, la session entre alors en état zombie et le pair attendra passivement une éventuelle relance ultérieure de son correspondant (cf. l’état q3 de l’automate). Si au contraire les tentatives de reprise étaient fructueuses avant même qu’elles n’atteignent le seuil k, alors la session serait incessamment restaurée après un échange des messages Re-Hello (cf. l’état q2 de l’automate et les figures 6.36 et 6.37). Ces derniers sont prioritairement envoyés immédiatement après la reprise de session afin de déterminer une concordance du contexte de la session restaurée entre les deux pairs SEMOS avant une reprise effective de celle-ci. Ce processus, qui suit le schéma scrutation → détection → restauration, tourne indéfiniment jusqu’à ce que la session soit normalement clôturée, ou le seuil de tentatives de reprise de session, consécutives à une défaillance, soit atteint ou encore le processus SEMOS soit simplement arrêté. 66 6.2. ARCHITECTURE DE L’INTERGICIEL SEMOS

scrutation tentatives de reconnexion

defaillances´ constatees´ tentatives echou´ ees´ debut´ q0 q1 q3

connextion sous-jacente retablie´

reprise de session

echange´ du message Re-Hello

ﬁgure 6.38 – Processus de détection de défaillance et de restauration de session

6.2.3 Interfaçage entre SEMOS et les processus applicatifs L’intergiciel SEMOS et les processus applicatifs se communiquent à travers des sockets TCP locales. Ce choix technique est motivé par la volonté de décloisonner les deux concepts. Ainsi, lorsque des modifications sont apportées à l’intergiciel SEMOS, seul celui-ci qui doit être recompilé ; les applications qui interagissent avec SEMOS ne sont nullement impactées par ces changements. Aussi, les applications propriétaires dont le code source est fermé sont, par conséquent, dispensées d’importer les bibliothèques de SEMOS et elles sont donc, pour ainsi dire, exemptées des modifications et/ou de compilation. Ces fonctionnalités d’interfaçage entre SEMOS et les applications sont implémentées par le module LCM. Le module LCM a pour rôle de tenir à jour une table de hachage constituée des numéros de port, dans une colonne, et des descripteurs de sockets, dans l’autre. Comme l’unicité des numéros de port créés est garantie par le système d’exploitation, chaque processus applicatif est ainsi identifié de façon unique par son numéro de port source. Le module LCM permet donc de faire suivre les données qu’il reçoit de SEMOS aux applications. Lorsqu’une alerte d’inaccessibilité du correspondant est envoyée par le module SRM, LCM suspend la réception de données jusqu’à ce qu’une notification de reprise du trafic s’ensuive. L’intergiciel SEMOS ne ferme pas des sockets locales à moins qu’une demande explicite de fermeture soit formulée par les applications.

6.2.4 Module de redirection de port Le module PFM est conçu afin d’intercepter le trafic entrant (resp. sortant ) en vue de le traiter avant d’être effectivement reçu (resp. envoyé) par les processus applicatifs (resp. aux pairs correspondants). Toute transaction est ainsi redirigée vers l’intergiciel SEMOS pour son traitement lié à la sécurité (chiffrement/déchiffrement des paquets sortants/entrants, par exemple) et à la mobilité (identifiant de session, etc.) avant que cet échange ne se poursuive subséquemment. Ce module est d’autant plus important qu’il est doté des aptitudes permettant de rendre transparents aux processus utilisateur tous les traitements en rapport avec la sécurité et la mobilité. La technique de translation de port utilisée permet de créer des ports virtuels vers lesquels les données qui arrivent sur un pair sont redirigées afin d’être ensuite traitées. Typiquement, il s’agit en effet d’utiliser un proxy local dont le rôle consiste à intercepter et rediriger tout trafic entrant ou sortant vers un port local sur lequel écoute SEMOS. L’interception et la radirection du trafic CHAPITRE 6. SESSIONS VIRTUELLES SÉCURISÉES ET MOBILES 67

issu des applications ou en provenance du réseau sont utilisées à des fins de traitement à appliquer sur les données. D’une part, le traitement consiste à encapsuler les données reçues des applications dans un nouveau paquet SEMOS sur lequel les opérations de sécurité sont appliquées ; ensuite, le paquet ainsi traité reprend son chemin vers le pair destinataire. D’autre part, sur réception d’un paquet provenant du réseau, le récepteur lui applique les traitements sécuritaires appropriés et le décapsule. Enfin, le récepteur se sert des informations contenues dans le paquet afin d’identifier le processus destinataire et lui transmettre les données telles qu’elles étaient lors de leur émission par le processus applicatifs source. Le PFM fait, en quelque sorte, office d’aiguilleur du trafic entre les processus applicatifs et les modules de SEMOS d’un côté, et entre ces derniers et les pairs correspondants, de l’autre.

Algorithme 7 : Mécanisme de redirection du traﬁc sortant Input : socketLocal, idDst begin entête ← initialiserEntête() ; /* Redirection de port */ Ports ← obtenirPortsApp(socketLocal) ; idApp ← générerIDapp(Ports.source) ; stockerDansTableDeHachage(idApp, Ports) ; socketLocal.portDst ← MW.portLocal ; /* T raitement et transmission de données à SSM */ entête.idDst ← idDst ; entête.idSrc ← idSrc ; while siFermé(socketLocal) 6= true do if socketLocal.siVide() 6= true then données ← extraireDonnées(socketLocal) ; paquet ← créerPaquet() ; paquet.ajouterEntête(entête) ; paquet.ajouterChargeUtile(données) ; faireSuivrePaquetVersSSM(paquet) ;

L’algorithme 7 décrit formellement le mécanisme de redirection de port proposé.

6.3 Contraintes d’Internet

Dans cette section, nous étudions succintement les contraintes d’Internet dont peuvent être soumises les entités communicantes SEMOS. Les contraintes considérées portent essentiellement sur la traversée de NAT et le filtrage par les pare-feux. L’échange de données entre des entités SEMOS distantes s’effectue par le biais de l’infrastruture P2P sous-jacente qui s’occupe du routage et des autres fonctionnalités y afférentes. Les données qui transitent entre deux nœuds du réseau recouvrant sont en effet transmises sur des sockets TCP/UDP qui, faut-il le rappeler, agissent dans ce contexte comme des canaux de multiplexage supportant plusieurs sessions SEMOS parallèles. Les paquets générés au niveau de la couche SEMOS sont ensuite encapsulés dans des paquets IP avant leur acheminement effectif. Ces propriétés permettent donc à SEMOS, lorsque des pare-feux l’exigent, d’utiliser exclusivement des connexions TCP/UDP dont les numéros de port sont explicitement autorisés et de s’en servir ensuite pour, éventuellement, multiplexer plusieurs sessions virtuelles. Ainsi, les pare-feux peuvent filtrer la communication au 68 6.4. ANALYSE DE SÉCURITÉ

niveau de la couche transport, sans cependant impacter sur l’échange effectué à travers des sessions virtuelles SEMOS. En raison de leur architecture, les applications P2P se heurtent parfois aux dispositifs qui font office de NAT dans les réseaux, comme décrit dans l’article [112]. Ce défaut est en effet dû aux restrictions inhérentes au NAT : ce dernier n’autorise que les connexions sur les ports explicitement ouverts et n’accepte que des connexions entrantes/sortantes vers les hôtes clairement désignés dans sa configuration. Dépourvus d’adresses IP et de numéros de port, les paquets SEMOS se dérogent par conséquent aux règles établies relatives à la traversée de NAT. L’établissement, l’organisation, la gestion et la reprise des sessions sécurisées SEMOS ne sont ainsi nullement affectés par la présence ou l’absence de NAT sur le circuit de communication reliant les nœuds correspondants.

6.4 Analyse de sécurité

Un système VPN mobile permet, d’une part, d’oﬀrir une communication sécurisée et de tenir les sessions sécurisées actives pendant le changement d’emplacement opéré par un pair ou lors d’une inaccessibilité passagère, répétée ou prolongée d’un correspondant. D’autre part, les systèmes VPN mobiles sont exemptés de renégociation de clés post-intérruption. En dépit de l’importance notable de ces propriétés dans un environnement autonome, distribué et dynamique, les VPN mobiles sont soumis à des déﬁs sécuritaires liés à leur architecture. Dans cette section, nous analysons quelques-uns de problèmes de sécurité qui pourraient, éventuellement, être posés par les attaques par déni de service ou DoS (de l’anglais, Denial of Service) et les attaques par rejeu.

6.4.1 Protection contre les attaques par rejeu et les attaques DoS Afin de déjouer des attaques par rejeu des paquets de données (cf. la figure 6.33), SEMOS intègre un mécanisme basé à la fois sur l’utilisation de numéro de séquence, destiné à différencier chaque paquet des autres, et l’authentification des champs permanents dont, justement, le numéro de séquence. Ainsi, lorsqu’un paquet de données déjà reçu est rejoué, il pourrait être aisément détecté, puis détruit sur le coup. Cependant, dépourvus de numéro de séquence, les paquets Hello et Re-hello ne bénéficient point de cette contre-mesure précédemment énoncée. Par conséquent, un attaquant pourrait intercepter ces paquets et les rejouer plus tard sans que la cible ne pourrait le détecter. Plus préoccupant encore, l’attaquant pourrait malicieusement et frauduleusement créer une flopée de copies de ces paquets et les envoyer en cascade ou en parallèle à la victime dans le but de la saturer de requêtes et la mettre ainsi hors-service (attaque DoS). En d’autres termes, l’attaque consiste à envoyer une première succession (en série ou en parallèle) de paquets et avant que la cible n’ait fini de les traiter, une autre suite de paquets lui est encore expédiée, et ainsi de suite. En l’absence de numéro de séquence, une solution serait de disposer d’un moyen pouvant déterminer lequel des paquets reçus a la date d’émission la plus récente. Ainsi, si le paquet nouvellement reçu a une date supérieure ou égale, au moment de sa réception, à celle du paquet déjà reçu, alors on estime qu’il est rejoué et est illico détruit. La mise en œuvre de cette technique pourrait conduire à l’utilisation du mécanisme de l’horodatage ou de nonce. Bien qu’ils peuvent contrecarrer les attaques par rejeu, les horodateurs exigent cependant l’utilisation des horloges synchronisées. La RFC 3161 [113] propose en effet la description d’un protocole d’horodatage destiné à s’exécuter sur une autorité d’horodatage centralisée. Toutefois, cette technique est inadaptée aux environnements entièrement distribués. Lamport propose un protocole gérant le mécanisme de l’horodatage (timestamp, en englais) dans un environnement distribué et asynchrone [114]. Aussi, il faut préciser que l’algorithme de Lamport possède également des implications dans les problèmes basés sur les relations de causalité entre processus. Ceci étant, la gestion distribuée de l’horloge logique de Lamport est formellement décrite par l’algorithme 8. Il est donc évident de constater que l’ajout d’un champ HL dans les requêtes Hello et Re-Hello, doublé d’une authentification par HMAC, et l’application de cet algorithme CHAPITRE 6. SESSIONS VIRTUELLES SÉCURISÉES ET MOBILES 69

résoudraient les problèmes lié aux attaques par rejeu qui pourraient se solder par la mise hors-service de la cible. Enﬁn, comme SEMOS gère simultanément plusieurs sessions, chaque pair devrait alors maintenir une table de correspondance qui associe chaque session à une horloge logique aﬁn de se synchroniser avec les horloges logiques de ses correspondants.

Algorithme 8 : Horloge logique de Lamport

1. chaque processus i tient à jour une horloge logique HLi ;

2. lorsqu’un évèvement ek se produit, i met alors à jour HLi ← HLi + tk ;

3. lorsqu’un message est envoyé du processus i au processus j, HLi est joint à ce message ;

4. sur réception du message envoyé par i, le processus j calucle HLi ← max(HLi,HLj) + 1.

Comme le montre l’article qui traite l’analyse de sécurité du protocole [115], le système HIP est vulnérable aux attaques DoS. Les auteurs suggèrent cependant une suite des mesures qui pourraient parer à l’éventualité de ces attaques.

6.4.2 Autres propriétés Bien que l’intergiciel SEMOS offre un mécanisme robuste de sécurité sur la communication entre des pairs distants, la communication locale entre SEMOS et les processus applicatifs n’est pas sécurisée. En effet, un utilisateur malicieux pourrait écouter le trafic entre les applications locales et l’intergiciel SEMOS ou se connecter frauduleusement, via SEMOS, à un pair distant. Ce type d’intrusion pourrait créer des problèmes de sécurité. Afin de résoudre ces failles sécuritaires, d’une part, seules les applications ayant des adresses IP locales puissent se connecter à SEMOS. D’autre part, pour capturer les paquets circulant entre SEMOS et les processus applicaifs à l’aide des utilitaires comme tcpdump et/ou wireshark, seul l’utilisateur root pourrait le faire. Ainsi, l’échange de données entre SEMOS et les applications utilisateur est, dans certaines mesures, protégé.

6.5 Conclusion

À la lumière des études descriptives menées sur l’architecture SEMOS dans les précédentes sections, il en ressort que les sessions sécurisées virtuelles et mobiles proposées présentent des propriétés relativement intéressantes. Bénéficiant d’un découplage, basé sur une infrastruture DHT, entre l’espace d’adressage et l’espace de nommage qui fournit des identités virtuelles immuables, l’intergiciel SEMOS introduit un nouveau modèle VPN mobile distribué. Renforcé par les carac- téristiques héritées d’un système DHT entièrement distribué telles que la résistance aux pannes et la disponibilité, SEMOS est doté des facultés lui permettant d’évoluer sans encombre dans un environnement totalement mobile tout en offrant des communications sécurisées. Les contraintes d’Internet, comme la traversée de NAT et le filtrage malencontreux de paquets par les pare-feux, dont souffrent beaucoup de systèmes P2P, sont à la fois résolues par le caractère virtuel des sessions logiques utilisées et les propriétés de l’infrastructure sous-jacente. En outre, l’analyse de sécurité montre que la protection contre les attaques par rejeu et les attaques DoS serait assurée. Une politique de sécurité sur un réseau ne saurait être complète et fiable sans la définition et la mise en place d’un protocole robuste de gestion de clés cryptographiques. Afin de satisfaire cet impératif de sécurité, nous nous proposons, dans le prochain chapitre, de définir un mécanisme multi-chemin et distribué d’échange de clés basé sur l’extension du protocole Diffie-Hellman et sur une forme étendue du schéma à seuil (k, n) de Shamir. 70 6.5. CONCLUSION CHAPITRE 7

Paradigme multi-chemin d’échange de clés

Sommaire 7.1 Motivations ...... 71 7.2 Recherche des k−chemins s-t disjoints ...... 72 7.2.1 Contexte d’étude ...... 72 7.2.2 Chemins disjoints : concepts et principes ...... 72 7.2.3 Modes et politiques du routage multi-chemin ...... 73 7.2.4 Algorithme du routage multi-chemin ...... 76 7.3 Protocole d’échange de clés et ses corollaires ...... 79 7.3.1 Méthodes de segmentation des clés en sous-clés ...... 79 7.3.2 Échange bout-à-bout de clés ...... 83 7.3.3 Concept de proxy de conﬁance et délégation de négociation de clé 83 7.4 Analyse de sécurité ...... 86 7.4.1 Forces et faiblesses de l’utilisation des chemins disjoints . . . . . 86 7.4.2 Considérations sécuritaires ...... 87 7.4.3 Comparaison de notre approche avec deux protocoles connexes . 88 7.5 Conclusion ...... 89

7.1 Motivations

Les protocoles et techniques standards de sécurité actuels sont pour la plupart basés sur une cryptographie à clés publiques. Cependant, l’un des problèmes fondamentaux de ces algorithmes cryptographiques consistait à définir un mécanisme de certification qui garantit l’authenticité des clés publiques. En général, cette problèmatique est résolue par l’utilisation d’une tierce partie connue sous le nom d’Autorité de Certification. L’infrastructure centralisée qui met en œuvre cette technique, et bien d’autres encore, est appelée PKI. Toutefois, en raison des propriétés inhérentes à leur architecture, les systèmes P2P sont soumis à des défis et impératifs de sécurité auxquels les infrastructures traditionnelles de gestion des clés, basées sur une coordination centralisée telle que la PKI, ne peuvent efficacement faire face. Dépourvus conceptuellement d’entités centralisées, les systèmes distribués, notamment les architectures P2P, sont incompatibles avec les politiques traditionnelles de sécurité qui sont pourtant réputées être robustes. Par conséquent, l’intégration dans ces systèmes, qui jouissent d’une grande autonomie et dont la topologie évolue perpétuellement, d’une politique centralisée de gestion de clés ne se ferait sans provoquer des défaillances sécuritaires majeures. C’est pourquoi, nous nous proposons de concevoir, dans ce chapitre, un nouveau protocole d’échange de clés entièrement distribué ; l’approche proposée étend des protocoles cryptographiques

71 72 7.2. RECHERCHE DES K−CHEMINS S-T DISJOINTS

réputés pour leur robustesse et exploite en outre les propriétés relatives aux réseaux P2P pour arriver à cette fin. La méthode d’échange de clés proposée s’appuie sur une extension de l’algorithme Diffie-Hellman combinée avec le schéma à seuil (n, k) de Shamir. Afin d’éviter des attaques par HDM dont le protocole Diffie-Hellman est originellement vulnérable, l’approche consiste en effet à sectionner une clé principale en plusieurs sous-clés et de router ensuite chacune vers le nœud destinataire via un chemin disjoint frayé à travers le réseau recouvrant. Ce procédé permet ainsi à la fois d’assurer l’authentification des pairs et de permettre un échange bout-à-bout des clés entre des nœuds correspondants du réseau.

7.2 Recherche des k−chemins s-t disjoints

Dans cette section, nous étudions les éléments de base et les algorithmes en rapport avec notre approche de recherche des k−chemins s-t disjoints.

7.2.1 Contexte d’étude Pour des raisons de simplicité, dans ce chapitre, nous représentons un réseau P2P par un graphe non-orienté G = (V,E), où V est un ensemble non vide de sommets (nœuds) et E l’ensemble d’arcs (liens) reliant ces sommets. À la lumière de cette précision, étant donné deux sommets distincts et non adjacents s, t ∈ V et un entier k, le problème qui nous intéresse consiste à déterminer k−chemins disjoints P0, ..., Pk−1 reliant s et t à travers le graphe G ; aussi, doit-il exister une bijection entre les k−chemins s − t disjoints et les k−chemins t − s disjoints. En outre, nous supposons que chaque nœud n’a qu’une connaissance topologique locale, c’est à dire qu’il ne connait que ses voisins immédiats et n’a aucune vision globale de la topologie du graphe.

D’une part, il faut noter que chaque Pi est une collection de n sauts consécutifs hi0 , ..., hin−1 ; les chemins Pi considérés sont des chemins sommet-disjoints. D’autre part, il faut préciser que tout pas hij , situé sur le chemin Pi, représente un saut optimal à l’étape j satisfaisant les critères déﬁnis par le protocole du routage implémenté par l’infrastructure de routage sous-jacente. Un chemin Pi est donc formellement déﬁni par l’équation :

Pi = {hhi0 , ..., hin−1 i0≤i≤k−1 | hjp 6= hlq , avec 0 ≤ j 6= l ≤ k − 1 et 0 ≤ p, q ≤ n − 1} (7.7)

7.2.2 Chemins disjoints : concepts et principes Dans la pratique, bien que certains chemins peuvent s’intersecter sur quelques nœuds du réseau, si les n chemins vériﬁent l’équation 7.8, c’est à dire qu’il existe au moins un chemin qui ne contient pas ces points d’intersection, alors les attaques HDM pourraient être enrayées. Cependant, des nœuds malicieux coordonnés et placés à la fois aux points d’intersection et sur les chemins parallèles pourraient perpétrer des attaques visant les sous-clés échangées via ces voies. Toutefois, l’équation 7.9 décrit le cas idéal où les chemins sont deux à deux disjoints, c’est à dire qu’il n’existe aucun nœud d’intersection entre deux ou plusieurs chemins s-t disjoints déterminés à travers le réseau recouvrant.

n \ Pi = ∅ (7.8) i=0

Un nœud Ni du graphe G est qualifié pour être un maillon dans un chemin s-t si, et seulement si, Ni ∈/ V et Ni représente, à l’étape i, le choix optimal pour atteindre t. En outre, afin d’éviter la redondance et pour de raison de simplicité, les chemins Pi sont supposés ne pas contenir les identifiants du nœud source et du nœud destination. Cette précision est d’autant plus importante CHAPITRE 7. PARADIGME MULTI-CHEMIN D’ÉCHANGE DE CLÉS 73

que chaque paquet qui transporte une sous-clé arbore déjà en son entête les identités de deux pairs précédemment cités.

Pi ∩ Pj 0≤i6=j≤n−1 = ∅ (7.9)

Afin de déterminer les chemins Pi vérifiant les propriétés représentées par l’équation 7.9, nous procédons par une méthode de marquage de graphe ; la liste de nœuds déjà visités est représentée par V. L’algorithme consiste en effet à parcourir les nœuds optimaux vers le nœud destinataire t et à chaque nœud visité, la liste V est mise à jour jusqu’à ce que t soit atteint. Ce processus est censé donc être répété k fois, où k est égal au nombre minimun de sous-clés requis pour la reconstruction de la clé originale. Ces définitions conceptuelles, relatives à la recherche des chemins disjoints, doivent être placées en filigrane par le lecteur afin de mieux appréhender les notions qui seront introduites dans la suite de ce chapitre.

7.2.3 Modes et politiques du routage multi-chemin Le routage multi-chemin, nécessaire à l’acheminement des paquets transportant des sous-clés, peut être mis en œuvre par plusieurs algorithmes. Cependant, ces algorithmes de routage ne présentent pas des caractéristiques similaires, ni en termes de complexité ni au niveau de la robustesse dans l’acheminement des données. Nous décrivons succintement ces méthodes de routage dans les points suivants.

Algorithme 9 : Routage indéterministe Input : G = (V,E), (s, t), ComposantesClé V ← ∅ ; begin V ← V ∪ {s, t} ; foreach e ∈ ComposantesClé do nœud ← s ; while nœud 6= t do

dmin ← distanceH(nœud, t) ; foreach voisin ∈ listeVoisinsDe(nœud) do

d ← distanceH(voisin, t) ; if voisin∈ / V and d < dmin then dmin ← d ; nœud ← voisin ; V ← V ∪ {nœud} ; faireSuivre(e, nœud) ;

7.2.3.1 Routage indéterministe : combinaison marquage et routage La méthode basée sur le routage indéterministe permet de combiner, dans le même temps, le routage des sous-clés et le marquage des nœuds (cf. l’algorithme 9) ; les trajets empruntés par les paquets ne sont pas prédéﬁnis mais sont déterminés dynamiquement pendant le tranfert des paquets. L’algorithme consiste en eﬀet à sectionner une clé principale en plusieurs sous-clés puis de les envoyer successivement tout en plaçant chaque nœud utilisé (pas seulement visité) dans un chemin 74 7.2. RECHERCHE DES K−CHEMINS S-T DISJOINTS

dans la liste V. Typiquement, une première sous-clé est envoyée et sur réception d’un message d’acquittement, la sous-clé suivante est expédiée, et ainsi de suite (ce processus est répété k fois). En faisant abstraction des acquittements, cet algorithme a une complexité de temps d’exécution τ1 = O(k(|E| + |V | log |V |)), où E représente l’ensemble des arcs, V désigne l’ensemble de sommets et k définit le nombre de sous-clés. En outre, la complexité en termes d’espace vaut σ1 = O(k|V |). Comme il n’est pas possible de prédire le nombre des chemins disjoints dans le réseau, il pourrait exister une disproportion entre le nombre de sous-clés et le nombre effectif des chemins disjoints trouvés. Ceci est en effet dû au fait que la clé est fragmentée avant le démarrage du processus de recherche des chemins disjoints.

7.2.3.2 Routage déterministe : pre-routage puis routage La méthode du routage déterministe consiste en deux étapes successives, comme le montre formellement l’algorithme 10. D’abord, le procédé permet de déterminer tous les k−chemins disjoints, entre les nœuds s et t, à travers le graphe G ; les nœuds parcourus sont ainsi placés à la fois dans la liste V et dans la liste déﬁnissant le chemin concerné. Ensuite, se servant des informations récoltées durant l’exploration d’un chemin, chaque membre du couple (s, t) fragmente sa clé en plusieurs composantes proportionnellement au nombre des chemins disjoints trouvés, dont chaque composante est subséquemment expédiée via un chemin séparé antérieurement déterminé. L’un des avantages de cette approche est d’avoir une parité entre le nombre de chemins disjoints et le nombre de sous-clés à générer. Le temps d’exécution de l’algorithme décrivant cette approche, dans le pire des cas, est : τ2 = τ1 + O(k|V |) = O(k(|E| + |V |(1 + log |V |))). Alors que la complexité en termes d’espace, dans le pire des cas, vaut : σ2 = σ1 = O(k|V |). En dépit des coûts relativement élevés dûs au temps d’exécution et à la complexité en termes d’espace, cette méthode présente un avantage notable : le nombre de sous-clés est toujours pro- portionnel au nombre des chemins disjoints déterminés, ce qui permet d’éviter, éventuellement, de réutiliser certains chemins en raison du nombre élevé de sous-clés. Néanmoins, comme la topologie pourrait changer au cours du temps, les chemins disjoints initialement déterminés pourraient n’être plus valides au moment où ils sont eﬀectivement utilisés pour l’acheminement des sous-clés.

7.2.3.3 Prospection puis routage : routage à la source L’approche consiste en la combinaison des concepts introduits par les deux algorithmes précé- dents. Concrêtement, il s’agit de déterminer un seul chemin s − t à la fois puis directement l’utiliser aﬁn d’acheminer une sous-clé. Ce processus est exécuté k fois. Cet algorithme dispose de la même complexité que la methode auparavant déﬁnie (routage déterministe). Aussi, il reprend à son compte les inconvénients soulignés pour les deux premiers algorithmes et requiert, en outre, une certaine stabilité topologique du réseau.

7.2.3.4 Équivalence entre le flot maximal et le nombre des chemins disjoints L’idée derrière cette approche est basée sur le théorème de Menger [75] (cf. la section 3.3 pour plus de détails sur ce théorème). Elle consiste en effet en une réduction du problème de recherche des chemins disjoints au problème de recherche du flot maximal entre les nœuds s et t. Ce procédé consiste à assigner la capacité unitaire à chaque arc et déterminer ensuite la valeur du flot maximal entre les deux nœuds considérés, en l’occurence s et t. Bien qu’elle semble théoriquement intéressante, l’approche requiert cependant une connaissance globale de la topologie ; cette contrainte ne répond pas aux exigences des réseaux de grande taille, comme le sont les systèmes P2P.

7.2.3.5 Remarques 1. Aﬁn de minimiser les coûts relatifs à la recherche des chemins disjoints entre les nœuds s et t, une amélioration pourrait être apportée aux algorithmes décrits précédemment. Il s’agit CHAPITRE 7. PARADIGME MULTI-CHEMIN D’ÉCHANGE DE CLÉS 75

Algorithme 10 : Routage déterministe Input : G = (V,E), (s, t), ComposantesClé V ← ∅ ; begin k ← |ComposantesClé| ; j ← k − 1 ; V ← V ∪ {s, t} ; while j ≥ 0 do nœud ← s ; while nœud 6= t do

dmin ← distanceH(nœud, t) ; foreach voisin ∈ listeVoisinsDe(nœud) do

d ← distanceH(voisin, t) ; if voisin∈ / V and d < dmin then dmin ← d ; nœud ← voisin ; V ← V ∪ {nœud} ; Pj ← Pj ∪ {nœud} ; j ← j − 1 ; while k > 0 do e ← ComposantesClé[k] ; envoyerViaChemin(e, Pk) ; k ← k − 1 ; 76 7.2. RECHERCHE DES K−CHEMINS S-T DISJOINTS

de considérer le nœud destinataire t, dans la phase d’initiation d’échange de clés, comme une entité passive dans la recherche des chemins disjoints ; lequel nœud doit seulement se contenter de réutiliser les trajets empruntés par les paquets reçus du nœud source afin d’y envoyer ses sous-clés. Le nœud destinataire n’a pas, en effet, pour rôle de déterminer les chemins disjoints. Cependant, lorsqu’un changement de topologie se produit, entre la réception d’une sous-clé et avant l’entame d’une réponse de la part du nœud t, alors ce dernier sera contraint de lui-même trouver un chemin disjoint afin d’expédier une sous-clé. Ainsi, les rôles respectifs des nœuds s et t se permutent automatiquement. 2. L’échange des sous-clés peut se faire de façon parallèle et conjointe. Typiquement, chaque nœud détermine et utilise ses chemins disjoints indépendamment de son correspondant. Cette méthode exige néanmoins un coût lié à la recherche des chemins disjoints égale au double de celui relatif aux méthodes précédentes.

7.2.3.6 Comparaison technique des méthodes de routage multi-chemin Le tableau 7.11 dresse une compraison d’ordres de grandeur de diﬀérents algorithmes étudiés ci- dessus. En raison de sa robustesse, de ses coûts de complexité relativement réduits et des propriétés inhérentes au procédé de subdivision de clé (que nous étudierons plus loin dans ce chapitre), la méthode du routage indéterministe constitue, pour nous, une solution de choix. Nous allons en eﬀet l’adopter pour notre algorithme de routage, lequel algorithme est étudié dans les lignes suivantes.

tableau 7.11 – Comparatif de quelques modes du routage multi-chemin

Ordres de grandeur des indicateurs et autres propriétés Méthodes de routage Temps d’exécution Espace requis Parité a Robustesse b Vue globale √ Routage indéterministe O(k(|E| + |V | log |V |)) O(k|V |) √ Routage déterministe O(k(|E| + |V |(1 + log |V |))) O(k|V |) √ Prospection & routage O(k(|E| + |V |(1 + log |V |))) O(k|V |) √ Théorème de Menger NP − − a Parité entre le nombre de chemins disjoints et le nombre de sous-clés générées b Robustesse au changement de la topologie c La connaissance globale de la topologie est requise

7.2.4 Algorithme du routage multi-chemin Comme mentionné dans le chapitre 5, pour des raisons consubstantielles à la dynamicité de la topologie et donc aux changements perpétuels se produisant dans l’espace virtuel d’adressage, chaque nœud maintient des liens redondants avec plusieurs autres nœuds qui lui sont adjacents. Cette propriété peut être exploitée dans le cadre de recherche des chemins disjoints. Il va sans dire en eﬀet que si chaque nœud a plusieurs voisins, parents dans l’arbre d’adressage virtuel, alors celui-ci peut s’en servir pour atteindre ses correspondants et ce, à travers des chemins potentiellement disjoints. À l’évidence, lorsque le degré de l’arbre d’adressage est q, chaque nœud peut assigner q − 1 adresses à des fils potentiels, ce qui permet d’avoir encore davantage des liens redondants dans le réseau recouvrant. Dans cette partie, nous étudions notre protocole du routage ainsi que les éléments qui en découlent.

7.2.4.1 Description de la politique du routage Basé sur le routage indéterministe, l’algorithme multi-chemin proposé permet l’acheminement de k sous-clés sur n sous-clés générées (k ≤ n). Cette propriété, étudiée amplement dans la section CHAPITRE 7. PARADIGME MULTI-CHEMIN D’ÉCHANGE DE CLÉS 77

suivante, permet de se départir de la contrainte qui exige l’envoi de toutes les sous-clés. Cependant, si l’envoi intégral n’est pas couronné de succès mais que seules l sous-clés, tel que k ≤ l < n, sont effectivement transmises, alors l’échange est considéré, malgré tout, effectué avec succès. En d’autres termes, on estime au départ qu’il existe n chemins disjoints à travers le réseau mais si, à l’arrivée, on n’en trouve que l, alors cela n’affecte aucunement l’échange de clés. Ces propriétés constituent l’une des pierres angulaires sur lesquelles notre algorithme de routage est bâti. L’algorithme 12, tributaire de la routine d’initialisation 11, décrit formellement le mécanisme indéterministe de routage des sous-clés. Ayant une complexité en termes de temps d’exécution égale à O(k(|E| + |V | log |V |)), cet algorithme définit la politique du routage glouton tout en tenant compte des propriétés cryptographiques relatives à la segmentation et à la reconstitution des clés à partir des sous-clés générées conjointement par les pairs correspondants.

Algorithme 11 : Initialisation des paramètres initialisationParamètres(G =(V,E), (s,t), Clé) ; Output : ComposantesClé V 0 ← V \{s} ; ComposantesClé ← subdiviserClé(Clé) ; begin foreach v ∈ V 0 do if v∈ / listeVoisinsDe(s) then v.statut ← injoignable ; return ComposantesClé ;

Il faut préciser que l’algorithme 12 est assez générique, alors que l’algorithme récursif 19 est spéciﬁque à l’infrastructure CLOAK ; il est déﬁni dans l’annexe B.2. Comme précisé ci-dessus, l’entité passive se contente d’utiliser les chemins disjoints déterminés par l’entité active, initiatrice de l’échange. Pour ce faire, l’entité passive tient à jour la liste Vb des nœuds visités, initialisée à ∅. Sur réception d’un paquet contenant une sous-clé et une liste V, le nœud passif calcule le chemin P emprunté par le paquet : P = V ∩ Vb ; puis, il met à jour la valeur de Vb : Vb = V ∪ Vb. Ce processus est réitéré k fois, k étant le nombre de sous-clés reçues.

7.2.4.2 Illustration de la politique du routage La ﬁgure 7.39 décrit le processus de recherche des chemins disjoints reliant le nœud s à son correspondant distant t. D’abord, le nœud source expédie un premier paquet pour déterminer le chemin P1 (V et P1 sont initialisés à ∅) ; le paquet emprunte le chemin le plus optimal pour arriver à t. Ainsi, les nœuds intermédiaires 4 et 7 forment P1 (P1 = {4, 7}) et sont marqués dans la foulée : ils sont ajoutés à V (V = {4, 7}). Le nœud destinataire, en l’occurence t, accuse réception du paquet en renvoyant au nœud source un paquet d’acquittement contenant la liste V constituée des valeurs mises à jour, et ainsi qu’une sous-clé qu’il a générée. Ensuite, le même processus est exécuté pour la détermination de P2 (P2 = {3, 6, 8}), ponctuée par la mise de V (V = V ∪ P2). Enﬁn, il est aisé d’observer que P1 et P2 sont disjoints (P1 ∩ P2 = ∅). Aussi, il faut noter que les paquets échangés précisent en leur entête le rapport entre le numéro de séquence et le nombre total de sous-clés : par exemple, pour k sous-clés, la répartition des numéros de séquence est 1/k, 2/k, ..., k/k. Subséquemment, sur réception de toutes les sous-clés, chaque nœud correspondant procède au réassemblage des sous-clés pour en constituer la clé d’origine. Les nœuds pourraient ainsi démarrer une communication sécurisée, sauf s’il y avait eu une attaque coordonnée entre les nœuds malveillants se trouvant sur P1 et ceux qui sont situés sur P2. Pour en savoir plus sur la génération 78 7.2. RECHERCHE DES K−CHEMINS S-T DISJOINTS

Algorithme 12 : Routage des sous-clés Input : G = (V,E), (s, t), Clé, k Output : succès/échec V ← ∅ ; ComposantesClé ← initialisationParamètres(G =(V,E), (s,t), Clé) ; begin V ← V ∪ {s, t} ; n ← |ComposantesClé| ; l ← 0 ; foreach e ∈ ComposantesClé do nœud ← s ; while nœud 6= t do

dmin ← distanceH(nœud, t) ; foreach voisin ∈ listeVoisinsDe(nœud) do

d ← distanceH(voisin, t) ; if voisin∈ / V and d < dmin then dmin ← d ; nœud ← voisin ; V ← V ∪ {nœud} ; faireSuivreSous-clé(e, nœud) ; l ← l + 1 ; return (n ≥ l ≥ k) ? succès : échec ; CHAPITRE 7. PARADIGME MULTI-CHEMIN D’ÉCHANGE DE CLÉS 79

4,7 P1 4,7 V 2 5 7

4 P1 4 V source destination s 4 8 t

3,6,8 P2 4,7,3,6,8 V 3 6

3 2 3,6 P2 P 4,7,3 4,7,3,6 V V ﬁgure 7.39 – Processus de détermination des chemins disjoints : cas de deux (02) chemins disjoints et la reconstitution de clés ainsi que toutes les propriétés en rapport avec le protocole d’échange de clés, le lecteur est invité à se référer à la section suivante.

7.2.4.3 Limitation du nombre de sauts Les problèmes liés aux minima locaux dans le routage des paquets sont résolus par l’infrastructure P2P sous-jacente [116]. Cependant, compte tenu de la limitation mémoire et au vu de la présence de la liste des nœuds visités V dans chaque paquet utilisé dans le processus d’échange de clés, le nombre d’identifiants contenus dans V est limité. La figure 7.40 représente en effet un modèle abstrait de détection de la taille maximale de V et de changement de mode : basculement au mode pair de confiance ; le mécanisme de pair de confiance est étudié dans la section suivante.

7.3 Protocole d’échange de clés et ses corollaires

Dans cette section, nous étudions le protocole d’échange de clés proposé. Le partage du secret s’effectue en effet directement et conjointement entre deux pairs désirant établir une session sécurisée. Ce paradigme distribué d’échange de clé donne lieu à une combinaison intéressante de deux protocoles cryptographiques parmi les plus utilisés et/ou les plus populaires actuellement, à savoir : le protocole Diffie-Hellman et le schéma à seuil (k, n).

7.3.1 Méthodes de segmentation des clés en sous-clés Nous étudions, dans cette sous-section, deux approches qui permettent de subdiviser une clé en plusieurs sous-clés. Les mécanismes utilisés dans la segmentaion des clés doivent avoir la propriété de reconstitution ultérieure de la clé principale à partir des sous-clés dérivées.

7.3.1.1 Approche naïve L’approche naïve consiste à segmenter une clé K = {0, 1}∗, où |K| = τ, en n sous-clés τ sk1, ..., skn ; chaque sous-clé ski, où |ski| = n , est ensuite expédiée séparément au destinataire. Ainsi, le réassemblage ultérieur de K nécessite alors la connaissance de toutes les sous-clés sk1, ..., skn 80 7.3. PROTOCOLE D’ÉCHANGE DE CLÉS ET SES COROLLAIRES

notiﬁcation compteur saut ++ recherche d’un autre chemin

compteur saut > valeur limite debut´ q0 q1

(autre) chemin introuvable

destination atteinte

si nombre de chemins disjoints k q2 ≥ q4

sinon enclencher le mecanisme´ de pair de conﬁance

figure 7.40 – Processus de détection du nombre maximum de sauts et enclenchement du mécanisme de pair de confiance initialement forgées. La possession de l sous-clés, avec l < n, ne permettrait pas, à priori, de déterminer la clé K. Point faible de l’approche : Cette subdivision, qui paraît au premier abord comme logique, n’est cependant pas efficace car elle permet de réduire, pour un dépositaire de α sous-clés, la τ τ(n−α) difficulté d’exécuter une attaque par force brute de τ − α n , soit n .

7.3.1.2 Approche robuste : schéma à seuil (k, n) de Shamir Concept : Le schéma à seuil (k, n), avec k ≤ n, de Shamir [41] consiste à générer une donnée ∆ et à forger ensuite une suite de n sous-données ∆1, ..., ∆n, en se servant du paramètre k, telles que celles-ci satisfassent les deux propriétés suivantes : 1 1. la connaissance d’au moins k données détermine ∆ : ∆ = ∆u ⊕ ... ⊕ ∆v ; | {z } ≥ k termes

1. Le symbole ⊕ représente l’opération de reconstitution de donnée par l’interpolation de Lagrange. CHAPITRE 7. PARADIGME MULTI-CHEMIN D’ÉCHANGE DE CLÉS 81

2. la connaissance d’au plus k − 1 données ne reconstitue pas ∆ : ∆ 6= ∆x ⊕ ... ⊕ ∆y. | {z } < k termes

Fondement mathématique : Formellement, lorsque la valeur de k est fixée, l’approche l k−1 consiste à déterminer un polynôme f (X) = a0 + a1X... + ak−1X tels que les cœfficients a1, ..., ak−1 sont choisis aléatoirement, à l’exception de a0 qui se substitue à la valeur du secret à l l segmenter : a0 = f (0) = ∆. Ainsi, les couples (xi, f (xi))0≤i≤n−1, où xi 6= 0, sont stockés/envoyés séparément. Il est donc trivial de constater que le couple (0, f l(0)) ne fait pas partie des couples (d’antécédents et des images correspondantes déterminées à l’aide du polynôme f l) qui sont envoyés/stockés ; lesquels couples, faut-il le rappeler, sont représentés par les points d’interpolation l l (xi, f (xi))0≤i≤n−1. Il faut remarquer que : k = deg(f ) + 1. Réciproquement, la reconstruction de ∆ se fait par l’interpolation polynômiale L(X) de degré n, où n ≥ k ; L(X) se définit en effet par une combinaison linéaire des polynômes de base lj(X), comme le montre l’équation 7.10.

n X L(X) = yjlj(X) (7.10) j=0

l où yi = f (xi) et les polynômes de Lagrange :

n Y X − xi lj(X) = (7.11) xj − xi i=0,i6=j Une fois la valeur de L(X), qui est unique, déterminée à partir de l’équation 7.10, il suﬃt seulement de calculer ensuite L(0) pour retrouver la donnée d’origine ∆.

Points forts : 1. Les parties de clé ne sont pas expédiées : l’attaque par force brute est donc difficile à réaliser ; 2. Flexibilité : le nombre de sous-clés ainsi que la valeur de k sont réajustables à souhait ; 3. L’échec dans le routage de α sous-clés, avec n − α ≥ k, n’affecte pas la reconstitution de ∆ ; 4. Le polynôme f l peut être complètement changé, tout en conservant le premier terme, mais cela n’affecte le secret ∆. La propriété numéro 3 est particulièrement importante dans le routage indéterministe. En effet, lorsque n sous-clés sont forgées mais on ne réussit au final qu’à envoyer k sous-clés, k ≤ n, faute des chemins disjoints suffisants et/ou des défaillance dans le routage, le destinataire pourra malgré tout reconstruire ∆.

7.3.1.3 Approche proposée Le modèle proposé, qui est une extension du schéma à seuil (k, n) de Shamir, consiste simplement à affecter la valeur gS( mod p), déterminée à l’aide du protocole Diffie-Hellman, à f l(0). La spécificité et l’originalité de cette méthode s’appuient donc sur la valeur de f l(0) (i.e, f l(0) = gS( l mod p)). Ensuite, les points d’interpolation (xi, f (xi)) sont calculés puis utilisés comme des sous-clés ; lesquelles sous-clés sont subséquemment transmises à travers des chemins séparés au destinataire. L’algorithme 13 montre formellement comment les sous-clés sont générées à partir des paramètres cryptographiques pris en argument. Il faut noter que si on avait choisi la méthode du routage appelée déterministe, on aurait pris k = n : car la segmentation de clé s’effecturait après la détermination de n chemins disjoints, il existerait donc une parité entre le nombre de ces chemins et celui des sous-clés. 82 7.3. PROTOCOLE D’ÉCHANGE DE CLÉS ET SES COROLLAIRES

Algorithme 13 : Génération des sous-clés Input : k, n, gS (mod p) S fl(X) ← créerPolynôme(k, g (mod p)) ; // Application de l’algorithme 14 ComposantesClé ←⊥ ; begin i ← 1 ; while i ≤ n do xi ← sélectionnerUneValeurAléatoire() ; l fb(xi) ← (xi, f (xi)) ; stockerDansListeDeSous-clés(fb(xi), ComposantesClé[i]) ; i ← i + 1 ;

Algorithme 14 : Création du polynôme créerPolynôme(k, gS (mod p)) return Polynôme ; begin S a0 ← g (mod p) ; fl(0) ← a0 ; i ← 1 ; while i ≤ k − 1 do ai ← choisirCœfficientAléatoire() ; if i = k − 1 and ai = 0 then continue ; i li(X) ← aiX ; i ← i + 1 ; k−1 P fl(X) ← li(X) + fl(0) ; i=1 return fl(X) ; CHAPITRE 7. PARADIGME MULTI-CHEMIN D’ÉCHANGE DE CLÉS 83

L’algorithme 15 montre la reconstruction de la clé à base des points d’interpolation reçus, telle qu’énoncée ci-dessus.

Algorithme 15 : Reconstitution de la clé à partir des sous-clés reçues

Input : k, (xi, yi)0≤i≤n Output : Clé begin if |(xi, yi)0≤i≤n| < k then return ⊥ ; else foreach i ∈ 0, n do J n K Q X−xj li(X) ← x −x ; j=0,j6=i i j j ← 0 ; fl(X) ← 0 ; while j ≤ n do fl(X) ← yj × lj(X) + fl(X) ; j ← j + 1 ;

return fl(0) ;

7.3.2 Échange bout-à-bout de clés

À défaut d’une coordination centrale, l’utilisation des chemins disjoints à travers un réseau P2P compense l’absence d’authentification qui, faut-il le préciser, est intrinsèquement liée au protocole Diffie-Hellman. Le protocole d’échange de clés proposé s’appuie sur une négociation bout-à-bout des clés entre deux correspondants sans aucun concours d’aucun nœud spécifique. Basé sur le modèle de subdivision de clé en sous-clés inventé par Shamir et la politique du routage introduite ci-dessus, l’algorithme 16 décrit formellement le mécanisme d’échange de clés. Les requêtes 11 et 12 de l’algorithme 16 correspondent à la finalisation de négocition et permettent de vérifier si l’échange de clés s’est bien déroulé ou pas. Typiquement, il s’agit pour Alice de soumettre un défi à son correspondant Bob et de voir ensuite s’il peut le résoudre ou pas. Techniquement, le message challenge consiste en deux opérandes choisis aléatoirement O1 et O1, et un opérateur arithmétique commutatif op obtenu dans la même condition. Sur réception du paquet contenant le challenge, le nœud récepteur Bob effectue l’opération algébrique O1 op O2 et envoie le résultat obtenu, chiffré par la clé symétrique gsasb (mod p), au nœud Alice à l’origine de la requête. La résolution du défi est d’autant plus importante que si le paquet contenant le challenge est rejoué au nœud source ayant premièrement émis la requête, il est automatiquement détecté du fait de la non résolution de l’opération proposée.

7.3.3 Concept de proxy de confiance et délégation de négociation de clé Un sommet dont la suppression disloque un graphe en deux sous-graphes séparés est appelé, en théorie des graphes, un point d’articulation. Lorqu’il existe en effet un nœud qui constitue un passage obligé entre deux nœuds correspondants non adjacents (voir la position du nœud 4 de la figure 7.41 par rapport aux nœuds s et t), celui-ci pourrait potentiellement être désigné comme proxy de confiance. Est appelé proxy de confiance, tout point d’articulation avec lequel un échange 84 7.3. PROTOCOLE D’ÉCHANGE DE CLÉS ET SES COROLLAIRES

Algorithme 16 : Échange de clés multi-chemin basé sur le protocole Diﬃe-Hellman données publiques : données privées : p : un nombre premier Alice : clé secrète sa g : un générateur Bob : clé secrète sb

sa 1. Alice génère sa et détermine ensuite sa clé partielle Cléa = g (mod p) ; l l 2. Alice détermine un polynôme fa, tel que fa(0) = Cléa, et calcule ensuite n points

d’interpolation du polynôme : fba0 , ..., fban−1 (avec n ≥ k); l 3. Alice expédie les n sous-clés fbai , sans le point (0, f (0)), à Bob via des chemins disjoints ; b 4. Bob détermine L (X) à partir des sous-clés fbai obtenues de Alice et calcule b sa subséquemment L (0) qui donne g (mod p), si |fbai | ≥ k ; s 5. Bob génère sb et détermine ensuite sa clé partielle Cléb = g b (mod p) ; l l 6. Bob forge un polynôme fb, tel que fb(0) = Cléb, et détermine ensuite n points

d’interpolation du polynôme fbb0 , ..., fbbn−1 (avec n ≥ k); l 7. Bob envoie les n sous-clés fbbi , sans le point (0, f (0)), à Alice à travers des chemins disjoints ; a 8. Alice détermine L (X) à base des sous-clés fbbi reçues de Bob et calcule ensuite a sb L (0) qui donne g (mod p), si |fbbi | ≥ k ; sa s sas 9. Alice calcule Clé = Cléa × L(0) = g (mod p) × g b (mod p) = g b (mod p) ;

s sa s sa 10. Bob détermine Clé = Cléb × L(0) = g b (mod p) × g (mod p) = g b (mod p) ; 11. Alice génère un challenge, le chiﬀre avec gsasb (mod p) et l’envoie à Bob ; 12. Bob reçoit le challenge, le déchiﬀre avec gsasb (mod p), le résoud et le renvoie à Alice ;

de clés a déjà eu lieu avec succès et dont on souhaite l’utiliser pour négocier indirectement avec un autre correspondant ; il doit exister par conséquent un tunnel de sécurité entre le proxy de confiance et le nœud source s désirant joindre un nœud distant t à travers ce proxy. Ce concept est motivé par le risque d’absence des chemins disjoints dans le réseau recouvrant, notamment quand le réseau est de type petit-monde : lorsque la recherche d’au moins deux chemins disjoints se solde par un échec, alors on procède à la désignation d’un proxy de confiance. Ce dernier négocie l’échange de clés avec le nœud t mais pour le compte du nœud source s. Si cette négociation est couronnée de succès, la clé déterminée est alors transmise au nœud source s. Au cas échéant, un autre nœud est choisi pour devenir proxy de confiance. Ce processus se poursuit jusqu’à ce que la négociation de clés aboutisse ou que la liste des pairs susceptibles de devenir des pairs de confiance s’épuise. La délégation de négociation de clés consiste à transmettre, via un cannal sécurisé, à un proxy de confiance, qui arrive atteindre la destination à travers au moins deux chemins disjoints, tous les paramètres cryptographiques nécessaires au processus d’échange de clés. Ainsi, le proxy de confiance se sert de ces paramètres ainsi que de l’identifiant du nœud source pour déterminer la clé de session conjointement avec le nœud destinataire. Ensuite, la clé déterminée est retransmise à l’ayant droit, en l’occurence au nœud source s. CHAPITRE 7. PARADIGME MULTI-CHEMIN D’ÉCHANGE DE CLÉS 85

L’algorithme 17, qui dépend de l’algorithme 18, montre formellement comment les proxys de conﬁance sont choisis et comment la délégation de négociation de clés s’eﬀectue.

Algorithme 17 : Délégation de négociation de clé un proxy de conﬁance Input : s, t, ListePairsDeConﬁance begin proxy ← s ;

dmin ← distanceH(s, t) ; foreach nœud ∈ ListePairsDeConﬁance do

d ← distanceH(nœud, t) ; if d < dmin then dmin ← d ; proxy ← nœud ; if proxy 6= s then DéléguerNégociationDeClés(Key, t, proxy) ; else proxy ← ObtenirPointDArticulation(s, t) ; // Appel de l’algorith. 18 ÉchangeDeClés(s, proxy) ; // construction du tunnel entre s et proxy DéléguerNégociationDeClés(Key, t, proxy) ;

P1 6 V6 destination 1 6 t

reque ˆte source tunnel s 4 7

pair de conﬁance reponse´ P2 7 V 6,7

2 3

figure 7.41 – Processus de délégation de négociation de clé à un pair de confiance, en l’occurence le nœud 4 dans la figure 86 7.4. ANALYSE DE SÉCURITÉ

Algorithme 18 : Détection du point d’articulation obtenirPointDArticulation(s, t) return nœud ; begin j ← 0 ; i ← 0 ; listeVoisins ← listeVoisinsDe(s) ; foreach voisin ∈ listeVoisins do Pj ← ∅ ; déterminerChemin(voisin, t, Pj) ; nœud ← Pj.dernierNœud() ; if nœud∈ / t then i ← i + 1 ;

Pj ← Pj ∪ {nœud} ; j ← j + 1 ; n T return (i = j)? Pi : ⊥ ; i=0

7.4 Analyse de sécurité

Dans cette section, nous menons un étude analytique sur l’approche d’échange de clés proposée. Celle-ci a pour vocation de mettre en exergue les failles et les avantages présentés par le système de gestion des clés proposé.

7.4.1 Forces et faiblesses de l’utilisation des chemins disjoints Dans notre modèle d’échange multi-chemin de clés, un nœud malveillant qui souhaite compromettre une communication sécurisée serait contraint de posséder toutes les composantes de la clé cible de cette attaque. Formellement, lorsque k chemins P0, ...Pk−1 sont utilisés dans le cadre de l’échange de clés entre deux correspondants s et t (il faut souligner que des tels chemins sont bijectifs entre ces nœuds), les seuls nœuds malveillants qui pourraient potentiellement compromettre k−1 T la clé devraient à priori appartenir à l’ensemble M = Pi, qui réunit tous les points d’intersection i=0 k−1 2 T des chemins Pi . Ainsi, lorsque Pi = ∅ (le critère de bigone est respecté [117, Lemme 14 2.5]) i=0 alors il existe au moins un chemin qui est disjoint à tous les autres et aucune attaque HDM ne pourrait, à priori, s’exécuter avec succès. T Mieux, lorsqu’il existe k chemins tels que Pi Pj = ∅ (i.e, les chemins sont deux à deux i6=j disjoints), c’est à dire également qu’il existe un sous-graphe k-connexe entre le nœud source s et k T le nœud destination t, alors l’échange est encore plus robuste. Cependant, lorsque | Pi| ≥ 1, le i=0 risque qu’une attaque par HDM soit perpétrée est réel. La probabilité de l’existence d’un risque des kT−1 | Pi| i=0 attaques par HDM est déterminée par π = (où chaque chemin Pi est constitué des sauts kS−1 | Pi| i=0

2. Les Pi sont supposés ici ne pas contenir s et t mais seulement les nœuds intermédiaires qui les relient. CHAPITRE 7. PARADIGME MULTI-CHEMIN D’ÉCHANGE DE CLÉS 87

consécutifs reliant s et t). À l’évidence, si les Pi sont deux à deux disjoints, alors la probabilité k−1 T d’une attaque HDM isolée est nulle (i.e, π = 0, car | Pi| = 0). i=0 Il faut également noter que l’existence des chemins distincts entre deux nœuds s et t dépend aussi de degré de ces derniers. En effet, lorsque l’arbre d’adressage du réseau recouvrant est régulier et de degré q, chaque nœud peut avoir, en plus de son parent et d’éventuels nœuds impliqués dans les liens redondants, q − 1 nœuds qui lui sont adjacents (i.e, nœuds fils). Plus le degré q de l’arbre d’adressage est élevé, plus chaque nœud a la possibilité d’avoir de voisins plus nombreux ; la probabilité d’avoir beaucoup de chemins disjoints accroît donc avec la valeur q et le nombre des liens redondants. Le principal point faible de notre méthode réside évidemment dans la recherche coûteuse des chemins disjoints : lorsque la première recherche est infructueuse, le processus bascule alors en mode complexe utilisant le concept de pair de confiance qui est tout aussi coûteux, et pour cause. Ces opérations ne s’effectuent cependant qu’une seule fois au cours d’une session, ou voire de plusieurs sessions lorsque les correspondants s’entendent à réutiliser les paramètres cryptographiques déjà employés dans une session antérieure.

7.4.2 Considérations sécuritaires En dépit de sa robustesse accrue, l’échange de clés basé sur les chemins disjoints pourrait être entâché par des attaques HDM coordonnées. Typiquement, l’attaque consiste à placer un membre du groupe d’attaquants sur chaque trajet utilisé pour transférer une sous-clé. Ensuite, les membres du groupe réunissent leurs prises afin de reconstituer la clé d’origine : les sous-clés capturées pourraient être chiffrées, à l’aide d’une clé pré-partagée entre les nœuds malveillants coopératifs, avant d’être transmises au sein du groupe. Il est néanmoins très difficile de mettre en œuvre une telle attaque dans un environnement où la topologie change perpétuellement et où les chemins disjoints sont choisis dynamiquement lors de l’échange de clés. L’élection de pair de confiance pourrait se faire de façon récursive. En effet, lorsqu’un nœud du réseau est sollicité pour devenir un pair de confiance mais qu’il n’arrive pas à trouver des chemins disjoints le reliant au nœud destinataire, alors il pourrait enclencher le même processus de recherche des chemins disjoints. Ce processus pourrait récursivement continuer jusqu’à ce que le succès de l’échange de clés s’en suive. Cependant, l’utilisation de plusieurs pairs de confiance dans une même session fragilise considérablement la confidentialité de la clé. Afin de remédier ce problème, le nœud source indique, dans sa requête, le nombre maximum de pairs de confiance successifs qu’il accepte de les faire participer dans la négociation des clés. Malgré la subdivion de clé en sous-clés, les nœuds malveillants qui procèdent par une attaque par modification des sous-clés qui transitent en clair sur le réseau ne peuvent être empêchés d’essayer de compromettre la négociation de clés, loin s’en faut. La détection d’une attaque par modification qui altère l’intégrité des sous-clés s’effectue lors de l’échange du message challenge : lorsque le processus de vérification échoue, alors les sous-clés échangées sont considérées comme compromises par les correspondants impliqués dans l’échange. L’utilisation du schéma à seuil (k, n) permet flexiblement d’augmenter ou de diminuer à souhait le nombre de sous-clés ainsi que le nombre minimum de sous-clés requis pour reconstituer la clé d’origine. Ainsi, pour rehausser le niveau de sécurité, il suffit de considérer une valeur de k suffisamment grande et k ' n : la reconstruction de la clé exige alors la réunion de k sous-clés, si ce n’est de toutes les sous-clés. Aussi, il faut préciser qu’il est possible de regénérer de nouvelles sous-clés sans modifier la clé originale. Cette propriété permet à l’entité génératrice des sous-clés, lorqu’elle le désire, de réutiliser la clé principale avec de nouvelles sous-clés dérivées dans une session séparée. Preuve que notre modèle se démarque, de par sa robustesse, du protocole traditionnel Diffie- Hellman et de son extension proposée par Takano et al., l’échange de clés s’effectue à travers des chemins potentiellement nombreux et disjoints. Aussi, contrairement au premier algorithme qui 88 7.4. ANALYSE DE SÉCURITÉ

propose la transmission intégrale d’une clé sans aucun découpage préalable et au second protocole qui introduit une subdivion basique de clé, le mécanisme de segmentation de clé proposé par notre modèle s’appuie sur une technique mathématique robuste, en l’occurence le schéma à seuil (k, n) de Shamir.

7.4.3 Comparaison de notre approche avec deux protocoles connexes Le tableau 7.12 dresse un comparatif portant sur des propriétés techniques et sécuritaires de notre approche ainsi que de deux autres protocoles connexes.

tableau 7.12 – Comparaison technique entre quelques modèles d’échange de clés

Méthodes d’échange de clés Caractéristiques techniques Diffie-Hellman [37] Takano et al. [21] Modèle proposé √ √ Robustesse contre les attaques HDM b √ Imprédictibilité des chemins disjoints −√ √ Indépen. d’une topologique particulière Mise en œuvre des attaques HDMCa facile moyen difficile Robustesse liée à la nature des sous-clés − faible très élevée Quantité requise parmi n sous-clés − n k ≤ n Nombre de sous-clés générées − borné indéfini |Ensemble des chemins disjoints| = 1 = 2 > 2 Distance pour atteindre une destination n O(log n) O(log n) Maintenance de l’espace d’adressage O(n) O(log2 n) O(1)/O(n) a Attaques par HDM Coordonnée entre plusieurs nœuds malveillants b Ça dépend de la connaissance ou pas de la topologie du réseau considéré CHAPITRE 7. PARADIGME MULTI-CHEMIN D’ÉCHANGE DE CLÉS 89

7.5 Conclusion

Dans ce chapitre, nous avons mené une étude exhaustive sur notre modèle de gestion des clés, assortie d’une comparaison théorique avec le protocole traditionnel Diffie-Hellman et une de ses extensions proposée par Takano et al.. Il en ressort, d’une part, que le modèle d’échange de clés que nous proposons compense l’absence d’authentification inhérente au protocole traditionnel Diffie-Hellman. D’autre, le procédé qui consiste à sectionner une clé en plusieurs sous-clés est assez robuste et le caractère générique de notre modèle, c’est à dire que notre approche ne dépend d’aucune topologie particulière contrairement au deuxième algorithme énoncé ci-dessus, lui confère des propriétés qui sont tout autant robustes. Il n’en demeure pas moins que la recherche des chemins disjoints dans le réseau recouvrant induit une complexité des traitements dont le coût n’est pas négligeable, loin s’en faut. En dépit du coût évoqué, il faut préciser néanmoins que la recherche des chemins disjoints n’est pas systématiquement fréquente : elle n’est déclenchée qu’au début d’une session. Dans le chapitre 9 de la partie III, qui sera développée dans la suite de ce mémoire de thèse, nous évaluons notre modèle d’échange de clés sur des réseaux virtuels ayant des topologies aléatoires ou particulères (circulaire, etc.). Cette expérimentation évalue divers scénarios dans différents types de réseaux impliquant des attaques HDM coordonnées entre plusieurs nœuds malveillants. 90 7.5. CONCLUSION Troisième partie

Mise en œuvre et expérimentations

CHAPITRE 8

Simulations/évaluation de CLOAK / SEMOS

Sommaire 8.1 Introduction ...... 93 8.2 Évaluation des performances de CLOAK ...... 93 8.2.1 Outils et paramètres utilisés ...... 94 8.2.2 Résultats de simulation ...... 94 8.3 Évaluation de SEMOS ...... 96 8.3.1 Prototypage du système SEMOS ...... 96 8.3.2 Environnement d’expérimentation ...... 97 8.3.3 Résultats d’évaluation ...... 97 8.4 Conclusion ...... 99

8.1 Introduction

Dans ce chapitre, nous évaluons, par des simulations, les performances de notre modèle CLOAK définissant une table de hachage distribuée ; ces évaluations sont assorties d’une comparaison entre les performances induites par notre approche de DHT, basée sur les coordonnées virtuelles hyperboliques, et celles présentées par des autres systèmes DHT parmi les plus populaires et les plus performantes : Chord, Pastry et Kademlia. Les évaluations concernent en effet les performances portant, d’une part, sur les distances parcourues par les fonctionnalités GET (ou extraire) et PUT (ou stocker). D’autre part, les latences induites par ces opérations ainsi que le remous (appelé churn en anglais) sont également évaluées pour chacun des systèmes susmentionnés. Pour une gestion efficace des problèmes liés au remous qui sont inhérents aux systèmes autonomes et volatiles tels que les réseaux P2P, un mécanisme de réplication est nécessaire afin d’y faire face. Pour ce faire, l’infrastructure CLOAK propose une technique de réplication. Cependant, la description de cette méthode a déjà fait l’objet d’une thèse séparée [118]. Dans la deuxième phase de ce chapitre, nous procédons à l’évaluation du système SEMOS qui fournit des sessions virtuelles sécurisées et mobiles. Aussi, nous procédons à une évaluation comparative mettant en scène SEMOS avec quelques autres protocoles VPN mobiles, que sont nommément les protocoles MOBIKE, HIP et N2N.

8.2 Évaluation des performances de CLOAK

Les résultats présentés dans cette section proviennent des simulations réalisées avec le simulateur PeerSim [119].

93 94 8.2. ÉVALUATION DES PERFORMANCES DE CLOAK

8.2.1 Outils et paramètres utilisés Dans le but d’évaluer notre solution, nous avons implémenté l’adressage, le routage et les requêtes de notre DHT CLOAK. Nous avons de plus utilisé les implémentations existantes sur PeerSim de Chord, Kademlia et MSPastry et avons effectué les simulations avec les mêmes paramètres (e.g., durée de simulation, topologie des nœuds, durées des sessions des nœuds, etc.) afin de pouvoir comparer les résultats à ceux de CLOAK. Le code source de notre DHT CLOAK ainsi que tous les résultats de simulation sont disponible ici 1. Nous créons des réseaux recouvrants de taille initiale égale à 10 000 nœuds. Nous avons fixé le degré q de l’arbre d’adressage à 4 pour les simulations, conformément aux résultats aux travaux précédents [6] montrant que la longueur moyenne des chemins est plus courte pour q = 4 dans un contexte de simulation dynamique. Nous faisons varier le taux d’attrition ta entre 10 % et 60 % par intervalles de 10 % et nous cherchons à voir comment le système réagit face à ces perturbations. Chaque simulation dure deux heures et les mesures sont effectuées sur des périodes de 10 minutes. Cela signifie que toutes les 10 minutes ta % de nœuds quittent le réseau recouvrant et sont remplacés par des nouveaux nœuds suivant une loi de probabilité exponentielle. Les messages de stockage ainsi que ceux de recherche sont transmis à la fréquence de 1 000 par seconde. Chaque point de chaque graphique est la moyenne de 15 exécutions et l’écart type est donné.

8.2.2 Résultats de simulation Les résultats comparatifs entre Chord, CLOAK, Kademlia et MSPastry présentés dans cette section concernant le taux de succès des requêtes, la distance moyenne parcourue et la latence moyenne.

8.2.2.1 Taux de succès La ﬁgure 8.42 montre les taux de succès comparés des requêtes de recherche en fonction du taux d’attrition. Nous pouvons voir que tous les systèmes DHT s’exécutent de façon similaire avec un ratio de succès linéairement décroissant avec le taux d’attrition. CLOAK a le deuxième meilleur taux de succès, après MSPastry et suivi de près par Chord avec presque les mêmes valeurs pour des taux d’attrition compris entre 10 % et 30 %. Kademlia a le plus bas taux de succès. Comme les courbes pour les requêtes de stockage sont très similaire à celles de la résolution, nous ne les montrons pas pour éviter la redondance.

8.2.2.2 Distance La figure 8.43 montre les distances moyennes comparées des chemins mesurés en nombre de sauts des requêtes de recherche en fonction du remous. Ici encore, les systèmes DHT ont le même comportement avec une longueur de chemin (en sauts) faiblement décroissante lorsque le taux d’attrition augmente. MSPastry présente la plus courte longueur de chemin, suivi de CLOAK. Kademlia a en moyenne 0,6 saut de plus que MSPastry quel que soit le taux d’attrition, tandis que Chord a en moyenne une longueur du chemin supérieur de 1,2 pour MSPastry et de 1 pour CLOAK, bien que cette différence tende à décroître quand le taux remous est supérieur ou égal à 40 %. Les résultats pour les distances des requêtes de stockage montrés à la figure 8.44 sont très similaires à ceux des requêtes de recherche.

8.2.2.3 Latence La ﬁgure 8.45 montre les latences moyennes comparées des requêtes de recherche en fonction du taux d’attrition. Etant donné qu’un chemin mesuré en nombre de sauts ne ce traduit pas

1. http ://www.labri.fr/perso/magoni/cape CHAPITRE 8. SIMULATIONS/ÉVALUATION DE CLOAK / SEMOS 95

mmmP

mmchurn (%)

ﬁgure 8.42 – Taux de succès vs taux de remous selon la DHT utilisée

SSS KKK

KKchurn(%) SSchurn (%)

ﬁgure 8.43 – Distance parcourue par les ﬁgure 8.44 – Distance parcourue par les GET PUT 96 8.3. ÉVALUATION DE SEMOS

ii MM

MMchurn (%) iichurn (%)

figure 8.45 – Latence des GET figure 8.46 – Latence des PUT nécessairement par une latence élevée, nous avons mesuré cette dernière pour évaluer le temps pris par une requête pour arriver à destination. Tous les systèmes DHT ont presque la même latence à chaque taux d’attrition, excepté Kademlia qui a entre 200 ms et 280 ms de plus que les autres. Les résultats montrent en effet que malgré des distances supérieures, Chord s’exécute aussi rapidement que MSPastry et CLOAK lorsqu’on observe la latence. La figure 8.44 montre les latences moyennes comparées des requêtes de stockage en fonction du taux d’attrition. Les latences sont plus importantes que pour les requêtes de recherche car celles-ci doivent couvrir le temps nécessaire à la réplication. Là où une requête de recherche s’arrête dès le premier résultat trouvé, une requête doit se poursuivre pour être stockée sur tous les nœuds redondants nécessaires.

8.3 Évaluation de SEMOS

Afin d’évaluer les technologies VPN mobiles SEMOS, HIP, MOBIKE et N2N, nous utilisons l’outil d’émulation des réseaux virtuels appelé NEmu (de l’anglais Network Emulator for Mobile Universes ) présenté dans l’article [120]. NEmu est une application libre téléchargeable sur [121]. Comme précisé par Lochin et al. dans [122], l’émulation réseau, contrairement à la simulation d’un réseau, nous permet d’évaluer avec précision les métriques comme les délais tout en tenant comme de tous les aspects découlant de véritables piles réseau. NEmu est donc un émulateur permettant la création des hôtes virtualisés itinérants ou mobiles tels qu’attendus dans notre scénario. Les machines virtuelles qui s’exécutent au-dessus de QEMU tournent sous le système d’exploitation Debian 7. Les hôtes virtuels QEMU sont interconnectés par des commutateurs émulés par l’application VND (de l’anglais Virtual Network Device), disponible ici [123]. Afin d’émuler des hôtes mobiles ou itinérants, NEmu s’appuie en effet sur le module NEtwork MObilizer (nemo) de VND. nemo interagit avec NEmu en lui envoyant des ordres en temps réel afin d’émuler les changements de localisation (mobilité) opérés par des nœuds mobiles/itinérants. Lorsqu’un nœud mobile change de point d’attachement réseau à un instant donné, nemo instruit NEmu de créer, détruire ou changer les caractéristiques des liens pertinents au moment approprié.

8.3.1 Prototypage du système SEMOS L’API SEMOS est essentiellement codé en langage C. Les fonctionnalités liées à la sécurité utilisent les outils cryptographiques fournis par la boîte à outils OpenSSL [124], notamment ceux contenus dans sa bibliothèque libcrypto. L’intégrité du traﬁc est assurée à l’aide de l’algorithme cryptographique HMAC-SHA1 tandis que sa conﬁdentialité est garantie par l’implémentation CHAPITRE 8. SIMULATIONS/ÉVALUATION DE CLOAK / SEMOS 97

de l’algorithme AES fournie par OpenSSL. En outre, le prototype SEMOS assure la gestion de redirection de port (proxy) à l’aide de l’outil TCP appelé socat [125].

8.3.2 Environnement d’expérimentation L’expérimentation de SEMOS est résalisée dans l’environnement mobile décrit précédemment ; un nœud mobile évoluant dans cet environnement a la faculté de changer perpétuellement de réseau. Le changement de réseau opéré par un nœud mobile consiste pour celui-ci de quitter un réseau (un routeur virtuel) sur lequel il est connecté et de rejoindre un autre réseau (un autre routeur virtuel). Ce changement de réseau provoque une interruption temporaire de la session en cours jusqu’au rétablissement subséquent de la connexion. Cette interrupton de connexion est transparente aux processus applicatifs et n’empêche point l’intergiciel SEMOS de continuer à s’exécuter en dépit du fait que le nœud mobile soit injoignable momentanément.

Dave Bob R3 R5

Alice R1 Carol Changement d’emplacement

Eve R2 R4 Bob

ﬁgure 8.47 – Un scénario de changement du point d’attachement réseau

Techniquement, dans notre expérimentation illustrée par la figure 8.47, la mobilité d’un nœud consiste à créer une panne artificielle sur l’interface virtuelle qui le connecte sur un routeur virtuel puis une nouvelle connexion est ensuite établie entre le nœud mobile et un autre routeur virtuel après un temps ∆t. La figure 8.47 représente un scénario de changement du point d’attachement réseau dans lequel le nœud mobile Bob, tout étant en communication avec Alice via le routeur R4, bascule sur un autre routeur R5 du réseau virtuel et inversement. Cependant, cet évèment est totalement transparent aux applications s’exécutant au-dessus des nœuds Alice et Bob. Subséquemment Bob recontacte Alice et la session qui s’est précédemment intérrompue est restaurée.

8.3.3 Résultats d’évaluation Nous avons utilisé une application FTP minimaliste basée sur la version OpenBSD de nc [126] afin d’évaluer les solutions VPN mobiles considérées. Le tableau 8.14 fournit les résultats moyens de dix (10) exécutions menées sur chaque système VPN mobile expérimenté. La durée ∆t, mise entre une déconnexion et une reconnexion ultérieure, représentée dans la deuxième colonne, est assignée à un paramètre du réseau virtuel NEmu. Ensuite, la troisième colonne montre la latence moyenne due à la reprise effective de session sécurisée intérrompue. Enfin, la dernière colonne représente la latence maximale induite par les systèmes VPN mobiles évalués lors de la reprise de session. Il faut aussi préciser que les expérimentations menées sur ces différents systèmes n’ont engendré aucune perte de données consécutive à la mobilité d’une entité communicante. En outre, le tableau 8.13 dresse un comparatif technique des autres caractéristiques constatées lors des expérimentations. 98 8.3. ÉVALUATION DE SEMOS

N2N HIP 1600 1600

1400 1400

1200 1200 latence latence 1000 1000

800 800

600 600 Débit (Octet / s) Débit (Octet / s) changement d’emplacement changement d’emplacement 400 400

200 200

0 0 0 20 40 60 80 100 120 140 0 20 40 60 80 100 120 140 Temps (seconde) Temps (seconde)

ﬁgure 8.48 – N2N : latence de reprise. ﬁgure 8.49 – HIP : latence de reprise.

MOBIKE SEMOS 1600 1600

1400 1400

1200 1200 latence latence 1000 1000

800 800

600 600 Débit (Octet / s) Débit (Octet / s) changement d’emplacement changement d’emplacement 400 400

200 200

0 0 0 20 40 60 80 100 120 140 0 20 40 60 80 100 120 140 Temps (seconde) Temps (seconde)

ﬁgure 8.50 – MOBIKE : latence de reprise. ﬁgure 8.51 – SEMOS : latence de reprise

Les figures 8.48 à 8.51 montrent l’évolution des courbes représentant la communication entre deux correspondants, ponctuée par une mobilité, par rapport au temps ; chaque point de chaque courbe représente la moyenne de dix (10) exécutions du système considéré conformément au scénario décrit précédemment. Pour tous les systèmes évalués, le changement du point d’attachement réseau se produit à la 40ième seconde après le début de communication et se termine à la 60ième seconde (60 s) : durant l’intervalle [40 s, 60 s[, la courbe représentant la communication retome donc à zéro. ième Cela veut dire que ∆t = 20 s et la connectivité est restaurée à la 60 seconde. Cependant, en raison de la latence, les courbes restent à zéro après cette date et ce, durant quelques fractions de secondes jusqu’à la reprise effective de session. Cette latence peut donc varier d’un système à un autre. En effet, alors que la latence engendrée par l’intergiciel SEMOS est de 4 secondes en moyenne (voir la figure 8.51), les protocoles MOBIKE, HIP et N2N possèdent respectivement des latences moyennes de 12 secondes (voir figure 8.50), 51 secondes (voir figure 8.49 et 13 secondes (voir la figure 8.48). La latence relativement faible de SEMOS s’explique par le fait que ce système est évalué séparement, sans une intégration effective dans l’infrastructure CLOAK qui, lui, est évalué dans un simulateur séparé. Dès lors, il est donc évident de constater que les traitements relatifs au système sous-jacent ne sont pas pris en compte dans le calcul de la latence. CHAPITRE 8. SIMULATIONS/ÉVALUATION DE CLOAK / SEMOS 99

tableau 8.13 – Comparaison des systèmes VPN mobiles évalués

Systèmes VPN mobiles Caractéristiques MOBIKE N2N HIP SEMOS Échange de connexion / proto. 8 / UDP 3 / UDP 3 / UDP 2 / −a Échange de reprise / proto. 6 / UDP 3 / UDP 3 / UDP 2 / − b c Mode de connexion sécurisée indirect triangulaire direct√ direct √ Mobilité d’extrémités du tunnel limitée d limitée d Implémentation logicielle StrongSwan[127] N2N[128] OpenHIP[129] SEMOS a Indépendant de la connexion sous-jacente reliant deux voisins, celle-ci peut donc être TCP et/ou UDP. b Une passerelle MOBIKE est requise pour l’échange entre un nœud mobile et son correspondant. c Une connexion de deux extrémités sur le Super Node est nécessaire avant la connexion entre celles-ci. d Seul le client (ou le Edge Node dans le cas du système N2N) peut être mobile.

tableau 8.14 – Résultats d’évaluation des systèmes VPN mobiles

a VPN Mobile ∆t Latence moyenne Latence maximale HIP 20 s 16 s 21 s MOBIKE 20 s 13 s 19 s N2N 20 s 49 s 92 s SEMOS 20 s 4 s 11s a Durée entre la déconnexion et la reconnexion sur un autre routeur virtuel

8.4 Conclusion

Fournir un service d’annuaire DHT aux applications distribuées est une tâche difficile. Grâce à ses propriétés de tessellation, le plan hyperbolique au travers du modèle du disque de Poincaré est adéquat pour attribuer des coordonnées virtuelles aux nœuds participant à un réseau recouvrant. Nous avons montré conjointement dans ce chapitre et dans la partie II qu’en définissant une fonction de correspondance appropriée, il est facile de construire et de maintenir une DHT sur un tel réseau. Nous avons proposé un système DHT nommé CLOAK qui est capable de passer à l’échelle tout en restant fiable face aux remous. Nos résultats de simulation ont confirmé notre analyse et ont montré que le taux de succès, le nombre de sauts et la latence des requêtes de recherche et de stockage sont similaires à ceux de Chord, MSPastry et Kademlia qui sont trois systèmes DHT très populaires. L’avantage clé de notre solution est qu’elle requiert un coût mémoire indépendant de la taille du réseau recouvrant car elle ne nécessite pas dans chaque nœud le maintien d’une table de routage mais seulement le maintien d’une liste des voisins. Cette liste est en général de très petite taille, en particulier dans les réseaux de type petit-monde. Un autre avantage de notre solution est que les nœuds peuvent se connecter librement les uns aux autres, tandis que dans les autres systèmes DHT tels que Chord, les nœuds doivent s’insérer dans la DHT en se connectant à d’autres nœuds prédéterminés en fonction de leurs adresses IP. Etant donné ces deux avantages, et ayant des performances identiques par ailleurs, nous pensons que notre DHT peut être une alternative supérieure aux DHT existantes. Les expérimentations menées sur les différents systèmes VPN mobiles considérés montrent que l’intergiciel SEMOS présente des caractéristiques intéressantes proches de celles fournies par le protocole HIP, en dehors notamment du fait que la communication sous SEMOS est indépendante d’un protocole particulier du niveau transport. En outre, contrairement au protocole HIP qui 100 8.4. CONCLUSION

s’appuie sur un mécanisme de rendezvous favorisé par l’utilisation des serveurs spéciaux ou de N2N qui utilise des Super Nodes, le système SEMOS, basé sur une infrastructure DHT appelée CLOAK qui oﬀre une technique de nommage, est totalement distribué. Aussi, il faut noter que SEMOS permet, à l’opposé des systèmes VPN mobiles comme MOBIKE, d’avoir une mobilité accrue de deux extrémités d’un tunnel. CHAPITRE 9

Simulations du modèle d’échange de clés

Sommaire 9.1 Introduction ...... 101 9.2 Outils et paramètres ...... 102 9.2.1 Étapes du processus d’échange de clés ...... 102 9.2.2 Cartographie des réseaux virtuels utilisés ...... 103 9.2.3 Diﬀérentes politiques du routage ...... 103 9.3 Résultats des simulations ...... 104 9.3.1 Simulations par nature de réseau ...... 104 9.3.2 Simulations par taille de réseau ...... 104 9.3.3 Impact du nombre de chemins disjoints sur l’échange de clés . . . 105 9.3.4 Interception des chemins disjoints ...... 106 9.3.5 Simulations par type de routage ...... 108 9.3.6 Nombre de sauts et longueur moyenne de transmission ...... 109 9.3.7 Distribution de probabilités par rapport au nombre de chemins . 110 9.4 Écart-type des taux de réussite ...... 111 9.5 Récapitulatif des résultats ...... 112 9.6 Conclusion ...... 112

9.1 Introduction

Dans ce chapitre, nous présentons et analysons les résultats issus de nos expérimentations portant sur notre approche de gestion des clés cryptographiques ; aussi, ces résultats ont-ils permis d’avoir une appréciation précise des taux de succès relatifs aux échanges de clés effectués entre des nœuds correspondants à travers des réseaux virtuels. Afin d’évaluer notre mécanisme d’échange de clés, nous procédons à diverses évaluations menées sur plusieurs types de réseau ; les réseaux virtuels utilisés tournent sous différents protocoles. En outre, pour chaque expérimentation, nous faisons varier le nombre de nœuds qui composent aléatoirement les différents réseaux virtuels ; la taille d’un réseau peut prendre l’une des valeurs suivantes : 2 500, 5 000, 10 000 ou 20 000 pairs. Les topologies de réseaux virtuels employés dans les expérimentations sont aléatoirement générées ; l’organisation aléatoire des réseaux virtuels est favorisée par l’utilisation de quelques protocoles de génération des graphes aléatoires tels que l’algorithme Erdős-Rényi [27] et Magoni- Pansiot (MP) [26]. Aussi, des réseaux virtuels dont les topologies sont basées sur une cartographie de l’Internet sont employés dans le cadre de ces mêmes expérimentations. Par ailleurs, dans chaque expérimentation, une proportion d’attaquants coordonnés est choisie dans le réseau ; plusieurs

101 102 9.2. OUTILS ET PARAMÈTRES

scénarios sont alors considérés allant des plus extrêmes aux plus raisonnables.

9.2 Outils et paramètres

Afin d’évaluer notre approche d’échange des clés multi-chemin et ses aptitudes à réduire les risques d’attaques, nous utilisons le simulateur nem 1. Utilisé comme un simulateur statique qui contient une paire de nœuds (s, t) et des nœuds intermédiaires situés le long des chemins reliant s et t, nem nous permet de créer des topologies diverses, mais conformes à quelques protocoles spécifiques, qui peuvent contenir des dizaines de milliers de nœuds. Dans nos expérimentations, les différents paramètres utilisés peuvent varier (sont des variables). Il peut en effet s’agir de la topologie du réseau, de la taille du réseau, de la proportion des nœuds du réseau considérés comme compromis, etc. Chaque expérience suit une suite d’étapes et est réalisée selon une configuration conforme aux caractéristiques réelles des protocoles réseaux utilisés tels que le protocole BGP4 [130] ou MP [26].

9.2.1 Étapes du processus d’échange de clés Nous présentons succinctement les étapes successives qui doivent être réalisées dans le cadre des simulations de notre modèle d’échange de clés : 1. Définition d’un réseau virtuel : un réseau P2P est premièrement créé. Dans cette étape, le type de la topologie est aléatoirement choisi (graphes de Waxman [131], modèle de Erdős-Rényi (ER) [27], topologie analogue à celle de l’Internet, etc.) ainsi que la taille du réseau, l’ensemble de nœuds V . 2. Élection des nœuds malveillants : Dans cette seconde phase, un sous-ensemble Vb ⊂ V de nœuds du réseau constitué de X % des nœuds qui agissent comme des attaquants est choisi ; ces nœuds malveillants forment un groupe au sein duquel les attaques menées sont coordonnées. 3. Sélection de deux correspondants s et t : Deux nœuds {s, t} ⊂ V , tels que {s, t} ( Vb (i.e, les deux nœuds ne sont pas compromis), sont aléatoirement choisis comme une paire des nœuds correspondants. 4. Échange de sous-clés : La transmission des sous-clés s’effectue à travers des chemins les plus courts reliant s et t ; tous les nœuds intermédiaires utilisés dans construction d’un chemin sont marqués et ne doivent être utilisés qu’une seule fois dans la détermination des chemins une même paire de nœuds s et t. Le nœud destinataire t accuse réception de chaque paquet transportant une sous-clé par un message du même type. 5. Détection d’attaque : Au terme d’un échange des sous-clés, les nœuds correspondants s’échangent des messages pour vérifier s’ils disposent bien d’une même clé déterminée à partir des sous-clés reçues. Si cette vérification n’est pas couronnée de succès, alors l’échange est considéré comme un échec. 6. Chemins alternatifs : À cette phase, le processus recommence à partir de l’étape 4 avec quasiment les mêmes paramètres mais en utilisant un chemin séparé afin d’atteindre le nœud destinataire.

(a) Si au cours de la recherche d’un nouveau chemin le paquet arrive à une étape où il ne peut plus progresser vers le nœud t, le paquet retourne sur ses traces et la recherche recommence à partir du dernier déjà visité. Si cette dernière recherche est infructueuse, la recherche recommence alors à partir de l’avant-dernier nœud, et ainsi de suite.

1. http://www.labri.fr/perso/magoni/nem/ CHAPITRE 9. SIMULATIONS DU MODÈLE D’ÉCHANGE DE CLÉS 103

(b) Si le processus du retour sur trace se poursuit jusqu’à atteindre le nœud source s, on en conclut alors qu’il n’existe pas d’autres chemins disjoints sur le réseau recouvrant reliant s et t. (c) La recherche des chemins s’arrête également lorsque tous les nœuds adjacents au nœud source s sont marqués comme visités. Aussi, il faut préciser que nous limitons, dans nos expérimentations, le nombre maximun des chemins disjoints entre deux nœuds correspondants s et t à 10.

7. changement des nœuds s et t : Lorsque deux nouveaux nœuds correspondants sont choisis, alors le processus est répété à partir de l’étape 3. 8. Changement de proportion des nœuds malveillants : Pour ce cas, le processus recommence à partir de l’étape 2 avec un ensembe de nœuds malveillants Vb rafraîchi ; il s’agit typiquement de changer le pourcentage des attaquants sur le réseau. 9. Changement de conﬁguration réseau : Le processus recommence à partir de l’étape 1 avec une nouvelle topologie et/ou une nouvelle valeur du nombre des nœuds constituant le réseau recouvrant.

9.2.2 Cartographie des réseaux virtuels utilisés Dans nos paramètres d’expérimentation, nous utilisons des cartes de réseaux obtenues à l’aide des mesures effectuées sur Internet. Nous utilisons en particulières une cartographie partielle de IPv4 réalisée en 2004 et qui renferme environ 12 000 nœuds. Aussi, nos simulations sont effectuées sur une cartographie réseau basée sur le protocole BGP4[130] et qui est cartographié en 2010 ; cette cartographie porte sur environ 20 000 nœuds. En outre, les modèles de génération aléatoire des topologies utilisés sont Erdős-Rényi [27] (avec liens = 5 × nœuds et la probabilité p = 0, 5), qui génère des graphes aléatoires avec une probabilité fixe pour chaque lien, et Magoni-Pansiot (MP) [26], qui genère des graphes selon la loi de la puissance. Les expérimentations portent sur quatre différentes tailles des graphes aléatoires pour chaque type de topologie. Pour chaque carte, seule la partie maillée est conservée de la topologie (la partie arborescente est enlevée). Ensuite, chaque scénario est soumis à 100 exécutions (i.e, avec à chaque fois un repositionnement des attaquants sur de nouveaux emplacements) et chaque exécution teste 1 000 couples s-t aléatoires, donc 100 000 paires s-t sont utilisées à chaque scénario. Enfin, il faut noter que les attaquants pré-partagent une clé secrète afin de chiffrer leur échange à travers le réseau.

9.2.3 Différentes politiques du routage Dans les expérimentations menées, nous distinguons principalement trois types de politique de routage appliqués sur l’acheminement multi-chemin des sous-clés : 1. flexible. Le routage flexible est une politique de routage qui consiste, lorsque le routage glouton se solde par un échec, à router le paquet par une méthode de contournement du minimum local, c’est à dire en empruntant le deuxième plus court chemin peu importe sa distance finale en termes de nombre de sauts ; 2. plafonné ou borné. Le routage borné est une politique de routage qui consiste, lorsque le routage glouton se solde par un échec, à router le paquet par une méthode de contournement du minimum local, c’est à dire en empruntant le deuxième plus court chemin tout en fixant une distance maximale pour ce chemin en termes de nombre de sauts ; 3. strict. Le routage strict est un algorithme de routage qui considère que le paquet est perdu dès lors que le routage glouton échoue à cause de la présence d’un minimun local dans le chemin emprunté. 104 9.3. RÉSULTATS DES SIMULATIONS

9.3 Résultats des simulations

Dans cette section, nous étudions les résultats d’évaluation produits par diverses simulations de notre approche d’échange de clés. Comme énoncé ci-dessus dans les étapes suivies par chaque expérimentation, nous analysons l’impact de chaque paramètre utilisé dans le processus d’échange de clés dans les réseaux P2P.

9.3.1 Simulations par nature de réseau Le type de tolopogie et/ou la nature d’un système P2P sont des paramètres cruciaux qui peuvent conditionner ses métriques, et donc impacter mécaniquement sur les performances qui en découlent. En raison de son caractère générique, notre approche d’échange de clés est indépendant du réseau P2P sous-jacent. Cette propriété est d’autant plus importante que notre infrastructure d’adressage et de routage, qui est basée sur les coordonnées virtuelles prises sur le plan hyperbolique, ne s’appuie sur aucune topologie particulière. Cependant, il en ressort de nos expérimentations que la nature d’un réseau utilisé dans la simulation de notre protocole de gestion des clés peut influencer le taux de succès lié aux échanges de clés. Les paramètres utilisés sont : 5 chemins disjoints, une distance maximale de 64 sauts par paquet et un réseau P2P constitué de 20 000 nœuds. La figure 9.52 montre une distribution des taux de succès engrangés par chaque type de réseau dans les échanges de clés par rapport à la proportion des attaquants coordonnés présents dans le réseau. Lorsqu’il y a environ 1 % d’attaquants, les taux de réussite avoisinent le 100 % pour chaque réseau, à l’exception de celui ayant une topologie en anneau dont le taux de succès moyen est 0.53 %. Ce taux de succès démontre, s’il en est encore besoin, que la topologie circulaire est structurellement inadéquate aux échanges multi-chemi. Aussi, les taux de succès chutent-ils progressivement à mesure que la proportion d’attaquants augemente dans le réseau. Ainsi, lorsqu’il y a 30 % ou 60 % de nœuds malveillants coordonnés, les taux de succès sont respectivement inférieurs à 30 % et à 10 % pour tout type de réseau évalué. À ce stade d’infection, les échanges peuvent être considérés comme incertains. En outre, alors que les autres réseaux présentent des performances similaires, hormis le réseau en anneau, la topologie construite à l’aide l’algorithme Erdős-Rényi offre des performances légèrement élevées.

L’approche d’échange de clés proposée est compatible avec diverses natures de réseau comme le montre nos expérimentations ; dans un réseau infesté par des nœuds malveillants coopératifs, nous atteignons un taux de succès relativement élevé. Le réseau basé sur une topologie en anneau présente cependant un taux de succès très médiocre.

9.3.2 Simulations par taille de réseau Nous analysons, dans cette sous-section, les performances des réseaux en faisant varier leur taille (2 500 nœuds, 5 000 nœuds, 10 000 nœuds et 20 000 nœuds). Les figures figures 9.53, 9.55 et 9.54, qui représentent les expérimentations menées respectivement sur les réseaux MP, ER et un réseaux en anneau, montrent qu’il existe une corrélation évidente entre les tailles de réseaux et les taux de succès pour toutes les proportions d’attaquants considérées. Le nombre d’attaquant est en effet choisi proportionnellement à la taille du réseau, ce qui se traduit par les allures que prennent ces courbes : plus la taille du réseau est grande, plus le nombre d’attaquants est élevé et moins il y a de succès dans les échanges de clé. Les résultats présentés dans la figure 9.56, portant sur un réseau ER dont le nombre de sauts est limité à 64, corroborent cette assertion. Cependant, le réseau MP déroge à la règle et la figure 9.53, qui représente ses évaluations, montre que la variation de taille du réseau n’a pas d’impact significatif sur lui-ci, puisque les différentes courbes s’intersectent pratiquement, contrairement aux deux résaux précédemment cités et représentés par les figures 9.55 et 9.54. CHAPITRE 9. SIMULATIONS DU MODÈLE D’ÉCHANGE DE CLÉS 105

100 topologie ER topologie MP topologie en anneau IP BGP4 80

40 % échanges de clés réussis

0 0.5 1 2 4 8 16 32 64 % attaquants

ﬁgure 9.52 – Taux de réussite en focntion de taux d’attaquants pour diﬀérents types de réseau ayant chacun 20 000 nœuds

Les résultats d’évaluation obtenus sur la topologie en anneau, représentés par la ﬁgure 9.55, montrent que la variation de taille du réseau a une répercussion sur les taux de succès : plus la taille du réseau est faible, plus les taux de résussite sont élevés. Ceci conﬁrme une fois de plus la vulnérabilité des mécanismes multi-chemin d’échanges de clés basés sur la topologie en anneau.

La taille du réseau peut avoir ou non de l’impact sur les taux de réussite d’échanges de clés selon la nature du réseau considéré. Dans la topologie en anneau, l’impact dû à la variation de taille du réseau est plus marqué.

9.3.3 Impact du nombre de chemins disjoints sur l’échange de clés

Dans notre approche, la fiabilité dans l’échange des clés entre deux nœuds d’un réseau dépend largement du nombre de chemins disjoints utilisés dans la transmission des sous-clés. En d’autres termes, le nombre moyen de chemins disjoints qui peuvent être trouvés entre une paire de nœuds communicants conditionne la robustesse de la méthode. Ainsi, la figure 9.57, qui présente les résultats d’une évaluation conduite sur un réseau ER formé par 20 000 nœuds, montre la distribution de taux de réussite par rapport au nombre des nœuds malveillants coordonnés présents dans le réseau. Dans cette expérimentation, nous faisons varier le nombre de chemins disjoints entre 1 et 10 tout en conservant à chaque fois les mêmes proportions du nombre d’attaquants. Nous constatons que plus le nombre de chemins disjoints est élevé, moins les attaques coordonnées réussissent ; lorsque le nombre de chemins disjoints est supérieur ou égal 3, les taux s’élevent à plus de 80 % pour une proportion d’attaquants allant jusqu’à 10 %. Plus intéressant encore, lorsque nous avons environ 3 % d’attaquants dans le réseau, qui est une proportion raisonnable au regard de la difficulté liée à la mise en œuvre d’une attaque coordonnée, les taux de succès atteignent 100 % pour un nombre de chemins supérieur ou égal à 4. 106 9.3. RÉSULTATS DES SIMULATIONS

100 100 2,5k pairs 2,5k pairs 5k pairs 5k pairs 10k pairs 10k pairs 20k pairs 20k pairs 80 80

60 60

40 40

20 20 % échanges de clés réussis % échanges de clés réussis

0 0 0.5 1 2 4 8 16 32 64 0.5 1 2 4 8 16 32 64 % attaquants % attaquants

ﬁgure 9.53 – Taux de réussite vs tailles du ﬁgure 9.54 – Taux de réussite vs tailles du réseau pour la carte MP réseau pour la carte ER

100 100 taux de réussite inférieur à 50 % 2,5k pairs taux de réussite entre 50 et 60 % 5k pairs 90 taux de éussite supérieur à 60 % 10k pairs 20k pairs 80 80 70

60 60 50

40 40 30

20 20 % échanges de clés réussis 10 moyenne d’échanges de clés réussis (%) 0 0 2,5K 5K 10K 20K 0.5 1 2 4 8 16 32 64 taille du réseau % attaquants

ﬁgure 9.56 – Variation des taux de réussite ﬁgure 9.55 – Taux de réussite vs tailles du d’échange de clés par aux tailles de réseau pour une topologie en anneau réseaux : cas du réseau ER borné à 64 sauts

Un nombre raisonnablement élevé du nombre de chemins disjoints impacte positivement sur le taux de succès d’échange de clés. Il est certes diﬃcile de trouver beaucoup de chemins disjoints dans un réseau de type petit-monde mais un nombre relativement petit de chemins disjoints permet d’avoir un taux de succès élevé dans l’échange de clés.

9.3.4 Interception des chemins disjoints Les figures 9.58 et 9.59 mettent en évidence à la fois le nombre moyen de chemins disjoints trouvés et le nombre moyen de chemins disjoints interceptés sur le réseau ER contenant 20 000 nœuds. La figure 9.58 montre que, lorsqu’il existe une proportion de 5.0 %, 6 d’environ 8 chemins disjoints sont interceptés. Cependant, la dispersion des attaquants sur le réseau fait que les chemins disjoints ne sont entièrement infestés qu’avec une proportion de 64 % d’attaquants, ce qui est indéniablement un scénario extrême. La figure 9.59 montre les résultats d’expérimentation menée sur un réseau IP, c’est à dire un réseau construit à l’image des traces récoltées sur Internet en 2004. Dans ce type de réseau, le CHAPITRE 9. SIMULATIONS DU MODÈLE D’ÉCHANGE DE CLÉS 107

100 10 chemins 9 chemins 8 chemins 7 chemins 6 chemins 80 5 chemins 4 chemins 3 chemins 2 chemins 1 chemin

40 % échanges de clés réussis

0 0.5 1 2 4 8 16 32 64 % attaquants

ﬁgure 9.57 – Taux d’échanges de clés réussis par nombre de chemins disjoints par rapport au pourcentage d’attaquants coordonnés présents dans le réseau recouvrant nombre de chemins disjoints est relativement petit. L’interception complète des chemins disjoints ne se produit cependant qu’avec une proportion supérieure à 64 % d’attaquants, comme le montre la courbe tracée en rouge dans la ﬁgure 9.59.

9 4 chemins disjoints chemins disjoints chemins disjoints interceptés chemins disjoints interceptés 8 3.5 7 3 6 2.5 5 2 4 1.5 3 1 2

1 nombre moyen de chemins disjoints 0.5 nombre moyen de chemins disjoints

0 0 0.5 1 2 4 8 16 32 64 0.5 1 2 4 8 16 32 64 % attaquants % attaquants

ﬁgure 9.58 – Nombre de chemins disjoints ﬁgure 9.59 – Nombre de chemins disjoints & nombre de chemins interceptés dans le & nombre de chemins interceptés dans le réseau ER contenant 20 000 nœuds réseau IP contenant 20 000 nœuds 108 9.3. RÉSULTATS DES SIMULATIONS

Les résultats d’évaluation présentés dans les ﬁgures 9.58 et 9.59 prouvent une fois encore que l’utilisation des chemins disjoints peut être considérée comme un gage de robustesse contre les attaques ; beaucoup de chemins peuvent être interceptés par une petite proportion d’attaquants mais il reste souvent d’autres chemins qui échappent à leurs emprises.

9.3.5 Simulations par type de routage Comme nous l’avons décrit au début du chapitre, les modes de routage utilisés sont : flexible, borné ou plafonné et strict. La figure 9.60 montre le cas de l’algorithme de routage borné et compare les deux courbes dont l’une correspond au cas où la borne est fixée à 64 sauts et l’autre au cas où la limitation est plafonnée à 200 sauts. Il en ressort de cette compraison que la première courbe est toujours au-dessus de la deuxième. En effet, lorsque la borne est relativement faible, les acheminements effectués sur des distances relativement longues n’aboutissent pas. La figure 9.62 met en évidence une comparaison expérimentale entre les trois types d’algorithme de routage proposés ; cette expérimentation est menée sur un réseau ER composé de 20 000 nœuds. Comme attendu et indiqué précédemment, la courbe représentant l’algorithme de routage flexible se situe toujours au-dessus de celles des autres techniques de routage quelque soit la distribution des attaquants (de 0.5 % à 64 %). Les figures 9.61, 9.64 et 9.64 représentent les résultats des expérimentations issus respectivement des algorithmes de routage strict, flexible et borné menées sur différents types de routage ; chaque réseau virtuel utilisé se compose 20 000 nœuds et se structure selon une topologie aléatoire.

100 ER−plafonné200 ER−plafonné64

40 % échanges de clés réussis

0 0.5 1 2 4 8 16 32 64 % attaquants

ﬁgure 9.60 – Comparaison de deux échanges dont l’un est limité à 64 sauts et l’autre à 200 sauts : cas de 2 500 nœuds

Les résultats de ces évaluations montrent que pour chacune d’expérimentations, les courbes du réseau IP, basé sur le protocole BGP4, caracolent en tête en termes de taux réussite et sont suivies, par ordre, par les courbes du réseau IP, c’est à dire un réseau virtuel créé à l’image d’Internet, celles du réseau ER et enﬁn celles du réseau MP. Il faut ainsi noter donc que la nature de l’algorithme de routage n’impacte pas signiﬁcativement sur ce classement. CHAPITRE 9. SIMULATIONS DU MODÈLE D’ÉCHANGE DE CLÉS 109

100 100 MP−flexible ER−plafonné ER−flexible ER−flexible BGP4−flexible ER−strict IP−flexible 80 80

60 60

40 40 % échanges de clés réussis % échanges de clés réussis 20 20

0 0 0.5 1 2 4 8 16 32 64 0.5 1 2 4 8 16 32 64 % attaquants % attaquants

figure 9.61 – Comparaison du routage figure 9.62 – Comparaison de différents flexible effectuée sur différents réseaux algorithmes de routage sur le réseau ER

100 100 MP−plafonné200 MP−strict ER−plafonné200 ER−strict BGP4−plafonné200 BGP4−strict IP−plafonné200 IP−strict 80 80

60 60

40 40

% échanges de clés réussis 20 % échanges de clés réussis 20

0 0 0.5 1 2 4 8 16 32 64 0.5 1 2 4 8 16 32 64 % attaquants % attaquants

figure 9.63 – Comparaison du routage figure 9.64 – Comparaison du routage strict borné effectuée sur différents réseaux effectuée sur différents réseaux

9.3.6 Nombre de sauts et longueur moyenne de transmission

Les figures 9.65 et 9.66 présentent la longueur moyenne de transmission (points rouges) et la valeur du 90ième percentile (centile) de la longueur des chemins, en d’autres termes pour cette longueur donnée, 90 % des autres longueurs sont inférieures (points bleus). La figure 9.65 représente la longueur moyenne et le 90ième percentile de l’algorithme du routage strict. La longueur moyenne, c’est à dire le nombre moyen de sauts, varie entre 7.42 et 8.57 tandis que la valeur de 90ième percentile va de 8.51 à 11.87. La figure 9.66 porte sur les résultats d’expérimentations menées à l’aide de l’algorithme de routage borné.

Dans le routage strict, la valeur de 90ième percentile et la longueur moyenne se confondent pratiquement lorsque le nombre de chemins disjoints est égal à 10. Cependant, dans les deux autres algorithmes de routage, où le nombre de sauts est relativement élevé, la valeur de 90ième et la longueur ne se croisent pas dans une distribution de 10 chemins disjoints. 110 9.3. RÉSULTATS DES SIMULATIONS

14 180 90e percentile 90e percentile longueur moyenne longueur moyenne 160 12 140 10 120

8 100

6 80

Nombre de sauts Nombre de sauts 60 4 40 2 20

0 0 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 Nombre de chemins disjoints Nombre de chemins disjoints

ﬁgure 9.65 – Distribution de 90e percentile ﬁgure 9.66 – Distribution de 90e percentile et de la longueur moyenne des chemins : et de la longueur moyenne des chemins : cas du réseau ER composé de 20 000 cas du réseau ER composé de 20 000 nœuds, routage strict nœuds, routage borné

9.3.7 Distribution de probabilités par rapport au nombre de chemins Dans notre contexte, la CCDF (de l’anglais Complementary Cumulative Distribution Function) ou Fonction de Distribution Cumulative Complémentaire est une fonction qui à tout nombre de chemins disjoints cumulé associe une probabilité. La figure 9.67 décrit les CCDF de différents algorithmes de routage appliqués sur le réseau MP. Le protocole de routage flexible, dont le résultat est représenté en rouge dans cette figure, présente une distribution de probabilités, par rapport au nombre de chemins disjoints, les plus élevées comparées à celles présentées par les deux autres algorithmes de routage. En outre, l’algorithme de routage flexible est d’autant plus intéressant que la probabilité d’en avoir deux chemins disjoints entre deux nœuds correspondants non adjacents s’élève à 87, 6640 %. La figure 9.68 montre les CCDF de différents types de réseau constitués chacun de 20 000 nœuds ; la probabilité d’avoir cinq (05) chemins disjoints est relativement haute pour quatre de cinq réseaux évalués. Cependant, dans un réseau structuré en anneau, la probabilité d’avoir plus de deux (02) chemins disjoints est nulle tandis que la probabilité d’avoir sept (07) chemins disjoints est proche de 100 % dans un réseau formé à l’aide de l’algorithme ER.

Ces résultats d’évaluation montrent que les réseaux ayant une topologie circulaire ne peuvent avoir plus de deux chemins disjoints ; il suﬃt donc la présence de deux attaquants coordonnées dans le réseau pour compromettre dangereusement la communication sécurisée. Cependant, les autres types de réseau possèdent une probabilité relativement intéressante d’existence de trois chemins disjoints. CHAPITRE 9. SIMULATIONS DU MODÈLE D’ÉCHANGE DE CLÉS 111

1 1 MP−CCDF−borné CCDF-BGP4 MP−CCDF−strict CCDF-ER MP−CCDF−flexible CCDF-IP CCDF-MP CCDF-anneau

0.1 0.1 CCDF CCDF

0.01 0.01

0.001 0.001 1 2 3 4 5 6 7 8 9 10 1 2 3 4 5 6 7 8 9 10 Nombre de chemins disjoints Nombre de chemins disjoints

figure 9.67 – Réseau MP composé de 20000 figure 9.68 – CCDF de différents réseaux nœuds : CCDF de différents algorithmes de évalués : chaque réseau est composé de routage 20000 nœuds

100 BGP4: ecart-type

% echanges de cles reussis 20

0 0.5 1 2 4 8 16 32 64 % attaquants

ﬁgure 9.69 – Écart-types des taux de réussite des échanges de clés sur un réseau tournant sous le protocole BGP4

9.4 Écart-type des taux de réussite

Dans les résultats d’expérimentations donnés précédemment dans ce chapitre qui traite le mécanisme d’échange de clés basé sur les chemins disjoints, les évaluations présentées constituent des moyennes de dix (10) exécutions. C’est pourquoi, la ﬁgure 9.69 founit une distribution des écart-types de taux de réussite par rapport aux proportions d’attaquants présents dans le réseau virtuel ; ces résultats portent essentiellement sur un réseau virtuel tournant sous le protocole BGP4 et est constitué de 20 000 nœuds ; la topologie considérée est aléatoire. 112 9.5. RÉCAPITULATIF DES RÉSULTATS

9.5 Récapitulatif des résultats

Le tableau 9.15 dresse un comparatif synthétique des résultats issus de nos expérimentations menées dans l’environnement nem ; ces résultats portent sur les différents types d’algorithme de routage utilisés dans de différentes natures de réseau. Il en ressort clairement que le réseau basé sur le protocole BGP4 possède les taux de réussite, dans les échanges de clé, les plus élevés quelque soit le type de l’algorithme de routage qui lui est appliqué. Dans cette configuration, en moyenne, environ 70 % des échanges de clés sont couronnés de succès pour une proportion d’environ 18 % d’attaquants coordonnés présents dans le réseau. En considérant la présence de 4 % d’attaquants coordonnées dans le réseau, les taux de réussite obtenus s’élèvent à plus de 70 % ; ces taux de réussite sont à plus de 80 % et 90 % pour respectivement 2 % et 1 % d’attaquants coordonnées sévissant dans le réseau. tableau 9.15 – Récapitulatif des résultats moyens

Taux de réussite des échanges de clés (%) % attaquants Routage borné Routage ﬂexible Routage strict ER IP MP BGP ER IP MP BGP ER IP MP BGP 0,5 96,66 97,40 96,80 99,35 98,01 97,68 96,85 99,39 97,13 97,28 96,74 99,20 1 93,81 95,10 93,55 98,60 95,25 95,59 94,03 98,35 94,70 95,19 93,93 97,95 2 87,76 90,22 86,99 96,39 89,34 90,52 87,49 95,88 89,70 90,19 88,02 96,51 4 76,41 80,38 73,76 90,95 78,06 80,51 74,30 90,61 80,07 81,77 77,39 91,34 8 56,50 64,65 55,15 77,95 57,83 63,74 54,78 81,26 61,99 66,50 57,81 84,11 16 30,24 40,74 29,12 60,90 31,16 40,40 29,49 60,62 36,17 42,95 32,18 66,80 32 08,07 15,49 07,39 31,52 08,65 15,99 07,87 31,96 10,90 17,87 08,70 38,52 64 00,36 02,26 00,40 06,57 00,50 02,58 00,49 06,90 00,62 02,79 00,57 08,02 18, 21 56,23 60,78 55,40 70,28 57,35 60,87 55,66 70,62 58,91 61,82 56,92 72,81

9.6 Conclusion

Au cours de ce chapitre, nous avons étudié l’évaluation, par diverses expérimentations, de notre protocole d’échange de clés basé sur des chemins disjoints. Cette méthode empêche efficacement les attaques par interception isolées dans le réseau ; les attaques coordonnées peuvent néanmoins compromettre cette politique d’échange de clés lorsque les différents chemins disjoints, utilisés dans l’acheminement des sous-clés, sont tous interceptés. Cependant, il est difficile de mettre en œuvre de telles attaques, à fortiori prédire ou intercepter les potentiels chemins disjoints déterminés par les correspondants. Dans les expérimentations menées, les échanges de clé aboutissent de moins en moins à mesure que le nombre d’attaquants dans le réseau s’accroît. Ce faisant, lorsque le nombre d’attaquants coordonnés est suffisamment grand, le réseau devient totalement vulnérable, c’est à dire que les taux de réussite chutent jusqu’en dessous de 10 %. Cependant, la proportion d’attaquants qui permet d’atteindre un tel niveau de compromission doit être faramineuse (c’est à dire environ 64 % des nœuds du réseau) ; en général, cette proportion ne correspond pas à des scénarios habituels et/ou réalistes qu’on rencontre sur Internet. Il faut toutefois noter que lorsque la proportion d’attaquants est relativement petite, alors la présence de ceux-ci n’est pas de nature à compromettre les échanges de clés : les taux de réussite peuvent avoisiner 100 %. Conclusion générale

Bilan

Dans ce mémoire de thèse, une infrastructure de sécurité, qui étend le système CLOAK et qui est conceptuellement adaptée aux réseaux P2P, est proposée. Les travaux de cette thèse ont permis en effet de définir, d’une part, un intergiciel appelé SEMOS, qui est la déclinaison VPN mobile du système CLOAK, et, d’autre part, une méthode d’échange de clés multi-chemin basée sur le protocole Diffie-Hellman et le schéma à seuil (k, n) de Shamir. En d’autres termes, la pierre angulaire de notre infrastructure est constituée d’un système VPN mobile robuste et d’un mécanisme de négociation de clés, basé sur l’extension de deux protocoles cryptographiques susmentionnés, qui l’est tout autant. À l’instar d’un système VPN mobile comme le protocole HIP, l’infrastructure SEMOS permet de maintenir les sessions sécurisées actives et ce, même lorsqu’une perturbation se produit ou un changement inopiné de configuration réseau s’opère. Cette faculté, renforcée par les caractéristiques inhérentes de notre DHT CLOAK, fournit à SEMOS des propriétés telles que la disponibilité, la mobilité de deux extrémités d’une session sécurisée, le passage à l’échelle et une gestion décentralisée et efficace des identifiants virtuels d’hôtes. Il convient de noter que, contrairement à SEMOS qui propose une mobilité accrue et bidirectionnelle, les systèmes VPN mobiles comme MOBIKE ou, dans une certaine mesure, N2N offrent une flexibilité réduite dans la mobilité des nœuds : seuls le nœud client, dans le premier protocole, et le Edge node, dans le second système, peuvent supporter la mobilité. Afin de gérer efficacement la mobilité simultanée de deux extrémités d’un tunnel, les développeurs du protocole HIP suggèrent l’emploi du mécanisme de rendezvous favorisé par l’utilisation des serveurs spéciaux. Dès lors, le caractère totalement distribué dont le protocole HIP se revendique originellement s’amenuise considérablement. Nous pouvons ainsi considérer que l’intergiciel SEMOS, qui hérite des propriétés fournies par une infrastructure DHT ayant des performances équivalentes de celles des autres systèmes structurés populaires, tels que Chord, Pastry ou Kademlia, présente des caractéristiques qui offrent une résistance aux pannes et résolvent le problème relatif au passage à l’échelle qui est consubstantiel aux protocoles VPN traditionnels s’appuyant fondamentalement sur l’architecture client/serveur. Constituant un prélude crucial dans la sécurisation des échanges effectués via un réseau, la négociation de clés constitue un enjeu sécuritaire fondamental et déterminant dans la confidentialité des données émises à travers des canaux dont la fiabilité est douteuse. Ce faisant, nous avons mené une étude conceptuelle exhaustive sur un nouveau modèle de gestion des clés, assortie d’expérimentations menées sur des réseaux virtuels constitués par des topologies P2P générées aléatoirement. Il en ressort, d’une part, que le modèle d’échange de clés que nous proposons compense l’absence d’authentification inhérente au protocole Diffie-Hellman. Le procédé qui consiste à subdiviser une clé en plusieurs sous-clés est assez robuste et le caractère générique de notre modèle, c’est à dire que notre approche ne dépend d’aucune topologie particulière contrairement à l’algorithme proposé par Takano et al, qui est intrinsèquement lié aux systèmes possédant une topologie circulaire que sont Chord et Symphony, constitue aussi un gage de qualité. D’autre part, les résultats issus de nos expérimentations montrent généralement que, si la proportion d’attaquants

113 114

coordonnés est raisonnablement petite, c’est à dire de l’ordre de 0, 5 % ou 1 %, les taux moyens de réussite dans les échanges de clés oscillent entre 90 % et 100 %. Il n’en demeure cependant pas moins vrai que la recherche des chemins disjoints dans le réseau recouvrant induit une complexité des traitements dont le coût n’est pas négligeable, loin s’en faut. En dépit du coût évoqué, il faut préciser néanmoins que la recherche des chemins disjoints n’est pas systématiquement réitérée : elle n’est déclenchée qu’au début de chaque session. Aussi, il ne faut pas perdre de vue la diﬃculté, voire l’impossibilité, de trouver des chemins disjoints dans un réseau de type petit-monde.

Perspectives

Nos travaux futurs vont consister, entre autres, à implémenter et évaluer d’autres mécanismes permettant de maintenir l’arbre d’adressage en évitant les ré-adressages complets ou bien en réduisant le coût de leur complexité. Nous souhaitons aussi définir et implémenter des niveaux de DHT supplémentaires sur notre infrastructure existante afin de pouvoir utiliser des indirections : par exemple, un nom de groupe se traduirait par un ensemble de noms d’individus, qui se traduirait à son tour par un ensemble de noms de terminaux qui se traduirait enfin par un ensemble d’adresses du réseau recouvrant. Il faudra donc faire des requêtes successives à différents niveaux afin de récuperer l’information souhaitée (i.e., les adresses dans notre exemple). Cette faculté permettra à notre système de fournir des services innovants de type routage au plus proche (anycast en anglais), routage par contenu, etc. Les expérimentations menées sur notre méthode d’échange de clés, basée sur des chemins disjoints, portent essentiellement sur des réseaux ayant des topologies statiques. Cependant, le système SEMOS est nativement destiné à opérer dans un environnement dynamique. C’est pourquoi, nous prévoyons, dans un futur proche, d’effectuer des expérimentations dans un environnement mobile et/ou dynamique, dans lequel la topologie du réseau change perpétuellement, afin d’évaluer les performances de notre mécanisme d’échange de clés. Aussi, afin de fournir des services de sécurité assez exhaustifs, nous projetons de concevoir un système anonyme visant à offrir une protection des identités vis à vis des pairs espions qui sont fréquents sur Internet ; les identités des nœuds, contenues dans les flux transmis à travers le réseau recouvrant, deviennent ainsi inaccessibles aux nœuds relayeurs ou aux entités tierces malveillantes qui surveillent de façon frauduleuse les échanges émis par les pairs communicants. ANNEXE A

Contributions issues de cette thèse

Les publications produites dans le cadre de ce mémoire de thèse se composent d’articles présentés dans les conférences internationales à comité de lecture et des journaux publiés dans les revues scientiﬁques et techniques.

A.1 Journaux

Découplage entre l’espace d’adressage et l’espace de nommage — Telesphore Tiendrebeogo, Daouda Ahmat, Damien Magoni, and Oumarou Sié. Virtual connections in p2p overlays with dht-based name to address resolution. International Journal on Advances in Internet Technology, 5(1) :11–25, 2012

— Telesphore Tiendrebeogo, Daouda Ahmat, and Damien Magoni. Évaluation de la ﬁabilité d’une table de hachage distribuée construite dans un plan hyperbolique. Technique et Science Informatique, TSI, Volume 33 - n◦ 4/2014, Lavoisier, pages 311–341, Juin 2014

A.2 Articles

Découplage entre l’espace d’adressage et l’espace de nommage — T. Tiendrebeogo, D. Ahmat, and D. Magoni. Reliable and scalable distributed hash tables harnessing hyperbolic coordinates. In New Technologies, Mobility and Security (NTMS), 2012 5th International Conference on, pages 1–6, 2012

Échange de clés — Daouda Ahmat, Tegawendé Bissyandé, and Damien Magoni. Towards securing communications in infrastructure-poor areas. In 5th EAI International Conference on e-Infrastructure and e-Services for Developing Countries, Nov. 25-27 2013, Blantyre, Malawi

Sessions sécurisées mobiles — Daouda Ahmat and Damien Magoni. Muses : Mobile user secured session. In 5th IFIP Wireless Days Conference, pages 1–6, November 2012, Dublin, Irland

Divers — Tegawendé F. Bissyandé, Daouda Ahmat, Jonathan Ouoba, Gertjan van Stam, Jacques Klein, and Yves Le Traon. Fifth International IEEE EAI Conference on e-Infrastructure and e-Services for Developing Countries, page 10pp., Nov 25-27 2013, Blantyre, Malawi

115 116 A.2. ARTICLES ANNEXE B

Preuves et algorithmes

B.1 Théorèmes et preuves

Théorème 3 (Flot max Coupe min - Ford-Fulkerson, 1956). La valeur maximum d’un ﬂot compatible entre s et t est égale à la capacité minimum d’une coupe séparant s et t dans le graphe G.

Preuve. Procédons par un raisonnement par l’absurde.

Théorème 1 (Menger, 1927 [75]). Étant donné un graphe non orienté G et deux sommets distincts s et t, le nombre maximum de chemins s-t arc-disjoints est égal au nombre minimum des arcs dont la suppression de G déconnecte s de t.

Preuve. ⇐) Soit F ⊆ E et |F | = k. Supposons que la suppression de F déconnecte s de t. Il est trivial d’observer que tous les chemins s-t utilisent au moins un arc de F ; il s’ensuit que le nombre de chemins s-t arc-disjoints est ≤ k.

⇒) Supposons que le nombre maximum de chemins arc-disjoints est k et F l’ensemble des arcs reliant S et T . Il est prouvé que le ﬂot maximal est aussi égal à k (Cf. théorème 1). Comme Flot max est égal à Coupe min (Cf. théorème 3 ) alors coupe (S,T) a une capacité égale à k. Étant donné que |F | = k et la déﬁnition de coupe implique F déconnect s de t.

Une autre preuve est proposée par William McCuaig en 1984 et présentée dans[136]. Théorème 2 (Even , Itai, Shamir [137]). Le problème de chemins arc-disjoints dans les graphes non-orientés et le problème de chemins arc-disjoints dans les graphes orientés acycliques sont de problèmes NP-complet, même si r(E(H)) = 3 (nombre de chemins recherchés). Théorème 3 (Fortune , Hopcroft, Wyllie [71]). Le problème de chemins sommet-disjoints est un problème NP-complet, même si r(E(H)) = 2. Théorème 4 (Fortune , Hopcroft, Wyllie [71]). Le problème de chemins arc-disjoints dans un graphe acyclique orienté et dont le nombre de chemins est borné r(E(H)) est soluble en temps polynomial.

117 118 B.2. ALGORITHMES

B.2 Algorithmes

Algorithme 19 : Routing a subkey over a CLOAK P2P overlay Input : CurrentPeer, SubKeyPacket, VisitedList Output : Success w ← SubKeyPacket.DestinationP eer.Coords ; m ← CurrentPeer.Coords ; |m−w|2 dmin ← argcosh 1 + 2 (1−|m|2)(1−|w|2) ; pmin ← CurrentPeer ; foreach Neighbor ∈ pmin.Neighbors do IsAlreadyVisited ← VisitedList.contains (Neighbor) ; if IsAlreadyVisited = false then n ← Neighbor.Coords ; |n−w|2 d ← argcosh 1 + 2 (1−|n|2)(1−|w|2) ; if d < dmin then dmin ← d ; pmin ← Neighbor ;

if pmin 6= CurrentPeer then VisitedList.add (pmin) ; routeSubKey (pmin, SubKeyPacket); if pmin = SubKeyPacket.DestinationP eer then return success ; else algorithm 19 (pmin, SubKeyPacket, VisitedList) ; else backtracking () ; ANNEXE C

Quelques résultats complémentaires

119 120 Bibliographie

[1] Sylvia Ratnasamy, Paul Francis, Mark Handley, Richard Karp, and Scott Shenker. A scalable content-addressable network. In IN PROC. ACM SIGCOMM 2001, pages 161–172, 2001.

[2] Antony Rowstron and Peter Druschel. Pastry : Scalable, decentralized object location, and routing for large-scale peer-to-peer systems. IN : MIDDLEWARE, pages 329–350, 2001.

[3] B.Y. Zhao, L. Huang, J. Stribling, S.C. Rhea, A.D. Joseph, and J.D. Kubiatowicz. Tapestry : A resilient global-scale overlay for service deployment. Selected Areas in Communications, IEEE Journal on, 22(1) :41–53, 2004.

[4] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, and Hari Balakrishnan. Chord : A scalable peer-to-peer lookup service for internet applications. In Proceedings of the 2001 Conference on Applications, Technologies, Architectures, and Protocols for Computer Communications, SIGCOMM ’01, pages 149–160, New York, NY, USA, 2001. ACM.

[5] Michael J. Freedman and Robert Morris. Tarzan : A peer-to-peer anonymizing network layer. In Proceedings of the 9th ACM Conference on Computer and Communications Security (CCS 2002), Washington, DC, November 2002. ACM New York, NY, USA, ACM New York, NY, USA.

[6] Cyril Cassagnes, Telesphore Tiendrebeogo, David Bromberg, and Damien Magoni. Overlay addressing and routing system based on hyperbolic geometry. In Proceedings of the 16th IEEE Symposium on Computers and Communications, pages 294–301, 2011.

[7] T. Tiendrebeogo, D. Ahmat, and D. Magoni. Reliable and scalable distributed hash tables harnessing hyperbolic coordinates. In New Technologies, Mobility and Security (NTMS), 2012 5th International Conference on, pages 1–6, 2012.

[8] Ian Clarke, Oskar Sandberg, Brandon Wiley, and Theodore W. Hong. Freenet : A distributed anonymous information storage and retrieval system. In International Workshop on Designing Privacy Enhancing Technologies : Design Issues in Anonymity and Unobservability, pages 46–66, New York, NY, USA, 2001. Springer-Verlag New York, Inc.

[9] Dahlia Malkhi, Moni Naor, and David Ratajczak. Viceroy : A scalable and dynamic emulation of the butterﬂy. In Proceedings of the Twenty-ﬁrst Annual Symposium on Principles of Distributed Computing, PODC ’02, pages 183–192, New York, NY, USA, 2002. ACM.

[10] Petar Maymounkov and David Mazières. Kademlia : A peer-to-peer information system based on the xor metric. In Revised Papers from the First International Workshop on Peer-to-Peer Systems, IPTPS ’01, pages 53–65, London, UK, UK, 2002. Springer-Verlag.

[11] Bram Cohen. Incentives build robustness in bittorrent. http://bittorent.com/, 2003.

[12] Craig Labovitz, Scott Iekel-Johnson, Danny McPherson, Jon Oberheide, and Farnam Jahanian.

121 122 BIBLIOGRAPHIE

Internet inter-domain traﬃc. In Shivkumar Kalyanaraman, Venkata N. Padmanabhan, K. K. Ramakrishnan, Rajeev Shorey, and Geoﬀrey M. Voelker, editors, SIGCOMM, pages 75–86. ACM, 2010.

[13] J. Seibert, R. Torres, M. Mellia, M. M. Munafo, C. Nita-Rotaru, and S. Rao. The internet-wide impact of p2p traﬃc localization on isp proﬁtability. Networking, IEEE/ACM Transactions on, 20(6) :1910–1923, Dec 2012.

[14] A. Finamore, M. Mellia, M. Meo, M.M. Munafo, and D. Rossi. Experiences of internet traﬃc monitoring with tstat. Network, IEEE, 25(3) :8–14, May 2011.

[15] Marios Iliofotou, Hyunchul Kim, Michalis Faloutsos, Michael Mitzenmacher, Prashanth Pappu, and George Varghese. Graption : A graph-based p2p traﬃc classiﬁcation framework for the internet backbone. Computer Networks, 55(8) :1909–1920, 2011.

[16] T.T.T. Nguyen and G. Armitage. A survey of techniques for internet traﬃc classiﬁcation using machine learning. Communications Surveys Tutorials, IEEE, 10(4) :56–76, Fourth 2008.

[17] M. Srivatsa and Ling Liu. Vulnerabilities and security threats in structured overlay networks : a quantitative analysis. In Computer Security Applications Conference, 2004. 20th Annual, pages 252–261, 2004.

[18] Guido Urdaneta, Guillaume Pierre, and Maarten Van Steen. A survey of dht security techniques. ACM Comput. Surv., 43(2) :8 :1–8 :49, February 2011.

[19] Jani Suomalainen, Anssi Pehrsson, and Jukka K. Nurminen. A security analysis of a p2p incentive mechanisms for mobile devices. In 3rd International Conference on Internet and Web Applications and Services, pages 397–402, 2008.

[20] Emil Sit and Robert Morris. Security considerations for peer-to-peer distributed hash tables. In Revised Papers from the First International Workshop on Peer-to-Peer Systems, IPTPS ’01, pages 261–269, London, UK, UK, 2002. Springer-Verlag.

[21] Y. Takano, N. Isozaki, and Y. Shinoda. Multipath key exchange on p2p networks. In Availability, Reliability and Security, 2006. ARES 2006. The First International Conference on, pages 8 pp.–, 2006.

[22] Agapios Avramidis, Panayiotis Kotzanikolaou, Christos Douligeris, and Mike Burmester. Chord-pki : A distributed trust infrastructure based on p2p networks. Comput. Netw., 56(1) :378–398, January 2012.

[23] Honghao Wang, Yingwu Zhu, and Yiming Hu. An eﬃcient and secure peer-to-peer overlay network. In Local Computer Networks, 2005. 30th Anniversary. The IEEE Conference on, pages 8 pp.–771, 2005.

[24] F. Lesueur, L. Me, and V.V.T. Tong. An eﬃcient distributed pki for structured p2p networks. In Peer-to-Peer Computing, 2009. P2P ’09. IEEE Ninth International Conference on, pages 1–10, Sept 2009.

[25] Lidong Zhou, Lintao Zhang, Frank McSherry, Nicole Immorlica, Manuel Costa, and Steve Chien. A ﬁrst look at peer-to-peer worms : Threats and defenses. In Miguel Castro and Robbert van Renesse, editors, IPTPS, volume 3640 of Lecture Notes in Computer Science, pages 24–35. Springer, 2005.

[26] Damien Magoni and Jean-Jacques Pansiot. Internet topology modeler based on map sampling. BIBLIOGRAPHIE 123

In Proceedings of the 7th IEEE Symposium on Computers and Communications, pages 1021–1027, 2002.

[27] Paul Erdős and Alfred Rényi. On the evolution of random graphs. Publications of the Mathematical Institute of the Hungarian Academy of Sciences 5, pages 17–61, 1960.

[28] L. Deri and R. Andrews. N2N : A Layer Two Peer-to-Peer VPN. AIMS ’08 : Proceedings of the 2nd international conference on Autonomous Infrastructure, Management and Security, Berlin, Heidelberg, page 53–64, 2008.

[29] R. Moskowitz and P. Nikander. Host Identity Protocol (HIP) Architecture. http://tools.ietf. org/html/rfc4423/, May 2006.

[30] P. Eronen. IKEv2 Mobility and Multihoming Protocol (MOBIKE). IETF RFC 4555, june 2006.

[31] S. Aoyagi, M. Takizawa, M. Saito, H. Aida, and H. Tokuda. ELA : A Fully Distributed VPN System over Peer-to-Peer Network. Proceedings of the Symposium on Applications and the Internet(SAINT’05), IEEE Computer Society, Los Alamitos, CA, USA, page 89 – 92, 2005.

[32] Cyril Cassagnes, David Bromberg, and Damien Magoni. An overlay architecture for achieving total ﬂexibility in internet communications. In Proceedings of the 8th International Conference on Advanced Information Technologies for Management, pages 39–60, 2010.

[33] FastTrack (KaZaA), [En ligne], 2001. http://www.kazaa.com.

[34] GNUTELLA DEVELOPMENT FORUM. The gnutella v0.6 protocol, [En ligne], 2001. http://groups.yahoo.com/group/the_gdf/ﬁles/.

[35] T. Tiendrebeogo, D. Ahmat, and D. Magoni. Reliable and Scalable Distributed Hash Tables Harnessing Hyperbolic Coordinates. New Technologies, Mobility and Security (NTMS), 5th International Conference on, pages 1–6, May 2012, Istanbul, Turkey. Istanbul, Turkey.

[36] Telesphore Tiendrebeogo, Daouda Ahmat, Damien Magoni, and Oumarou Sié. Virtual connections in p2p overlays with dht-based name to address resolution. International Journal on Advances in Internet Technology, 5(1) :11–25, 2012.

[37] W. Diﬃe and M.E. Hellman. New directions in cryptography. IEEE Transactions on Information Theory, 22(6) :644–654, 1976.

[38] B. den Boer. Diﬃe-hellman is as strong as discrete log for certain primes. In Proceedings on Advances in Cryptology, CRYPTO ’88, pages 530–539, New York, NY, USA, 1990. Springer- Verlag New York, Inc.

[39] S.C. Pohlig and M.E. Hellman. An improved algorithm for computing logarithms over and its cryptographic signiﬁcance (corresp.). Information Theory, IEEE Transactions on, 24(1) :106–110, Jan 1978.

[40] Neal Koblitz, Alfred Menezes, and Igor Shparlinski. Discrete logarithms, diﬃe-hellman, and reductions. IACR Cryptology ePrint Archive, 2010 :577, 2010.

[41] Adi Shamir. How to share a secret. Communications of the ACM, 22(11) :612–613, 1979.

[42] C. Perkins. IP Mobility Support for IPv4. http://tools.ietf.org/html/rfc3344/, August 2002.

[43] R. Stewart. Stream Control Transmission Protocol. http://tools.ietf.org/html/rfc4960/, September 2007. 124 BIBLIOGRAPHIE

[44] J. Rosenberg, H. Schulzrinne, G. Camarillo, A. Johnston, J. Peterson, R. Sparks, and M. Handley. SIP : Session Initiation Protocol. http://www.ietf.org/rfc/rfc3261.txt/, June 2002. [En ligne ; dernière consultation, mai 2012].

[45] J. Kauﬀmann. The freelan secure channel protocol. https://github.com/ereOn/libfscp/blob/1. 0/fscp.txt, [En ligne], April 2011.

[46] David Isaac Wolinsky, Linton Abraham, Kyungyong Lee, Yonggang Liu, Jiangyan Xu, P. Oscar Boykin, and Renato J. O. Figueiredo. On the design and implementation of structured p2p vpns. CoRR, abs/1001.2575, 2010.

[47] Motorolla. Mobile VPN, Secure Connectivity on the Move. White paper, 2008.

[48] Jim Binkley. An Integrated IPSEC and Mobile-IP for FreeBSD. Technical Report, page 01 – 10, October 2001.

[49] T. Braun and M. Danzeisen. Secure mobile IP communication. Local Computer Networks, 2001. Proceedings. LCN 2001. 26th Annual IEEE Conference on, page 586 – 593, 2001.

[50] Heesook Choi, Hui Song, Guohong Cao, and T. La Porta. Mobile multi-layered ipsec. INFOCOM 2005. 24th Annual Joint Conference of the IEEE Computer and Communications Societies. Proceedings IEEE, 3 :1929 – 1939 vol. 3, march 2005.

[51] R. Ruppelt, A. Pelinescu, C. Constantin, J. Floroiu, D. Sisalem, and B. Butscher. Building ALL-IP Based Virtual Private Networks in Mobile Environment. Int. Works. on Informatik and Mobile communication over wireless LAN : Research and applications, Australia, 2001.

[52] S. Kent and K. Seo. Security Architecture for the Internet Protocol. http://www.ietf.org/rfc/ rfc4301.txt, December 2005.

[53] F. Adrangi and H. Levkowetz. Problem Statement : Mobile IPv4 Traversal of Virtual Private Network (VPN) Gateways. http://www.ietf.org/rfc/rfc4093.txt, 2005.

[54] S. Vaarala and E. Klovning. Mobile IPv4 Traversal across IPsec-Based VPN Gateways. http://www.ietf.org/rfc/rfc5265.txt, 2008.

[55] V. Devarapalli and P. Eronen. Secure Connectivity and Mobility Using Mobile IPv4 and IKEv2 Mobility and Multihoming (MOBIKE). IETF RFC 5266, june 2008.

[56] M.M. Karbasioun, M. Berenjkub, and B. Taji. Securing mobile IP communications using MOBIKE protocol. Telecommunications, 2008. ICT 2008. International Conference on, page 1 – 5, june 2008.

[57] S. Huang, Z. Liu, and J. Chen. SIP-based mobile VPN for real-time applications . Wireless Communications and Networking Conference, IEEE, Vol. 4 :2318–2323, 2005.

[58] J. Salowey, H. Zhou, P. Eronen, and H. Tschofenig. Transport Layer Security (TLS) Session Resumption without Server-Side State. IETF RFC 5077, January 2008.

[59] T. Koponen and P. Eronen. Resilient Connections for SSH and TLS. Proceeding of USENIX Annual Technical Conference, May 2006. Boston.

[60] J. Schönwälder, G. Chulkov, E. Asgarov, and M. Cretu. Session Resumption for the Secure Shell Protocol. Integrated Network Management, 2009. IM ’09. IFIP/IEEE International Symposium on, page 157 – 163, 2009. BIBLIOGRAPHIE 125

[61] A. Zúquete and C. Frade. Fast VPN Mobility Across Wi-Fi Hotspots. Security and Commu- nication Networks (IWSCN), 2nd International Workshop on, IEEE Karlstad, Sweden, page 1–7, 2010.

[62] S. Minglei, T. Chengxiang, and W. Haihang. Mobile VPN Scheme Based on SOCKS V5. Machine Vision and Human-Machine Interface (MVHI), International Conference on, pages 792–795, April 2010.

[63] David Benenati, Peretz Feder, Nancy Y. Lee, Silvia Martin-Leon, and Reuven Shapira. A seamless mobile vpn data solution for cdma2000, star umts, and wlan users. Bell Labs Technical Journal, 7(2) :143–165, 2002.

[64] V. Devarapalli, R. Wakikawa, A. Petrescu, and P. Thubert. Network Mobility (NEMO) Basic Support Protocol. http://www.ietf.org/rfc/rfc3963.txt, 2005.

[65] T-C. Chen, J-C. Chen, and Z-H Liu. Secure Network Mobility (SeNEMO)for Real-Time Applications. Mobile Computing, IEEE Transactions on, Vol. 10 :1113–1130, 2011.

[66] B. Landfeldt, T. Larsson, Y. Ismailov, and A. Seneviratne. SLM, a framework for session layer mobility management. Proceedings of the 18th International Conference on Computer Communicants and Networks (ICCCN’ 99), Boston, MA, page 452 – 456, October 1999.

[67] Y. Zhang and S. Dao. A "Persistent Connection" Model for Mobile and Distributed Systems. Proceedings of the 4th International Conference on Computer Communications and Networks (ICCN’ 95), Las Vegas, Nevada, September 1995.

[68] A. Snoeren. A Session-Based Approach to Internet Mobility. PhD thesis, Massachusetts Institute of Technology, 2002.

[69] Meriem Abid, Daniel Macedo, Javier Rubio-Loyola, and Guy Pujolle. An autonomic mobility management solution for the future wireless int ernet. Annals of Telecommunications, 67(11- 12) :523–536, 2012.

[70] C. Perkins et al. Mobile ipv4 traversal across ipsec-based vpn gateways. http://www.ietf.org/ rfc/rfc5944.txt, November 2010.

[71] Steven Fortune, John E. Hopcroft, and James Wyllie. The directed subgraph homeomorphism problem. Theor. Comput. Sci., 10 :111–121, 1980.

[72] N. Robertson and P.D. Seymour. Graph minors .xiii. the disjoint paths problem. Journal of Combinatorial Theory, Series B, Volume 63, pages 65–110, January 1995.

[73] L. R. Ford and D. R. Fulkerson. Maximal ﬂow through a network. Canadian Journal of Mathematics, Vol. 8, pages 399–404, 1956.

[74] Jon Kleinberg and Eva Tardos. Algorithm Design. Addison-Wesley Longman Publishing Co., Inc., Boston, MA, USA, 2005.

[75] Menger Karl. Zur allgemeinen kurventheorie. Fund. Math. 10, pages 96–115, 1927.

[76] Michael J. Dinneen, Yun-Bum Kim, and Radu Nicolescu. Edge- and node-disjoint paths in p systems. In Gabriel Ciobanu and Maciej Koutny, editors, MeCBIC, volume 40 of EPTCS, pages 121–141, 2010.

[77] R. M. Karp. On the computational complexity of combinatorial problems. Networks, Networks (USA), vol.5, (no.1), (Proceedings of the Symposium on Large-Scale Networks, Evanston, IL, USA, 18-19 April 1974.). 126 BIBLIOGRAPHIE

[78] L. Perkovic and B. Reed. An improved algorithm for ﬁnding tree decompositions of small width. Internat. J. Found. Comput. Sci., 11(3), pages 365–371, 2000.

[79] Y. Shiloach and Y. Perl. Finding two disjoint paths between two pairs of vertices in a graph. J. ACM, 25(1) :1–9, January 1978.

[80] Torsten Tholey. Solving the 2-disjoint paths problem in nearly linear time. In Volker Diekert and Michel Habib, editors, STACS, volume 2996 of Lecture Notes in Computer Science, pages 350–361. Springer, 2004.

[81] Ken ichi Kawarabayashi, Yusuke Kobayashi, and Bruce A. Reed. The disjoint paths problem in quadratic time. J. Comb. Theory, Ser. B, 102(2) :424–435, 2012.

[82] Joan Daemen and Vincent Rijmen. The Design of Rijndael : AES - The Advanced Encryption Standard. Springer Verlag, Berlin, Heidelberg, New York, 2002.

[83] R.L. Rivest, A. Shamir, and L. Adleman. A method for obtaining digital signatures and public-key cryptosystems. Communications of the ACM, 21 :120–126, 1978.

[84] L. Lamport. The byzantine generals problem. ACM Transactions on Programming Languages and Systems, 4 :382–401, 1982.

[85] Robert Morris, David Karger, Frans Kaashoek, and Hari Balakrishnan. Chord : A Scalable Peer-to-Peer Lookup Service for Internet Applications. In ACM SIGCOMM 2001, San Diego, CA, September 2001.

[86] Gurmeet Singh Manku, Mayank Bawa, Prabhakar Raghavan, and Verity Inc. Symphony : Distributed hashing in a small world. In In Proceedings of the 4th USENIX Symposium on Internet Technologies and Systems, pages 127–140, 2003.

[87] J. Sen. A multi-path certiﬁcation protocol for mobile ad hoc networks. In Computers and Devices for Communication, 2009. CODEC 2009. 4th International Conference on, pages 1–4, 2009.

[88] Dijiang Huang and Deep Medhi. A byzantine resilient multi-path key establishment scheme and its robustness analysis for sensor networks. In Parallel and Distributed Processing Symposium (IPDPS), 2005. Proceedings. 19th IEEE International, pages 4–8, 2005.

[89] Jiang Wu and Douglas R. Stinson. Three improved algorithms for multi-path key establishment in sensor networks using protocols for secure message transmission, 2009.

[90] Danny Dolev, Cynthia Dwork, Orli Waarts, and Moti Yung. Perfectly secure message transmission. J. ACM, 40(1) :17–47, January 1993.

[91] Y. El Hajj Shehadeh, O. Alfandi, and D. Hogrefe. Towards robust key extraction from multipath wireless channels. Communications and Networks, Journal of, 14(4) :385–395, 2012.

[92] Jing Deng and Yunghsiang S. Han. Multi-path key establishment for wireless sensor networks using just-enough redundancy transmission. IEEE Trans. Dependable Sec. Comput., 5(3) :177– 190, 2008.

[93] François Lesueur, Ludovic Mé, and Valérie Viet Triem Tong. A distributed certiﬁcation system for structured p2p networks. In David Hausheer and Jürgen Schönwälder, editors, AIMS, volume 5127 of Lecture Notes in Computer Science, pages 40–52. Springer, 2008.

[94] Hongmei Deng, Anindo Mukherjee, and Dharma P. Agrawal. Threshold and identity-based BIBLIOGRAPHIE 127

key management and authentication for wireless ad hoc networks. In Proceedings of the International Conference on Information Technology : Coding and Computing (ITCC’04) Volume 2 - Volume 2, ITCC ’04, pages 107–, Washington, DC, USA, 2004. IEEE Computer Society.

[95] Martin Schanzenbach. Distributed pki in p2p networks. Proceedings of the Seminars Future Internet (FI) and Innovative Internet Technologies and Mobile Communications (IITM), Summer Semester 2010, volume NET-2010-08-2 of Network Architectures and Services (NET), pages 75–80, August 2010.

[96] Chun-Chieh Huang and Chi-Chun Lo. A two-key agreement based supervising mechanism for cluster-based peer-to-peer applications. In Parallel and Distributed Systems (ICPADS), 2010 IEEE 16th International Conference on, pages 823–828, Dec 2010.

[97] R. Pecori. A pki-free key agreement protocol for p2p voip applications. In Communications (ICC), 2012 IEEE International Conference on, pages 6748–6752, June 2012.

[98] Adi Shamir. Identity-based cryptosystems and signature schemes. In Proceedings of CRYPTO 84 on Advances in Cryptology, pages 47–53, New York, NY, USA, 1985. Springer-Verlag New York, Inc.

[99] A. Samreen and S. Ansari. Certiﬁcateless id-based authentication using threshold signature for p2p manets. In Information and Communication Technologies, 2009. ICICT ’09. International Conference on, pages 112–116, Aug 2009.

[100] Hua Jiang, Yongxing Jia, Rui Zhang, and Shanming Liu. A distributed key management scheme based on sgc-pkc for p2p network. In Wireless Communications, Networking and Information Security (WCNIS), 2010 IEEE International Conference on, pages 491–495, June 2010.

[101] Xinjun Du, Ying Wang, Jianhua Ge, and Yumin Wang. An id-based broadcast encryption scheme for key distribution. Broadcasting, IEEE Transactions on, 51(2) :264–266, June 2005.

[102] Yvo Desmedt and Royal Holloway. Some recent research aspects of threshold cryptography. In In Proc. of the 1st Intl. Information Security Workshop, pages 158–173. Springer-Verlag, 1997.

[103] Zhibin Xu, Zhongwen Li, and Weidao Zhang. A certiﬁcateless threshold signature scheme without parings in p2p networks. In Education Technology and Computer (ICETC), 2010 2nd International Conference on, volume 4, pages V4–367–V4–370, June 2010.

[104] R. Cohen and S. Havlin. Scale-Free Networks Are Ultrasmall. Phys. Rev. Lett., 90 :058701, 2003.

[105] Laganier J. and Eggert L. Host identity protocol (hip) rendezvous extension, rfc 5204. http://tools.ietf.org/html/rfc5204, April 2008.

[106] H. Levkowetz and S. Vaarala. Mobile ip traversal of network address translation (nat) devices. http://www.ietf.org/rfc/rfc3519.txt, April 2003.

[107] M. Komu, T. Henderson, H. Tschofenig, J. Melen, and A. Keranen. Basic hip extensions for traversal of network address translators. http://tools.ietf.org/html/draft-ietf-hip-nat-traversal-09, October 2009.

[108] C. Boulton, J. Rosenberg, G. Camarillo, and F. AUdet. Nat traversal practices for client-server sip. http://www.rfc-base.org/txt/rfc-6314.txt, July 2011. 128 BIBLIOGRAPHIE

[109] M.S. Hossain, M. Atiquzzaman, and W.D. Ivancic. Security vulnerabilities and protection mechanisms of mobility management protocols. In Aerospace Conference, 2011 IEEE, pages 1–12, March 2011.

[110] T. Berger. Analysis of current VPN technologies. Availability, Reliability and Security. ARES 2006. The First International Conference on, April 2006.

[111] M.Z.H. Sarker and M.S. Parvez. A cost eﬀective symmetric key cryptographic algorithm for small amount of data. In 9th International Multitopic Conference, IEEE INMIC 2005, pages 1–6, Dec 2005.

[112] Bryan Ford, Pyda Srisuresh, and Dan Kegel. Peer-to-peer communication across network address translators. In Proceedings of the Annual Conference on USENIX Annual Technical Conference, ATEC ’05, pages 13–13, Berkeley, CA, USA, 2005. USENIX Association.

[113] C. Adams, P. Cain, D. Pinkas, and R. Zuccherato. Internet x.509 public key infrastructure time-stamp protocol (tsp). http://www.ietf.org/rfc/rfc3161.txt, August 2001.

[114] Leslie Lamport. Time, clocks, and the ordering of events in a distributed system. Commun. ACM, 21(7) :558–565, July 1978.

[115] Tuomas Aura, Aarthi Nagarajan, and Andrei Gurtov. Analysis of the hip base exchange protocol. In In 10th Australasian Conference on Information Security and Privacy (ACISP 2005), pages 481–494, 2005.

[116] Cyril Cassagnes. Architecture autonome et distribuée d’adressage et de routage pour la ﬂexibilité des communications dans l’internet. Thèse de doctorat, Université de Bordeaux, pages 1–105, November 2012.

[117] D. B. A. Epstein. Curves on 2-manifolds and isotopies. In Acta Math, pages 15–16, 1966.

[118] Telesphore TIENDREBEOGO. Système dynamique réparti et extensible de nommage à indirections multiples. Thèse de doctorat, Université de Bordeaux, pages 1–135, Juin 2013.

[119] A. Montresor and M. Jelasity. Peersim : A scalable p2p simulator.

[120] Vincent Autefage and Damien Magoni. Network emulator : a network virtualization testbed for overlay experimentations. In Proceedings of the 17th IEEE International Workshop on Computer-Aided Modeling Analysis and Design of Communication Links and Networks, 2012.

[121] V. Autefage. NEmu, http ://nemu.valab.net/.

[122] Emmanuel Lochin, Tanguy Pérennou, and Laurent Dairaine. When should i use network emulation ? Annales des Télécommunications, 67(5-6) :247–255, 2012.

[123] Magoni D. Virtual Node Device (vnd), http ://www.labri.fr/perso/magoni/vnd/.

[124] The OpenSSL Project. OpenSSL : The open source toolkit for SSL/TLS. www.openssl.org, April 2003.

[125] socat - multipurpose relay. http://www.dest-unreach.org/socat/.

[126] OpenBSD. nc - arbitrary tcp and udp connections and listens. http://www.openbsd.org/ cgi-bin/man.cgi?query=nc.

[127] Strongswan. http://www.strongswan.org. BIBLIOGRAPHIE 129

[128] L. Deri and R. Andrews. Implémantation n2n : A layer two peer-to-peer vpn. http://www. ntop.org/products/n2n/, 2008. [129] Openhip. http://www.openhip.org.

[130] Y. Rekhter. A border gateway protocol 4 (bgp-4). RFC 4271, http ://www.ietf.org/rfc/rfc4271.txt ,january, 2006. [131] B. M. Waxman. Routing of multipoint connections. Selected Areas in Communications, IEEE Journal on, 6(9) :1617–1622, December 1988.

[132] Telesphore Tiendrebeogo, Daouda Ahmat, and Damien Magoni. Évaluation de la ﬁabilité d’une table de hachage distribuée construite dans un plan hyperbolique. Technique et Science Informatique, TSI, Volume 33 - n◦ 4/2014, Lavoisier, pages 311–341, Juin 2014. [133] Daouda Ahmat, Tegawendé Bissyandé, and Damien Magoni. Towards securing communications in infrastructure-poor areas. In 5th EAI International Conference on e-Infrastructure and e-Services for Developing Countries, Nov. 25-27 2013, Blantyre, Malawi. [134] Daouda Ahmat and Damien Magoni. Muses : Mobile user secured session. In 5th IFIP Wireless Days Conference, pages 1–6, November 2012, Dublin, Irland. [135] Tegawendé F. Bissyandé, Daouda Ahmat, Jonathan Ouoba, Gertjan van Stam, Jacques Klein, and Yves Le Traon. Fifth International IEEE EAI Conference on e-Infrastructure and e-Services for Developing Countries, page 10pp., Nov 25-27 2013, Blantyre, Malawi. [136] W. McCuaig. A simple proof of menger’s theorem. Journal of Graph Theory - JGT , vol. 8, no. 3, pages 427–429, 1984. [137] S. Even, A. Itai, and A. Shamir. On the complexity of time table and multi-commodity ﬂow problems. In Proceedings of the 16th Annual Symposium on Foundations of Computer Science, SFCS ’75, pages 184–193, Washington, DC, USA, 1975. IEEE Computer Society. 130 BIBLIOGRAPHIE Liste des Algorithmes

1 Échange de clés Diﬃe-Hellman ...... 14

2 Algorithme Ford-Fulkerson ...... 30

3 Calcul des coordonnées des ﬁls d’un nœud ...... 47 4 Routage glouton dans le réseau recouvrant ...... 48 5 Détermination du nœud suivant ...... 49 6 Technique de reprise de session ...... 55

7 Mécanisme de redirection du traﬁc sortant ...... 67 8 Horloge logique de Lamport ...... 69

9 Routage indéterministe ...... 73 10 Routage déterministe ...... 75 11 Initialisation des paramètres ...... 77 12 Routage des sous-clés ...... 78 13 Génération des sous-clés ...... 82 14 Création du polynôme ...... 82 15 Reconstitution de la clé à partir des sous-clés reçues ...... 83 16 Échange de clés multi-chemin basé sur le protocole Diﬃe-Hellman ...... 84 17 Délégation de négociation de clé un proxy de conﬁance ...... 85 18 Détection du point d’articulation ...... 86

19 Routing a subkey over a CLOAK P2P overlay ...... 118

131 132 LISTE DES ALGORITHMES Liste des tableaux

1 comparison ...... x

1.3 Comparatif de systèmes P2P non-structurés ...... 11 1.4 Comparatif de quelques systèmes DHT avec CLOAK ...... 12

2.5 Comparatif technique de solutions VPN mobiles ...... 25 2.6 Index et références de systèmes VPN mobiles du tableau comparatif 2.5 ...... 25

3.7 Classes de complexité de diﬀérents problèmes de chemins disjoints ...... 33

4.8 Index et références de systèmes de gestion distribuée de clés représentés dans la ﬁgure 4.25 ...... 40

5.9 Comparatif de quelques systèmes DHT avec CLOAK ...... 52 5.10 Comparatif entre CLOAK et trois autres protocoles standards de mobilité . . . . . 56

7.11 Comparatif de quelques modes du routage multi-chemin ...... 76 7.12 comparison ...... 88

8.13 comparison ...... 99 8.14 comparison ...... 99

9.15 Récapitulatif des résultats moyens ...... 112

133 134 LISTE DES TABLEAUX Liste des ﬁgures

1.1 Classification simplifiée des systèmes informatiques ...... 7 1.2 Modèle client/serveur : cas de quatre clients ...... 8 1.3 Exemple d’une topologie P2P totalement décentralisée ...... 9 1.4 Exemple d’une topologie P2P semi-décentralisée ...... 9 1.5 Exemple d’une topologie des systèmes P2P recouvrants ...... 10 1.6 Représentation simplifiée d’un réseau structuré ...... 11 1.7 Système VPN traditionnel ...... 16 1.8 Architecture du protocole Mobile IP ...... 17

2.9 Topologie du système N2N ...... 20 2.10 Scénario d’un problème de compatibilité entre IPSec et Mobile IP ...... 21 2.11 Mobile VPN proposé par RFC 5265 (source : RFC 5265) ...... 22 2.12 Couche HIP dans la pile TCP/IP ...... 23 2.13 Mécanisme de gestion de mobilité du protocole SIP ...... 23

3.14 Graphe quelconque contenant deux sommets distincts s et t ...... 27 3.15 Double réduction : passage du problème sommet-disjoints au problème arc-disjoints (1) et passage du problème arc-disjoints au problème du ﬂot maximal (2) . . . . . 28 3.16 Chemin sommet-disjoints ...... 28 3.17 Chemin arc-disjoints ...... 28 3.18 Graphe arc-disjoints ...... 29 3.19 Graphe sommet-disjoints ...... 29 3.20 Exemple d’un graphe avec un ﬂot maximal entre s et t égale à trois (03) ...... 31 3.21 Trois (03) chemins s-t arc-disjoints obtenus du graphe 3.20 ...... 31 3.22 Deux chemins disjoints sur une topologie circulaire ...... 32

4.23 Algorithme de routage utilisée dans [21] ...... 36 4.24 Scénario d’une attaque HDM coordonnée ...... 37 4.25 Répartition des approches distribuées de gestion de clés ...... 40

5.26 Vue générale de l’architecture ...... 46 5.27 Disque de Poincaré : exemple d’un arbre régulier d’ordre trois ...... 47 5.28 Processus de génération de IDCLOAK ...... 50 5.29 Stockage d’un couple dans la DHT ...... 51 5.30 Découplage de l’espace d’adressage avec l’espace de nommage ...... 53 5.31 Architecture simpliﬁée du mécanisme de mobilité ...... 54

6.32 Vue générale de l’architecture SEMOS ...... 60 6.33 Structure simpliﬁée d’un paquet SEMOS/CLOAK ...... 61 6.34 Mobilité d’utilisateur ponctuée par une continuée de la session sécurisée...... 63

135 136 LISTE DES FIGURES

6.35 Échange d’identifiants partiels et calcul conjoint de l’identifiant de session . . . . . 63 6.36 Structure du paquet Hello/Re-Hello ...... 64 6.37 Les différentes phases d’une communication SEMOS ...... 65 6.38 Processus de détection de défaillance et de restauration de session ...... 66

7.39 Processus de détermination des chemins disjoints : cas de deux (02) chemins disjoints 79 7.40 Processus de détection du nombre maximum de sauts et enclenchement du mécanisme de pair de confiance ...... 80 7.41 Processus de délégation de négociation de clé à un pair de confiance, en l’occurence le nœud 4 dans la figure ...... 85

8.42 Taux de succès vs taux de remous selon la DHT utilisée ...... 95 8.43 Distance parcourue par les GET ...... 95 8.44 Distance parcourue par les PUT ...... 95 8.45 Latence des GET ...... 96 8.46 Latence des PUT ...... 96 8.47 Un scénario de changement du point d’attachement réseau ...... 97 8.48 N2N : latence de reprise...... 98 8.49 HIP : latence de reprise...... 98 8.50 MOBIKE : latence de reprise...... 98 8.51 SEMOS : latence de reprise ...... 98

9.52 Taux de réussite en focntion de taux d’attaquants pour différents types de réseau ayant chacun 20 000 nœuds ...... 105 9.53 Taux de réussite vs tailles du réseau pour la carte MP ...... 106 9.54 Taux de réussite vs tailles du réseau pour la carte ER ...... 106 9.55 Taux de réussite vs tailles du réseau pour une topologie en anneau ...... 106 9.56 Variation des taux de réussite d’échange de clés par aux tailles de réseaux : cas du réseau ER borné à 64 sauts ...... 106 9.57 Taux d’échanges de clés réussis par nombre de chemins disjoints par rapport au pourcentage d’attaquants coordonnés présents dans le réseau recouvrant ...... 107 9.58 Nombre de chemins disjoints & nombre de chemins interceptés dans le réseau ER contenant 20 000 nœuds ...... 107 9.59 Nombre de chemins disjoints & nombre de chemins interceptés dans le réseau IP contenant 20 000 nœuds ...... 107 9.60 Comparaison de deux échanges dont l’un est limité à 64 sauts et l’autre à 200 sauts : cas de 2 500 nœuds ...... 108 9.61 Comparaison du routage flexible effectuée sur différents réseaux ...... 109 9.62 Comparaison de différents algorithmes de routage sur le réseau ER ...... 109 9.63 Comparaison du routage borné effectuée sur différents réseaux ...... 109 9.64 Comparaison du routage strict effectuée sur différents réseaux ...... 109 9.65 Distribution de 90e percentile et de la longueur moyenne des chemins : cas du réseau ER composé de 20 000 nœuds, routage strict ...... 110 9.66 Distribution de 90e percentile et de la longueur moyenne des chemins : cas du réseau ER composé de 20 000 nœuds, routage borné ...... 110 9.67 Réseau MP composé de 20000 nœuds : CCDF de différents algorithmes de routage . 111 9.68 CCDF de différents réseaux évalués : chaque réseau est composé de 20000 nœuds . . 111 9.69 Écart-types des taux de réussite des échanges de clés sur un réseau tournant sous le protocole BGP4 ...... 111