ROUTAGE MULTICHEMIN SECURISE POUR UN RESEAU DE CAPTEURS ... › document › TH3725.pdf · que le GPS ni la synchronisation des horloges (ce qui est difficile à réaliser pour un

DEPARTEMENT D'INFORMATIQUE

MEMOIRE Présenté par

BRAHIM Nacera.

Pour obtenir

LE DIPLOME DE MAGISTER Spécialité Informatique

Ecole doctorale

Option : Sciences et Technologies de l’Information et de la Communication

STIC.

Intitulé :

ROUTAGE MULTICHEMIN SECURISE POUR UN RESEAU DE CAPTEURS SANS FIL VIDEO.

ATTAQUE WORMHOLE: ETUDE ET CONTRE MESURE.

Soutenu le 29/05/2012 devant le jury :

Président du jury D.BENHAMAMOUCHE : Professeur - Université d’Oran.

Examinateur H.HAFFAF : Professeur - Université d’Oran.

Examinateur L.LOUKIL : MC-A - Université d’Oran .

Encadreur K.M.RAHMOUNI : Professeur - Université d’Oran.

Co-Encadreur KECHAR Bouabdellah : MC-A - Université d’Oran.

Année Universitaire : 2011/2012

i

Dédicace

Je dédie ce modeste travail à…

Très cher père qui a su faire de moi ce que je suis.

Ma très chère Mère pour sa grande affectation, Sa tendresse, son dévouement et ses prières

pour mon bonheur, dont je ne pouvais jamais assez la remercier.

A ma belle mère ainsi que mon beau père pour leurs encouragements.

A mon mari AEK pour son soutient durant la réalisation de ce travail.

Mes anges Mohamed Iyad & Israa Fatima Zohra.

Mes grandes mères que j’aime du fond du cœur.

Mon adorable frère AEK.

Et mes chères sœurs Fatima & Hanane.

A tous ceux qui m’aiment.

ii

Remerciements

Je remercie premier lieu DIEU, le tout puissant, qui m’a donné la force, la volonté et surtout

le courage pour accomplir ce modeste mémoire.

Je tiens à remercier Monsieur K.RAHMOUNI, et Monsieur B.KACHAR, pour m’avoir

donné l’opportunité de travailler sur ce sujet. J’aimerais leurs adresser mes plus vifs

remerciements pour leurs suivi.

Je tiens particulièrement à témoigner ma profonde gratitude à Monsieur B. KECHAR, pour sa

disponibilité, son aide, ses critiques constructives, ses explications et suggestions et surtout sa

rigueur tout au long de la réalisation de ce projet.

Je suis reconnaissante envers Pr BENHAMAMOUCHE d’avoir présidé le jury.

Je remercie très sincèrement Monsieur L. LOUKIL ainsi que H. HAFFAF, j'ai beaucoup

apprécié leur participation au jury.

J’adresse de tout mon cœur mes remerciements à mes très chers parents, je leurs suis

infiniment reconnaissante pour leur soutien illimité. Qu’ils trouvent dans ce travail le fruit de

leurs sacrifices.

Enfin, je remercie mon mari et tous les membres de ma famille pour leurs encouragements.

iii

Résumé

Un réseau de capteurs sans fil ne requiert aucune infrastructure préexistante ni aucune

autorité centrale. C’est un réseau déployé de façon dynamique. Les nœuds doivent participer

activement et coopérer avec les fonctions basics dans le réseau telles que le routage et la

sécurité.

Souvent déployés dans des environnements hostiles, les réseaux de capteurs sans fil sont

sujets à différentes types d'attaques. Parmi elles, il y a l'attaque Wormhole qui est une attaque

sévère où deux nœuds malveillants redirigent le trafic entre deux extrémités. Ces nœuds

malicieux manipulent l’algorithme de routage, contrôlant ainsi l’information partagée entre

les nœuds légitimes. La plupart des solutions proposées dans la littérature nécessitent des

ressources exceptionnelles (GPS ou synchronisation d’horloges).

Dans le second chapitre, nous détaillant l’attaque Wormhole, et ses différents modes, nous

présentons une vaste revue de la littérature des plus importantes solutions proposées pour y

faire face.

Dans ce travail de recherche, nous proposons une nouvelle solution de lutte contre les

attaques Wormhole dans le contexte des réseaux de capteurs sans fil.

Cette solution exploite le concept du RTT pour calculer la distance entre deux nœuds voisins

à chaque saut de RREP, durant la découverte de route d’AODV avant même de commencer la

transmission de données, Raison pour laquelle, elle ne nécessite aucun matériel additionnel tel

que le GPS ni la synchronisation des horloges (ce qui est difficile à réaliser pour un réseau de

capteurs sans fils).

Mots-clés : Réseaux de capteurs sans fil, Sécurité, AODV, attaque Wormhole, RCSF, WSN,

routage, Wireless Sensor Networks, RTT, routage multi-chemins.

iv

Organisation du mémoire

Ce mémoire est organisé comme suit :

Pour mieux cerner les enjeux de notre étude, nous présenterons dans le premier chapitre un

préambule sur les réseaux de capteurs sans-fil, leur architecture, leurs caractéristiques, leur

domaines d’application et finissons par les vulnérabilités et les attaques portées sur ces

réseaux.

Le second chapitre concerne l’étude détaillée de l’attaque Wormhole dans les RCSF en

définissant son impact sur les protocoles de routage tel qu’AODV.

Ensuite Nous exposons les différents modes de l’attaque. Nous terminerons ce chapitre par la

classification des solutions de sécurité proposées dans la littérature pour détecter et isoler cette

attaque.

Le troisième chapitre traite notre contribution dans la détection distribuée de l’attaque

Wormhole dans les RCSFs. On commencera par une description du RTT sur lequel se base le

calcule de la distance dans notre mécanisme de détection. Nous abordons aussi, brièvement,

les protocoles de routage AODV et AOMDV.

Enfin nous présentons l’extension des formats RREQ & RREP en vue d’intégrer notre

solution dans AODV & AOMDV.

Le quatrième chapitre, décrit la mise en œuvre de notre mécanisme distribué de détection de

l’attaque Wormhole durant la découverte de route et son intégration dans le simulateur réseau

NS2, et expose les résultats d'implémentation et de tests.

Enfin, notre mémoire s’achève par une conclusion générale résumant les grands points qui ont

été abordé ainsi que des perspectives pour les travaux futurs dans ce domaine.

v

Liste des acronymes

AODV Ad hoc On Demand Distance Vector.

AOMDV Ad hoc On Demand Multipath Distance Vector.

DSR Distance Source Routing.

GPS Global Positioning System.

LORAN LOng RAnge Navigation.

MAC Medium Access Control.

MANET Mobil Ad hoc NETwork.

NS Network Simulator.

RCSF Réseau de Capteurs Sans Fil.

RREQ Route REQuest message.

RREP Route REPly message.

RTT Roud Trip Time.

WSN Wireless Sensor Networks.

Table des matières CHAPITRE I : RESEAUX DE CAPTEURS SANS FIL. 1.1. Introduction ................................................................................................. 3 1.2. Anatomie d'un nœud capteur ....................................................................... 4 1.3. Architecture d’un RCSF .............................................................................. 6 1.4. Domaines d’applications des RCSF ............................................................ 7 1.4.1. Applications militaires ........................................................................................ 7 1.4.2. Applications médicales ....................................................................................... 8 1.4.3. Applications environnementales ....................................................................... 8 1.4.4. Applications commerciales ................................................................................ 8 1.4.5. La Domotique ...................................................................................................... 8 1.4.6. Surveillance des grandes structures civiles ...................................................... 9 1.4.7. Applications métier ............................................................................................. 9 1.4.8. Application en agriculture .................................................................................. 10 1.4.9. Détection des catastrophes naturelles ............................................................... 10 1.5. Classification des applications des RCSF ................................................... 10 1.5.1. Applications à contrainte temporelle ................................................................ 10 1.5.2. Applications orientées événements ................................................................... 10 1.5.3. Applications basées sur les requêtes ................................................................. 11 1.5.4. Applications hybrides ......................................................................................... 11 1.6. Communication dans les RCSF .................................................................. 11 1.6.1. Architecture de la communication basée sur le modèle OSI ......................... 11 1.6.2. Rôle des couches ................................................................................................. 12 1.6.3. Plans de gestion ................................................................................................... 13 1.7. Contraintes des RCSF ................................................................................. 13 1.7.1. Absence d'infrastructure ..................................................................................... 13 1.7.2. Ressources limitées ............................................................................................. 14 1.7.3. Durée de vie du réseau ........................................................................................ 14 1.7.4. Bande passante limitée ....................................................................................... 14 1.7.5. Passage à l’échelle ............................................................................................... 14 1.7.6. Topologie dynamique ......................................................................................... 14 1.7.7. Auto organisation du réseau............................................................................... 15 1.7.8. Agrégation de donnée ......................................................................................... 15 1.7.9. Sécurité physique limitée ................................................................................... 16 1.8. Sécurité (exigence/limites) des RCSF ......................................................... 16 1.8.1. Objectifs de Sécurité pour les données collectées .......................................... 16 1.8.2. Vulnérabilités des RCSF .................................................................................... 18 1.8.3. Attaques sur les RCSFs ...................................................................................... 20 1.8.4. Classification des attaques : ............................................................................... 21 1.8.5. Principales attaques sur les RCSFs ................................................................... 22 1.9. Conclusion .................................................................................................. 24 CHAPITRE II : Attaque Wormhole: Etat de l'art. 2.1. Introduction ................................................................................................. 25 2.2. Attaque Wormhole ...................................................................................... 26 2.3. Mise en application l’attaque Wormhole .................................................... 26 2.4. Impact de l’attaque Wormhole sur les protocoles de routage ..................... 27

2.4.1. Impact de l’attaque sur les protocoles proactifs .............................................. 28 2.4.2. Impact de l’attaque sur les protocoles réactifs ................................................ 28 2.5. Protocoles locaux d'émission ...................................................................... 31 2.6. Modes de l'attaque Wormhole ..................................................................... 34 2.6.1. Wormhole par encapsulation ............................................................................. 34 2.6.2. Wormhole par un réseau externe ....................................................................... 35 2.6.3. Wormhole par transmission à forte puissance ................................................. 35 2.7. Attaques réseaux dues à l'attaque Wormhole ............................................. 36 2.8. Les approches de détection du Wormhole ................................................. 37 2.8.1. Approches centralisées ....................................................................................... 38 2.8.2. Approches décentralisées ................................................................................... 43 2.9. Conclusion .................................................................................................. 52 CHAPITRE III : Solution proposée pour la détection et l'isolation de l'attaque Wormhole. 3.1. Introduction ................................................................................................. 54 3.2. Méthode distribuée pour la détection de l’attaque Wormhole .................... 55 3.3. Le protocole AODV .................................................................................... 57 3.4. Intégration dans AODV .............................................................................. 58 3.5. Le protocole AOMDV ................................................................................ 59 3.6. Conception de l'attaque Wormhole ............................................................. 63 3.7. Conclusion .................................................................................................. 63 CHAPITRE IV : simulation & expérimentation 4 Chapitre 4 : implementation & experimentation ........................................... 64 4.1. Introduction ................................................................................................. 64 4.2. Environnement de simulation ..................................................................... 65 4.3. Implémentation d’AODV sous NS-2 .......................................................... 66 4.4. Architecture d’un nœud dans ns2 ................................................................ 67 4.5. Implémentation de l’attaque Wormhole...................................................... 67 4.6. Implémentation de la solution proposée ..................................................... 73 4.7. Paramètres de la simulation ........................................................................ 77 4.8. Résultats de simulation et analyse............................................................... 77 Conclusion générale & Perspectives ......................................................................... 81 Références ................................................................................................................. 83

Liste des figures Figure I.1: Anatomie d’un nœud capteur. ................................................................................ 2 Figure I.2: Architecture des réseaux de capteur sans fil........................................................... 3 Figure I.3 : Domaines d’application des RCSF ........................................................................ 4 Figure I.4 : Modèle en couches pour la communication dans les RCSF ............................... 9 Figure I.5: Agrégation de données ........................................................................................... 12 Figure I.6: Sécurité dans les RCSF : propriétés, challenges et solutions ................................. 17 Figure I.7: Taxonomie des challenges et solutions de sécurité dans les RCSF. ...................... 18 Figure I.8: Classification des attaques par stallings. ................................................................ 20 Figure I.9: Brouillage sur un nœud agrégateur. ....................................................................... 21 Figure II. 1: Attaque Wormhole. .............................................................................................. 24 Figure II. 2 : impact de l’attaque Wormhole sur RREQ. ......................................................... 27 Figure II. 3: effet de l’attaque Wormhole sur le RREQ et RREP d’ AODV. .......................... 28 Figure II. 4: Attaque Wormhole contre les protocoles locaux d’émission. .............................. 29 Figure II. 5 : exemple d’une attaque Wormhole ...................................................................... 30 Figure II. 6 : Wormhole par encapsulation .............................................................................. 31 Figure II. 7: Attaques dues à l’attaque Wormhole. .................................................................. 33 Figure II. 8: Augmentation du nombre de voisins des nœuds victimes du Wormhole ............ 34 Figure II. 9 : Détection du Wormhole avec le dessin multi dimensionnel ............................... 35 Figure II.10: liste de requêtes d’un nœuds recevant trois requêtes .......................................... 36 Figure II. 11: reply table après la transmission d'une réponse ................................................. 37 Figure II. 12 : liste des réponses d’un nœud recevant trois réponses ....................................... 37 Figure II. 13: Lien Wormhole entre deux séparés par un obstacle .......................................... 40 Figure II.14: Utilisation des clés locales pour le cryptage/décryptage des paquets ................. 43 Figure II. 15: Transformation des graphes. .............................................................................. 45 Figure II. 16: Phase de confirmation –WORMEROS- ............................................................ 48 Figure III.1: déroulement du mécanisme distribué de détection de l’attaque Wormhole. ....... 52 Figure III.2 : extension de l’entete RREQ. ............................................................................... 54 Figure III. 3: extension de l’entete RREQ. ............................................................................... 54 Figure III.4: Organigramme du traitement des paquets RREQ. ............................................... 55 Figure III.5: Organigramme de la sélection des chemins disjoints. ......................................... 56 Figure III.6: Organigramme de traitement d’un message RREP. ............................................ 58

Liste des tableaux Tableau 1 : procédure du traitement d’un paquet reçus. .......................................................... 64 Tableau 2 : procédure qui se charge de transmettre le paquet via le tunnel ............................. 65 Tableau 3 : modification portées sur l’entête du RREQ. ......................................................... 66 Tableau 4 : modification portées sur l’entête du RREQ. ......................................................... 66 Tableau 5 : stockage des temps de transmission & réception du RREQ. ................................ 67

Tableau 6 : calcule de distance utilisant le RTT. ..................................................................... 68 Tableau 7 : Paramètres de simulation. ..................................................................................... 68

Chapitre 1 Réseaux de capteurs sans fil

- 3 -

1

Réseaux de

capteurs sans

fil

1.1. Introduction

Les progrès réalisés ces dernières décennies dans les domaines de la microélectronique, de

la micromécanique, et des technologies de communication sans fil, ont permis de produire

avec un coût raisonnable des composants de quelques millimètres cubes de volume. Ces

derniers, appelés capteurs. Un capteur est un dispositif qui transforme l'état d'une grandeur

physique observée en une grandeur utilisable, exemple : une tension électrique, une

hauteur de mercure... [32][41].


- 4 -

Les capteurs intègrent : une unité de capture chargée de collecter des grandeurs physiques

(température, humidité, vibrations) et de les transformer en grandeurs numériques, une

unité de traitement informatique et de stockage de données et un module de transmission

sans fil.

Grâce à ses divers avantages, cette technologie a pu s'instaurer comme acteur

incontournable dans les architectures réseaux. Le média hertzien offre en effet des

propriétés uniques, qui peuvent être résumées en trois points : la facilité et le coût réduit du

déploiement, ainsi que l'ubiquité de l'information.

Le déploiement de plusieurs nœuds capteurs d'une manière autonome, en vue de collecter

et transmettre des données environnementales vers le sink, forme un réseau de capteurs

sans fil.

Le besoin d'un suivi continu d'un environnement donné est assez courant dans diverses

activités de la société. Les processus industriels, les applications militaires de tracking, le

monitoring d'habitat, ainsi que l'agriculture de précision ne sont que quelques exemples

d'une panoplie vaste et variée d'applications possibles du suivi continu offert par les RCSF.

Grâce à ce potentiel riche en applications, les RCSF on su se démarquer de leur origine

MANET et attirer de grandes firmes à travers le monde, telles que IBM, Sun, Intel et

Philips. Malheureusement, les RCSF ne sont pas parfaits !

La sécurité est d’une importance primordiale dans les réseaux sans fil plus qu’elle l’a été

dans les réseaux filaires. Elle inclut aussi bien la protection des données contre les pertes et

la corruption, que leur confidentialité. Cependant, l’application des techniques classiques

(cryptage, signature,…) utilisée dans les environnements fixes est loin d’être évidente dans

les réseaux mobiles.

1.2. Anatomie d'un nœud capteur

Un nœud capteur (mote) contient quatre unités de base : l'unité de capture ou d’acquisition,

l'unité de traitement, l'unité de transmission, et l'unité de contrôle d'énergie. Il peut contenir

également, suivant son domaine d'application, des modules supplémentaires tels qu'un

système de localisation comme GPS (Global Positioning System), ou bien un système

générateur d'énergie (cellule solaire). On peut même trouver des capteurs, un peu plus


- 5 -

volumineux, dotés d'un module de mobilité chargé de déplacer le nœud en cas de

nécessité.[1]

Figure 1. 1: Anatomie d’un nœud capteur.

• l'unité de capture : elle est composée de deux sous unités d'un capteur qui va obtenir

des mesures sur les paramètres environnementaux et d'un convertisseur

Analogique/Numérique qui va convertir l'information relevée (en signal analogique) et la

transmettre à l'unité de traitement(en signal numérique);

• l'unité de traitement : elle dispose de deux interfaces, une interface pour l'unité

d'acquisition et une interface pour l'unité de transmission. Cette unité comprend un

processeur associé généralement à une petite unité de stockage et fonctionne à l'aide d'un

système d'exploitation spécialement conçu pour les micro-capteurs (TinyOS par exemple).

Elle acquiert les informations en provenance de l'unité d'acquisition et les envoie à l'unité

de transmission. L’unité de traitement est chargée également d'exécuter les protocoles de

communications qui permettent de faire collaborer le nœud avec les autres nœuds du

réseau. Elle peut aussi analyser les données captées pour alléger la tâche du nœud puits

(sink).

• l'unité de transmission : l'unité de transmission est responsable de toutes les émissions

et réceptions de données via un support de communication radio. Elle peut être de type

optique, ou de type radio-fréquence. Les communications de type optique sont robustes

vis-à-vis des interférences électriques. Néanmoins, elles présentent l'inconvénient d'exiger

une ligne de vue permanente entre les entités communicantes. Par conséquent, elles ne

peuvent pas établir de liaisons à travers des obstacles. Tandis que Les communications de

type radio-fréquence sont beaucoup plus gourmandes en terme d’énergie.

• l'unité de contrôle d'énergie : comme le montre la figure ci-dessous, les trois unités

précédentes sont alimentées par une ressource énergétique (généralement une batterie). en

conséquence de sa taille réduite, la ressource énergétique dont il dispose est limitée et


- 6 -

généralement irremplaçable, ce qui influe directement sur la durée de vie du réseau entier.

cette unité est responsable de répartir l'énergie disponible aux autres modules et de réduire

les dépenses en mettant en veille les composants inactifs par exemple. Elle peut aussi gérer

des systèmes de rechargement d'énergie à partir de l'environnement observé telles que les

cellules solaires, afin d'étendre la durée de vie totale du réseau.

1.3. Architecture d’un RCSF

Figure 1. 2: Architecture d’un RCSF[33].

Ce type de réseaux consiste en un grand nombre de nœuds capteurs capables de récolter et

de transmettre des données environnementales d'une manière autonome. La position de ces

nœuds n'est pas obligatoirement prédéterminée. Ils sont dispersés aléatoirement à travers

une zone géographique, appelée champ de captage, qui définit le terrain d'intérêt pour le

phénomène capté. Les données captées sont acheminées grâce à un routage multi-saut à un

nœud considéré comme un "point de collecte", appelé nœud puits (sink).

Les données collectées par ces nœuds capteurs sont acheminées grâce à un routage multi-

saut à une ou plusieurs stations de base ou nœud puis ‘sink’. Ce dernier est un point de

collecte de données capturées. Il peut communiquer les données collectées à l’utilisateur

final à travers un réseau de communication, éventuellement l’Internet ou un satellite.

L’utilisateur peut à son tour utiliser la station de base comme passerelle, afin de

transmettre ses requêtes au réseau (Voir la figure 1.2).

En effet, Les réseaux de capteurs sans fil - Wireless Sensor Networks (WSN) - sont

considérés comme un type spécial de réseaux ad hoc.


- 7 -

Ils partagent plusieurs propriétés en commun, telles que l'absence d'infrastructure et les

communications sans fil. Mais l'une des différences clés entre les deux architectures est le

domaine d'application. Contrairement aux réseaux MANET (Mobil Ad hoc NETwork), qui

n'ont pas pu connaître un vrai succès, les RCSF ont su attirer un nombre croissant

d'industriels, vu leur réalisme et leur apport concret.

1.4. Domaines d’applications des RCSF

Figure 1. 3: Domaines d’application des RCSF.

Le champ d'applications des réseaux de capteurs est de plus en plus élargi, grâce aux

évolutions techniques que connaissent les domaines de l'électronique et des

télécommunications. Parmi ces évolutions, on peut citer la diminution de taille et du coût

des capteurs, ainsi que l'élargissement des gammes de capteurs disponibles (thermique,

optique, vibrations, ...) et l'évolution des supports de communication sans fil.

Les réseaux de capteurs peuvent se révéler très utiles dans de nombreuses applications

lorsqu'il s'agit de collecter et de traiter des informations provenant de l'environnement.

Parmi les domaines où ces réseaux peuvent offrir les meilleures contributions, nous citons

les domaines : militaire, environnemental, domestique, santé, sécurité, etc.

1.4.1. Applications militaires

Un réseau de capteurs déployé dans un secteur stratégique ou difficile d'accès, permet par

exemple d'y surveiller tous les mouvements (alliés ou ennemis), ou d'analyser le champ de

Monitoring médical Tracking militaire

Contrôle des structures

civiles

Surveillance dans les environnements

hostiles

Agriculture

de précision


- 8 -

bataille avant d'y envoyer du renfort (détection d'agents chimiques, biologiques ou de

radiations)

1.4.2. Applications médicales

Il existe déjà dans le monde médical, des gélules multi-capteurs pouvant être avalées qui

permettent, sans avoir recours à la chirurgie, de transmettre des images de l'intérieur du

corps humain.

1.4.3. Applications environnementales

On peut créer un réseau autonome en dispersant les nœuds dans la nature. Des capteurs

peuvent ainsi signaler des événements tels que feux de forêts, tempêtes ou inondations.

Ceci permet une intervention beaucoup plus rapide et efficace des secours. [8].

Afin de contrôler la pollution, on pourrait disperser des capteurs au-dessus d'un

emplacement industriel pour détecter et contrôler des fuites de gaz ou de produits

chimiques. Ces applications permettraient de donner l'alerte en un temps record et de

pouvoir suivre l'évolution de la catastrophe.

1.4.4. Applications commerciales

Des nœuds capteurs peuvent être utilisés pour améliorer les processus de stockage et de

livraison. Le réseau peut ainsi être utilisé pour connaître la position, l'état et la direction

d'une marchandise. Un client attendant une marchandise peut alors avoir un avis de

livraison en temps réel et connaître la position des marchandises qu'il a commandées ([9]).

1.4.5. La Domotique

La domotique est un secteur en croissance qui est aussi bien adapté pour la technologie

sans fil. Avec le développement technologique, les capteurs peuvent être embarqués dans

des appareils, tels que les aspirateurs, les fours à micro-ondes, les réfrigérateurs,... . Ces

capteurs embarqués peuvent interagir entre eux et avec un réseau externe via internet pour

permettre à un utilisateur de contrôler les appareils domestiques localement ou à distance.

Le déploiement des capteurs de mouvement et de température dans les futures maisons

dites intelligentes permet d’automatiser plusieurs opérations domestiques telles que : la

lumière s’éteint et la musique se met en état d’arrêt quand la chambre est vide, la


- 9 -

climatisation et le chauffage s’ajustent selon les points multiples de mesure, d’une alarme

est déclenchée par le capteur anti-intrusion quand un intrus veut accéder à la maison.

1.4.6. Surveillance des grandes structures civiles

Une autre classe d’applications pour réseaux de capteurs concerne le suivi de l’´etat des

structures civiles. Ces structures peuvent être des bâtiments, des ponts et des routes, voire

des aéronefs. À l’heure actuelle, la sûreté de ces structures est principalement apportée par

le biais d’inspections manuelles ou visuelles ou occasionnellement par des technologies

onéreuses en temps et en argent, telles que les rayons X et les ultrasons. Des techniques de

détection réseau permettent d’automatiser le processus, en fournissant en temps opportun

de riches informations sur un début de fissure ou d’autres dommages structuraux [1].

Les ingénieurs et les scientifiques utilisent les dernières techniques de mesure et de

détection afin de permettre une infrastructure plus intelligente et plus sûre autour du monde

entier.

Les chercheurs envisagent le déploiement de ces capteurs avec une forte densité sur les

structures, en les intégrant dans le matériau de construction comme le béton, ou en les

mettant sur la surface. Les capteurs permettent de fournir des informations concernant

l’état du pont, par exemple, en temps réel [1].

On peut inclure sur les parois des barrages des capteurs qui permettent de calculer en

temps réel la pression exercée. Il est donc possible de réguler le niveau d'eau si les limites

sont atteintes. On peut aussi imaginer inclure des capteurs entre les sacs de sables formant

une digue de fortune. La détection rapide d'infiltration d'eau peut servir à renforcer le

barrage en conséquence. Cette technique peut aussi être utilisée pour d'autres constructions

tels que ponts, voies de chemins de fer, routes de montagnes, bâtiments et autres ouvrages

d'art [17].

1.4.7. Applications métier

On pourrait imaginer devoir stocker des denrées nécessitant un certain taux d'humidité et

une certaine température (min ou max). Dans ces applications, le réseau doit pouvoir

collecter ces différentes informations et alerter en temps réel si les seuils critiques sont

dépassés.


- 10 -

1.4.8. Application en agriculture

Des nœuds peuvent être incorporés dans la terre. On peut ensuite questionner le réseau de

capteurs sur l'état du champ (déterminer par exemple les secteurs les plus secs afin de les

arroser en priorité). On peut aussi imaginer équiper des troupeaux de bétail de capteurs

pour connaître en tout temps, leur position ce qui éviterait aux éleveurs d'avoir recours à

des chiens de berger.

1.4.9. Détection des catastrophes naturelles

On peut créer un réseau autonome en dispersant les nœuds dans la nature. Des capteurs

peuvent ainsi signaler des événements tels que les feux de forêts, les tempêtes ou les

inondations. Ceci permet une intervention beaucoup plus rapide et efficace des secours

[17].

1.5. Classification des applications des RCSF

En effet, la recherche dans le domaine des capteurs est en train de vivre une

révolution importante, ouvrant des perspectives d’impacts significatifs dans de nombreux

domaines. Ainsi, on peut classifier les applications des RCSF, selon leur mode de

fonctionnement, en quatre classes d’applications : orientées temps (time driven), orientées

événements (event driven), orientées requêtes (query driven) et hybrides [12].

1.5.1. Applications à contrainte temporelle

Cette classe représente les applications où l’acquisition et la transmission des données

capturées sont liées au temps : instant précis, période d’acquisition. Cette période

d’acquisition peut être plus au moins longue selon l’application (de quelques secondes

jusqu’à quelques heures voire des jours). Ainsi, la quantité de données échangée dans le

réseau dépend de la périodicité des mesures à effectuer sur l’environnement local. La

collecte de données environnementales peut représenter un bon exemple de cette classe

d’application dans des domaines variés : agriculture, expérimentation scientifique, etc[7].

1.5.2. Applications orientées événements

Dans ce cas, les capteurs envoient leurs données seulement si un événement spécifique se

produit. On peut citer l’exemple de surveillance des feux dans les forets où un capteur

envoi des alarmes à la station de base dés que la température dépasse un certain seuil. Au


- 11 -

départ, cette classe d’application était conçue à des fins militaires, comme la surveillance

du déplacement d’objets dans le champ de bataille. Par la suite, cette classe a rapidement

trouvé de nouvelles perspectives comme le contrôle industriel, le contrôle médical des

patients, la surveillance d’édifices (barrages, ponts, voies de chemins de fer, etc.)[7].

1.5.3. Applications basées sur les requêtes

Dans ce cas, un capteur envoi de l’information uniquement suite à une demande explicite

de la station de base. Cette classe d’application est destinée aux applications adaptées à

l’utilisateur. Ce dernier peut requérir des informations à partir de certaines régions dans le

réseau ou interroger les capteurs pour acquérir des mesures d’intérêts [7].

1.5.4. Applications hybrides

Ce type d’application met en œuvre les trois modes de fonctionnement décrits

précédemment. Par exemple, dans un réseau conçu pour le suivi d’objets, le réseau peut

combiner entre un réseau de surveillance (time driven) et un réseau de collecte de données

par événements (event driven). Par exemple, pendant les longues périodes d’inactivité des

capteurs et lorsque aucun objet n’est présent, le réseau peut assurer une fonction de

surveillance [7].

1.6. Communication dans les RCSF

L’architecture de la communication des nœuds capteurs est basée sur le modèle OSI. Dans

ce qui suit nous allons la détailler

1.6.1. Architecture de la communication basée sur le modèle OSI

Le rôle de ce modèle consiste à standardiser la communication entre les composants du

réseau afin que différents constructeurs puissent mettre au point des produits (logiciels

ou matériels) compatibles. Ce modèle comprend 5 couches qui ont les mêmes fonctions

que celles du modèle OSI ainsi que 3 couches pour la gestion de la puissance d'énergie,

la gestion de la mobilité ainsi que la gestion des tâches (interrogation du réseau de

capteurs). Le but d'un système en couches est de séparer le problème en différentes

parties (les couches) selon leur niveau d'abstraction. Chaque couche du modèle

communique avec une couche adjacente (celle du dessus ou celle du dessous). Chaque

couche utilise ainsi les services des couches inférieures et en fournit à celle de niveau

supérieur.


- 12 -

Figure 1. 4 : Modèle en couches pour la communication dans les RCSF.

1.6.2. Rôle des couches

• La couche physique : Spécifications des caractéristiques matérielles, des

fréquences porteuses, etc...

• La couche liaison : Spécifie comment les données sont expédiées entre deux

nœuds/routeurs dans une distance d'un saut. Elle est responsable du multiplexage des

données, du contrôle d'erreurs, de l'accès au media,... Elle assure la liaison point à point

et multi-point dans un réseau de communication.

La couche réseau : Dans la couche réseau le but principal est de trouver une route et une

transmission fiable des données, captées, des nœuds capteurs vers le puits "sink" en

optimisant l'utilisation de l'énergie des capteurs. Ce routage diffère de celui des réseaux

de transmission ad hoc sans fils par les caractéristiques suivantes:

� il n'est pas possible d'établir un système d'adressage global pour le

grand nombre de nœuds.

� les applications des réseaux de capteurs exigent l'écoulement des

données mesurées de sources multiples à un puits particulier.

� les multiples capteurs peuvent produire de mêmes données à

proximité d'un phénomène (redondance).

� les nœuds capteur exigent ainsi une gestion soigneuse des ressources.

En raison de ces différences, plusieurs nouveaux algorithmes ont été proposés pour le

problème de routage dans les réseaux de capteurs.

• La couche transport : Cette couche est chargée du transport des données, de leur

découpage en paquets, du contrôle de flux, de la conservation de l'ordre des paquets et

de la gestion des éventuelles erreurs de transmission.


- 13 -

• La couche application : Cette couche assure l'interface avec les applications. Il

s'agit donc du niveau le plus proche des utilisateurs, géré directement par les logiciels.

1.6.3. Plans de gestion

Les plans de gestion d'énergie, de mobilité et de tâche contrôlent l'énergie, le

mouvement et la distribution de tâche au sein d'un nœud capteur. Ces plans aident les

nœuds capteurs à coordonner la tâche de captage et minimiser la consommation

d'énergie. Ils sont donc nécessaires pour que les nœuds capteurs puissent collaborer

ensemble, acheminer les données dans un réseau mobile et partager les ressources entre

eux en utilisant efficacement l'énergie disponible. Ainsi, le réseau peut prolonger sa

durée de vie.

• Plan de gestion d'énergie : contrôle l'utilisation de la batterie. Par exemple, après

la réception d'un message, le capteur éteint son récepteur afin d'éviter la duplication des

messages déjà reçus. En outre, si le niveau d'énergie devient bas, le nœud diffuse à ses

voisins une alerte les informant qu'il ne peut pas participer au routage. L'énergie restante

est réservée au captage ;

• Plan de gestion de mobilité : détecte et enregistre tous les mouvements des nœuds

capteurs, de manière a leur permettre de garder continuellement une route vers

l’utilisateur final, et maintenir une image récente sur les nœuds voisins. Cette image

est nécessaire pour pouvoir équilibrer l’exécution des taches et ainsi la consommation

d’énergie ;

• Plan de gestion de tâche : balance et ordonnance les différentes tâches de captage

de données dans une région spécifique. Il n'est pas nécessaire que tous les nœuds de

cette région effectuent la tâche de captage au même temps ; certains nœuds exécutent

cette tâche plus que d'autres selon leur niveau de batterie.

1.7. Contraintes des RCSF

1.7.1. Absence d'infrastructure

Les RCSF et les réseaux ad hoc, en général, se distinguent des autres réseaux mobiles par

la propriété d'absence d'infrastructure préexistante et de tout genre d'administration

centralisée. Les hôtes mobiles sont responsables d'établir et de maintenir la connectivité du

réseau d'une manière continue.


- 14 -

1.7.2. Ressources limitées

En plus de l’énergie, les nœuds capteurs ont aussi une capacité de traitement et de mémoire

limitée. En effet, les industriels veulent mettre en œuvre des capteurs simples, petits et peu

coûteux.

1.7.3. Durée de vie du réseau

C’est l’intervalle de temps qui sépare l’instant de déploiement du réseau de l’instant où

l'énergie du premier nœud s'épuise. Selon l’application, la durée de vie exigée pour un

réseau peut varier entre quelques heures et plusieurs années.

1.7.4. Bande passante limitée

Afin de minimiser l’énergie consommée lors de transfert de données entre les noeuds, les

capteurs opèrent à bas débit. Typiquement, le débit utilisé est de quelques dizaines de Kb/s.

Un débit de transmission réduit n’est pas handicapant pour un réseau de capteurs où les

fréquences de transmission ne sont pas importantes.

1.7.5. Passage à l’échelle

Le nombre de nœuds déployés pour une application peut atteindre des milliers. Des

réseaux de 10000 nœuds peuvent être envisagés. Dans ce cas, le réseau doit fonctionner

avec des densités de capteurs très grandes. Un nombre aussi important de nœuds engendre

beaucoup de transmissions inter nodales et nécessite que la station de base soit équipée de

mémoire suffisante pour pouvoir stocker les informations reçues.

1.7.6. Topologie dynamique

La topologie des réseaux de capteurs peut changer au cours du temps pour les raisons

suivantes :

• Les nœuds capteurs peuvent être déployés dans des environnements hostiles

(champ de batail par exemple), la défaillance d’un nœud capteur est, donc très

probable.

• Un nœud capteur peut devenir non opérationnel à cause de l’puisement de son

énergie.


- 15 -

• Dans certaines applications, les nœuds capteurs et les stations de base sont mobiles

d'une façon libre et arbitraire rendant ainsi, la topologie du réseau fréquemment

changeante.

1.7.7. Auto organisation du réseau

Ceci peut être nécessaire dans plusieurs cas. Par exemple, un réseau comportant un grand

nombre de nœuds, placés dans des endroits hostiles où la configuration manuelle n’est pas

faisable, doit être capable de s’auto organiser. Un autre cas est celui où un nœud est inséré

ou retiré (à cause d’un manque d’énergie ou de destruction physique), ainsi le réseau doit

être capable de se reconfigurer pour continuer sa fonction.

1.7.8. Agrégation de donnée

Dans les réseaux de capteurs, les données produites par les nœuds capteurs voisins sont

très corrélées spatialement et temporellement. Ceci peut engendrer au niveau de la station

de base la réception d’informations redondantes.

L’agrégation de données dans les réseaux de capteurs consiste à remplacer les lectures

individuelles de chaque capteur par une vue globale, collaborative sur une zone donnée .

On peut utiliser par exemple de simples fonctions d’agrégat telles que MIN, MAX ou

MOYENNE, qui permettent à partir d’une série de n messages reçus par un « agrégateur »

de ne renvoyer vers le puits qu’un seul message résumant l’information contenue dans ces

n messages. Ceci réduit le nombre de messages envoyés vers le sink.

Réduire la quantité d’informations redondantes transmises par les capteurs permet de

réduire la consommation d’énergie dans le réseau et ainsi d’améliorer sa durée de vie.

Cette technique est connue aussi sous le nom de fusion de données [4].

Figure 1. 5: Agrégation de données [4] [3].


- 16 -

1.7.9. Sécurité physique limitée

Les RCSF sont plus touchés par le paramètre de sécurité que les réseaux filaires classiques.

Cela se justifie par les contraintes et limitations physiques qui font que le contrôle des

données transférées doit être minimisé.

Les RCSF connaissent actuellement une grande extension et une large utilisation dans

différents types d'applications, dont celles exigeant une grande sécurité. Leurs contraintes

font que l'application des mesures classiques de sécurité, sur les RCSF, est restreinte.

1.8. Sécurité (exigence/limites) des RCSF

« Chacun a le droit à la protection des intérêts moraux et matériels découlant de toute

production scientifique, littéraire ou artistique dont il est l’auteur. » Article 27.2 ;

Déclaration universelle des droits de l’homme (1948) [13].

Malheureusement, les RCSF ne sont pas parfaits ! A cause de leur faible coût et leur

déploiement dans des zones parfois hostiles, les nœuds sont assez fragiles et vulnérables.

Ainsi, la perte de connexions sans fils peut être due à une extinction d'un capteur suite à un

épuisement de sa batterie, ou tout simplement à une destruction physique accidentelle ou

intentionnelle par un ennemi.

La sécurité des RCSF a deux volets complémentaires [11] :

•••• La sécurité opérationnelle, qui a comme objectif qu'un réseau devrait continuer à

fonctionner même lorsque certains de ses composants sont attaqués (l’exigence de

la disponibilité du service).

•••• La sécurité des informations, qui assure la confidentialité, l'intégrité et l'authenticité

des informations.

1.8.1. Objectifs de Sécurité pour les données collectées

•••• La confidentialité

La confidentialité consiste à s'assurer que l'information n'a pas été divulguée.

Les données ne seront pas révélées à une personne non autorisée grâce à une méthode de

chiffrement des données [2]. On peut en distinguer deux permettant d’assurer cette

confidentialité, bout en bout (end-to-end), ainsi que saut-par-saut (hop-by-hop). Avec cette

dernière, un nœud agrégateur par exemple devra déchiffrer les données qu’il reçoit,

appliquer la fonction d’agrégation, puis chiffrer à nouveau les données avant de les


- 17 -

envoyer au prochain nœud. En revanche, avec la confidentialité de bout-en-bout, les

agrégateurs ne peuvent pas déchiffrer les données. Par conséquent ils appliquent en direct

la fonction d’agrégation sur les données chiffrées.

L'approche standard pour garantir la confidentialité des données sensibles est de crypter les

données avec une clé secrète que seul le récepteur, auquel sont destinées les données, la

possède. Puisque la cryptographie à clé publique est trop coûteuse pour être utilisés dans

les réseaux de capteur caractérisés par leurs ressources limitées, la plupart des protocoles

proposés utilisent des méthodes chiffrement à clé symétriques [3].

•••• L’intégrité

Cette propriété consiste à s'assurer que l'information n'a pas été modifiée.

Vérifier l'intégrité des données consiste à déterminer si les données n'ont pas été altérées

durant la communication (de manière accidentelle ou intentionnelle).

La confidentialité n’est pas suffisante pour s’en assurer, puisqu’un attaquant peut

remplacer les données cryptées par les siennes sans que ce ne soit détecté [2][3].

•••• L’authentification

S'assurer que

�� une entité est bien ce qu'elle prétend être.

�� une information provient d'où elle est censée provenir.

Cette propriété nous permet de vérifier l’identité d’un émetteur de données, ce qui permet

d’éviter l’injection de paquet par un tiers non autorisé. Mais elle permet également

d’authentifier les données qui transitent sur le réseau.

Dans un RCSF, un adversaire peut facilement injecter des messages, de sorte que le

récepteur a besoin de s'assurer que les données, utilisées dans tout processus de prise de

décision, proviennent de la source correcte.

L'authentification des données empêche les entités non légitimes à participer dans le

réseau et donc les nœuds légitimes devraient être en mesure de détecter les messages à

partir des nœuds non autorisés et les rejeter.

L’authentification des données peut être réalisée par un mécanisme purement symétrique:

L'expéditeur et le destinataire partagent une clé secrète pour calculer un code

d'authentification de message (MAC) de toutes les données communiquées.

Si un message avec un MAC correcte arrive, il est accepté car qu'il s’agit d’un message

envoyé par l'émetteur, sinon il est rejeté [3].


- 18 -

•••• La disponibilité

S'assurer que l'information est présente et utilisable au moment ou l'on en a besoin.

Permet de s’assurer que l’on peut toujours communiquer avec toutes les parties du réseau

et que leurs données soient accessibles [3].

•••• La nonRépudiation

S’assurer que l’émetteur ne peut pas nier l’émission et le récepteur ne peut nier la

réception.

•••• Fraîcheur de données :

Elle concerne la fraicheur de données et la fraicheur des clés. Puisque tous les réseaux de

capteurs fournissent quelques formes de mesures variables dans le temps, nous devons

assurer que chaque message est frais. La fraicheur de données implique que les données

sont récentes, et elle assure qu'aucun adversaire n'a rejoue les vieux messages[2][3].

Dans le cas de l’agrégation de données, un nœud qui envoi le résultat de ses calculs

Permet de s’assurer que les données sont récentes, ce qui permet de contrer des attaques où

d’anciens messages sont émis de nouveaux par un attaquant pour perturber les résultats ou

la gestion des clés partagées.

Un mécanisme est mis en place pour garantir cette propriété est d'inclure un compteur

monotone croissant avec chaque message et rejeter les messages avec les anciennes valeurs

du compteur. Avec cette politique, chaque nœud doit maintenir une table de la dernière

valeur de chaque émetteur duquel a reçu un message [3]

1.8.2. Vulnérabilités des RCSF

Les propriétés des réseaux de capteurs sont à double tranchant. Certes ils permettent une

grande facilité de production et de déploiement, mais rendent le système global de

communication assez « fragile » à un certain nombre de défaillances.

Les vulnérabilités des RCSF émergent à partir des propriétés qui les rendent efficaces et

attrayants.

Vulnérabilités de la Liaison. La première vulnérabilité est liée à la technologie sans

fil sous jacente. en plus de fournir un déploiement simple, la communication sans fil


- 19 -

a l'avantage d'offrir l'accès à des endroits difficilement accessibles tels que des

terrains désastreux et hostiles. Malheureusement, la portée de la communication

radio des "motes" est limitée en raison de considérations énergétiques. La

communication multi-sauts est donc indispensable pour la diffusion des données

dans un RCSF. Cela introduit de nombreuses failles de sécurité à deux niveaux

différents: attaque de la construction et maintenance des routes, et attaque des

données utiles par injection, modification ou suppression de paquets. En outre, la

communication sans fil introduit d'autres vulnérabilités à la couche liaison en ouvrant

la porte à des attaques de brouillage et de style déni de service par épuisement des

batteries.

Vulnérabilités Matériels. Les nœuds eux-mêmes sont des points de vulnérabilité du

réseau car une attaque peut compromettre un composant laissé sans surveillance. La

plupart des applications de RCSF exigent un déploiement étroit des nœuds à

l'intérieur ou à proximité des phénomènes à surveiller. Cette proximité physique avec

l'environnement conduit à de fréquentes compromissions intentionnelles ou

accidentelles des nœuds. Comme le succès des applications RCSF dépend également

de leur faible coût, les nœuds ne peuvent pas se permettre une protection physique

inviolable. Par conséquent, un adversaire "bien équipé" peut extraire des

informations cryptographiques des nœuds capteurs. Comme la mission d'un RCSF

est généralement sans surveillance, le potentiel d'attaquer les nœuds et de récupérer

leur contenu est important. Ainsi, les clefs cryptographiques et informations

sensibles devraient être gérées d'une manière qui augmente la résistance à la capture

des nœuds.

Vulnérabilités Réseau.

� Attaques sur le protocole de routage

L'absence d'infrastructure fixe pénalise l'ensemble du réseau dans la mesure où il faut faire

abstraction de toute entité centrale de gestion pour l'accès aux ressources ;

� Attaques sur la confidentialité et l’authenticité des paquets transmis

Les mécanismes de routage sont d'autant plus critiques dans les réseaux RCSF que Les

attaques peuvent exploiter le comportement coopératif durant le processus de routage, Où

chaque nœud participe à l'acheminement des paquets à travers le réseau.


- 20 -

Les messages de routage transitent sur les ondes radio. Donc ces messages peuvent être

interceptés, modifié, interrompus ou relayés ce qui rend les protocoles de routage

vulnérables.

Vulnérabilités Applicatives. Vu le nombre important des nœuds capteurs dans un rcsf et la

corrélation des données captées, l’agrégation de données est devenue cruciale, cela fait

qu’elle est ciblée par beaucoup d’attaques afin de fausser les données reçues par le puits

(sink). Par conséquent la sécurisation de cette opération devient de plus en plus

indispensable

En route vers le puits les données passent par un ou plusieurs nœuds agrégateurs et si l’un

de ces nœuds est compromis le message agrégé sera donc altérer, et son altération fausse

les altérations qui suivent jusqu'à son arrivée au puits (sink).

Figure 1. 6: Sécurité dans les RCSF : propriétés, challenges et solutions [33].

1.8.3. Attaques sur les RCSFs

Souvent déployés dans des environnements hostiles, les réseaux de capteurs sans fil font

sujets à plusieurs types d'attaques. Une attaque est un ensemble de techniques

informatiques, visant à causer des dommages à un réseau, en exploitant les failles de celui-

ci [14]. Elles peuvent aggraver les problèmes de sécurité. En effet, les conséquences liées à

ces attaques peuvent varier d’une simple écoute du trafic jusqu’à l’arrêt total du réseau

selon les capacités des attaquants. Pour les combattre, il est nécessaire de connaître les

classes et les types d’attaques afin de mettre en œuvre des solutions optimales.


- 21 -

1.8.4. Classification des attaques :

Les attaques connaissent plusieurs classifications envisageables dont les plus utilisées sont

regroupées selon les critères suivants[14] :

� Selon l’origine

• Attaque externe: elle est déclenchée par un nœud qui n’appartient pas au réseau, ou

qui n’a pas accès.

• Attaque interne: elle est déclenchée par un nœud capteur interne malveillant.

Les stratégies de défense visent généralement à combattre les attaques externes.

Cependant, les attaques internes sont les menaces les plus sévères qui peuvent perturber le

bon fonctionnement des RCSF.

� Selon la nature

• Attaque passive : Cette classe Regroupe les attaques portant atteinte à la

confidentialité.

L’attaquant écoute passivement le trafic pour en extraire des informations sensibles, sans

modifier les données ou perturber le fonctionnement du réseau. Il profite ainsi de la nature

du réseau ; Une fois l'attaquant ayant acquis suffisamment d'informations, il peut produire

un attentat contre le réseau, ce qui transforme l’attaque passive en une attaque active.

Les attaques passives ne sont pas facilement détectables car elles n’impliquent aucune

altération des informations.

• Attaque active : concerne celles qui entraînent une modification des données ou

injection de données incorrectes. Autrement dit, celles qui portent atteinte à l’intégrité,

l’authenticité et la disponibilité. On retrouve alors plusieurs types d’attaques actives :

� le rejeu : retransmission de messages capturés lors d’une communication,

et cela à des fins illégitimes,

� la modification de messages,

� le déni de service,

� selon leurs effets


- 22 -

Dans une telle classification, qui est proposée par Stallings dans [10], les attaques peuvent

perturber le flux normal des paquets en utilisant : la modification, l'interception,

l'interruption ou la fabrication, ou des combinaisons de ces mécanismes.

• Interruption (attaque contre disponibilité) Un lien de communication devient

perdu ou indisponible.

• Interception (attaque contre confidentialité) Le réseau des capteurs est compromis

par un attaquant non autorisé qui peut accéder à un nœud ou aux données échangées par ce

dernier (écoute clandestine du traffic).

• Modification (attaque contre intégrité) L’attaquant fait certains changements aux

paquets de routage, et ainsi l’intégrité de données intégrité dans le réseau.

• Fabrication (attaque contre authentification) L’adversaire injecte fausses données

et donc compromet la fiabilité des informations transmises.

Figure 1. 7: Classification des attaques par stallings[10].

1.8.5. Principales attaques sur les RCSFs

Différentes sortes d’attaques sont potentiellement en mesure de mettre en péril l’utilisation

d’un réseau de capteurs. Dans cette section, on se propose de présenter un aperçu des

principales formes d’attaques menées contre les réseaux de capteurs sans fil.

• Attaques par déni de service (DoS)

L’attaque vise à rendre indisponible (au moins) une ressource à ses utilisateurs. Dans le cas

des RCSF, on peut par exemple envoyer des signaux radio (sur la même fréquence de

communication) qui interfèrent avec les fréquences radios utilisées par les capteurs,

rendant ainsi les nœuds incapables de communiquer [16]. Ce type d’attaque est parfois

appelé brouillage (jamming).


- 23 -

La source du brouillage peut être plus ou moins puissante, ce qui n’affecterait alors que

localement un sous-réseau du réseau. Dans notre cas, un agrégateur cessant d’envoyer des

données peut avoir un impact très important sur l’ensemble du RCSF. C’est cette attaque

qui est représentée sur la figure ci-dessous. Le sous-réseau compromis est composé de

noeuds rouges et l’étendue du brouillage est en vert. Ainsi, une moitié du réseau n’envoi

plus ses données à la station de base avec un seul noeud brouillé. De toute façon si la

source est assez puissante, l’ensemble du RCSF devient inutilisable.

Figure 1. 8: Brouillage sur un nœud agrégateur[3].

• attaque d'expédition sélective, l'attaquant transfère certains paquets qu'il intercepte et

en supprime d'autres, engendrant ainsi une perte de donnée. Il modifie donc l’agrégat

qu’aurait du envoyer le nœud compromis et donc fausse les résultats.

• attaque Sinkhole

L’attaquant tente de se faire passer pour un faux puits en se montrant très attractif aux

nœuds avoisinants puis crée une topologie erronée du réseau.

• Attaque du trou noir "black hole"

L’attaquant falsifie les informations de routage pour forcer le passage des données par lui-

même. Sa seule mission est ensuite de ne rien transférer, créant ainsi une sorte de puits ou

trou noir dans le réseau. L’intrus (nœud malveillant, qui s’introduit illégitimement), peut

aussi se placer sur un endroit stratégique de routage dans le réseau et supprime tous les

messages qu’il devrait retransmettre, causant la suspension du service de routage du réseau

dans les routes qui passent par le nœud intrus.

La nature des RCSFs ou les informations sont routées vers une station de base rend ce type

d’attaque plus réussi.

• attaque Sybille


- 24 -

Un nœud malveillant présente plusieurs identités dans le but d'attirer le plus de trafic

possible et donc devient un puits pour les nœuds de son voisinage.

Ainsi dans le cas d’un vote, pour un agrégateur par exemple, l’attaquant est capable de

fausser les résultats en pouvant voter plusieurs fois sous différentes identités, et ainsi élire

un noeud compromis. L’attaquant peut aussi fausser efficacement l’agrégation en envoyant

plusieurs données fausse.

• attaque d'inondation par paquets Hello, l'attaquant tente de convaincre des nœuds

qu'il est dans leur voisinage même pour ceux qui sont hors de portée. Ainsi, le but de cette

attaque est de faire en sorte que tous les nœuds redirigent leurs paquets vers l'attaquant.

• attaque Wormhole, un adversaire connecte deux nœuds malveillants distants en

utilisant un lien de communication directe à faible latence. Le tunnel relaie les paquets

entre deux nœuds légitimes et distants dans le but de les convaincre qu'ils sont voisins.

1.9. Conclusion

Les réseaux de capteurs sans fil présentent un intérêt considérable et une nouvelle étape

dans l’évolution des technologies de l’information et de la communication. Cette nouvelle

technologie suscite un intérêt croissant vu la diversité de ces applications : santé,

environnement, industrie et même le domaine de l’agriculture.

Dans ce premier chapitre, nous avons fait le tour d'horizon sur les RCSFs, à savoir

l’anatomie d’un nœud capteur, sa pile protocolaire, l’architecture des RCSFs et leurs

diverses applications ainsi que les attaques, sur ce type de réseaux, qui vont en augmentant,

Au terme de ce chapitre, plusieurs constats sont à noter comme l’impact contraignant des

caractéristiques des RCSFs sur la gestion de ce type de réseaux, y compris les techniques

de sécurisation.

Les mauvais comportements et ses contre-mesures dans les RCSFs peut être considérée

comme le jeu du chat et souris, chacun cherche des nouveaux et des différents moyens de

défense pour protéger ses intérêts.

Le chapitre qui suit est consacré à la description détaillé de l’une des attaques les plus

dangereuses qui est l’attaque Wormhole. Notre but consiste à décortiquer cette dernière ses

effets sur la découverte de route ainsi que l’acheminement des données.

Chapitre 2 Attaque Wormhole, état de l’art

- 25 -

2

Attaque

Wormhole :

État de l’art

2.1. Introduction

Comme tout autre système informatique, les réseaux de capteurs sans fil sont vulnérables et les

mécanismes de sécurité des réseaux filaires et même ceux des réseaux ad hoc ne sont pas

applicables sur ce type de réseaux, car ils offrent des restrictions plus sévères en termes

d’énergie, capacités de traitement, bande passante et de communication.

Ce chapitre met en évidence une des attaques les plus critiques contre les RCSF, puis décrit les

différents mécanismes, existants dans la littérature, qui permettent de la détecter et de l’éviter.


- 26 -

2.2. Attaque Wormhole

Le terme Wormhole fait référence aux trous de ver en astronomie, qui sont des raccourcis entre

deux points éloignés dans l’espace [42]. Le principe ici est le même : l’attaquant utilise un

chemin hors du réseau (ou un chemin virtuel par la mise en place d’un tunnel) pour faire passer

les messages. Cette attaque requière plusieurs attaquants (au moins deux). Chacun des deux

attaquants se place non loin d’un des deux nœuds légitimes. Ainsi, ils peuvent intercepter le

trafic échangés entre ces derniers. Les deux attaquants disposent en plus de leur accès au réseau,

d’un lien direct physique (liaison filaire ou radio directionnelle par exemple) ou logique (par

encapsulation). Ils emploient alors cette liaison directe pour acheminer les messages entre eux.

Ce chemin, étant le plus court, il sera emprunté par les messages échangés entre les deux nœuds

(légitimes) compromis. Ainsi, les attaquants auront le contrôle total de ce chemin

[18,19,20,21,22].

2.3. Mise en application l’attaque Wormhole

L’adversaire établie initialement un lien appelé lien wormhole (ou tunnel) entre deux endroits du

réseau n'ayant pas un lien en commun. Dans un endroit on trouve le nœud origine (le nœud S9

dans la figure 2.1) et dans l'autre le nœud destination (le nœud S dans la figure 2.1). L'adversaire

écoute ensuite clandestinement le trafic du côté de l'extrémité où se trouve le nœud origine et

l’achemine via le tunnel vers l’autre extrémité qui proche de la destination sans y ajouter son

adresse dans l’entête. Ceci a pour résultat la création d'un lien inexistant entre les deux nœuds

légitimes et qui va fonctionner d'une manière invisible.

L’attaque Wormhole a plusieurs comportements, puisque le tunnel est sous le contrôle total de

l’attaquant, alors ce dernier peut supprimer totalement ou sélectivement les paquets de données

ou du routage transitant via le tunnel, comme il peut conserver les paquets pour les envoyant plus

tard. Ou simplement il regroupe les paquets dans le but d'analyser le trafic.

Le problème réel de cette attaque est que les nœuds intrus (attaquants) sont capables de

transmettre des messages valides du réseau[18].


- 27 -

Figure 2.1: Attaque Wormhole

Cette attaque permet de faciliter la mise en place d’autres attaques. Le tunnel wormhole, peut être

réalisé de différentes manières : par exemple par encapsulation des paquets, par un réseau filaire

à haut débit ou par un réseau sans fil à forte puissance de transmission, de façon à ce que la

latence du chemin Wormhole soit inférieure ou égale à celle du chemin légitime multi sauts.

Les dispositifs et les liens Wormhole déployés par l’adversaire ne font pas partie du réseau et ne

nécessitent pas une id valide du réseau. Par cette attaque l’adversaire vise l’acheminement du

trafic et pas forcément le contenu de ce trafic. De ce fait, il n’a pas donc besoin de casser le

système cryptographique employé par les nœuds du réseau pour effectuer cette attaque. Ainsi,

les propriétés de confidentialité, d’intégrité et d’authentification sont préservées. Ceci rend

l’attaque Wormhole invisible pour les couches supérieures. En outre, l'adversaire n'a pas besoin

d'allouer des ressources informatiques pour compromettre les communications. Il est donc

relativement aisé de mettre en application l’attaque Wormhole.

2.4. Impact de l’attaque Wormhole sur les protocoles de routage

L’attaque Wormhole peut perturber la fonction de routage, car elle cible essentiellement le

mécanisme de découverte de route « route disccovery ». Pour confectionner une attaque

Wormhole, l’attaquant n’a pas besoin de contrôler les nœuds dans le réseau, c'est pour cela que

cette attaque peut être invisible pour la couche réseau. Il suffit d’installer deux simples


- 28 -

transceivers radio aux extrémités du lien Wormhole qui fonctionnent avec la couche physique en

tant que répéteurs.

Puisque les communications sans fil se font en mode diffusion « broadcast », l’adversaire peut

intercepter les paquets transmis à l'aide de l'un de ses transceivers radio et les transférer vers

l’autre bout du tunnel [22].

2.4.1. Impact de l’attaque sur les protocoles proactifs

Considérons la figure 2.1, qui montre un réseau de capteurs sans fil composé de 13 nœuds

capteurs et un sink. Un nœud Si est connecté à un nœud Sj si la distance qui les sépare est

inférieure au rayon de communication noté r. Considérant un attaquant qui établit un lien

Wormhole entre deux nœuds légitimes distants S et S9 en utilisant une connexion ayant une

latence inférieure (low-latency) à celle des nœuds légitimes du réseau.

Dans le cas d’un protocole proactif comme DSDV, la découverte des voisins se fait par l’envoi

des messages HELLO. L’attaquant peut envoyer à travers le tunnel des messages HELLO de S9

vers S et de S vers S9 pour faire croire à ces deux nœuds qu’ils sont voisins alors qu’en réalité ils

ne le sont pas. De cette façon, l’attaquant réussit à perturber le mécanisme de découverte de route

puisqu’il y a de mauvaise perception de voisins [22,43].

2.4.2. Impact de l’attaque sur les protocoles réactifs

L’effet de l’attaque Wormhole sur ces protocoles est l’établissement d’une fausse route entre la

source et la destination. Un nœud A cherche un chemin vers un autre nœud B, alors il diffuse

tout d’abord un message Route Request qui sera rediffusé par chaque nœud qui le reçoit jusqu’à

ce qu’il arrive à la destination. Cette dernière répond par un Route Reply.

Si un attaquant établi un lien Wormhole entre A et B et si la distance qui les sépare dépasse un

saut, alors un chemin d’un saut sera établi entre ces deux nœuds via le lien Wormhole.

Considérons la figure 2.1 où l’attaquant établie un lien Wormhole entre les noeuds S9 et S.

Supposons que S12 cherche un chemin vers S, alors il diffuse un message Route Request. Ce

dernier sera transmis via le tunnel vers S comme s’il est le voisin direct de S9. Après la réception

de la réponse de S, les deux nœuds établissent la route via le lien Wormhole comme s’ils étaient


- 29 -

deux nœuds voisins [22]. De même pour les autres nœuds du réseau, le lien Wormhole sera inclus

dans la majorité des routes établies.

• Impact de l’attaque Wormhole sur la découverte des voisins (HELLO) :

Quand un protocole réactif est utilisé, les nœuds diffusent périodiquement des messages Hello

indiquant leur présence dans le réseau.

Si S émet un Hello alors l’un des deux nœuds malicieux le capte puis l’achemine vers l’autre bout

du tunnel Wormhole, qui se trouve dans la portée radio du S9. Le Hello est diffusé par la suite et

arrive au nœud S9 qui croit qu’il est voisin direct de S.

• Impact de l’attaque Wormhole sur Route Request:

Si un nœud du réseau désire communiquer avec un autre, il diffuse un message RREQ demandant

une route vers sa destination qui soit le chemin le plus court. L’une des copies de RREQ passe

par le tunnel Wormhole en évitant le parcourt de plusieurs nœuds. Et elle arrive avant les autres

obligeant ainsi la destination à sélectionner son chemin.

Dans la figure 2.2, le nœud capteurs S12 initie une découverte de route. Après la réception du

RREQ le nœud S9 le rediffuse. Une copie passe par le tunnel et arrive 0 la destination S avant les

RREQ valides.

Figure 2.2: impact de l’attaque Wormhole sur RREQ


- 30 -

• Impact de l’attaque Wormhole sur Route Reply :

Le message RREP est généré par la destination une fois qu'elle reçoit le premier message RREQ.

Si ce dernier est arrivé à la destination via un lien Wormhole alors son chemin est élus comme

étant le plus court chemin. Ainsi RREP parcourra le chemin inverse du RREQ.

Considérons le réseau de la figure 2.3. lorsque le nœud S reçoit un RREQ via le tunnel Wormhole

il génère un RREP et l’envoi via le tunnel vers S9, avant d’arriver à S12.

Figure 2. 3: Effet de l’attaque Wormhole sur RREP

La figure 2.4 illustre l’effet de l’attaque Wormhole sur le RREQ et le RREP.

Cette attaque peut être lancée par la transmission du message RREQ du nœud 2 (nœud

intermédiaire) directement vers la destination D Qui va recevoir le message RREQ venant de

l’attaquant en premier lieu et elle va donc rejeter tous les autres messages RREQs. Lors du

passage de RREQ, chaque nœud intermédiaire met à jours les entrées des nœuds précédents dans

sa table de routage. Le premier RREQ reçus est stocké dans le cache du nœud en plus de la mise

à jour de la table de routage constituant ainsi le chemin inverse (reverse route).

D génère par la suite un RREP qui parcoure le chemin inverse passant par le tunnel Wormhole

vers la source S. De cette façon, l’attaquant empêche la découverte d’une autre route que celle

passant par lui. L’attaquant devient donc un point central dans le réseau du fait qu’il contrôle la

majorité des routes.


- 31 -

Figure 2.4: Effet de l’attaque Wormhole sur le RREQ et RREP du protocole AODV.

2.5. Protocoles locaux d'émission

Dans une architecture en clusters, l’information capturée pour certaines applications est

significative juste dans le voisinage du nœud origine de cette capture. Par exemple dans la figure

2.5. : Deux régions A et B qui captent la température, ou chacune de ces régions possède un seuil

qui lui permet de déclencher une alarme. Si un capteur de la région B capte une température x qui

dépasse le seuil de A et le nœud malicieux achemine cette information via le tunnel Wormhole

vers l’autre bout du tunnel qui est dans la région A, alors une alarme sera déclenchée dans cette

zone malgré que sa température n’a pas encore atteint le seuil maximal.


- 32 -

Figure 2.5: Attaque Wormhole contre les protocoles locaux d’émission

L’attaque Wormhole influx sur l’exécution du service de routage de trois manières :

� si le lien Wormhole est bien localisé dans le réseau alors les nœuds peuvent devenir des

sinkholes sans se rendre compte qu'ils soient des victimes de l’attaque Wormhole. Ils

captent tout le trafic autour d’eux, même s’il n’est pas destiné à eux. Ces nœuds épuisent

donc leur énergie et par conséquent diminue la durée de vie du réseau.

� Si l’attaquant garde le lien Wormhole fonctionnel de façon permanente sans ignorer

aucun paquet, alors il fournira un service pour le réseau. Par contre, s’il ignore

sélectivement quelques paquets, le réseau dans ce cas sera perturbé.

� En faisant tout simplement un switch sur les deux états ON et OFF, l’attaquant peut

causer une faille de route, ce qui mène vers une attaque de déni de service (DoS).

Exemple d’une attaque Wormhole :

L’attaque Wormhole peut aussi infecter des réseaux d’autres applications sans fil où la

communication directe en un seul saut et la proximité physique jouent un rôle important.

Dans un hôtel géré à l’aide d’un système de contrôle d’accès sans fil où chaque porte est dotée

d’un lecteur de cartes intelligentes sans contact. Une porte n’est ouverte que si une carte valide

est présentée au lecteur. La sécurité d’un tel système dépend de la sécurité physique des cartes. Si

temp temp

Région ARégion B

Attaquant Noeud Clusterhead Transmission sans fil

Tunnel Wormhole

Sous réseaux

temp temp

Région ARégion B

Attaquant Noeud Clusterhead Transmission sans fil

Tunnel Wormhole

Sous réseaux


- 33 -

une carte valide est présente, alors le système réagit comme si une personne légitime est présente

et la porte s’ouvrira dans ce cas.

Une attaque Wormhole peut être confectionnée en établissant un lien Wormhole entre un lecteur

de cartes et une carte valide quelque part dans la poche d’un utilisateur légitime par exemple.

Le noeud malicieux qui est près de la carte valide capte son code, le transfère via le lien

Wormhole vers le nœud de l’autre extrémité (qui est prés du lecteur de cartes fixé sur la porte) ,

l’authentification se fait et la porte s’ouvrira.

Figure 2.6: Exemple d’une attaque Wormhole.

Il existe une autre attaque qui a des effets similaires sur le routage que l’attaque Wormhole.

Contrairement à cette dernière, elle est effectuée dans la couche réseau. Cette attaque est appelée

l’attaque Tunneling.

Elle consiste à contrôler des nœuds corrompus du réseau, quand l’un de ces nœuds reçoit un

message RREQ, l’attaquant met ce paquet entièrement dans la partie donnée (payload) d’un

paquet de données normal et l’envoi à un nœud complice en utilisant un chemin multi-sauts. Lors

de la réception du paquet, le nœud malicieux retire le message RREQ du paquet et le traite

comme s’il l’a reçus via son transceiver radio. Cela est similaire à la façon par laquelle les

paquets sont transmis d’un nœud vers un autre dans un VPN d’où vient le nom Tunneling[39].


- 34 -

Bien que les effets des deux attaques sur les protocoles de routage soient similaires, il y a des

différences importantes entre les deux.

� Afin d'effectuer l’attaque Tunneling, l’adversaire doit Corrompre des nœuds dans le

réseau. Ce qui rend cette attaque visible pour la couche réseau.

� Contrairement à l’attaque Wormhole, dans l’attaque Tunneling l’adversaire n’a pas besoin

d’une connexion spécifique utilisant une autre bande de fréquence entre les dispositifs de

l’attaque, mais ils peuvent communiquer en se servant du réseau lui-même.

� L’attaque Wormhole est effectuée dans la couche physique tandis que l’attaque Tunneling

s’effectue dans la couche réseau.

2.6. Modes de l'attaque Wormhole

Selon la manière avec laquelle est réalisé le tunnel Wormhole, nous distinguons différents modes

de l'attaque Wormhole : wormhole par encapsulation, wormhole par réseau externe, wormhole

par transmission à forte puissance.

2.6.1. Wormhole par encapsulation

Dans ce mode d’attaque, le tunnel est réalisé par encapsulation de sorte que les champs du paquet

encapsulé ne seront pas modifiés au cours de son acheminement [43].

Considérons la Figure 2.8 dans laquelle la source S12 veut découvrir le chemin le plus court vers

le sink S. le nœud S12 diffuse alors un paquet RREQ. En recevant le paquet RREQ le nœud

malicieux M1, première extrémité du tunnel, l’encapsule dans un nouveau paquet destiné à M2,

deuxième extrémité du tunnel, et l’envoie à travers le tunnel. Le nœud M2 décapsule le paquet

reçu, extrait le paquet RREQ et diffuse ce dernier à ses voisins en particulier S. En même temps,

le paquet RREQ traversera le chemin S9-S8-S6-S5 pour atteindre la destination S. Cette dernière

reçoit donc deux paquets RREQ. Le premier provenant de M1 avec un nombre de sauts égal à

deux comme s’il avait traversé uniquement S9, M1, S alors qu’en réalité il a traversé quatre sauts

{S9-M1-S7-M2-S}. Le deuxième paquet RREQ provenant de S5 avec un nombre de sauts égal à

quatre. Le sink S choisit alors le chemin le plus court, soit celui provenant de M2. De cette façon

l’intrus peut contrôler tout le trafic.


- 35 -

Figure 2. 7 : Wormhole par encapsulation.

2.6.2. Wormhole par un réseau externe

Dans ce mode, l’attaquant utilise un réseau externe à haut débit, en fibre optique par exemple,

pour faire parvenir ces paquets les premiers en suivant le même principe décrit auparavant.

2.6.3. Wormhole par transmission à forte puissance

Ce mode d’attaque peut être réalisé par un seul nœud. L’intrus transmet les paquets RREQ reçus

par une forte puissance pour augmenter sa chance d’être un nœud intermédiaire entre les deux

parties en communication.


- 36 -

Figure 2. 8 : Wormhole par transmission à forte puissance.

2.7. Attaques réseaux dues à l'attaque Wormhole

Les attaques radio bénéficient de l'ouverture du médium et l'utilisation de l'interface radio. Ils

sont la base de plusieurs autres attaques qui provoquent une dégradation des performances du

réseau. Si un intrus réussit son attaque radio, il a de forte chance pour exécuter des attaques

réseau.

Comme le montre la figure 2.9, les attaques sybile [44] et blackhole [44] peuvent être dues à

l’attaque Wormhole. Ceci est dû au fait que les paquets RREQ en particulier passant par le tunnel

arrivent avant les autres paquets RREQ qui passent par les nœuds légitimes. Par conséquent, si

les attaquants sybile ou blackhole sont favorisés, leurs attaque peut facilement être mise en place.

Ainsi, la détection de l'attaque radio permet d'éviter les autres attaques.

Figure 2.9: Attaques dues à l’attaque Wormhole


- 37 -

En réussissant l'attaque Wormhole, le noeud malveillant va bénéficier du tunnel Wormhole pour

attirer à lui-même les données des nœuds situant dans la portée radio de l’autre bout du tunnel en

plus des données de tous ses voisins. Ainsi, il peut appliquer l'attaque "Déformation du trafic" par

la corruption du contenu des paquets. Il peut initier aussi une attaque "Selective Forwarding" en

refusant d'envoyer certains messages.

En s'annonçant comme un nœud par lequel passe le chemin le plus court, il peut surveiller et

analyser, par la suite, le trafic de tous ses voisins pour trouver leurs modèles d'activités (Man in

the Middle).

Le tunnel permet d’augmenter le nombre des voisins. Ce qui aide l’attaquant à controler plus de

trafic. En supprimant tout les paquets par un nœud situant dans la portée radio de l’une des deux

extrémités du tunnel, ce qui mène vers une attaque Black Hole.

En faisant tout simplement un switch sur les deux états du tunnel ‘ON’ et ‘OFF’, l’attaquant peut

causer une faille de route, ce qui mène vers une attaque Dénie de Service (DoS).

2.8. Les approches de détection du Wormhole

La plupart des protocoles de routage des réseaux de capteurs sans fil ont été étendus à fin de

garantir un niveau de sécurité. Ces extensions sont généralement des mécanismes de

cryptographie.

Mais malheureusement ces mécanismes de sécurité qui assurent l’authentification, la non

répudiation, la confidentialité et l’intégrité ne peuvent en aucun cas détecter ni empêcher

l’attaque Wormhole et elle peut continuer à perturber le réseau. Car elle n’est pas mise en place

pour créer ou modifier des paquets, mais tout simplement pour rejouer les paquets générés par les

nœuds légitimes dans une autre partie du réseau.

Depuis l’apparition de cette attaque et sont classement parmi les attaques les plus dévastatrices

des réseaux adhoc en géneral et les réseaux de capteurs sans fil en particulier, plusieurs travaux

de recherche ont vu le jour dont l’objectif principal est de trouver des solutions de sécurité vias à

vis de cette attaque. Toutes les solutions proposées reposent sur ce principe : « Afin de détecter

l'attaque Wormhole, il doit y avoir un certain mécanisme pour s'assurer que n'importe quelle

transmission reçue par un noeud S provient en effet d'un voisin valide à un seul saut de S, qui est


- 38 -

situé dans sa portée radio». Ainsi, Plusieurs approches ont été proposées et nous pouvant les

classées en deux classes principale : approches centralisées et approche décentralisées.

2.8.1. Approches centralisées

Dans cette approche, les données collectées du voisinage de chaque nœud sont envoyées à une

entité centrale qui se charge de construire le modèle global du réseau et essaye ensuite de détecter

les inconsistances qui indiquent les liens Wormhole.

A. Détection statistique du Wormhole

Supposons un système constitué de n nœuds statiques placés dans une zone plate de taille s avec

une portée de communication r qui est fixe et la même pour tous les noeuds. p(k) est la

probabilité qu’un nœud a exactement k voisin .

knkqq

k

nkp

−−

−−

=1

)1.(.)1(

)(

Tel que : nk <≤0 et s

rq

π2

=

Figure 2. 10 : Augmentation du nombre de voisins des nœuds victimes du Wormhole.

Le lien Wormhole est établi de sorte qu’il fait croire aux nœuds légitimes du réseau, qui sont

autour des deux nœuds malicieux, qu’ils sont des voisins directs, et ainsi accroitre le nombre de

voisins des nœuds situant dans la portée radio des extrémité du tunnel Wormhole.

Lien WormholeLien Wormhole

(2.1)


- 39 -

Par exemple les voisins du nœud c dans la figure 2.10 seront les nœuds qui sont dans sa portée

radio (qui sont les vrai voisins) ainsi que ceux qui sont dans la portée radio du nœud malicieu X

deuxième extrémité du tunnel (qui sont les faux voisin).

Alors la distribution des degrés que l'entité centrale peut observer dans le graphe de connectivité

qui est construit à partir de l’information de voisinage des nœuds sera déformée par rapport à la

distribution binomiale dérivée auparavant. Cela indique la présence de l’attaque wormhole.

L’inconvénient majeur de cette méthode est qu’elle détecte la présence d’un lien Wormhole sans

le localiser (et spécifier ainsi les nœuds compromis).

A. Détection du Wormhole avec dessin multidimensionnel :

Dans cette approche la visualisation du réseau est utilisée pour la découverte de l’attaque

Wormhole dans les réseaux de capteurs stationnaires. Elle est basée sur l’augmentation de

l’information de connectivité et les estimations de distance entre les nœuds voisins et permet de

localiser les liens Wormhole.

Chaque nœud mesure la distance qui le sépare de chacun de ces voisins en utilisant la force du

signal reçu, et l’envoi à l’unité centrale qui calcule la topologie physique du réseau.

Un plan virtuel du réseau est reconstitué en se servant des informations de connectivité et les

distances estimées entre les nœuds voisins à l’aide d’un algorithme de dessin multidimensionnel

MDS (multi dimensional scaling) qui détermine une position virtuelle pour chaque nœud.

Supposons qu’un adversaire a installé des liens Wormhole, ceci permet la création des faux liens

entre des nœuds éloignés dans le plan virtuel.

Si la distance entre les nœuds victimes est supérieure à leur portée de communication alors le lien

est immédiatement détecté (voir figure 2.11).


- 40 -

Figure 2.11: Détection du Wormhole avec le dessin multi dimensionnel

Partie (a) de la figure 2.11 : cette partie montre le placement réel des nœuds, le cercle représente

la portée de communication du nœud « b ». Le lien entre « b » et « f » est un lien Wormhole.

Partie (b) de la figure 2.11 : cette partie montre le plan virtuel reconstitué à partir des mesures de

distance inexacte des nœuds voisins.

L’inconvénient de ce mécanisme est qu’il n’est pas applicable aux réseaux de capteurs mobiles.

B. Le protocole DAWWSEN

Le protocole DAWWSEN (A deffense mechanism against wormhole attacks in wireless

networks) [21] un protocole de routage proactif qui consiste à construire un arbre hiérarchique où

la station de base est la racine, tandis que les nœuds capteurs sont les nœuds internes et les

feuilles.

On considère un réseau composé d’un petit nombre de stations de base et un nombre massif de

capteurs sans fil distribués d’une façon aléatoire. Ces nœuds ne sont pas mobiles et ils sont

équipés des antennes omni directionnelles [21].

• Construction de l'arbre hiérarchique

La construction de l'arbre est initiée par la station de base qui représente la racine. Elle diffuse

une requête afin de découvrir ses fils. Cette requête contient l'identificateur (ID) du nœud

d'origine de la requête ainsi que le nombre de sauts. Dans le cas de la station de base, le nombre

de sauts est fixé à 1. Lorsqu’un un nœud reçoit la première requête, il ne décide pas

immédiatement son père mais il attend pendant une durée de "REPLY DELAY" secondes afin de


- 41 -

collecter un ensemble de requêtes. A chaque réception de requête, le nœud crée une entrée dans

sa liste de requêtes de sorte qu'elle soit triée de façon croissante par le nombre de sauts comme le

montre la figure 2.12, c-à-d la requête ayant le nombre de sauts minimal sera placée en tête de la

liste.

Figure 2. 12 : Liste de requêtes d’un nœud recevant trois requêtes.

Après l'écoulement de la durée de "REPLY DELAY" de la réception de la première requête, le

nœud envoie une réponse avec son ID comme ID émetteur, le ID du premier élément de la liste

des requêtes comme ID destinataire et le nombre de sauts du premier élément de la liste des

requêtes. En plus, il met à jour sa table "Reply table" donnée par la figure 2.13.

Figure 2. 13 : "Reply table" après la transmission d'une réponse.

Dans cette figure :

ID 1 correspond à l'ID de destination de la réponse;

Nbr_saut1 correspond au Nbr_saut contenu dans la réponse.

Les champs Num_rep et Recv_accept sont initialisés à 0.Durant une période de « Check Delay »

secondes, le nœud qui a transmis la réponse reste en écoute des paquets de réponse. Il incrémente

le champs Num_rep à chaque fois qu’il reçoit une réponse avec les champs ID Source et ID

destination qui correspondent respectivement à son ID et l’ID de la destination dans sa table

« Replay table ».

Durant la période de « Accept Delay », après la réception de chaque réponse, le nœud parcoure sa

liste de réponses, si elle contient un élément avec le même ID source alors il incrémente le champ

Num_reply correspondant. Sinon, une entrée sera créée avec Num_reply =1 (voir figure 2.14).

ID 1 Nbr_saut1 Num_rep

=0

Recv_accept

=0

ID1

Hop Count1

ID3

Hop Count3

ID2

Hop Count2

ID1

Hop Count1

ID1

Hop Count1

ID3

Hop Count3

ID3

Hop Count3

ID2

Hop Count2

ID2

Hop Count2


- 42 -

Figure 2. 14 : Liste des réponses d’un nœud recevant trois réponses.

Après l’écoulement de la durée de « Accept Delay », le nœud envoi à chaque entrée de sa liste

« Reply liste » un paquet d’acceptation qui contient son ID comme ID source et l’ID contenu

dans sa liste de réponses comme ID destination ainsi que le champ Num_Reply qui désigne le

nombre de répétitions de réponses reçues de la destination.

Le nœud recevant un paquet d’acceptation « Accept Packet » parcoure sa table « Replay Table »

et vérifie si l’ID source correspond à un de ses éléments. Si ce n’est pas le cas, alors cela signifie

que ce paquet a été sauvegardé depuis une construction d’arbre précédente et a été réintroduit

maintenant et doit être supprimé. Sinon, le nœud met à jours sa table en modifiant la valeur du

champ Recv_Accept à « 1 » et teste l’égalité suivante :

Num_reply= Num_rep+1 (2.2)

Si elle n’est pas vérifiée alors une attaque Wormhole est détectée par ce nœud qui va :

1. Supprimer le paquet d’acceptation reçu,

2. Ajouter l’ID source à sa table NAP (Not Accept Packets),

3. Modifier sa table « Replay Table » en modifiant toutes les valeurs à « 0 »,

4. Envoyer une autre réponse au nœud qui correspond à la deuxième entrée dans sa

liste de requêtes, ou bien attendre une autre requête s’il n’y a pas.

Tous les ID contenus dans la table NAP d’un nœud ne peuvent jamais être ni ses pères ni ses

voisins. Toutes les requêtes reçues d’un nœud ayant l’ID dans la table NAP seront supprimées

immédiatement.

Si l’égalité (2.2) est vérifiée, alors le nœud recevant le paquet d’acceptation considère le nœud

ayant l’ID source dans le paquet d’acceptation son père et modifie sa table de routage en ajoutant

une entrée contenant l’ID du père ainsi que le nombre de sauts contenu dans le paquet

d’acceptation reçu. Il rediffuse ensuite une requête avec le nombre de sauts du père incrémenté.

De cette façon, un arbre de routage hiérarchique pour un réseau de capteurs sera créé rapidement.

Num_Reply1

ID1

Hop Count1

Num_Reply3

ID3

Hop Count3

Num_Reply2

ID2

Hop Count2

Num_Reply1

ID1

Hop Count1

Num_Reply3

ID3

Hop Count3

Num_Reply2

ID2

Hop Count2


- 43 -

C’est les nœuds recevant les requêtes et les paquets d’acceptation qui décident leurs pères, donc

les pères ne connaissent pas leurs fils. Cela n’a aucune influence sur le routage car les sens de

communication dans tels réseaux sont toujours des nœuds internes et feuilles vers la station de

base qui est la racine de l’arbre. La racine rediffuse une nouvelle requête pour la construction

d’un nouvel arbre hiérarchique après Trefresh secondes.

2.8.2. Approches décentralisées

L’avantage de ces approches est qu’elles ne nécessitent pas la présence d’une entité centrale dans

le système. Chaque nœud construit le modèle de ses voisins en utilisant les données collectées

localement.

Packet Leashes

Leash : est toute information, ajoutée à l’entête du paquet pour déterminer un seuil maximal de

distance de transmission autorisé. On distingue, selon la nature de l’information ajoutée, les

leashes géographiques des leashes temporels. Les deux types peuvent empêcher l'attaque

Wormhole.

A. Leashes géographiques

Ce mécanisme est basé sur l’information géographique pour construire des leashes

géographiques. Tous les nœuds doivent avoir des horloges synchronisées avec un taux d’erreur

t∆ et connaître leurs positions. Pour cela, chaque nœud doit être doté d’un système de

positionnement géographique GPS (Global Positioning System) avec un taux d’erreur p∆ .

A l’émission, l’émetteur ajoute au paquet sa position Ps et le temps d’émission du premier bit du

paquet Ts. Ensuite, le récepteur les compare avec sa position Pr et le temps de la réception du

premier bit du paquet Tr en calculant la distance réelle qui le sépare de l’émetteur comme suit :

)(22 ttstrvpdd Max ∆+−+∆+≤′

(2.3)


- 44 -

Tel que :

receptiondeetemissiondtempstt

noeudsdesimalevitessev

tempsdeerreurt

mentpositionnedeerreurp

ppd

rs

sr

':,

max:

max:

max:

max

∆

∆

−=rr

Si les nœuds ne sont pas mobiles alors :

pdd ∆+≤′ 2

(2.4)

Dans certaines circonstances, limiter la distance maximale entre l'émetteur et le récepteur ne peut

ni détecter ni empêcher l’attaque Wormhole.

Figure 2. 15 : Lien Wormhole entre deux nœuds séparés par un obstacle.

Par exemple, dans la figure 2.15 lorsque deux nœuds A et B ne s’entendent pas malgré qu’ils

soient dans la même portée radio, à cause d’un obstacle qui les empêche de communiquer, alors

ce mécanisme basé sur la localisation géographique permet le lien Wormhole entre l’émetteur et

le récepteur.

Les réseaux qui utilisent ce mécanisme peuvent aussi contrôler ce type de Wormhole grâce au

modèle de propagation radio1 (La propagation des ondes radio obéit à des règles complexes,

surtout lorsqu’il y a des obstacles entre l’émetteur et le récepteur). Parmi les modifications que

peut subir une onde radio, on peut citer :

1 Le modèle de propagation radio c’est un modèle mathématique utilisé pour acquérir des informations déterminantes

des phénomènes qui influent sur la radio comme la présence d’un obstacle.

A B

Lien Wormhole

Distance ≤ r

Obstacle

A B

Lien Wormhole

Distance ≤ r

Obstacle


- 45 -

• La réflexion,

• La diffraction,

• La diffusion,

• La réfraction.

Leashes temporelles

Elles sont implémentées avec un temps d’expiration de paquet. Pour construire des leashes

temporelles, tous les noeuds doivent avoir des horloges étroitement synchronisées, telle que la

différence maximum entre deux horloges de noeuds quelconques est ∆ .

La valeur du paramètre ∆ doit être connue par tous les nœuds du réseau et généralement elle doit

être de l'ordre de quelques microsecondes ou même des centaines de nanosecondes.

A l’émission, l’émetteur insère dans le paquet le temps de transmission du premier bit du paquet

ts. Quand le récepteur reçoit le paquet, ce dernier compare ts avec le temps de réception du

premier bit tr, ainsi le récepteur peut calculer la distance traversée par le paquet, puisque la

vitesse des nœuds ne peut pas dépasser celle de la lumière.

Le principal inconvénient de cette solution est qu’elle nécessite un mécanisme de synchronisation

entre tous les nœuds en raison de l’utilisation d’horloge. Ce niveau de synchronisation peut être

atteint actuellement avec un matériel près à l'utilisation basé sur LORAN-C2 [39],

WWVB3

[39], ou GPS mais pas pour les réseaux ad hoc et même impossible pour les réseaux de

capteurs sans fil [19].

B. Time-of-flight

Ce mécanisme est similaire à celui du temporal packet leashes et repose sur l’estimation du

temps qui s’écoule entre l’émission d’un paquet et la réception de son acquittement ACK. Ce

temps est connu sous le nom RTT (Round Trip Time). Le mécanisme calcule aussi la distance d

2Le LORAN (LOng RAnge Navigation) est un système de radionavigation utilisant les ondes d'émetteurs terrestres

fixes pour établir une position. Il s'agit du seul système hauturier à base terrestre restant en service car utilisé en

secours des systèmes de positionnement par satellite et notamment du GPS, quoique moins précis. La version

actuelle, le LORAN-C couvre un large parti de l'hémisphère Nord. Une version plus performante est en projet dans le

même but (E-LORAN).

3 WWVB est la station qui commande les horloges par radio dans tout le nord américain, elle est utilisée pour les

synchroniser.


- 46 -

donnée par l'équation (2.5) entre l’émetteur et le récepteur en fonction du RTT et détermine

ensuite si le récepteur est à l’intérieur de la région couverte par l’émetteur.

2

* vRTTd =

(2.5)

Avec :

d : la distance entre l'émetteur et le récepteur,

RTT : le temps de transmission d’un paquet et de son acquittement,

v : vitesse de la lumière,

Pour qu’un paquet soit accepté, il doit vérifier la condition suivante :

v

RRTT

vRTTRdR

*2

2

*<>> ⇒⇒

(2.6)

Avec :

R : la gamme de transmission radio,

Ainsi, on peut dire que le RTT constitue une délimitation du temps de transmission.

La formule (2.6) ne prend pas en considération le temps d’attente entre la réception du paquet,

son traitement puis l’envoi de son ACK au niveau du récepteur.

La formule deviendra alors :

tv

RRTT ∆+

*2<

(2.7)

Avec t∆ : le temps de traitement du paquet.

L’avantage qu’apporte l’utilisation du RTT est l’élimination du besoin de la synchronisation

exigée par temporal paquet leashes du fait que le nœud utilise seulement son horloge locale [38].

C. Location-aware guards

Une approche graphique théorique a été développée pour la prévention de l’attaque Wormhole.

Elle est basée sur l’utilisation des nœuds de garde qui connaissent leurs localisations (LAGNs:

Location-aware guard nodes ) et une diffusion locale des clés.

Les LAGNS ont une portée de communication plus large que celle des nœuds du réseau. Et les

clés utilisées ne sont valides que sur un seul saut, c'est-à-dire un message crypté par un noeud ne

peut être décrypté que par un de ses voisins directs (à un saut).

Lorsqu'une attaque Wormhole est présente, le message crypté avec une clé locale sera transféré

vers l’autre bout du tunnel et ne pourra en aucun cas être décrypté (voir figure 2.16).


- 47 -

Figure 2. 16 : Utilisation des clés locales pour le cryptage/décryptage des paquets.

Mais, l’établissement des clés locales en présence d’un lien Wormhole n’est pas évident, car elles

peuvent être acheminées d’une extrémité du lien vers l’autre extrémité. Ceci signifie que la clé

sera valide pour deux nœuds distants du réseau.

Pour remédier à ce problème, les LAGNs diffusent des messages hachés afin de détecter les liens

Wormhole durant l’établissement des clés locales. Les LAGNs sont supposés comme noeuds de

confiance par tous les noeuds du réseau. Comme leur position est connue, un nœud peut détecter

certaines inconsistances lors de la réception des messages en provenance de différents LAGNs si

un lien Wormhole est présent.

Sans la présence d’un lien Wormhole, un nœud ne peut pas entendre deux LAGNs qui sont loin

l’un de l’autre ni entendre un message du même LAGN deux fois [38].

L’utilisation des LAGNs, essentiellement, permet aux nœuds non équipés de GPS la perception

des irrégularités du réseau, qui résultent de la présence d’un tunnel Wormhole , et avoir une

approximation de leur position relative à celles des LAGNs.

Cette méthode apporte une amélioration à celle de paquet Leashes, en plus elle est plus

convenable aux réseaux de capteurs stationnaires denses qu’aux réseaux de capteurs mobiles.

D. Détection et élimination du Wormhole par la théorie des graphes

La formalisation du problème Wormhole selon [18] a été étudiée pour les réseaux ad hoc

comme suit :

Chaque réseau ad hoc peu être représenté par un graphe géométrique G(V, r ) où V désigne

l’ensemble de sommets et RdV ⊂ ; et r représente le rayon de communication tel que :

S 21 D4

Présence

d’un lien

Wormhole

Tunnel

Wormhole

3SS 2211 DD44

Présence

d’un lien

Wormhole

Tunnel

Wormhole

33


- 48 -

rji ≤− / Vji ∈,

Les entrées de la matrice de connectivité sont notés par :

(2.8)

L’existence de l’attaque Wormhole viole ce modèle, du fait que deux nœuds qui ne sont pas

voisins peuvent établir un chemin d’un seul saut en se servant du lien Wormhole. Cela entraîne

une transformation du graphe géométrique (initial) G(V, r) en graphe logique (déformé)

),(~

~G

EVG dans lequel on peut trouver :

rjipourjie >−= 1),( . (2.1)

La solution de ce problème consiste tout d’abord à constituer un graphe de communication

),( GEVG′

′ , où il n’existe aucun lien plus long que r, à l'aide d'une fonction de transformation

'~

: GGGS →×

Avec : r)G(V,),( ⊆′′GEVG .

Figure 2. 17 : Transformation des graphes.

Détecter l’attaque Wormhole et son élimination en employant des techniques de la théorie des

graphes:

Notons par :

CX : La matrice de connectivité du graphe X,

)(

=

≤−

−

rjisi

rjisijie

1

0,

>


- 49 -

)(iC X : Le vecteur de connectivité correspondant à un nœud i,

),( jiCX : La connectivité des nœuds i et j.

Dans [18] la détection des liens établis par l’attaquant se fait par une opération XOR entre la

matrice de connectivité du graphe géométrique CG et celle du graphe logiqueCG

~ .

Dans la matrice qui résulte de l’opération XOR, les valeurs qui sont positionnées à 1 indiquent

l’existence d’un lien Wormhole entre le nœud i et le nœud j.

Figure 2. 18 : Attaque Wormhole dans un Réseau Ad hoc[18].

Prenant par exemple le vecteur du nœud 2 dans la figure 2. 18 :

]0001011100000[)2( =CG

]0001011100010[)2(~ =CG

]0000000000010[)2)(( ~ =⊕CC GG

⇒=⊕ 1)9,2)(( ~CC GG Le lien entre les nœuds 2 et 9 est un lien Wormhole.

E. WORMEROS

C’est une méthode constituée de deux phases pour détecter une attaque Wormhole [22]. On

considère un réseau ad hoc sans aucun serveur centralisé où aucun de ses nœuds n'est compromis.

Les liens sont supposés bidirectionnels et la topologie ne change pas rapidement. On suppose que

chaque paire de nœuds dans le réseau partage deux clés cryptographiques K1 et K2.

Dans ce qui suit on utilise les notations suivantes :

• P : délai de propagation d'un nœud légitime,

• RTT(S,D) : RTT entre le nœud S et D,

• RTT Wormhole : RTT d’un lien en présence d'une attaque Wormhole,

• AvgsAll : la moyenne RTT de tous les liens à partir de S vers ses voisins,


- 50 -

• w : le temps de transfert d’un paquet entre les deux extrémités d’un Wormhole,

• d : le nombre de voisins d’un nœud,

• E(K,M) : le message M est crypté en utilisant la clé secrète K.

Figure 2. 19 : Attaque Wormhole dans un réseau Ad hoc [22].

(a)liens légitimes ;(b) lien Wormhole.

Phase de suspicion :

Dans cette phase, on cherche les liens suspects d’être des liens Wormhole.

Considérons par exemple la figure 2.19 dans laquelle on suppose que le nœud S communique

avec le nœud D via le Wormhole XY. S connaît que les nœuds B, D sont ses voisins directs et il

peut mesurer le RTT4 des liens (S, B) et (S, D).

Si AvgkRTTS

AllDS≥

),(

Alors le lien (S, D) peut être un lien Wormhole

Avec k: paramètre système qui dépend de d et w.

Algorithme1 : détection par RTT

Cet algorithme détecte la présence de lien Wormhole en mesurant le RTT du lien durant la

découverte de route « route discovery ».

S calcule RTT moyenne après n essai.

S calcule RTT moyenne de d voisin.

Si AvgkRTTS

AllDS ≥),(

Alors le lien (S, D) est suspect d’être Wormhole

4 C'est le temps que prend un paquet pour traverser le réseau d'un nœud vers un autre. Le nœud calcule la RTT des

liens menant vers d'autres nœuds par la différence entre le temps d'émission du paquet et le temps de réception de

son ACK.


- 51 -

Exécuter la phase confirmation

Algoithme2 :

Cet algorithme utilise l’information de voisinage

S collecte l’identité de ses voisins d’un et de deux pas et crée son ensemble de

voisinage ;

Si D figure dans le voisinage de S

Alors le lien (S, D) est suspect d’être un lien Wormhole

Phase de confirmation

Comme l'indique son nom, c'est la phase qui sert à confirmer les liens wormhole après leur

détection durant la phase de suspicion, pour cela on utilise le saut de fréquence. Cette phase est

illustrée par la figure 2.20.

Algoithme3 : frequency hopping challenge

� S transmet un message crypté sur la fréquence f1 au noeud D lui demandant la

réservation du lien (S, D);

� D répond par un message crypté sur la fréquence f1 en spécifiant aléatoirement une

fréquence f2;

� D règle son tranceiver sur la fréquence f2 et reste en attente durant 2*RTT(S,D);

� Après la réception du message émis par D, S envoi un message sur la fréquence f2 et

attend l'ACK correspondant;

� Si S ne reçoit pas l'ACK de D dans une durée de 2*RTT(S,D) alors le lien (S,D) est un

Wormhole.


- 52 -

Figure 2. 20 : Phase de confirmation -WORMEROS-

Si S et D sont éloignés et deviennent voisins directs à cause du lien Wormhole, alors le

changement de la fréquence de communication rend la communication directe, en un seul saut,

impossible. Ceci est dû à l'ignorance de l'attaquant de la nouvelle fréquence de communication

utilisée par les extrémités et ainsi ne peut ni recevoir les messages de S ni retransmettre des

messages vers D. De cette façon, l’attaque Wormhole est détectée [22].

2.9. Conclusion

Ce chapitre a été consacré au concept de l’attaque Wormhole, objet de notre travail, et son impact

sur le routage (découverte de route et acheminement de données par la suite). Nous avons aussi

montré comment cette attaque peut être montée de différents modes afin de perturber le

fonctionnement du réseau et dégrader ces performances.

Nous avons présenté aussi un état de l’art dans lequel nous avons énuméré les différentes

solutions existantes dans la littérature, qui s’étoffe très rapidement dans ce domaine et offre des

solutions pour l’attaque Wormhole dans les réseaux de capteur sans fil.

Mais, ces solutions sont généralement difficiles à implémenter. Certaines solutions nécessitent

un dispositif de localisation GPS, d’autres exigent une synchronisation des horloges des nœuds

du réseau. La solution qui nous semble la plus réaliste et la plus pratique est celle basée sur le

RTT, car elle n’a besoin que de l’horloge interne du nœud lui-même.


- 53 -

Cette étude nous a permis de tirer profits des méthodes basées sur le RTT pour proposer un

protocole de routage sécurisé.

Le chapitre suivant sera consacré à la description détaillée de notre approche pour lutter contre

l’attaque Wormhole dans les RCSFs. Notre but consiste à sécuriser un protocole de routage

réactif pour détecter la présence du tunnel Wormhole dans un RCSF afin de l’éviter durant

l’acheminement des données.

Chapitre 3 Mécanisme de détection & isolation de l’attaque Wormhole

- 54 -

3 Mécanisme de

détection &

isolation de

l’attaque Wormhole

dans les RCSF.

3.1. Introduction

Ce chapitre traite une solution qui permet de sécuriser le protocole AODV contre l’attaque

Wormhole. On a commencé par présenter la notion de réseau de capteur sans fil, son

architecture de communication, ses contraintes et les attaque mené sur lui. Et on s’est

intéressé à l’attaque Wormhole. Plusieurs solutions ont été proposées pour sécuriser les

réseaux de capteur sans fil contre cette attaque. Ces solutions diffèrent selon les moyens

utilisés tel que RTT, Packet leashes, GPS, et la nature de la méthode de traitement (centralisée

ou décentralisée).


- 55 -

Par la suite, on introduira notre mécanisme proposé pour la détection de l’attaque Wormhole

basée sur le calcule de la distance à partir du RTT (Round Trip Time) et ainsi interdire les

paquets passant par le tunnel.

3.2. Méthode distribuée pour la détection de l’attaque Wormhole

On suppose notre réseau de capteur sans fils est stationnaire.

Comme il a été précédé, la distance qui sépare deux nœuds voisins est calculée en fonction de

RTT.

2

* vRTTd =

v

RRTT

vRTTRdR

*2

2

*<>> ⇒⇒

v

RRTT

*2< .

Notre solution vise la sécurisation du mécanisme de découverte de routes (Route Discovery)

avant même de commencer la transmission de données ce qui rend le contrôle des paquets de

données impossible pour les nœuds malicieux. Ce processus comporte deux phases : phase de

détection et celle d’établissement de route en évitant les tunnels Wormhole (isolation).

A. Phase de détection :

La détection de la présence d’un Wormhole dans notre solution est faite par le biais de

distance entre deux nœuds voisins.

RTT est le temps qui s’écoule entre l’envoi d’une requête et la réception de sa réponse mais

avant de recevoir la réponse d’une requête, cette dernière continu à parcourir le réseau

jusqu’atteindre sa destination qui génère une réponse RREP. Celle là parcourra le chemin

inverse de la RREQ ;

Le délai de propagation est calculé en éliminant la durée qui s’écoule entre la réception du

RREQ et la transmission du Rrep par le nœud précédent du chemin inverse.

Le schéma qui suit démontre le calcule du RTT et du délai de propagation.

Dans cette étape la source initie une recherche de route en diffusant un message RREQ et

sauvegarde le temps de sa transmission TReq. Les nœuds intermédiaires à leur tour

rediffusent RREQ et sauvegardent le temps de transmission TReq. Quand RREQ atteint sa

destination elle génère RREP (Route Reply) avec une route inverse. Quand un nœud

intermédiaire reçoit RREP il calcule son RTT et il l’intègre dans RREP pour l’envoyé au

nœud suivant.


- 56 -

RTT se calcule comme suit :

�� (1)

RTT inclut le temps durant lequel RReq atteint la destination, en parcourant les nœuds

intermédiaires, et RREP atteint le noeudi.

� �� (2)

�� /2 (3)

Tel que

�� : Distance entre le nœud i et le nœud (i-1) ;

�� : Temps de Parcours calculé au niveau du nœud (i-1);

� �� : Délai de propagation calculé par le noeudi;

�: vitesse de la lumière. � � 299 792 458 m/s.

Quand la distance d est supérieure à la portée du nœud alors un lien Wormhole entre le nœud i

et le nœud i-1 est présent.

Figure 3. 1: Déroulement du mécanisme distribué de détection de l’attaque Wormhole.

B. Phase d’isolation du tunnel Wormhole :

Quand un tunnel Wormhole est détecté par un nœud i alors ce dernier :

� Marque le nœud i-1 comme un faux voisins dans sa liste des voisins ;

� envoi un HELLO d’avertissement pour alerter le nœud i-1 disant qu’il n’est

pas son vrai voisin. En recevant le hello d’avertissement le nœud i-1 à son tour

marque le nœud i dans sa liste de voisins comme un faut voisin1 ;

1 Un faut voisin est un nœud considéré comme voisin et qui n’est pas dans la porté radio de ce nœud. Donc il

est atteint via un lien Wormhole.


- 57 -

� Achemine RREP en indiquant qu’il y a un tunnel. il sert aussi à détecter

d’autres tunnels s’il y en a et mettre à jour les listes des faux voisins de chacun

des intermédiaires parcourus jusqu’à la source.

Quand la source reçoit un RREP passant via le tunnel Wormhole alors elle :

• Ignore le RREP ;

• initie une nouvelle découverte de route.

Dans les découvertes de routes qui suivent, si un nœud reçoit un RREQ parvenant d’un faux

voisin alors il sera ignoré. Ce qui interdit tout RREQ de passer par un tunnel Wormhole.

Et comme ça le tunnel est évité.

Exemple

Selon la Figure 3.1, le nœud S initie une découverte de route en diffusant un message RREQ,

qui traverse les nœuds intermédiaires jusqu’à l’arrivée à la destination D; quand cette dernière

est atteinte un paquet RREP est généré, elle parcourt le chemin inverse de RREQ vers la

source S.

Les nœuds intermédiaires ainsi que la source profitent du passage de RREP pout mettre à jour

de leurs tables de routage, et calculer la distance à base de RTT.

Et comme le RTT est le temps entre la transmission du RREQ et la réception du RREP, le

temps de propagation est calculé par l’extraction de la durée du parcours où le message a

traversé les nœuds suivants en route vers la destination et l’arrivé de la réponse RREP.

3.3. Le protocole AODV

C’est un protocole de routage conçu par Charles E.Perkins et Elizabeth M. Royer et spécifié

dans le RFC 3561 [23]. C'est un protocole basé sur le principe des vecteurs de distance et

appartient à la famille des protocoles réactifs c'est-à-dire que les routes ne sont établies qu’à la

demande. Il représente essentiellement une amélioration de l'algorithme proactif DSDV mais

réduit l'overhead (nombre de diffusions de messages de contrôle) en ne calculant les routes

que sur demande et en maintenant les chemins d’une façon distribuée en gardant une table de

routage, au niveau de chaque nœud de transit appartenant au chemin cherché , contrairement à

DSDV qui maintient la totalité des routes.

Il est constitué de deux mécanismes "découverte de route" (Route Discovery) et "maintenance

de route" (Route Maintenance), en plus du routage " nœud par nœud " et construit les routes

par l'emploi d'un cycle de requête "route request/route reply".

Le mécanisme de fonctionnement du protocole est détaillé dans [24].

Chapitre 3 Mécanisme de détection & isolation de l’attaque W

AODV utilise le principe des numéros de séquence afin de maintenir la consistance des

informations de routage [24][25]

ad hoc, les routes changent fréquemment ce qui fai

nœuds, deviennent invalides. Les numéros de séquence permettent d'utiliser les routes les plus

fraîches (fresh routes).

Afin de maintenir des routes cohérentes, une transmission périodique du message "HELLO"

est effectuée. Si au bout d’un certain temps aucun message "HELLO" n’est reçu à partir d’un

nœud voisin, le lien en question est considéré défaillant. Le protocole AODV ne présente pas

de boucle de routage, et offre une convergence rapide quand la topologie du

Cependant, l’AODV maintient les chemins d’une façon distribuée en gardant une table de

routage, au niveau de chaque nœud

3.4. Intégration dans AODV

Plusieurs extensions doivent être in

que Route Reply (RREP) pour que le mécanisme de détection de l’attaque

précédemment soit intégré dans le protocole AODV.

3.4.1. Extension des RREQ d’AODV

Le format de route request RREQ

� Temps de Transmission du RREQ

� Temps de Réception du RREQ

Figure 3.

3.4.2. Extension du RREP

Le format de route reply RREP

� Temps de Transmission du RREP : T_rep;

� Temps de Réception du RRE

� Temps de Transmission du RREQ

� Temps de Réception du RREQ: R_req

Figure 3.

3.4.3. Extension de la structure BROADCASTID

Chapitre 3 Mécanisme de détection & isolation de l’attaque W

- 58 -


[24][25]. A cause de la mobilité des nœuds dans les réseaux mobiles

ad hoc, les routes changent fréquemment ce qui fait que les routes maintenues par certains



fectuée. Si au bout d’un certain temps aucun message "HELLO" n’est reçu à partir d’un

voisin, le lien en question est considéré défaillant. Le protocole AODV ne présente pas

de boucle de routage, et offre une convergence rapide quand la topologie du


nœud de transit appartenant au chemin cherché.

Intégration dans AODV

Plusieurs extensions doivent être introduites dans la structure de Route Request (RREQ) ainsi

eply (RREP) pour que le mécanisme de détection de l’attaque

précédemment soit intégré dans le protocole AODV.

des RREQ d’AODV

RREQ est étendu pour inclure deux nouveaux champ

Temps de Transmission du RREQ par le nœud précedent : T_req_prec;

Temps de Réception du RREQ: R_req ;

Figure 3. 2 : extension de l’entête RREQ.

RREP d’AODV

est étendu pour inclure quatre nouveaux champ

Temps de Transmission du RREP : T_rep;

Temps de Réception du RREP: R_rep ;

Temps de Transmission du RREQ par le nœud précedent : T_req_prec;

Temps de Réception du RREQ: R_req ;

Figure 3. 3: extension de l’entête RREP.

de la structure BROADCASTID



cause de la mobilité des nœuds dans les réseaux mobiles

t que les routes maintenues par certains



fectuée. Si au bout d’un certain temps aucun message "HELLO" n’est reçu à partir d’un

voisin, le lien en question est considéré défaillant. Le protocole AODV ne présente pas

de boucle de routage, et offre une convergence rapide quand la topologie du réseau change.


de transit appartenant au chemin cherché.

equest (RREQ) ainsi

eply (RREP) pour que le mécanisme de détection de l’attaque Wormhole décrit

champs qui spécifient :

: T_req_prec;

champs qui spécifient :

: T_req_prec;


- 59 -

Pour maintenir les temps de transmission et réception du RREQ reçus une extension de la

structure BROADCASTID est nécessaire. Elle consiste à étendre l’entré de chaque ID d’un nœud

précis pour inclure deux nouveaux champs :

� Temps de Transmission du RREQ par le nœud précédent : T_req;

� Temps de Réception du RREQ: R_req ;

3.5. Le protocole AOMDV

C’est une extension d’AODV [25], supportant le routage multi-chemin à lien disjoint. Pour

garder trace de plusieurs chemins, à chaque destination est associée une liste de sauts

prochains avec le nombre de sauts correspondants. Pour trouver des chemins lien-disjoints

entre une paire source destination, chaque nœud intermédiaire ne supprime pas tous les

paquets RREQs dupliqués, mais il accepte ceux arrivant via différents voisins du nœud

source.


- 60 -

Figure 3. 4: Organigramme du traitement des paquets RREQ.

Début

Lire le Brcst_id du RREQ

Brcst_id > RREQ_id de la table

source-broadcast_id ?

Brcst_id = RREQ_id de la table

source-broadcast_id ?

RREQ_id = Brcst_id

Sauvegarder le chemin dans le

cache

Le chemin Liste_nd est

disjoint avec le reste des

chemins sauvegardés ?

Détruire le RREQ

Ajouter l’adresse de destination

à la liste des nœuds du chemin

Incrémenter le numéro de

séquence

Générer un paquet RREP

Non

Fin Envoyer le paquet RREP au

nœud à partir duquel le RREQ a

été reçu

Récupérer le temps de transmission du RREP T_rep

Récupérer le temps de réception et de

transmission du RREQ R_req & T_req

Oui Non


- 61 -

Figure 3. 5: Organigramme de la sélection des chemins disjoints.

Non Oui

Début

Recevoir un paquet RREP

Dst_ns du RREP >=

Dst_ns de la table de

routage ?

Envoyer le paquet RREP vers le prochain saut

Lire le Dst_ns du RREP

Lire la liste des nœuds du chemin

Mettre à jour la table de routage

Envoyer les paquets de données

Fin

Vérifier le nombre de routes existantes dans la table

de routage

Nombre de routes > 3 ?

Mettre à jour la table de routage

Dst_ns du RREP >=

Dst_ns de la table de

routage ?

Lire le Dst_ns du RREP

Oui Non

Non

L’adresse destination du

RREP = l’adresse du nœud ?

Oui

Non Mentionner le passage par un

Wormhole

Calculer le Temps de parcours & RTT

Récupérer le temps de réception de RREP R_rep

RTT*3*108>r

Récupérer le temps de transmission du RREP T_rep

Récupérer le temps de reception et de

transmission du RREQ R_req & T_req


- 62 -

Figure 3. 6: Organigramme de traitement d’un message RREP.

Recevoir un paquet RREQ

Débu

Stocker temps d’émission & réception du RREQ T_req

Récupérer le temps de

transmission du RREQ

Oui

Non

Lire l’adresse source du RREQ

Lire l’adresse destination du RREQ

L’adresse source du

RREQ = L’adresse du

Mettre à jour la valeur du

T_erreur

Mettre à jour la valeur du

T_délai > 0 et T_erreur <

Brcst_id > RREQ_ID de la

table source-

Brcst_id = RREQ_ID de

la table source-

Lire le Nbr_saut du RREQ

Nbr_saut du RREQ <

Nbr_saut du plus court

Détruire le RREQ

RREQ_id = Brcst_id

Nbr_saut du plus court

chemin inverse = Nbr_saut du

RREQ

Ajouter l’adresse du nœud

dans Liste_nd

Diffuser le paquet RREQ aux

nœuds voisins

Fin

Procédure de

sélection des

chemins

Lire le Brcst_id du RREQ

Non

Oui

Non

Non

Oui

Oui

Oui

Oui

L’adresse dest RREQ = L’adresse du

nœud ?

Non


- 63 -

3.6. Conception de l'attaque Wormhole

La validation de n’importe quel nouvel algorithme conçus pour les RCSF est d’une grande

importance, et cela n’est faisable qu’après la simulation qui nous permet de tirer des résultats

afin de les comparer avec les autres. Et comme notre mécanisme est conçus pour la détection

des l’attaque Wormhole, cette dernière est cruciale pour simuler et tester le protocole sécurisé.

L’attaque que l'on considère est une attaque passive. Elle est conçue comme elle a été décrite

dans le chapitre précédent. Deux nœuds malveillants acheminent les messages captés à une

extrémité du tunnel vers l’autre en se servant d’une liaison filaire. Dans le chapitre qui suit

nous présentons en détail l’implémentation de cette attaque sous ns2.

3.7. Conclusion

Dans ce chapitre nous avons présenté un nouveau mécanisme distribué pour la détection de

l’attaque Wormhole dans les réseaux de capteur sans fil durant la phase de découverte de

route. Dans le chapitre qui suit nous présentons l’implémentation de notre solution après avoir

implémenté l’attaque Wormhole.

Chapitre 4 Implémentation & expérimentation

- 64 -

4 Implémentation

&

expérimentation

4.1. Introduction

Avec l’évolution des réseaux sans fil et l’élaboration de plusieurs normes pour ces réseaux, et

avec le besoin des simulations dans le contexte de l’évaluation des performances, de

nombreux simulateurs des réseaux ont été développés. Les simulateurs les plus connus sont :

NS-2 (Network Simulator 2), OPNET[34], OMNET[35] et GloMoSim/Qualnet [36].

L’utilisation d’un réseau réel pour l’évaluation est difficile et coûteuse. Aussi, le réseau réel

n’offre pas la souplesse de varier ses différents paramètres et pose en plus le problème

d’extraction de résultats ; c’est pour cela la majorité des travaux d’évaluation des

performances utilisent le principe de la simulation vu les avantages qu’il offre.


- 65 -

Dans le cadre de ce travail, l'évaluation de performance du protocole de routage AODVsec

sera abordée par les simulations sous NS2, elle permet de dégager l'effet de notre solution sur

le délai de bout en bout.

Il est à noter que l’étude expérimentale sur la version multichemin d’AODV est la même que

celle que nous proposons dans ce chapitre, car elle pourra s’appliquer aux chemins prix

individuellement.

Dans ce chapitre, nous allons en premier lieu, présenter la plate-forme logicielle que nous

avons utilisée pour les simulations NS2, ensuite, nous allons présenter les contextes des

simulations et les résultats obtenus pour le protocole standard AODV et sa version sécurisée.

4.2. Environnement de simulation

Le tableau présente plateforme d’implémentation que nous avons choisie ainsi que les

caractéristiques de la machine utilisée. Pour réaliser notre travail on a installé NS2 sur une

machine virtuelle en utilisant VMWARE.

Simulateur NS2.34

Système d’exploitation LINUX UBUNTU 8.04

CPU Core 2 Duo, 2GHZ

RAM 512 MO

Disque dur 12 GO

Tableau 4. 1 : La plate forme logicielle.

Le simulateur NS-2 que nous avons choisi Dans le cadre de notre étude, est développé à

Lawrence Berkeley National Laboratory (LBNL). C’est le simulateur de réseaux le plus

utilisé par la communauté des chercheurs dans le domaine des réseaux.

Le simulateur NS2 est un simulateur à événements discrets qui permet d'exécuter tout type de

scénarios sur des topologies définies par l'utilisateur. Il permet la description et la simulation

de réseaux IP. Le réseau est représenté (modélisé) par ses sources de trafic (applications), ses

protocoles (UDP, TCP), ses routeurs (avec leurs files d'attente) et les liens qui les relient. Le

réseau est ensuite simulé, ce qui produit des traces et des statistiques. Des outils périphériques

permettent l'animation du réseau (NAM : Network Animator) ou la conversion vers d'autres

outils, comme par exemple Xgraph pour dessiner des courbes.

NS2 offre plusieurs avantages ; nous pouvons citer [28]:


- 66 -

• Il est open source et gratuit. Il englobe les contributions de nombreux chercheurs à

travers le monde.

• Il peut être étendu à d'autres modèles grâce à sa conception orientée objet et son

implémentation en C++.

• Il est riche en modèles et en protocoles pour les environnements filaires/sans fil et

stationnaire/mobiles.

• Il fournit des résultats fiables sous forme de fichier trace riche en informations que

l'utilisateur peut exploiter.

• Il est bien documenté. Les ressources bibliographiques relatives à sa conception et son

implémentation sont très nombreuses.

• Il inclut les implémentations de plusieurs protocoles de routage à savoir : AODV,

DSDV, DSR et TORA.

En plus de ces avantages, l’approche évolutive que nous avons choisie dans cette étude

justifie notre choix de NS2, car une implémentation du protocole AODV ainsi que celle du

protocole AOMDV existent déjà, il suffit donc d’y apporter les modifications nécessaires qui

permettent d’intégrer le mécanisme de détection et d’isolation de l’attaque Wormhole décrit

dans le chapitre précédent.

Ce présent chapitre est consacré aux détails de l’implémentation du protocole AODVSec sous

NS2. Pour ce faire, nous présentons d’abord les différents fichiers et modules concernés par

les modifications.

4.3. Implémentation d’AODV sous NS2

L’implémentation du protocole AODV sous NS-2 a été faite autour des fichiers sources situés

dans le répertoire : \home\...\ns-allinone-2.34\ns-2.34\aodv. Les fichiers concernés sont les

suivants :

aodv.h : c’est le fichier principal header dans lequel sont définis tous les temporisateurs

timers nécessaires, et l’agent de routage qui exécute les fonctionnalités du protocole.

aodv.cc : dans lequel tous les timers, les commandes (liens entre les composants c++ et ceux

d’OTcl) sont implémentés, ainsi que l’agent de routage et ces fonctionnalités.

aodv_packet.h : ici sont déclarés tous les types de paquets qu’utilise AODV dans les

échanges entre les nœuds du réseau.

aodv_rtable.h : le fichier header où la table de routage est déclarée.

aodv_rtable.cc : implémentation de la table de routage.

Chapitre 4

aodv_rqueue.h : ce fichier définit la file d’attente utilisée par le protocole de routage

déclaration des différentes fonctions et méthodes utilisées qui servent à la

cette file.

aodv_rqueue.cc : il contient l’implémentation de la file et de fonctionnalités.

aodv_logs.cc : destiné à la gestion de la connectivité locale entre les

Pour plus de détails d’implémentation du protocole AODV sous NS2 et la relations entre

fichiers avec d’autres fichiers ainsi que les différentes classes et méthodes utilisées

[28] .

4.4. Architecture d’un

La classe Node est une classe OTcl.

tcl/lib/ns-node.tcl. Un

classifier démultiplexe les paquets. L'agent est habituellement l'entité d'un protocole

Figure 4.

4.5. Implémentation de l’attaque W

Avant d’implémenter notre algorithme, l’implément

extrêmement importante parce qu’elle

Afin de simuler l’attaque Wormhole décrite dans le chapi

couche supplémentaire insérée dans la pile protocolaire

sont dans notre cas deux nœuds)

comme le montre la figure 4.2

Implémentation & expérimentation

- 67 -

ce fichier définit la file d’attente utilisée par le protocole de routage

déclaration des différentes fonctions et méthodes utilisées qui servent à la

l’implémentation de la file et de fonctionnalités.

destiné à la gestion de la connectivité locale entre les nœuds

Pour plus de détails d’implémentation du protocole AODV sous NS2 et la relations entre

chiers ainsi que les différentes classes et méthodes utilisées

nœud dans ns2

lasse Node est une classe OTcl. Cette classe et ses méthodes sont définies dans le fichier

Un nœud est une collection de classifiers et d'agents. Le

classifier démultiplexe les paquets. L'agent est habituellement l'entité d'un protocole

Figure 4. 1 : architecture du nœud dans ns2.

Implémentation de l’attaque Wormhole

nter notre algorithme, l’implémentation de l’attaque Wormhole est

importante parce qu’elle nous permet de tester la solution proposée

ormhole décrite dans le chapitre 2, nous avons

lémentaire insérée dans la pile protocolaire des nœuds supposées compromis (qui

sont dans notre cas deux nœuds), exactement entre la couche MAC et la couche physique

comme le montre la figure 4.2

Implémentation & expérimentation

ce fichier définit la file d’attente utilisée par le protocole de routage et la

déclaration des différentes fonctions et méthodes utilisées qui servent à la manipulation de

l’implémentation de la file et de fonctionnalités.

nœuds du réseau.

Pour plus de détails d’implémentation du protocole AODV sous NS2 et la relations entre ces

chiers ainsi que les différentes classes et méthodes utilisées, voir [26]

Cette classe et ses méthodes sont définies dans le fichier

de classifiers et d'agents. Le

classifier démultiplexe les paquets. L'agent est habituellement l'entité d'un protocole[26][28].

l’attaque Wormhole est une étape

la solution proposée.

vons développé une

supposées compromis (qui

et la couche physique,


- 68 -

Figure 4. 2: Deux nœuds malicieux reliés constituant un tunnel Wormhole.

Le tunnel Wormhole relie les nœuds malicieux au niveau de cette couche, dans notre cas, via

une liaison filaire.

Le comportement de cette couche dite 'Wormhole' est détaillée par le code source qui suit.

Commençant par l’explication du rôle de la propriété direction du paquet :

Cette propriété désigne le sens du paquet, s’il parvient du voisinage ou des nœuds voisins,

alors il va parcourir les couches de la pile protocolaire de bas en haut donc sa destination est

mise à « UP »

Si le paquet est généré par ce nœud alors il va parcourir les couches de la pile protocolaire du

haut en bas, dans ce cas sa destination sera forcement mise à « DOWN ».

Le traitement du paquet reçus par la couche Wormhole diffère selon sa direction :

• S’il est reçu de la couche MAC (couche supérieure) alors sa direction est égale à

‘DOWN’, et ainsi la couche Wormhole transmis une copie de ce paquet vers la

deuxième extrémité du tunnel, avant de le transmettre à la couche physique (couche

inférieure) ;

• S’il est reçu de la couche physique (couche inférieure) alors sa direction est égale à

‘UP’, et ainsi la couche Wormhole transmis une copie de ce paquet vers la deuxième

extrémité du tunnel, avant de le remonter vers la couche MAC (couche supérieure);

• S’il est reçu de la couche Wormhole de la deuxième extrémité du tunnel donc sa

direction est égale à ‘TUNNELEDU’ ou ‘TUNNELEDD’. Dans ce cas la couche

Wormhole remonte une copie de ce paquet vers le haut (couche MAC) et le rediffuse

dans le voisinage.


- 69 -

void Wormhole::recv(Packet* p, Handler* h)

{

hdr_cmn *ch = HDR_CMN(p);

hdr_mac802_11 *mh = HDR_MAC802_11(p);

u_int32_t dst = ETHER_ADDR(mh->dh_ra); //Adresse MAC Destinataire

u_int32_t src = ETHER_ADDR(mh->dh_ta); //Adresse MAC Recepteur

switch (ch->direction()) {

case hdr_cmn::UP :

{

if (State_wormhole==ACTIVATED)

{

tunnel(p,h);

}

sendUp(p, h);

}

break;

case hdr_cmn::DOWN :

{

if (State_wormhole==ACTIVATED)

{

tunnel(p,h);

}

ch->tt=Scheduler::instance().clock();//temps actuel

sendDown(p, h);

}

break;

case hdr_cmn::TUNNELEDD :

{

if(dst== MAC_BROADCAST)

{if (src != (u_int32_t)(mac_->addr()))

{ch->direction() = hdr_cmn::UP; //changer la direction packets

acheminés via le tunnel

sendUp(p->copy(), h);}

ch->direction() = hdr_cmn::DOWN; //changer la direction

packets acheminés via le tunnel

sendDown(p, h);

}

else{ if(dst == (u_int32_t)(mac_->addr()))


{ch->direction() = hdr_cmn::UP; //changer la direction



- 70 -

sendUp(p, h);

}

}

else { ch->direction() = hdr_cmn::DOWN; //changer la

direction packets acheminés via le tunnel

sendDown(p, h);

}

}

}

break;

case hdr_cmn::TUNNELEDU :

{

ch->tunneled=true;

if(dst== MAC_BROADCAST)




sendUp(p->copy(), h);

}

ch->direction() = hdr_cmn::DOWN; //changer la direction


sendDown(p, h);

}

else { if (dst == (u_int32_t)(mac_->addr()))



sendUp(p, h);

}

else {ch->direction() = hdr_cmn::DOWN; //changer la

direction packets acheminés via le tunnel

sendDown(p, h);

}

}

}

break;

default:

printf("Erreur Direction du paquet non spécifié; utilisant 'UP' par

défaut\n\n");

}

}

Figure 4. 3 : Le code source de la procédure du traitement d’un paquet reçus.


- 71 -

La procédure tunnel (Packet *p, Handler *h) illustrée par la figure 4.4 est appelée par une

extremité du tunnel Wormhole pour transmettre une copie du paquet « p », reçus vers l’autre

extrémité du tunnel, par l’instruction : tunnel_->recv(p1,h) ; tel que p1 est une copie du

paquet p.

Avant de transmettre le paquet via le tunnel on le nœud Wormhole emetteur met dans le

champs direction l’une des deux valeurs suivantes :

TUNNELEDU ou TUNNELEDD pour indiquer que ce paquet est déjà transmis via le tunnel

et ainsi éviter des boucles.

void Wormhole::tunnel(Packet *p, Handler *h)

{

Packet *p1;

p1=p->copy(); // creation d’une copie du paquet p

hdr_cmn *ch = HDR_CMN(p1);

hdr_mac802_11 *mh = HDR_MAC802_11(p1);

u_int32_t dst = ETHER_ADDR(mh->dh_ra); //address MAC destinataire.

u_int32_t src = ETHER_ADDR(mh->dh_ta); //address MAC emetteur.

char *pkttype;

pkttype=new char[12];

switch(ch->ptype()) {

case PT_MAC:

sprintf(pkttype,"PT_MAC");

break;

case PT_ARP:

sprintf(pkttype,"PT_ARP");

break;

case PT_AODV:

sprintf(pkttype,"PT_AODV");

break;

default:

sprintf(pkttype,"type non defini");

break;

}

switch (ch->direction()) {

case hdr_cmn::UP :

{ch->direction() = hdr_cmn::TUNNELEDU; //pour indiquer que ce paquet est

déjà transmis via le tunnel Wormhole et ainsi éviter des boucles}

break;

case hdr_cmn::DOWN :


- 72 -

{ch->direction() = hdr_cmn::TUNNELEDD; //pour indiquer que ce paquet est

déjà transmis via le tunnel Wormhole et ainsi éviter des boucles }

break;

default:

printf("Error: Packet Direction not specified; Using default 'UP'

direction\n\n");}

assert(tunnel_);

tunnel_->recv(p1,h) ;

}

Figure 4. 4: La procédure qui se charge de transmettre le paquet via le tunnel.

Pour insérer cette nouvelle couche dite Wormhole dans la pile protocolaire, des

modifications sont à apporter sur le fichier /…/NS2.34/TCL/LIB/ns-mobilnode.tcl qui est

relatif à l’architecture interne des nœuds mobiles. La figure 4.5 présente ces modifications

Node/MobileNode instproc wormhole-attach {tunnellink} {

$self instvar mac_ ifq_ ll_ wormhole_ netif_

:

:

:

set wormhole_ [new Wormhole]

$wormhole_ down-target [$mac_(0) down-target]

$wormhole_ up-target $mac_(0)

$netif_(0) up-target $wormhole_

$mac_(0) down-target $wormhole_

$wormhole_ mac $mac_(0)

}

Figure 4. 5: Code TCL pour l’Insertion de la couche Wormhole dans la pile protocolaire du nœud

mobile sous NS2.

Après avoir terminé l’implémentation de l’attaque Wormhole, passons maintenant à la couche

réseau. C’est à ce niveau que l’agent de routage AODV exécute la fonction de détection du

Wormhole en plus de ces différentes fonctionnalités. Pour simplifier l’implémentation des


- 73 -

modifications nous avons gardé le même nom de l’agent et les mêmes fonctionnalités (la

gestion des paquets de contrôle, de la table de routage…).

4.6. Implémentation de la solution proposée

Dans ce qui suit nous allons décrire le processus d’implémentation de notre solution proposée

pour la détection du Wormhole, se processus est divisé en deux parties : structures et

traitement.

4.6.1. Les modifications apportées sur les structures d’AODV

Avant tout, nous décrivons les modifications apportées aux structures d’AODV citons:

L’entête RREQ, l’entête RREP, le cache BroadcastID.

• L’entête RREQ

La figure 4.6 montre les modifications apportées sur le format de l’entête RREQ. Nous avons

ajouté les champs suivants:

� rq_Sreq_Prec, pour récupérer le temps de transmission du RREQ par le nœud

précédent ;

� rq_Rreq pour récupérer le temps de réception du RREQ par le nœud courant.

struct hdr_aodv_request {

u_int8_t rq_type; // Packet Type

:

:

double rq_Sreq_Prec;

double rq_Rreq;

:

:

}

Figure 4. 6: Les modifications apportées sur l’entête du RREQ.

• L’entête RREP

Lorsqu’un message RREP est généré, il parcourt le chemin inverse emprunté par le premier

RREQ arrivé au sink. Les nœuds capteurs constituant ce chemin on déjà stocké le temps de

réception de RREQ et celui de transmission de RREQ par le nœud précédant, rq_Rreq et

rq_Sreq_Prec respectivement.

Donc les champs rp_Rreq, rp_Sreq_Prec servent à récupérer les le temps de réception de

RREQ et celui de transmission de RREQ par le nœud précédant.

Le champ rp_src_Bid contient le BROADCAST ID du RREQ qui correspond à ce RREP et il

sert à la recherche des temps d’émission et de réception de RREQ stocké dans le cache de

chaque nœud emprunté.

Tandis que les champs rp_Rrep, rp_Srep sont dédiés aux temps de réception et d’émission

du RREP pour chaque saut.


- 74 -

struct hdr_aodv_reply {

u_int8_t rp_type; // Packet Type

u_int8_t reserved[2];

:

:

:

double rp_timestamp; // when corresponding REQ sent;

// used to compute route discovery latency

double rp_Rreq;

double rp_Sreq_Prec;

double rp_Rrep;

double rp_Srep;

double rp_src_Bid;

:

:

}

Figure 4. 7: Les modifications apportées sur l’entête du RREP.

• La structure BroadcastID

Le temps de réception de RReq est récupéré par la couche inférieure MAC qui profite de son

passage et insère dans son entête son temps de réception.

class BroadcastID {

friend class AODV;

public:

BroadcastID(nsaddr_t i, u_int32_t b,double Sreq_Prec,double Rreq) { src = i; id = b; Rreq =

Rreq; Sreq_Prec = Sreq_Prec; }

protected:

LIST_ENTRY(BroadcastID) link;

nsaddr_t src;

u_int32_t id;

double expire; // now + BCAST_ID_SAVE s

double Sreq_Prec; //temps de transmission du RREQ par le nœud précédent.

double Rreq; // temps de recption du RREQ par le nœud courant.

};

LIST_HEAD(aodv_bcache, BroadcastID);

Figure 4. 8 : Les modifications apportées sur la structure BroadcastID.

4.6.2. Les modifications apportées sur le Traitement d’AODV

Void

AODV::recvRequest(Packet *p) {

struct hdr_cmn *ch = HDR_CMN(p);

struct hdr_ip *ih = HDR_IP(p);

struct hdr_aodv_request *rq = HDR_AODV_REQUEST(p);


- 75 -

aodv_rt_entry *rt;

:

:

id_insert1(rq->rq_src, rq->rq_bcast_id, rq->rq_Sreq_Prec, rq->rq_Rreq);// stocker les temps de

transmission & réception du RREQ dans le cache du noeud.

:

:

Figure 4. 9: Le stockage des temps de transmission & réception du RREQ dans le cache

BroadcastID.

Le calcule du temps de parcours, rtt et ainsi la distance entre deux nœuds successifs lors de la

réception d’un RREP sont illustrés par la figure 4.10.

Void AODV::recvReply(Packet *p) {

struct hdr_cmn *ch = HDR_CMN(p);

struct hdr_ip *ih = HDR_IP(p);

struct hdr_aodv_reply *rp = HDR_AODV_REPLY(p);

aodv_rt_entry *rt;

char suppress_reply = 0;

double delay = 0.0,rtt,parcours,d;

:

:

parcours=rp->rp_Srep -rp->rp_Rreq; //temps de parcours.

rtt= rp->rp_Rrep - rp->rp_Sreq_Prec - parcours; // calcul du RTT.

d=rtt*300000000/2; // distance entre le nœud courant et le nœud précédent dans le chemin inverse.

//vitesse de la lumière = 300000000 m/s.

:

:

}

Figure 4. 10: Le calcule de distance utilisant le RTT.

Si la distance séparant le nœud précédent et le nœud courant alors ce dernier:

� Marque le paquet RREP être passé par un tunnel wormhole ;

� Met à jours la liste des voisins en marquant le nœud correspondant comme faux

voisin ;

� Emettre un hello d’avertissement au nœuds précédent l’informant qu’ils sont des faux

voisin afin qu’il met à jours sa liste des voisins


- 76 -

Void AODV::recvReply(Packet *p) {

:

:

d=rtt*300000000/2;

if (d>250){AODV_Neighbor *nb, *nb1;

rp->wormhole=true;//marquer RREP être transmis par le tunnel wormhole

nb = nb_lookup(ch->prev_hop_);// recherché l’entrée correspondante au nœud

precedent dans la liste des voisins

if(nb == 0) {

nb_insert(ch->prev_hop_);

nb1 = nb_lookup(ch->prev_hop_);

nb1->faux_voisin=true;

}

else {nb->nb_expire = CURRENT_TIME + (1.5 * ALLOWED_HELLO_LOSS *

HELLO_INTERVAL);

nb->faux_voisin=true;

}

sendHelloAvertissement(ih->saddr()); //emission d’un hello d’avertissement

}

Figure 4. 11: La spécification des faux voisins dans la liste des voisins.

Dans le code illustré par la figure 4.12, nous nous somme servi du local repaire pour initier

une nouvelle découverte de route par le nœud source si le RREP est marqué être transmis par

le tunnel wormhole.

if (ih->daddr() == index) { // si je suis la source

if (rp->wormhole) { // si ce RREP est passé par un tunnel Wormhole

dst=rp->rp_dst;

local_rt_repair(rt,p);// local repaire est une

procédure d’aodv elle sert à réparer la route d’une façon locale en ré initiant une nouvelle

découverte de route

return;

}

:

:

:

Figure 4. 12: Appel de local repaire par le nœud source pour refaire une découverte de route

en évitant le tunnel Wormhole.


- 77 -

4.7. Paramètres de la simulation

Les simulations sont faites sur NS2 version 2.34 sous Ubuntu8.04. La table qui suit liste les

paramètres de simulation, tels qu’ils sont définit au niveau du script TCL

Protocoles de routage AODV

AODVsec

Type d’antenne Antenne Omnidirectionnelle

Type du canal Sans fil (Channel/Wireless Channel)

Modèle de la propagation radio (Propagation/TwoRayGround)

Modèle de la couche MAC Mac/802.11

Type de la file d’attente Queue/DropTail/PriQueue

Nombre maximal de paquet dans la file d’attente 50

Taille du paquet 512 Octets

Dimension du réseau 900 × 900 (Annexe3)

Nombre de nœuds 8

Tableau 4. 2: Les paramètres de simulation.

4.8. Le Wormhole simulé

Nous avons simulé une attaque Wormhole interne c-à-d les deux extrémités du tunnel

Wormhole sont des nœuds internes du réseau et qui sont supposées compromis. Tout paquet

acheminé via le tunnel n’est pas modifié au niveau de l’entête ni des données. Ce qui rend

cette attaque passive.

4.8.1. Les résultats de la simulation

NS2 écrit les résultats de ses simulations dans un fichier texte ou chaque ligne correspond à

un événement qui s’est produit à un niveau ou à un autre de la pile protocolaire. Il est possible

de configurer NS2 de telle sorte qu’il ne garde une trace que de certains types d’événements

(par exemple tout ce qui concerne le routage, mais pas ce qui concerne la couche MAC). Ceci

est en particulier utilisé pour accélérer la simulation et réduire la taille du fichier.

Ce fichier texte peut porter en lui même énormément d’informations. Mais pour extraire et

représenter de manière synthétique ces informations, il faut souvent appliquer de nombreux

traitements à ce fichier.

L’analyse des fichiers de trace dans nos simulations est réalisée en utilisant le langage Awk

pour extraire les champs nécessaires au calcul des différents paramètres du protocole. Enfin

les graphes sont obtenus en utilisant Xgrah (module du ns2) [29], [30].


- 78 -

4.8.2. Délai de bout en bout

Les figures 4.13, 4.14 et 4.15 représentent la variation du délai de bout en bout durant le

temps de simulation de trois scénarios différents. On a simulé dans un premier temps un

réseau utilisant la version standard d’AODV sans aucune attaque Wormhole, puis on l’a

soumis à une attaque Wormhole dans un intervalle de temps. Et enfin on a soumis la version

sécurisée d’AODV à une attaque Wormhole dans le même intervalle de temps.

Figure 4. 13 : AODV sans Wormhole.

On remarque sur la figure 4.14, lorsqu’AODV est soumis à une attaque Wormhole son délai

de bout en bout subit une baisse importante. Cela est dû à la latence du chemin Wormhole qui

est inférieure considérablement à celle du chemin légitime multi saut.

Figure 4. 14 : AODV soumis à une attaque Wormhole.

Dé

lai

(s)

Temps de simulation (s)

Dé

lai

(s)



- 79 -

La figure 4.15 ne montre aucune baisse du délai de bout en bout dans l’intervalle de temps

[20,60] malgré la présence de l’attaque Wormhole, cela prouve que l’attaque est détectée et le

tunnel est isolé.

Figure 4. 15 : AODV version Sécurisée soumis à une attaque Wormhole.

4.8.3. énergie :

Les nœuds capteurs sont déployés dans un champ de taille 1500×1500 m2 sous la forme

d’une grille de 5 x 5 noeuds.

La figure qui suit illustre l’énergie consommée par l’extrémité du tunnel (qui est un nœud

compromis) en ajoutant à chaque fois une nouvelle source dans son voisinage.

Figure 4. 16 : Le pourcentage d’énergie consommée par un nœud compromis.

0

0,05

0,1

0,15

0,2

0,25

0 1 2 3 4 5

po

urc

en

tag

e E

ne

rgie

(%

)

nombre sources

Energie consommée

AODV

AODV sécurisé

Dé

lai

(s)



- 80 -

4.8.4. Délai moyen de bout en bout

Le délai moyen de bout en bout d’AODV est inférieure à celui d’AODV sécurisé, car le

chemin Wormhole a une latence inférieure à celle du chemin légitime.

Figure 4. 17 :Délai moyen de bout en bout AODV Vs AODV Sécurisé.

0,00

0,05

0,10

0,15

0,20

0,25

0,30

0,35

0,00 1,00 2,00 3,00 4,00 5,00

de

lai

mo

ye

n b

ou

t e

n b

ou

t

distance extrémité destination (nb sauts)

AODV Securisé

AODV

81

Conclusion générale & Perspectives

Les réseaux de capteurs sans fils bouleversent notre façon de vivre, ils sont de plus en plus utilisés

et dans des activités très variantes, mais leurs propriétés (communication sans fil multi saut,

couplage étroit avec l’environnement) sont à doubles tranchants. Certes elles permettent un

déploiement facile mais elles rendent le système de communication très fragile à un certain nombre

de défaillances. De nombreux problèmes de sécurité en découlent. Ces réseaux sont sujets de

plusieurs attaques telles l’attaque Jamming, Sinkhole, Sybile et Wormhole.

Dans ce mémoire nous avons réalisé une étude approfondie sur l’une des attaques portées sur ces

réseaux qui est l’attaque Wormhole ainsi que de nombreuses solutions ont été proposées dans la

littérature. Certaines nécessitent un dispositif supplémentaire tel que GPS, d’autres une

synchronisation d’horloges.

Notre solution diffère de celles-ci, elle est basée sur RTT(Round Trip Time) et vise la sécurisation

du mécanisme de découverte de route (Route discovery) avant même de commencer la transmission

des données. Elle est constituée de deux phases. La première est la phase de détection où la distance

est calculée à chaque saut de RREP, si elle dépasse la portée radio du nœud alors un tunnel

Wormhole est détecté. La seconde phase est la celle de l’isolation; elle consiste à interdire toute

communication entre paire de nœuds reliés par un tunnel.

Le fait de calculer la distance entre chaque paire de nœuds voisins de façon distribuée au moment

de la recherche de route, permet de :

� Eviter l’interception des données en établissant des routes dans lesquels le tunnel

Wormhole ne figure pas ;

� Gain d’Energie:

� minimiser le nombre de cycle « Route discovery » ;

� éviter de passer tout le trafic par un nœud compromis et ainsi épuiser son

énergie ce qui réduit la duré de vie du réseau;

� Interdire l’attaquant de contrôler un segment de la route et produire ainsi des

coupures fréquentes ce qui :

� Influe sur la qualité des données capté dans d’un RCSF video.

� Oblige la source de refaire un « route discovery », augmentant ainsi le

Délai de transmission

82

Aux termes de ce travail nous envisageons deux extensions :

• L’intégration de ce mécanisme dans le protocole AODV multichemins afin de bénéficier

des avantages qu’apporte le routage multichemins et minimiser ainsi le nombre de cycle «

route discovery »;

• L’extension ce mécanisme pour qu’il supporte la mobilité.

83

Références

[1] R.KACIMI. “Techniques de conservation d'énergie pour les réseaux de capteurs sans fil”, thèse

de doctorat, universit´e de Toulouse Toulouse, France, Juillet, 2009.

[2] J. P.l Walters, Z. Liang, Weisong Shi, and V. Chaudhary. “Wireless Sensor Network Security: A

Survey”, Chapter 17, Security in Distributed, Grid, and Pervasive Computing, Auerbach

Publications, CRC Press, 2006.

[3] Mayank Saraogi, SECURITY IN WIRELESS SENSOR NETWORK.

[4] XUE Yong, AGUILAR Andres, GONZALEZ Andres and BARROUX Mickaël. ”Agrégation de

données dans les réseaux de capteurs”, rapport final, 2010.

[5] Mohamed Hamdi, Noureddine Boudriga, and Mohammad S. Obaidat.Whomoves : An

optimized broadband sensor network for military vehicle tracking. Int. J. Communication Systems,

21(3):277,300, 2008.

[6] Elyes Ben Hamida, Guillaume Chelius, and Jean-Marie Gorce. Scalable versus accurate

physical layer modeling in wireless network simulations. In 22st International Workshop on

Principles of Advanced and Distributed Simulation, PADS 2008, June 3-6, 2008, Roma, Italy,

pages 127{134. IEEE

[7] Sana Tmar Ben Hamida, Jean-Benôt Pierrot, and Claude Castelluccia. An adaptive quantization

algorithm for secret key generation using radio channel measurements. In NTMS 2009, 3rd

International Conference on New Technologies, Mobility and Security, 20-23 December 2009,

Cairo, Egypt, pages 1{5. IEEE, 2009

[8] Fran_cois Ingelrest, Guillermo Barrenetxea, Gunnar Schaefer, Martin Vetterli, Olivier Couach,

and Marc Parlange. Sensorscope : Application-speci_c sensor network for environmental

monitoring. ACM Transactions On Sensor Networking, 6(2) :1{32, 2010.

[9] Vassileios Tsetsos, George Alyfantis, Tilemahos Hasiotis, Odysseas Sekkas, and Stathes

Hadjiefthymiades. Commercial wireless sensor networks : Technical and business issues. In 2nd

International Conference on Wireless on Demand Network Systems and Service (WONS 2005), 19-

21 January 2005, St. Moritz, Switzerland, pages 166-173. IEEE Computer Society, 2005.

[10] W.Stallings, «Cryptography and network security, Principles and practice, 2nd

edition »,

Prentice Hall, 1999.].

[11] B. Khalifa. " La sécurité dans les réseaux de capteurs sans fil", conférence à l’université de

Bechar. 2006.

84

[12] M. Ilyas and I. Mahgoub. " Handbook of sensor networks Compact wireless and wired Sensing

Systems", ISBN 08493196864. CRC PRESS LLS, USA, 2005.

[13] A.Beghriche,« De la Sécurité à la E-Confiance basée sur la Cryptographie à Seuil dans les

Réseaux sans fil Ad hoc », Mémoire De Magistère En Informatique, Université de L’Hadj Lakhdar-

Batna, 2008/2009 .

[14] Chris Karlof, David Wagner, « Secure routing in sensor networks: Attacks and

countermeasures. Ad Hoc Networks», vol 1, issues 2–3 (Special Issue on Sensor Network

Applications and Protocols), Elsevier, September 2003.

[15] A. Manjeshwar and D. P. Agarwal. "Apteen : A hybrid protocol for efficient routing and

comprehensive information retrieval in wireless sensor networks", Parallel and distributed

processing Symposium. Proceedings International, IPDPS, pp. 195-202, 2002.

[16]Y. XUE , A. AGUILAR , A. GONZALEZ, M. BARROUX, "Agrégation de données dans les

réseaux de capteurs", rapport final de projet, 2010.

[17] YOUSEF Yaser, Routage pour la Gestion de l’Energie dans les Réseaux de Capteurs Sans Fil,

Thèse de Doctorat en informatique, UNIVERSITE DE HAUTE ALSACE Faculté des Sciences et

Techniques, 2010.

[18] Radha Poovendran & Loukas Lazos, A graph theoretic framework for preventing the wormhole

attack in wireless ad hoc networks. Wireless Netw (2007) . DOI 10.1007/s11276-006-3723-x.

[19] Maria Alexandrovna Gorlatova, Review of Existing Wormhole AttackDiscovery Techniques.

Defence R&D Canada √ Ottawa CONTRACT REPORT DRDC Ottawa CR 2006-165. August 2006

[20] Yih-Chun Hu &Adrian Perrig & David B. Johnson. Packet Leashes: A Defense

againstWormhole Attacks in Wireless Ad Hoc Networks. Rice University Department of Computer

Science. Technical Report TR01-384. December 17, 2001. Revised: September 25, 2002.

[21] Rouba El Kaissi, Ayman Kayssi, Ali Chehab and Zaher Daw.DAWWSEN: A DEFENSE

MECHANISM AGAINST WORMHOLE ATTACKS IN WIRELESS SENSOR NETWORKS.

Department of Electrical and Computer Engineering American University of Beirut Beirut,

Lebanon.

[22] Hai Vu, Ajay Kulkarni, Kamil Sarac, and Neeraj Mittal. WORMEROS: A New Framework for

Defending against Wormhole Attacks onWireless Ad Hoc Networks Department of Computer

Science The University of Texas at Dallas Richardson, TX 75080, USA.

85

[23] C. Perkins, E. Belding-Royer, S. Das: Ad hoc On-Demand Distance Vector (AODV) Routing,

Network Working Group, July 2003 available on: ftp://ftp.nordu.net/rfc/rfc3561.txt

[24] I. Chekeres, E.Belding Royer. AODV routing protocol implementation design. 2006

[25]S.R biradar, M.kouchik, Subir Kumar. Performance evaluation and comparison of AODV and

AOMDV

[26] http://www.isi.edu/nsnam/ns/.le site officiel de ns2

[27] P. Anelli & E. Horlait. ‘NS-2: Principes de conception et d'utilisation’ Version 1.3.

[28] K. Fall et K. Varadhan, ‘The ns Manual’, le projet de VINT, 2008.

[29] Kulothungan.K. ‘How to Plot a Graph in NS 2’.

[30] Mohit P. Tahiliani.’Xgraph and AWK Scripts in NS-2‘.

Documents

ROUTAGE MULTICHEMIN SECURISE POUR UN RESEAU DE CAPTEURS ... › document › TH3725.pdf · que le GPS ni la synchronisation des horloges (ce qui est difficile à réaliser pour un