5.7.2 Nombre et la taille des clés
stockées
Dans le tableau 5.2, nous avons calculé le nombre et la
taille des clés stockées par un noeud Cluster Head (CH) et par un
noeud normal membre d'un cluster dans une topologie hiérarchique. Dans
cette topologie, chaque noeud CH partage trois types de clés : i) une
clé partagée avec son noeud parent dans la hiérarchie, ii)
une clé partagée avec chacun des noeuds de son cluster et iii)
74
CHAPITRE 5. NOTRE CONTRIBUTION : UNE APPROCHE DE PROTOCOLE DE
GÉOCASTING SÉCURISÉ DANS UN RCSF DÉPLOYÉ
DANS L'ESPACE (EN 3D)
|
Taille du nombre premier P
|
160 bits
|
|
Taille du secret x
|
< 160 bits
|
|
Taille d'un point Px
|
320 bits
|
|
Taille d'une clé publique
|
320 bits
|
|
Taille d'une clé privée
|
160 bits
|
TABLE 5.1: Taille des clés ECC et de leurs
paramètres de calcul
une clé commune partagée avec tous les noeuds de
son cluster. Un noeud membre d'un cluster partage deux types de clés :
i) une clé personnelle avec son CH et ii) une clé commune avec
son CH et tous les autres noeuds du cluster. On note que tous les noeuds du
réseau partagent entre eux à la phase d'initialisation une
clé commune qui sert à authentifier et sécuriser toutes
les communications durant la phase d'installation des clés par paires.
Cette clé n'est pas prise en compte car elle sera supprimée
à la fin de la phase d'initialisation et d'installation des clés.
La taille des clés est calculée selon les informations
données par le tableau 5.2 ci-dessus. Le tableau 5.2 donne le nombre et
la taille des clés stockées par chaque noeud du réseau
où Nc est le nombre moyen de noeuds d'un cluster.
|
Type du noeud
|
Nombre de clés stockées
|
Taille des clés stockées
|
|
Noeud CH
|
(Nc + 2)
|
20 (Nc + 2) octets
|
|
Noeud membre
|
2
|
40 octets
|
TABLE 5.2: Le nombre et la taille des clés
stockées dans notre méthode
5.7.3 Nombre de paquets échangés
Les figures 5.4 et 5.5 présentent le nombre de paquets
de données échangés lors de l'installation des clés
sur des réseaux de taille variant de 100 à 1000 noeuds capteurs
en présence ou non de noeuds attaquants. Les messages
échangés concernent ceux des opérations
d'authentification, de découverte de voisinage et de calcul des
clés secrètes. Les deux figures ci-dessus résument les
résultats obtenus après avoir réalisé
différentes expériences. Sur la figure 21 où on suppose
l'absence de noeuds attaquants, la complexité en communication de notre
protocole est meilleure.
Dans la figure 5.5 où on suppose la présence de
10% de noeuds attaquants de l'ensemble des noeuds du réseau, le nombre
d'informations échangées par radio est beaucoup plus important
(environ une différence de 500% de paquets) et cela est dû
à la diffusion d'un grand nombre de fausses informations de
contrôle. Chaque noeud du réseau essaye alors d'authentifier
l'émetteur puis d'ignorer ses futurs messages dans le cas d'une
intrusion. Dans le protocole TinyKeyMan, les informations produites par les
noeuds malicieux comportent une forte probabilité de partage d'un
même polynôme ce qui touche à un plus grand nombre de
noeuds. Notre solution échange
75
CHAPITRE 5. NOTRE CONTRIBUTION : UNE APPROCHE DE PROTOCOLE DE
GÉOCASTING SÉCURISÉ DANS UN RCSF DÉPLOYÉ
DANS L'ESPACE (EN 3D)
FIGURE 5.4: Nombre de paquets échangés en absence
d'intrus
moins de paquets pour installer les clés ce qui garantie
un temps d'installation plus court et un
niveau de sécurité
plus élevé. Sur la figure 5.4 où on suppose l'absence de
noeuds attaquants,
FIGURE 5.5: Nombre de paquets échangés en
présence d'intrus
la complexité en communication de notre protocole est
meilleure notamment pour des réseaux denses comme les RCSF et sont
négligeables pour les réseaux de petite taille. Notre solution
échange moins de paquets, environ 10 fois moins que la solution
probabiliste du protocole TinyKeyMan.
| 
