Simulations et résultats

3.2.4.1. Environnement de simulation

Les primitives cryptographiques nécessitent un traitement additionnel pour les nœuds du réseau. Ce traitement se fait au détriment des performances du protocole et du réseau ad hoc. Pour cet effet, nous avons effectué des simulations pour mesurer l‟impact des systèmes cryptographiques sur les performances du réseau et du protocole.

Nous avons remarqué que dans la littérature, les travaux de recherche qui traitent le problème des signatures numériques dans les réseaux ad hoc, et plus précisément pour le protocole OLSR, n‟implémentent pas des signatures numériques. Dans des cas, ils se contentent d‟ajouter des temporisations avant l‟émission et/ou après la réception pour simuler le temps additionnel causé par les algorithmes cryptographiques [87]. Dans d‟autres cas, ils ne présentent que la surcharge (overhead) engendrée par les tailles des messages de signature [83].

Nous avons effectué les simulations sur le simulateur réseau NS2 sous la plateforme

LINUX 2.6.11-6mdksmp. L‟annexe A donne une présentation détaillée de ce simulateur.

Pour le protocole OLSR, nous avons utilisé l‟implémentation de l‟université de Mursia sous NS2 [88]. Pour l‟implémentation des algorithmes cryptographiques nous avons utilisé Crypto++.5.44, une bibliothèque C++ libre, qui offre l‟implémentation d‟un éventail choix d‟algorithmes cryptographiques. L‟annexe B présente la méthode d‟intégration de la bibliothèque Crypto++ dans NS2. L‟annexe C présente une partie du code source de l‟implémentation des messages de signature.

Pour le choix des fonctions de hachage et des algorithmes cryptographiques, nous nous sommes appuyés sur le benchmark de test fourni sur le site web de la bibliothèque4 Crypto++. Ainsi, nous avons utilisé la fonction de hachage MD5, l‟algorithme AES pour le cryptage symétrique et l‟algorithme DES pour le cryptage asymétrique. Le choix de ces primitives cryptographiques s‟est basé sur le critère du plus faible temps nécessaire pour chaque algorithme à restituer son résultat.

3

Voir Annexe A

Chapitre 4 Signature des messages de contrôle

88

3.2.4.2. Paramètres des simulations

Pour la configuration des paramètres de simulation, nous avons utilisé un nombre de nœuds variable entre 10 et 100 par pas de 10 ; la vitesse des nœuds varie entre 0 m/s et 40m/s par pas de 5. Le temps de simulation est 300 s. La surface de simulation fait 1000m x 1000m. La file d‟attente dans les nœuds est de type DropTail qui consiste à supprimer tous les paquets en cas de débordement de la file, et elle a une taille de 50 paquets. La taille des paquets de données est de 512 octets. Le trafic considéré est de type UDP avec un flux CBR. Les nœuds se déplacent suivant le modèle de mobilité Random Way Point de NS2 et le trafic de données est généré aléatoirement.

Pour donner plus de validité aux résultats obtenus, chaque simulation est répétée une trentaine de fois, avec des scénarios différents les uns des autres. Le résultat final est obtenu en calculant la moyenne des trente résultats déjà obtenus. Cette opération représente un handicap pour l‟avancement des mesures, parce qu‟elle demande beaucoup de temps allant dans certains cas jusqu‟à une dizaine de jours pour tracer un seul graphe.

3.2.4.3. Résultats des simulations

Nous avons réalisé des simulations pour trois cas de figures différents. Le premier concerne le standard OLSR comme il a été implémenté dans umOLSR que nous avons noté OLSR. Le deuxième contient l‟implémentation des signatures comme nous l‟avons proposé, et que nous avons nommé secOLSR. Et le troisième représente l‟implémentation d‟un réseau OLSR dans lequel des attaquants effectuent des attaques de type „trou noir‟ qui est noté OLSRattacked. Cette attaque permet d‟absorber le trafic de routage, ce qui peut avoir des résultats néfastes en provoquant un partitionnement du réseau et la perte de connectique entre les nœuds.

Figure 3. 12- délai de bout en bout en termes de la vitesse des nœuds

La figure 3.12 montre le comportement du réseau en termes de délai de bout en bout en milliseconde pour les différents cas de figures simulées. Nous remarquons un comportement normal du délai de bout en bout, car il augmente avec l‟augmentation de la vitesse de déplacement des nœuds; et ceci est vrai pour OLSR, secOLSR et OLSR- attacked. D‟autre part, il est à noter que secOLSR engendre un délai additionnel causé par les algorithmes de cryptage, mais il reste raisonnable devant le délai causé par une attaque de trou noir qui absorbe le trafic et oblige les nœuds à chercher des chemins plus longs pour trouver leurs destinations.

0 2 4 6 8 10 12 14 0 5 10 15 20 25 30 35 40 vitesse (m/s)

délai

OLSR sec-OLSR OLSR-attacked

Partie 2 Contributions

89 Figure 3. 13 – nombre des boucles de routage durant la simulation

La figure 3.13 montre le nombre de boucles de routage dans le réseau durant la simulation. Nous remarquons bien que secOLSR réduit considérablement les boucles dans le réseau, ainsi des attaques par modification ou injection de trafic en guise de création des boucles de routage dans le réseau auront un effet négligeable et ceci grâce aux mécanismes de sécurité de secOLSR.

Figure 3. 14 – nombre des collisions dans le réseau durant la simulation

La figure 3.14 montre le nombre de collisions survenues dans le réseau. Nous remarquons que ce phénomène devient très rare avec secOLSR par rapport à OLSR ou OLSR-attaqué. Ceci, parce que secOLSR détruit tout paquet qui n‟est pas signé ou dont la signature n‟est pas vérifiée. De cette façon le réseau se débarrasse de tout message inutile ou non autorisé à circuler.

0 20 40 60 80 100 120 140 0 5 10 15 20 25 30 35 40 vitesse (m/s)

routing loops

OLSR

sec-OLSR OLSR-attacked 0 1000 2000 3000 4000 5000 6000 7000 0 5 10 15 20 25 30 35 40 vitesse (m/s)

Collisions

OLSR sec-OLSR OLSR-attacked

Chapitre 4 Signature des messages de contrôle

90

Figure 3. 15 – total des paquets perdus durant la simulation

La figure 3.15 montre le nombre de paquets éliminés durant la simulation. Pour les trois cas de figures, ce paramètre augmente avec le nombre de nœuds dans le réseau. Mais, la valeur affichée par secOLSR dépasse de peu celle affichée par OLSR ou OLSRattacked. Ce comportement est justifié par le fait que secOLSR élimine volontairement plus de paquets que OLSR ou OLSRattacked.

0 10000 20000 30000 40000 50000 60000 70000 10 20 30 40 50 60 70 80 90 100 nbr de nœuds

tot pkt droped

OLSR

sec-OLSR OLSR-attacked

Partie 2 Contributions

91

Dans le document Sécurité du routage dans les réseaux sans fil spontanés : Cas du protocole OLSR (Page 107-111)