5.7 Implémentation et Analyse des
résultats
Dans cette sous section, nous présentons les
résultats des simulations de notre algorithme de partitionnement pour
montrer l'influence de l'heuristique mise en oeuvre pour le choix du
clusterhead et de la solution de sécurité. Ces simulations ont
été exécutées sur un laptop (Core i2-950B CPU@
2.10Ghz x2, 4GO de RAM, Ubuntu 12.04 LTS ) en utilisant le logiciel WSNet [56]
et sont basés sur la zone sphérique de 9km de
diamètre, sur lequel nous générons au hasard des
réseaux connectés de 500 et 1000 capteurs. Le simulateur NS-2 a
été utilisé pour le modèle
énergétique et les courbes ont été
réalisées grâce à l'outil Gnuplut version 4.3.
Nous avons comparé notre solution de
sécurité et de gestion de clés à une solution
combinant les approches probabilistes et dites t-secure (dont les principaux
inconvénients sont l'absence d'authentification entre chaque paire de
noeuds et le problème d'espace mémoire réservé aux
clés stockées). Les problèmes du nombre et de la taille
des paquets de données échangés durant les phases de
déroulement du protocole (découverte de voisinage, installation
des clés, renouvellement des clés et insertion des nouveaux
noeuds) ainsi que le problème de la consommation d'énergie par
les noeuds capteurs sont deux concepts majeurs déterminant la
durée de vie d'un réseau de capteurs sans fil (RcSF). C'est pour
cette raison que la plupart des solutions proposées essayent davantage
de réduire le nombre de messages émis et reçus et la
quantité d'énergie consommée dans les opérations
cryptographiques durant tout le cycle de vie du réseau. Dans la
littérature, l'idée de combiner le modèle probabiliste
avec les schémas dits t-secure est illustrée par le protocole
TinyKeyMan [57]. En adoptant les deux modèles, TinyKeyMan souffre de
quelques inconvénients : A chaque construction ou reconstruction de
routes pour une installation ou une mise à jour des clés, le
nombre de paquets échangés entre les noeuds accroit
73
CHAPITRE 5. NOTRE CONTRIBUTION : UNE APPROCHE DE PROTOCOLE DE
GÉOCASTING SÉCURISÉ DANS UN RCSF DÉPLOYÉ
DANS L'ESPACE (EN 3D)
rapidement avec la taille du réseau et la
probabilité que deux noeuds partagent un même secret ou trouvent
un voisins commun pour établir une clé symétrique devient
de plus en plus faible. Par conséquent, on peut dire que ces deux
approches combinées n'offrent pas de compromis entre la taille du
réseau et le nombre de messages échangés. Dans ce
contexte, nous avons présenté une nouvelle solution
déterministe qui assure une probabilité complète (100%)
d'établir une clé symétrique entre chaque paire de noeuds
sans le partage d'aucune information. Ce gain de messages transmis et
reçus est synonyme d'une consommation réduite de
l'énergie. Les opérations de calcul de secrets et de clés
sont également optimisées pour une consommation raisonnable de
ressources physiques et énergétiques des noeuds capteurs. Dans ce
qui suit, nous allons présenter les métriques et
paramètres utilisés, la librairie TinyKeyMan, et les
résultats obtenus par rapport à ces métriques et en
fonction du nombre de noeuds du réseau.
5.7.1 Les métriques
Pour l'évaluation des performances de notre solution,
nous nous basons sur les métriques suivantes :
· Le nombre de clés stockées dans la
mémoire des noeuds capteurs.
· La taille des clés stockées dans la
mémoire des noeuds capteurs.
· Le nombre de paquets de données
échangés durant les différentes phases de
déroulement du protocole : initialisation (découverte du
voisinage), installation des clés symétriques, révocation
des clés découvertes par les noeuds intrus, renouvellement des
clés et insertion des nouveaux noeuds.
· La consommation d'énergie moyenne par tous les
noeuds du réseau en fonction de la taille du réseau.
· La consommation d'énergie par composant :
énergie consommée durant les opérations de calcul des
clés et l'énergie consommée pour l'émission /
réception des paquets de données. Le nombre de clés
stockées dans la mémoire des noeuds est obtenu par
l'exécution de notre protocole de sécurité et de gestion
de clés sur le protocole LEACH [58], considéré comme la
référence des protocoles hiérarchiques et qui convient
mieux aux besoins en simulation de notre solution.
La taille des clés ECC présentes dans la
mémoire des noeuds capteurs et utilisées par notre protocole de
sécurité et de gestion de clés est calculée sur la
base des données présentées sur le tableau 5.1 :
| 
