Définition d’une infrastructure de sécurité et de mobilité pour les réseaux pair-à-pair recouvrants Ahmat Mahamat Daouda
To cite this version:
Ahmat Mahamat Daouda. Définition d’une infrastructure de sécurité et de mobilité pourles réseaux pair-à-pair recouvrants. Informatique. Université de Bordeaux, 2014. Français. NNT : 2014BORD0186. tel-01132381
HAL Id: tel-01132381 https://tel.archives-ouvertes.fr/tel-01132381 Submitted on 17 Mar 2015
HAL is a multi-disciplinary open access L’archive ouverte pluridisciplinaire HAL, est archive for the deposit and dissemination of sci- destinée au dépôt et à la diffusion de documents entific research documents, whether they are pub- scientifiques de niveau recherche, publiés ou non, lished or not. The documents may come from émanant des établissements d’enseignement et de teaching and research institutions in France or recherche français ou étrangers, des laboratoires abroad, or from public or private research centers. publics ou privés. 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éfinition 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, Diffie-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 sacrifices 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 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
xi xii TABLE DES MATIÈRES
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
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
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 confiance 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 Diffé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
5
CHAPITRE 1
Terminologie et définition 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é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
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´
figure 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 figure 1.2, le serveur offre 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 informa- tique 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écificités concep- tuelles.
1.3.2.1 Réseaux P2P décentralisés & semi-décentralisés (ou hybrides)
figure 1.3 – Exemple d’une topologie P2P figure 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
figure 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 modification 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 trafic, 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 figure 1.6 – Représentation simplifié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éfinition 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 effectué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 à chiffrer et/ou à vérifier 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 infor- mations 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 permet- tant de s’assurer de l’authenticité d’un message ; elle garantit qu’aucune modification 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 Diffie et Hellman.
Algorithme 1 : Échange de clés Diffie-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 finalement K = Kb = g b (mod p) ;
sb sa·s 8. Bob détermine finalement 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 efficace car elle permet de réduire, pour un dépositaire τ τ(n−α) de α sous-secrets, la difficulté d’exécuter une attaque par force brute en τ − α n , soit n .
1.4.3.2 Schéma à seuil (k, n) Définition : 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
figure 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éfinie comme une technique permettant aux entités de changer de configuration 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
5
figure 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 fins 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 effet 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 Diffie-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 figure 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
figure 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
figure 2.10 – Scénario d’un problème de compatibilité entre IPSec et Mobile IP
Afin 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 figure 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 multiho- ming [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 identifié 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
3
figure 2.13 – Mécanisme de gestion de mobilité du protocole SIP
Motivés par la mobilité et gestion de sessions offertes 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 souffre 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é. Afin 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 concep- tuelles 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 authentifié. 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éficiant 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 efficace 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 figure 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
figure 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 flot 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 flot maximal dans le graphe?
figure 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 flot maximal (2)
3.1.1 Réduction problème sommet-disjoint ; problème arc-disjoint
La réduction, illustrée par les figures 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éfini 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
figure 3.16 – Chemin sommet-disjoints figure 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 } .
;
figure 3.18 – Graphe arc-disjoints figure 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’effectuer en temps polynomial : le problème est dit alors NP-complet [71]. Néanmoins, lorsque les paramètres sont définis (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’effectue 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 flot) ; 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, flot : f) : flot 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 flot 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 figure 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 flot 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 flot 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
s
t
figure 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 fixé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 effet, il lui suffirait 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 Classification des problèmes
Le tableau 3.7 récapitule les différents problèmes relatifs à la recherche de chemins disjoints dans les graphes et leurs classes de complexité respectives. Cette classification 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 différents problèmes de chemins disjoints
Nombre de chemins k borné Nombre de chemins k indéfini 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 fiabilité 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 effet 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écificité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 fiable 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 Diffie-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 figure 4.23.
sous-cl´ex
s
sous-cl´ey
t
figure 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 effet, il suffirait 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é afin de chiffrer 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, afin 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 enfin 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éfinie 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éfinition : 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’authentification de bout en bout basée les identités des hôtes [94]. Ce protocole s’appuie en effet 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’authen- tification 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 Diffie-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
figure 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 figure 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 Diffie-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
43
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
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
figure 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 fils. Cet algorithme exécuté de façon distribuée sur chaque nœud assure que les nœuds ont des coordonnées hyperboliques uniques.
figure 5.27 – Disque de Poincaré : exemple d’un arbre régulier d’ordre trois
Algorithme 3 : Calcul des coordonnées des fils 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 identifié, 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éfinit 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’effectue 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 fine, 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éfinie dans les travaux [7, 36] ; nous y détaillons le principe utilisé dans la définition du modèle de notre DHT ainsi que le mécanisme de nommage proposé. Aussi, la technique de stockage des couples
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
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 >)
figure 5.28 – Processus de génération de IDCLOAK
5.3.3 Stockage des couples
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
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
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
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
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
Processus
ID CLOAK, numero´ de port Espace d’adressage et de nommage Identification (cle)´ Espace de nommage ID CLOAK
Decouplage´ DHT ⇒ Localisation (valeur) Espace d’adressage AD overlay
figure 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
1 DHT
2 3 4 5
non AD newAD () ID newID() AD newAD () pair joignable? ´echanges itinerance´ ov ← ov ← ov ← ov oui
figure 5.31 – Architecture simplifiée du mécanisme de mobilité
3. Pour des raisons de simplicité, IDCLOAK est simplement désigné par ID dans la figure 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 effet 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écifications 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 confidentialité 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 Diffie-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 figure 6.32 présente une vue globale de l’architecture SEMOS qui montre comment les interactions ont lieu entre diffé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
figure 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 Identification 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éeChiffrée()
figure 6.33 – Structure simplifié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’authenti- fication à 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 Diffie-Hellman et le schéma à seuil (k, n) de Shamir. Le procédé d’échange de clés proposé consiste en effet à 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 figure 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 trafic 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
figure 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 Identification Entête Identification 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()
figure 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é
figure 6.37 – Les diffé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
q2
echange´ du message Re-Hello
figure 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 modifica- tions 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 trafic 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’offrir 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éfis 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. Enfin, comme SEMOS gère simultanément plusieurs sessions, chaque pair devrait alors maintenir une table de correspondance qui associe chaque session à une horloge logique afin 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 confiance 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éfinis par le protocole du routage implémenté par l’infrastructure de routage sous-jacente. Un chemin Pi est donc formellement défini 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érifient 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éfinis mais sont déterminés dynamiquement pendant le tranfert des paquets. L’algorithme consiste en effet à 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éfinissant 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 effectivement 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 afin 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éfinie (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. Afin 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 diffé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 effet 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 effet 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écifique à l’infrastructure CLOAK ; il est défini 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 figure 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). Enfin, 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 figure 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
q3
notification 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 confiance
q5
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 suffit 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 Diffie-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 chiffre avec gsasb (mod p) et l’envoie à Bob ; 12. Bob reçoit le challenge, le déchiffre 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 confiance sont choisis et comment la délégation de négociation de clés s’effectue.
Algorithme 17 : Délégation de négociation de clé un proxy de confiance Input : s, t, ListePairsDeConfiance begin proxy ← s ;
dmin ← distanceH(s, t) ; foreach nœud ∈ ListePairsDeConfiance 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 confiance 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 com- promettre 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
91
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 figure 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 figure 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