Soutenance mémoire
TEEN et APTEEN (Threshold sensitive Energy Efficient sensor Network protocol)
TEEN est un protocole hiérarchique conçu pour être sensible aux changements improviste des attributs détectés tels que la température. L’architecture du réseau est basée sur un groupement hiérarchique où les noeuds les plus proches forment des clusters. Après la construction des clusters, le cluster head diffuse deux seuils aux noeuds. Qui sont la valeur minimale d’un attribut pour pouvoir être transmis et le degré minimale du changement de cet attribut. Le TEEN adaptatif (APTEEN) est une extension du TEEN basée sur la capture périodique des données et la réaction aux événements temps-réel. Quand la station de base forme les clusters, les cluster-heads diffusent les attributs, les seuils et le plan de transmission à tous les noeuds et effectuent également l’agrégation des données afin d’économiser l’énergie [9].
Les protocoles de routage «PEGASIS & Hierarchical-PEGASIS»
Power-Efficient GAthering in Sensor Information Systems (PEGASIS) est une version améliorée du protocole LEACH. PEGASIS forme des chaînes plutôt que des clusters de noeuds de capteurs afin que chaque noeud transmette et reçoive uniquement des données d’un voisin. Un seul noeud est sélectionné à partir de cette chaîne pour transmettre à la station de base. L’idée de PEGASIS est qu’il utilise tous les noeuds pour transmettre ou recevoir des données avec ses plus proches voisins. Il déplace les données reçues de noeud à noeud, puis les données seront agrégées jusqu’à ce qu’elles atteignent tous la station de base. Donc, chaque noeud du réseau est tour à tour un chef de file de la chaîne, ainsi que responsable pour transmettre l’ensemble des données recueillies et fusionnées par la chaîne de noeuds au niveau de la station de base [2].
Le protocole de routage SPIN
SPIN (Sensor Protocols for Information via Negociation) est un protocole de routage qui se base sur le principe de métadonnées lors du processus de diffusion de requêtes sur le réseau. Le récepteur de la requête a la possibilité de choisir d‟accepter la donnée ou non. C‟est le principe de la négociation. SPIN est considéré comme le premier protocole data centric destiné aux RCSF. Tous les noeuds du réseau sont traités comme des noeuds de destination dont la tâche principale est de recueillir un point de vue globale sur leur environnement. Egalement, SPIN s‟attaque à la redondance de données transmises sur un réseau de capteurs sans fil [21].
Directed Diffusion (DD)
Directed Diffusion ou diffusion dirigée est un protocole de propagation de données. C‟est l‟un des protocoles les plus intéressants dans le routage data Centric des RCSF. Son utilité réside dans sa capacité à réduire considérablement le nombre d‟opérations de la couche réseau par la création de plusieurs chemins pour le routage d‟informations et ainsi permettre une économie d‟énergie conséquente aux capteurs. Cette réduction d‟opération passe par une mise en place de quatre éléments : i) la nomination des données (décrire les intérêts) ; ii) propagation des intérêts ; iii) propagation des données ; iv) renforcement des chemins de transport de données. Le protocole DD à travers ces quatre éléments définit au préalable la nature de la donnée à capter, décrit cette donnée sous forme d‟intérêt et diffuse cette requête sur le réseau. Les noeuds concernés commencent à capter et propager les données sur des chemins différents. A la réception des premières données par la station de base, elle procède au choix puis au renforcement des meilleurs chemins [8].
Rumour Routing
Le protocole Rumour Routing utilise un procédé probabiliste, similaire au gossiping, afin de trouver un compromis entre l‟inondation des intérêts et la propagation de données. Ce procédé probabiliste repose sur la méthode Monté-Carlo qui suppose que la probabilité que deux lignes se croisant au sein d‟une région rectangulaire est de 0.69, et si on utilise cinq lignes passant par un point, la probabilité qu‟une autre ligne se croise avec l‟une des cinq lignes est de 0.997. Par conséquent, si on considère la source et le puits deux points distincts, on établit un certain nombre de mi-chemin depuis la source et d‟autres mi-chemin depuis le puits et on aura une forte probabilité que deux mi-chemin se joignent créant ainsi un chemin complet entre la source et la destination. Ce procédé permet d‟éviter l‟inondation de données [22].
Le protocole de routage «GEAR »
Le protocole de routage GEAR (Geographic and Energy Aware Routing) a été suggéré par Y. Yu, D. Estrin. Il consiste à utiliser l’information géographique lors de la diffusion des requêtes aux régions cibles car les requêtes contiennent souvent des données géographiques. L’idée est de restreindre le nombre de données dans la diffusion dirigée en prenant en considération uniquement une certaine région, plutôt que d’envoyer les données à l’ensemble du réseau. Avec le protocole GEAR, chaque noeud maintient le coût pour atteindre la destination en passant par ses voisins. Ce coût est divisé en deux parties : un coût estimé et un coût d’apprentissage. Le coût estimé est une combinaison de l‟énergie résiduelle et de la distance jusqu’à destination. Le coût d’apprentissage est un raffinement du coût estimé qu‟un noeud dépense pour le routage autour des trous dans le réseau [2].
Le protocole MECN (Minimum Energy Communication Network)
C‟est un protocole de routage géographique conçu pour des noeuds capteurs équipés d‟un GPS à basse puissance. L‟idée est de trouver un sous réseau composé d‟un nombre minimum de noeuds, proches entre eux, afin d‟avoir une puissance de transmission faible et moins couteuse en énergie entre deux noeuds particuliers du réseau.
Le protocole AODV (Ad-hoc On Demand Distance Vector)
C‟est un protocole de routage conçu par Charles E.Perkins et Elizabeth M. Royer basé sur le principe des vecteurs de distance et appartient à la famille des protocoles réactifs. Il représente essentiellement une amélioration de l’algorithme proactif DSDV mais réduit l’overhead (nombre de diffusions de messages) en ne calculant les routes que sur demande(AODV). Ce protocole utilise les deux mécanismes « découverte de route » et « maintenance de route », en plus du routage « noeud par noeud » et construit les routes par l’emploi d’un cycle de requête « route request/route reply « .
La sécurité dans les RCSF
Exigences en sécurité
Un réseau de capteur est un type spécial de réseaux. Il partage quelques vulgarisations avec un réseau informatique typique, mais pose également des conditions uniques de ses propres caractéristiques. Par conséquent, un protocole de sécurité pour un RCSF, doit satisfaire une ou plusieurs conditions de sécurité, à savoir :
La confidentialité
Elle consiste à s‟assurer que personne ne pourra interférer dans la communication entre deux noeuds afin de récupérer les données lors de leur transfert. Les algorithmes cryptographiques de nos jours peuvent assurer une confidentialité suffisante en utilisant des clés de grande taille. Cependant, ces algorithmes sont lourds en termes de mémoire et de calcul, de plus pour les RCSF il faut considérer le temps et l‟énergie qu‟ils consomment. Il est nécessaire d‟adapter ces algorithmes pour qu‟ils puissent être un bénéfice et non pas un handicap pour les RCSF [1].
Intégrité des données
Un noeud intrus (adversaire) peut modifier les données transférées. Par exemple, un noeud malveillant peut ajouter quelques fragments ou manoeuvrer les données dans un paquet. Ce nouveau paquet peut alors être envoyé au récepteur original. La perte ou les dommages de données peut même se produire sans présence d’un noeud malveillant dû à l’environnement dur de communication. Ainsi, l‟intégrité des données s’assure qu’aucune donnée reçue n’a été changée en transit [23].
L’authentification d’un noeud
C‟est le fait de pouvoir vérifier et connaître avec une grande certitude l‟identité d‟un noeud. Elle pourra être assurée implicitement dans un système à chiffrement symétrique, car dans un tel système, deux entités partagent d‟une façon sûre une seule clé secrète. Alors, seule l‟entité qui possède la clé secrète pourra chiffrer/déchiffrer les données. Dans les systèmes asymétriques, l‟authentification pourra être assurée lors de l‟utilisation d‟un certificat d‟identification. C‟est une relation sûre entre la clé publique et l‟identité de l‟entité. Le destinataire doit être capable d‟identifier l‟expéditeur en contactant un tiers de confiance qui a la responsabilité de signer, délivrer et vérifier la validité des certificats.
La non-répudiation
C‟est le fait qu‟aucun noeud ne pourra nier (désavouer) le fait d‟avoir échanger des informations. Autrement dit, la non-répudiation de l’origine prouve que les données ont été envoyées, et la non-répudiation de l’arrivée prouve qu’elles ont été reçues.
Fraîcheur De Données
Même si la confidentialité et l‟intégrité des données sont assurées, il est nécessaire d‟assurer la fraîcheur de chaque message. Officieusement, la fraîcheur de données suggère que les données soient récentes, et elles s’assurent qu’aucun vieux message n’a été rejoué. Cette condition est particulièrement importante quand il y a des stratégies de partage des clefs utilisées dans la conception. Des clefs typiquement partagées doivent être changées avec le temps. Cependant, cela prend du temps pour de nouvelles clefs partagées d’être propagées au réseau entier. Dans ce cas-ci, il est facile pour l’adversaire d’employer une attaque de rejouer. Pour résoudre ce problème un compteur relatif au temps différent, peut être ajouté dans le paquet pour assurer la fraîcheur de données [23].
Vulnérabilités de la sécurité dans les RCSF
Les principaux problèmes de sécurité dans les RCSF émergent à partir des propriétés qui les rendent efficaces et attrayants, qui sont:
Limitation de ressources
L’énergie est la contrainte la plus forte aux capacités d’un noeud capteur. La réserve d’énergie de chaque noeud doit être conservée pour prolonger sa durée de vie et ainsi que celle de l’ensemble du réseau. Dans la plupart du temps, l’information transmise est redondante vus que les capteurs sont généralement géographiquement co-localisés. La plupart de cette énergie peut donc être économisée par agrégation de données. Cela exige une attention particulière à détecter l’injection de fausses données ou la modification défectueuse de données, lors des opérations d’agrégation au niveau des noeuds intermédiaires.
La communication sans fils
En plus de fournir un déploiement simple, la communication sans fil a l’avantage d’offrir l’accès à des endroits difficilement accessibles tels que des terrains désastreux et hostiles. Cela introduit de nombreuses failles de sécurité à deux niveaux différents, attaque sur 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ériel
La plupart des applications de RCSF exigent un déploiement étroit des noeuds à 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 noeuds. Comme le succès des applications RCSF dépend également de leur faible coût, les noeuds ne peuvent pas se permettre une protection physique inviolable. Par conséquent, un adversaire « bien équipé » peut extraire des informations cryptographiques des noeuds capteurs. Comme la mission d’un RCSF est généralement sans surveillance, le potentiel d’attaquer les noeuds 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 noeuds [23].
|
Table des matières
INTRODUCTION GENERALE
CHAPITRE I : RCSF et les protocoles de routage et de sécurité dédies
I.1. Introduction
I.2. Réseaux de capteurs sans fil
I.2.1. Définition de RCSF
I.2.2. Architecture physique d’un capteur
I.2.3. Architecture d’un RCSF
I.2.4. Fonctionnement des RCSF
I.2.5. Contraintes de conception des RCSF
I.2.6. Applications des RCSF
I.3. Protocole de routage des RCSF
I.3.1. Définition de routage
I.3.2. Contraintes de routage dans les réseaux de capteurs sans fil
I.3.3. Les critères de performance des protocoles de routage en RCSF
I.3.4. Types de routage
I.3.5. Les protocoles de routage proposé pour les RCSF
I.4. La sécurité dans les RCSF
I.4.1. Exigences en sécurité
I.4.2. Vulnérabilités de la sécurité dans les RCSF
I.4.3. Solutions adaptées aux communications des RCSF
I.5. Conclusion
Chapitre II : Sécurisation et optimisations du protocole AODV
II.1. Introduction
II.2. Le protocole AODV
II.2.1. Présentation
II.2.2. Table de routage
II.2.3. Mécanismes de création des routes
II.2.4. Génération et acheminement des réponses RREP
II.2.5. Les messages « Hello»
II.2.6. Mécanismes de maintenance des routes
II.2.7. Génération et acheminement des erreurs RERR
II.3. Le protocole AODV optimisé pour RCSF
II.3.2. La Table de routage
II.3.3. Maintenance des routes
II.4. Sécurisation des données dans le RCSF
II.4.1. Algorithme de chiffrement symétrique implémenté RC
II.4.2. Algorithme de chiffrement ECC (Elliptic Curve Cryptography)
II.5. Conclusion
CHAPITRE III : implémentation du protocole OAODV sur capteurs telosb
III.1. Introduction
III.2. Systèmes d’exploitation et langage de programmation utilisés
III.2.1. Le système d‟exploitation TinyOS
III.2.2. Le langage NESC
III.3. Outilles utilisés dans l’implémentation et la simulation
III.3.1. VMware Workstation version 10.0
III.3.2. Ubuntu version 14.04
III.3.3. Java Jdk version 1.8.0
III.3.4. Eclipse neon.2 et yeti2
III.3.5. Port série
III.4. Cartes TelosB
III.4.1. Composants du capteur CM5000
III.4.2. Microcontrôleur TI MSP430F1611
III.4.3. Module RF 2.4 GHz IEEE 802.15.4
III.4.4. Les capteurs d‟humidité et de température Sensirion® SHT11
III.4.5. Détecteur de lumière Hamamatsu® S1087 / S1087-01
III.4.6. Interfaces USB
III.4.7. Mémoire flash ST® M25P80
III.4.8. Bottons d‟utilisation
III.4.9. Alimentation du capteur
III.5. Interfaces et composants du NESC utilisés
III.5.1. Initialisation
III.5.2. Compteurs
III.5.3. Emission et réception
III.5.4. Utilisation des LEDs
III.5.5. Lecture des données captées
III.5.6. La communication radio entre les capteurs
III.6. Implémentation des protocoles de routage (AODV et OAODV)
III.6.1. Fonctions principales utilisées
III.6.2. Programmation
III.7. Implémentation des algorithmes de cryptage (RC4 et ECDSA)
III.7.1. Algorithme RC4
III.7.2. Algorithme ECDSA
III.8. Conclusion
CHAPITRE IV : implémentation et résultats
IV.1. Introduction
IV.2. Test et résultats
IV.2.1. Paramètres de test
IV.2.2. Architecture de réseau
IV.2.3. Tests sur le fonctionnement des protocoles de routages
IV.2.4. Tests sur le taux de perte des paquets
IV.2.5. Testes sur l‟effet de la taille de réseau sur la recherche de la route
IV.2.6. Testes sur l‟effet de la taille de réseau sur la consommation de l‟énergie
IV.2.7. Tests sur le fonctionnement des algorithmes de cryptages
IV.3. Conception d’une application Web pour le contrôle de la température
IV.3.1. Langage PHP
IV.3.2. Base des données
IV.3.3. Conception de site
IV.4. Conclusion
CONCLUSION GENERALE ET PERSPECTIVES
BIBLIOGRAPHIE
Résume
Abstract
Télécharger le rapport complet
