Modélisation de XCORE

Introduction

Dans le domaine des réseaux de communication, les besoins de connectivité sans fil et de communication mobile sont en évolution permanente. Les réseaux ad hoc ont la capacité de satisfaire une communication mobile de nature temporaire, celle-ci sans une infrastructure préexistante. Cependant, pour de nombreuses raisons, les nœuds dans un MANET peuvent préférer de ne pas collaborer. Par exemple, chaque nœud doit utiliser une partie de ses ressources (CPU, bande passante, batterie, …) pour acheminer le trafic des autres nœuds, ceci sans gain personnel et peut préférer, à court terme, de ne pas faire partie du réseau.
L’introduction des notions de Réputation et de Punition, ou de Paiement, peut inciter les nœuds à jouer pleinement leur rôle pour ne pas perdre leur bon comportement. Parmi les solutions qui se fondent sur le paiement nous pouvons citer Virtual Currency (monnaie virtuelle). Parmi celles qui se fondent sur la Réputation et sur la Punition nous donnons CONFIDANT et plus particulièrement CORE, sur laquelle porte l’objet de notre proposition.
Nous avons choisi de travailler avec CORE car il met les nœuds qu’on considère égoïste dans une liste noire tandis que CONFIDANT supprime ces nœuds définitivement du réseau, ce qui va engendrer des fréquentes déconnexions.
Dans cette partie nous rappelons du fonctionnement de base de CORE et présentons quelques unes de ses vulnérabilités, afin de proposer un nouvel algorithme.

Quelques vulnérabilités de CORE

Dans l’attaque Cooperative Blackhole, deux nœuds malicieux peuvent coopérer pour avoir une bonne réputation. Un nœud attaquant peut aussi envoyer un message annonçant le mauvais comportement d’un nœud légitime (Black mail). Les nœuds peuvent stocker des liens inexistants provoquant ainsi l’attaque Overflow. Ces vulnérabilités peuvent conduire à un Blackhole. Dans notre algorithme nous essayons de parer aux trois vulnérabilités citées en dotant CORE d’un mécanisme appelé table DRI.

Architecture proposée : XCORE

La figure 6.2 illustre le fonctionnement de XCORE que nous avons proposé.

Implémentation et test de CORE et XCORE

L’implémentation des algorithmes est présentée sur les annexes B et C. Pour les tests nous avons fait notre programme sur Dev-C++ du compilateur C. Pour tester notre proposition, nous avons donné en entrée le nombre d’itérations du DRI, si le taux Taux_Env_Reception du DRI appartient à [0,0] nous déclarons que ce lien est fictif (c’est une attaque Overflow). Sinon lorsqu’ un mobile envoie un message de route, nous évaluons ce message. Si c’est une route error, nous allons vérifier sa validité en regardant le DRI. Si le Taux_Env_Reception est [0,0] alors nous confirmons que ce nœud est défectueux sinon nous considérons que ce message n’est pas valide (s’il s’agit d’une attaque Blackmail) et dans ce cas nous continuerons à évaluer la réputation. Si la réputation est ≤ 0 nous considérons que ce nœud est un nœud de déni de service (un nœud Selfish) sinon nous déclarons que ce nœud est un nœud coopérant.
Les paramètres d’évaluations sont représentés dans le tableau 14.

Attaque Black mail sur CORE et XCORE

Dans ces tests nous évaluons l’attaque blackmail. Si nous recevons un message « route error », nous regardons la table DRI, si le taux est dans [0,0], nous considérons que ce nœud est effectivement défectueux, sinon nous considérons que ce message a été envoyé par un nœud attaquant et nous rejetons ce message c’est-à-dire nous n’allons pas laisser l’attaque blackm ail passer. Ces tests sont illustrés par les figures 6.3 a) et b).

Attaque Overflow sur CORE et XCORE

Pour tester notre proposition, nous avons donné en entrée le nombre d’itération du DRI, si le taux Taux_Env_Reception du DRI appartient à [0,0] nous déclarons que ce lien est fictif c’est-à-dire entre temps un nœud attaquant a stocké des liens inexistants pour mettre en œuvre l’attaque Overflow.

Attaque Selfish sur CORE et XCORE

Ce test nous permet de voir si un nœud est égoïste ou non. Cela se base sur l’évaluation de sa réputation. Un nœud peut recevoir un faux message de « route error » et il va supprimer ce lien dans sa table alors que ce nœud fonctionnement correctement. Si nous recevons un message nous évaluons si c’est valide ou non et si c’est valide, nous évaluons maintenant la réputation. Si la réputation est ≤ 0 nous considérons que ce nœud est un nœud de déni de service (un nœud Selfish) sinon nous déclarons que ce nœud est un nœud coopérant.

Conclusion

Dans cette partie nous avons procédé à une simulation de certaines attaques comme la non coopération, sleep deprivation, Blackhole, saturation de la bande passante. Nous avons proposé un modèle mathématique qui peut être utilisé pour évaluer les attaques. Nous avons fait des études comparatives sur les différents logiciels de simulation utilisés afin de pouvoir évaluer l’impact des attaques dans ce type de réseau. De plus nous avons présenté le mode de fonctionnement de CORE et avons dégagé quelques unes de ces vulnérabilités. Ensuite nous avons proposé un nouvel algorithme de fonctionnement qui améliore de base de CORE et que nous avons nommé XCORE. Cet algorithme permet de résister aux attaques Blackhole coopérative, Black mail, Overflow, Selfish. En raison de l’absence de simulateurs qui prennent en compte ce protocole CORE, nous avons implémenté nous même CORE et XCORE dans Dev-C++ en vue de procéder à des tests comparatifs. Ces tests ont permis de montrer que les attaques précitées ne passent plus avec XCORE ce qui valide notre architecture.