Mon Livre

DEDICACE
A la mmoire de mon cher oncle Lamine Sarr.

A mes trs chers parents, nulle ddicace nest susceptible de vous exprimer ma
profonde affection, mon immense gratitude pour tous les sacrifices que vous avez
consacrs pour moi
A mes petites surs Gayssiry et Rokhaya que jaime plus que tout au monde
A tous ceux qui maiment

REMERCIEMENTS

Je tiens adresser mes plus chaleureux remerciements Mon professeur et
encadreur, Monsieur Karim Konat et lui exprimer toute ma reconnaissance pour son
encadrement, ses conseils, son soutien constant ainsi que pour sa confiance et sa
patience. Jai eu lhonneur et le plaisir de travailler sous sa direction pendant mon stage
de DEA et jespre pouvoir continuer travailler avec lui dans le futur.

Mes remerciements vont aussi lendroit de mes professeurs :
Monsieur Mbaye Sne qui ma beaucoup encourage lorsque jai choisi de poursuivre
avec le DEA, Monsieur Abdourahmane Raimy, Monsieur Ibrahima NIANG, Monsieur
Samba Ndiaye qui mont forme et qui ont bien voulu accepter de composer ce jury.

Mes vifs remerciements vont lensemble des enseignants de la section
Informatique qui mont encadre durant ma formation.
Mes amis Abdou Rahim Gaye, Oulimata Kon et Abdou Karim Maikano pour leurs
soutiens et encouragements.
Mes collgues : Youssou Kass, Mamadou Thiongane et Modou Guye pour toutes ces
annes passes ensemble.
Mes camarades de promotion avec qui jai pass des annes merveilleuses.
Mes parents, mes frres et soeurs qui mont accompagne dans toutes les entreprises de
ma vie.

Merci tous ceux que jaime et que je nai pas cits

TABLE DES MATIERES

Table des matires

INTRODUCTION GENERALE ....................................................................................... 1
PREMIERE PARTIE ....................................................................................................... 3
I. CONCEPTS DE BASE DE LA SECURITE ............................................................... 4
1.1 La scurit rseau ............................................................................................................................ 6
1.1.1 Les attaques de scurit ......................................................................................................... 7
1.1.2 Les services de scurit ........................................................................................................ 8
1.1.3 Les mcanismes de scurit ................................................................................................. 8
1.2 Mcanismes cryptographiques ................................................................................................... 9
1.2.1 Chiffrement symtrique ....................................................................................................... 10
1.2.2 Chiffrement cl publique ................................................................................................. 10
1.2.2.1 Signature numrique .................................................................................................... 11
1.2.2.2 Certificat numrique .................................................................................................... 12
II. LES RESEAUX MOBILES AD HOC ..................................................................... 14
2.1 Technologies de communication sans fil ................................................................................ 14
2.2 Proprits des nuds .................................................................................................................... 15
2.3 Proprits des MANETs .............................................................................................................. 17
2.4 Phases de mise en uvre du rseau .......................................................................................... 18
2.5 Vulnrabilits, Menaces et Attaques dans les MANETs ................................................... 19
III. LA GESTION DES CLES DANS LES RESEAUX MOBILES AD HOC ........... 21
3.1 La gestion des cls pour la scurit rseau ............................................................................. 21
3.1.1 Trusted Third Parties (TTPs) ............................................................................................. 22
3.1.2 Public Key Infrastructure (PKI) ........................................................................................ 24
3.2 Gestion des cls dans les rseaux ad hoc ................................................................................ 25
3.2.1 Proprits dun mcanisme de gestion des cls dans les MANETs ....................... 26
3.2.2 Les approches de gestion des cls dans les MANETs ................................................ 27
Conclusion ....................................................................................................................... 28
TABLE DES MATIERES

DEUXIEME PARTIE ..................................................................................................... 29
V. PROTOCOLES DE GESTION DES CLES DANS LES RESEAUX MOBILES AD
HOC ................................................................................................................................. 30
4.1 Classification des protocoles de gestion des cls dans les MANETs ............................. 30
4.2 Les protocoles contributifs .......................................................................................................... 32
4.2.1 DiffieHellman (D-H) .......................................................................................................... 32
4.2.2 Ingemarsson, Tang, and Wong (ING) ............................................................................. 32
4.2.3 Hypercube and Octopus (H&O) ....................................................................................... 33
4.2.4 Password Authenticated Key Agreement (A-G) ........................................................... 34
4.3 Les protocoles distributifs ........................................................................................................... 34
4.3.1 Les protocoles distributifs cl publique ....................................................................... 34
4.3.1.1 Partially Distributed Certificate Authority (PDCA) ........................................... 34
4.3.1.2 Mobile Certificate Authority (MOCA) .................................................................... 36
4.3.1.3 Secure and Efficient Key Management (SEKM) .................................................. 36
4.3.1.4 Ubiquitous Security Support (UBIQ) ...................................................................... 37
4.3.1.5 Autonomous Key Management (AKM) ................................................................... 37
4.3.1.6 Self-Organized Key Management (PGP-A) .......................................................... 39
4.3.1.7 Composite Key Management for Ad Hoc Networks (COMP).......................... 40
4.3.1.8 Mobility-Based Key Management (MOB) ............................................................. 41
4.3.1.9 Identity-Based Public Key (IBC-K) ......................................................................... 42
4.3.2 Les protocoles distributifs cl symtrique .................................................................. 44
4.3.2.1 Preshared Group Key (PSGK) .................................................................................. 44
4.3.2.2 Simple Key Management Protocol (SKiMPy) ...................................................... 44
4.3.2.3 Self-Healing Session Key Distribution (S-HEAL) ............................................... 45
4.3.2.4 Logical Key Hierarchy (LKH) .................................................................................. 46
V. ANALYSE DES PROTOCOLES DE GESTION DES CLES DANS LES
RESEAUX AD HOC ...................................................................................................... 48
5.1 Critres dvaluation des protocoles ........................................................................................ 48
5.2 Evaluation des protocoles de gestion des cls dans les MANETs .................................. 49
5.2.1 Evaluation des protocoles contributifs ............................................................................ 50
5.2.2 Evaluation des protocoles distributifs ............................................................................. 52
5.2.2.1 Evaluation des protocoles distributifs cl publique ......................................... 52
5.2.2.2 Evaluation des protocoles distributifs cl symtrique ................................... 58
Conclusion ....................................................................................................................... 65

TABLE DES MATIERES

TROISIEME PARTIE ..................................................................................................... 68
VI. MECANISME DE REVOCATION DE CERTIFICATS POUR LE PROTOCOLE
UBIQ ................................................................................................................................ 69
6.1 Rvocation des cls pour les protocoles cl publique ..................................................... 69
6.1.1 Travaux relatifs la rvocation des cls pour les protocoles cl publique ....... 69
6.1.1.2 Mcanisme pour les protocoles bass sur lidentit ............................................ 70
6.1.2 Mcanisme de rvocation pour les protocoles bass sur lidentit ......................... 71
6.1.2.1 Fonctionnement du mcanisme de rvocation ..................................................... 72
6.1.2.2 Critique du mcanisme de rvocation propos pour les protocoles bass sur
lidentit ......................................................................................................................................... 80
6.2 Proposition dun mcanisme de rvocation pour le protocole Ubiquitous Security
Support (UBIQ) ..................................................................................................................................... 81
6.2.1 Choix du protocole UBIQ ................................................................................................... 82
6.2.2 Fonctionnement du mcanisme de rvocation de certificats propos .................... 83
6.2.3 Analyse du mcanisme de rvocation de certificat ..................................................... 91
6.2.3.1 Identification des attaques qui exploitent les failles de scurit inhrentes
UBIQ ............................................................................................................................................... 91
6.2.3.2 Analyse du mcanisme de rvocation de certificats propos ........................... 92
6.2.4 Cot du programme .............................................................................................................. 94
VII. TESTS ET VALIDATION DU MECANISME DE REVOCATION DE
CERTIFICATS ................................................................................................................ 96
7.1 Simulation du processus de maintien des listes de rvocation de certificats jour ... 98
7.1.1 Exprience 1 : Accusation du nud
5
ID ..................................................................... 100
7.1.2 Exprience 2 : Propagation de message daccusation .............................................. 102
7.1.3 Exprience 3 : Accusation des nuds
2
ID ,
3
ID

et

4
ID ...................................... 102
7.2 Evolution de la scurit du mcanisme propos en fonction du nombre de sauts .... 108
7.2.1 Exprience 4 : Evolution du taux de contrle moyen en fonction du nombre de
sauts ................................................................................................................................................... 110
Conclusion ..................................................................................................................... 113
CONCLUSION GENERALE ....................................................................................... 115
Rfrences : ................................................................................................................... 118
Annexe ........................................................................................................................... 124

TABLE DES FIGURES

Table des figures

1. 1: Systme de chiffrement symtrique. ....................................................................... 10
1. 2 : Systme de chiffrement cl publique. .................................................................. 11
1. 3: Exemple dune signature numrique. ...................................................................... 12
1. 4 : Format de certificat X.509 ...................................................................................... 13
2. 1: Communication entre les nuds i et j: (a) communication un saut, (b)
communication multi sauts ........................................................................................... 15
3. 1: Principaux composants d'une PKI. .......................................................................... 24
4. 1 : Classification des protocoles de gestion des cls dans les MANETs. ................... 31
4. 2 : Fonctionnement du protocole D-H. ........................................................................ 32
4. 3 : Fonctionnement du protocole ING. ........................................................................ 33
4. 4 : Fonctionnement des protocoles H&O et A-G. ........................................................ 33
4. 5 : Logical Key Hierarchy. .......................................................................................... 47
7. 1: Exemple de reprsentation de rseau ...................................................................... 98
7. 2 : Liste de rvocation envoye par
5
ID et reue par
4
ID et
6
ID . ............................. 101
7. 3 : Liste de rvocation du nud
4
ID aprs mise jour. ............................................ 101
6
ID aprs mise jour. ............................................ 102
7. 5 : Listes de rvocation reues par le nud
1
ID ........................................................ 105
7. 6 : Traitement des listes de rvocation reues par le nud
1
ID ................................ 106
7. 7 : Etat des matrices accusatrices .............................................................................. 107
1
ID

aprs mise jour. ............................................ 108
7. 9: Exemple de rseau ................................................................................................. 110
7. 10 : Evolution du taux de controle moyen en fonction du nombre de sauts.............. 113
LISTE DES TABLEAUX

Liste des tableaux
Tableau 2. 1: Portes, dbits et consommation dnergie de quelques technologies de
communication sans fil .................................................................................................... 14
Tableau 2. 2 : Spcifications techniques de quelques dispositifs de MANETs .............. 16
Tableau 5. 1: Rsum de lvaluation des protocoles contributifs .................................. 52
Tableau 5. 2: Rsum de lvaluation des protocoles distributifs cl publique ............ 57
Tableau 5. 3: Rsum de lvaluation des protocoles distributifs cl symtrique ........ 61
Tableau 5. 4: Avantages et Inconvnients des protocoles distributifs cl publique ..... 62
Tableau 5.5: Avantages et Inconvnients des protocoles distributifs cl symtrique .. 64
Tableau 5. 6: Avantages et Inconvnients des protocoles contributifs ........................... 65
Tableau 5. 7 : Rsum de lanalyse des protocoles de gestion des cls dans les
MANETs ......................................................................................................................... 66

PREMIERE PARTIE : La scurit et gestion des cls dans les MANETs
1

Introduction Gnrale

Depuis quelques annes nous assistons un dploiement exponentiel des rseaux
spontans grce lmergence de nouvelles technologies sans fil et des standards
associs, et aussi grce la disponibilit croissante de terminaux volus et autonomes
(tlphones, PDAs, ). Les rseaux spontans permettent un ensemble de machines
htes dtre connectes facilement et rapidement entre elles sans aucune infrastructure
pralable. Les rseaux ad hoc sont une illustration de ce concept de spontanit [1].

Un rseaux mobile ad hoc (MANET) est un rseau maill temporaire constitu par une
collection de nuds sans fil et mobiles, sans laide dune infrastructure prtablie,
utilise pour excuter les fonctions de base de gestion de rseau comme lacheminement
et lexpdition de paquets. Dans un tel environnement, il peut tre ncessaire quun
nud mobile demande laide dautres nuds pour expdier un paquet sa destination
cause de la couverture limite du champ radio disponible pour chaque nud.
Les rseaux ad hoc sont dynamiques dans lespace et dans le temps et offrent une
grande flexibilit. Cependant cette flexibilit associe la vulnrabilit des connexions
sans fil ncessite davantage de scurit pour les donnes.
La scurit dans les rseaux sans fil ad hoc occupe une place primordiale; un des
problmes majeurs lis la fourniture de service de scurit dans les rseaux ad hoc est
2

comment grer les cls cryptographiques qui sont requises [2]. Afin de concevoir un
systme de gestion des cls pratique et efficace il est ncessaire de comprendre les
caractristiques des rseaux ad hoc et pourquoi les approches traditionnelles de gestion
des cls ne peuvent pas tre utilises.

Ce manuscrit est structur comme suit :
Dans la premire partie nous prsentons dabord les concepts de base de la scurit
rseau, une description gnrale des rseaux sans fil ad hoc ainsi que les dfis associs
la scurisation des MANETs.
Ensuite nous donnons un aperu gnral sur la gestion des cls avant dtudier les
approches de gestion des cls proposes pour les rseaux traditionnels filaires afin de
mieux apprhender les difficults lies la gestion des cls dans les rseaux sans fil ad
hoc.
La deuxime partie est consacre ltude des protocoles qui ont t proposs pour la
gestion des cls dans les rseaux ad hoc. Elle fournit aussi une tude beaucoup plus
pousse en proposant une analyse de ces diffrents protocoles.
La troisime partie prsente un mcanisme de rvocation de certificats propos dans le
but de solutionner un des problmes soulevs lors de lanalyse des protocoles tudis.
Enfin elle fournit limplmentation du mcanisme de rvocation de certificats en C et
par la suite une srie de tests.

3

Premire partie

LA SECURITE ET GESTION DES
CLES DANS LES MANETs

4

Problmatique

Malgr lvolution des rseaux mobiles ad hoc durant la dernire dcennie il ya
toujours des problmes relatifs la scurit qui restent non rsolus [58]. Cela signifie
que bien que des solutions ont t proposes aucune ne semble satisfaire toutes les
contraintes des rseaux ad hoc.
Les chercheurs dans le domaine de la scurit des MANETs se sont initialement
focaliss sur les protocoles de routage scuriss [59, 60]. Les protocoles de routage
utilisent diffrents mcanismes de scurit pour assurer la robustesse des techniques de
routage. Il est largement reconnu que les techniques cryptographiques peuvent fournir
certains de ces mcanismes robustes pour garantir lauthenticit, lintgrit et la
confidentialit des informations de routage.

La gestion des cls scurise avec une grande disponibilit est fondamentale pour
fournir la scurit rseau [6]. Cependant tous les mcanismes de routage ngligent la
tche cruciale de gestion des cls scurise et supposent la pr existence ainsi que le pr
partage de secrets et de paire de cls publique/prive [14]. Cela place ltude de la
gestion des cls dans un secteur de recherche ouvert dans le domaine de la scurit des
MANETs [58], et tmoigne de lactualit du thme.

En raison de la nature sans fil du mdium de communication des rseaux ad hoc, le
trafic est frquemment sujet des coutes clandestines. Le manque dun mcanisme de
contrle daccs permet un nud quelconque de prendre partie dans le rseau. Aussi
la faible protection physique des nuds signifie que certains des nuds du rseau
peuvent potentiellement tre compromis. Fournir des mcanismes dauthentification
efficaces en labsence de toute autorit centrale de confiance est un dfi majeur.
Le besoin dun routage scuris est plus accentu dans les rseaux ad hoc en raison de la
participation de presque tous les nuds dans le processus de routage [58].
La scurit dans les rseaux ad hoc tant base sur lusage dun systme de gestion des
cls adquat, le problme majeur dans la fourniture de services de scurit dans de tels
rseaux est comment grer les cls cryptographiques qui sont requises.
5

Le prsent travail a pour objectif dapporter des amliorations un ou plusieurs des
protocoles de gestion des cls existants pour les rseaux ad hoc.

Pour atteindre cet objectif nous menons une brve tude portant sur la scurit rseau,
les rseaux mobiles ad hoc et le processus de gestion des cls dans les MANETs. A cet
effet nous rappelons, dans la premire partie de notre travail, les principaux aspects
couverts par la scurit rseau, savoir les attaques de scurit potentielles, les services
de scurit et les mcanismes de scurit en insistant sur ceux qui sont le plus souvent
utiliss par la cryptographie.
Nous dcrivons aussi les caractristiques gnrales des rseaux ad hoc en mettant
laccent sur les proprits qui rendent lapplication de la scurit une tche difficile.
Ensuite nous esquissons le processus de gestion des cls en gnral en donnant un
aperu sur les diffrentes tapes quil peut englober. Les approches de gestion des cls
adoptes pour les rseaux traditionnels filaires sont passes en revue. Ceci dans le but
de comprendre pourquoi celles-ci ne peuvent pas directement tre appliques
lenvironnement des MANETs.

Toujours dans le but datteindre notre objectif nous prsentons une tude sur les
diffrentes approches qui ont t proposes pour adresser le problme de la gestion des
cls dans les MANETs, afin de faire ressortir les avantages et inconvnients des
diffrents protocoles proposs, mais surtout de mettre en vidence les problmes qui
sont relatifs ces derniers.
Malgr le nombre de protocoles proposs les problmes non rsolus sont multiples et
labsence dun mcanisme efficace de rvocation pour les protocoles cl publique en
constitue un exemple.

Dans le but dapporter des amliorations aux protocoles de gestion de cls existants
nous nous proposons dtudier un mcanisme de rvocation de certificats pour un des
protocoles tudis, en nous appuyant sur une solution de rvocation de cls dj
propose pour les protocoles bass sur lidentit. Pour tester et valider notre proposition
nous nous proposons de raliser un programme de simulation informatique.

6

I. CONCEPTS DE BASE DE LA
SECURITE

Les rseaux ad hoc constituent un nouveau paradigme de communication pour les htes
mobiles appels nuds. Contrairement aux rseaux traditionnels sans fil, les rseaux ad
hoc ne sont pas lis une infrastructure fixe. Dans ce type de rseau, les nuds
communiquent les uns les autres pour maintenir le rseau connect.
Lenvironnement ad hoc ajoute de nouveaux dfis lis la scurit rseau. La nature
sans fil et dynamique des MANETs les laisse plus vulnrables aux attaques de scurit
que les rseaux traditionnels filaires. Les attaques dcoute clandestine, dinsertion de
messages, de dni de service et dexhaustion de batterie sont inhrentes
lenvironnement ad hoc et faciles raliser. En outre les nuds agissant en tant que
routeur et terminal de communication ne sont pas ncessairement fiables.
Les techniques cryptographiques sont essentielles pour la protection dinformation de
routage et de donnes dapplication. Les cls cryptographiques servent comme preuve
de fiabilit afin dauthentifier les nuds comme membre lgitime du rseau, elles sont
aussi utilises pour garantir la confidentialit et lintgrit. Une gestion scurise et
efficace des cls cryptographiques est cruciale pour un service rseau fiable et ainsi
pour le succs des rseaux sans fil ad hoc.

1.1 La scurit rseau

La scurit rseau se rfre aux moyens employs pour protger les donnes lors de leur
transmission dans un rseau ou entre les rseaux. Quand nous parlons de scurit trois
aspects peuvent tre couverts [2] : les services requis, les attaques potentielles et les
mcanismes de scurit.
L'aspect service de la scurit inclut la fonctionnalit qui est exige pour fournir un
environnement de gestion de rseau scuris, tandis que les attaques de scurit
couvrent les
7

mthodes qui pourraient tre utilises pour casser ces services de scurit. Enfin les
mcanismes de scurit sont les blocs fonctionnels de base employs pour fournir les
services de scurit.
1.1.1 Les attaques de scurit

Les attaques de scurit peuvent tre classes en deux catgories selon la nature de
l'attaquant :
Attaques passives : L'attaquant peut seulement couter clandestinement ou surveiller le
trafic du rseau. Typiquement c'est la forme d'attaque la plus facile et elle peut tre
excute sans difficult dans beaucoup d'environnements de gestion de rseau, par
exemple les rseaux d'mission tels que Ethernet et les rseaux sans fil. Comme type
dattaque passive nous pouvons citer :
coute clandestine : Cette attaque est employe pour gagner la connaissance des
donnes transmises. Cependant cette attaque peut facilement tre empche en
employant un systme de chiffrement pour protger les donnes transmises ;
Analyse de trafic : Le but principal de cette attaque est dextraire de
linformation partir des caractristiques de la transmission, par exemple la
quantit de donnes transmises, l'identit des nuds communicants etc. Cette
information peut permettre l'attaquant de dduire l'information sensible, par
exemple les rles des nuds communicants, leur position etc. Elle est plus
difficile prvenir.

Dans le cas des attaques actives, l'attaquant peut non seulement couter la transmission
mais peut galement activement la changer ou lobstruer. Comme type dattaque active
nous pouvons citer :
Usurpation (mascarade): Ici l'attaquant emploie l'identit d'un autre nud pour
gagner l'accs non autoris une ressource ou des donnes. En personnifiant
un nud lgitime l'attaquant peut essayer d'accder la cl de chiffrement
employe pour protger les donnes transmises. Une fois que cette cl est
connue l'attaquant, il peut avec succs effectuer l'attaque dcoute clandestine ;
8

Modification : Cette attaque modifie des donnes pendant leur transmission
entre les nuds communicants, impliquant que les nuds communicants ne
partagent pas la mme vision des donnes transmises.
Rejeu : L'attaquant retransmet des donnes prcdemment transmises par un
nud lgitime ;
Dni de service : Cette attaque active vise obstruer ou limiter l'accs une
certaine ressource. Cette ressource peut tre un nud spcifique, un service ou le
rseau entier.
1.1.2 Les services de scurit

Pour fournir un environnement de gestion de rseau scuris certains ou tous les
services suivants peuvent tre requis :
Confidentialit : Assure que seuls les rcepteurs prvus peuvent accder
linformation transmise ;
Authentification : Permet aux parties communicantes d'tre assures des autres
identits ;
Intgrit : Assure que les donnes n'ont pas t changes pendant la
transmission ;
Non rpudiation : Assure que les parties peuvent prouver la transmission ou la
rception d'information par les autres parties ; cest dire une partie ne peut pas
nier avoir reu ou envoy certaines donnes ;
Contrle daccs : consiste empcher lutilisation non autorise dune
ressource ;
Disponibilit : Assure que les services rseau prvus sont disponibles pour les
parties prvues quand ils sont requis.
Selon les possibilits de n'importe quel attaquant potentiel diffrents mcanismes
peuvent tre employs pour fournir les services ci-dessus.
1.1.3 Les mcanismes de scurit

9

La plupart des services de scurit prcdemment mentionns peuvent tre assurs en
utilisant diffrents mcanismes cryptographiques ou non.
Le service de confidentialit peut tre de deux types diffrents. Le type dexigence le
plus commun de confidentialit est que l'information transmise ne devrait pas tre
expose une entit non autorise. Une exigence plus stricte de confidentialit est que
l'existence mme d'information ne devrait pas tre indique une entit non autorise.
Le premier type de condition de confidentialit exige seulement la protection contre des
attaques dcoute clandestine et peut tre fourni en utilisant un systme de chiffrement.
La condition plus stricte implique que le service doit galement assurer la protection
contre l'analyse du trafic. Un tel service exigera typiquement des mcanismes
additionnels avec un certain systme de chiffrement.
Le service d'intgrit peut tre fourni en utilisant des fonctions cryptographiques de
hachage accompagnes dune certaine forme de chiffrement. En traitant la scurit
rseau le service d'intgrit est souvent fourni implicitement par le service
d'authentification.
L'authentification peut tre fournie en utilisant le chiffrement accompagn de fonctions
de hachage cryptographiques.
La non rpudiation exige l'utilisation de la cryptographie cl publique pour fournir les
signatures numriques. En mme temps que les signatures numriques un tiers de
confiance peut tre impliqu.
Le contrle daccs peut tre assur par des mcanismes non bass sur la cryptographie
tels que la dtection dvnements, les firewalls etc.
La disponibilit est typiquement assure par redondance, protection physique et d'autres
moyens non cryptographiques.

1.2 Mcanismes cryptographiques
Plusieurs mcanismes utiliss pour scuriser les rseaux sont lis la cryptographie. Les
plus communment utiliss sont ici prsents [2].

10

1.2.1 Chiffrement symtrique

Le chiffrement symtrique est illustr la Figure1.1. Le message texte en clair m est
chiffr en utilisant une cl partage k, ayant pour rsultat le texte chiffr c. Pour
rcuprer le message texte en clair le texte chiffr est dchiffr en utilisant la mme cl
utilise pour le chiffrement. Des systmes de chiffrement symtriques peuvent tre
employs pour fournir la confidentialit, l'intgrit et l'authentification. La cl partage
doit tre distribue sur une voie de transmission scurise.

Figure 1. 1: Systme de chiffrement symtrique.

1.2.2 Chiffrement cl publique

Les systmes de chiffrement cl publique dpendent de l'utilisation de deux cls
diffrentes mais mathmatiquement lies. Une des cls est employe pour le chiffrement
et l'autre pour le dchiffrement.
Le systme de chiffrement cl publique est illustr la Figure1.2. Bob gnre une
paire de cls publique/prive
Bob Bob
sk pk / . La cl publique est lie la cl prive, mais
de telle manire que la cl prive ne puisse pas tre drive delle sans information
additionnelle.
Si Alice veut envoyer un message chiffr Bob, elle a d'abord besoin d'obtenir sa cl
publique. La cl publique de Bob n'a pas besoin d'tre garde secrte ; toutefois elle doit
tre authentifie cest dire Alice doit tre assure que la cl publique qu'elle croit venir
de Bob appartient vraiment ce dernier. Une fois quAlice a lauthenticit de la cl
publique
Bob
pk , elle chiffre le message texte en clair m en lutilisant. Le texte chiffr c
11

rsultant peut alors seulement tre dchiffr en utilisant la cl prive
Bob
sk que seul Bob
connat.

Figure 1. 2 : systme de chiffrement cl publique.

Il exige seulement un canal authentifi, par opposition au canal scuris exig pour la
distribution des cls de chiffrement symtrique. Le chiffrement cl publique peut
galement fournir la non rpudiation en mme temps que la confidentialit, l'intgrit et
l'authentification. Cependant, le chiffrement cl publique exige beaucoup plus de
ressources de calcul que le chiffrement symtrique et a donc moins de performance. Par
consquent le chiffrement cl publique est en gnral employ seulement pour chiffrer
de petites quantits de donnes, par exemple les cls de chiffrement symtrique et les
signatures numriques.

1.2.2.1 Signature numrique

Une signature numrique est une structure de donnes qui fournit la preuve de l'origine,
c'est--dire authentification et intgrit, et selon la faon dont elle est employe, elle
peut galement fournir la non rpudiation. La Figure 1.3 illustre comment une signature
numrique est utilise. Alice veut envoyer un message Bob, toutefois elle ne veut pas
qu'il soit modifi pendant la transmission et Bob veut tre sr que le message est
vraiment venu d'Alice. Alice calcule alors avec une fonction de hachage un digeste du
message qu'elle chiffre avec sa cl prive
Alice
sk . Elle envoie alors le message et le
digeste chiffr qui est ici une signature. Bob peut ainsi vrifier la signature en calculant,
12

avec une fonction de hachage, le digeste du message qu'il a reu, et le comparer celui
quil a obtenu en dchiffrant la signature grce la cl publique d'Alice
Alice
pk . Si les
digestes sont gaux Bob sait qu'Alice a envoy le message et qu'il n'a pas t modifi
depuis qu'elle l'a sign.

Figure 1. 3. Exemple dune signature numrique.

1.2.2.2 Certificat numrique

La cryptographie cl publique est trs utile, mais en prsence dattaquants actifs un
problme surgit [2]. Considrons quAlice veut envoyer un message secret Bob. Elle
chiffre le message en utilisant la cl publique de Bob
Bob
pk qu'elle a rcupre d'un
serveur. Cependant la cl qu'Alice a rcupre appartient rellement un attaquant. Le
message secret qui t prvu pour Bob peut maintenant tre dchiffr et lu par
l'attaquant.
Les certificats numriques sont mis en uvre pour empcher ce type d'attaque.
Fondamentalement un certificat numrique est un rapport publi par une certaine partie
de confiance qui vrifie que la cl publique
A
pk appartient en fait l'utilisateur A. La
partie de confiance signe numriquement ce rapport et donc n'importe qui, avec la cl
publique authentique de cette dernire, peut vrifier le certificat et ensuite utiliser
A
pk
et tre suffisamment sr qu'elle appartient rellement au nud A.
La Figure1.4 montre l'information dans un certificat X.509. Le numro de srie sert
identifier uniquement le certificat, et le nom d'metteur est celui de la partie de
confiance qui a dlivr le certificat. Le champ de validit indique combien de temps le
certificat est valide. Le sujet est l'entit identifie par le certificat, cest dire l'entit
13

dont la cl publique est certifie. Les deux champs suivants contiennent la cl publique
certifie et des informations propos de la raison pour laquelle elle est certifie. Le
champ dextension peut tre employ pour indiquer n'importe quelles informations
additionnelles sur le certificat. Le champ de signature contient la signature de certificats
accompagne dinformations concernant lalgorithme de hachage utilis.

Figure 1. 4 : Format de certificat X.509

14

II. LES RESEAUX MOBILES
AD HOC

Dans cette section nous prsentons une description gnrale des rseaux ad hoc ainsi
que les dfis associs la scurisation de tels rseaux.

Nous limitons notre attention aux proprits des MANETs qui rendent l'application de
la scurit une tche difficile.

2.1 Technologies de communication sans fil

Les technologies de communication sans fil utilises dans les MANETs sont IEEE
802.11, IEEE 802.15.1 / Bluetooth, IEEE 802.15.4 / ZigBee, IEEE 802.16, et IrDA
(Infrared Data Association) [3]. Les MANETs prsentent des contraintes lies la
porte de communication, les dbits limits, et les consommations quantitatives
d'nergie de ces technologies de communication. Le Tableau 2.1 prsente ces
diffrentes caractristiques pour diverses technologies.

Tableau 2. 1: Portes, Dbits et Consommation dnergie de quelques technologies de communication
sans fil

IEEE
802.11
IEEE
802.15.1 /
Bluetooth
IEEE
802.15.4 /
ZigBee
IEEE
802.16
IrDA
Porte
~ 100 m ~ 10 -100
m
~ 10 m ~ 6 - 8 km ~ 1 m
Dbit
~ 2 11
Mbps
~ 1 Mbps ~ 0.25
Mbps
~ 45 Mbps
par canal
~100
Mbps
Consommation
dnergie
Moyenne Faible trs faible leve Moyenne
15

Notons que excepte IrDA, toutes les normes numres utilisent les technologies radio.
Si deux nuds i et j dans un MANET sont dans la gamme ou la porte de transmission
immdiate l'un de l'autre, ils peuvent directement changer des messages. Cela est
parfois appel communication un saut et est illustr la Figure 2.1-a. Toutefois,
partir du Tableau 2.1, nous pouvons observer que les technologies de communication
susmentionnes ont des portes de communication trs restrictives. Par consquent, afin
de permettre aux nuds de communiquer avec d'autres nuds situs en dehors de leurs
portes de communication, le routage multi sauts doit tre utilis. Ainsi, chaque nud
du rseau agit en tant que routeur r et les paquets sont transmis plusieurs reprises
d'autres nuds dans la gamme de communication directe, jusqu' ce que ces derniers
atteignent leur destination. Le routage multi sauts entre les nuds i et j via les nuds
intermdiaires
1
r ,
2
r ,
3
r et
4
r agissant comme des routeurs est illustr la Figure 2.1-b,
o pour des raisons de simplicit, nous supposons que la porte de transmission Tx et
celle de rception Rx sont gales, c'est--dire R = Tx = Rx, et est la mme pour tous les
nuds du rseau.

Figure 2. 1: Communication entre les nuds i et j: (a) communication un saut,
(b) communication multi sauts.

2.2 Proprits des nuds

Les nuds typiques dun MANET sont des ordinateurs portables, des assistants
personnels, des ordinateurs de poche, des tlphones cellulaires ou d'autres dispositifs
mobiles sans fil [3]. Contrairement aux rseaux locaux sans fil, les MANETs sont
16

gnralement composs d'un ensemble de dispositifs prsentant des contraintes
similaires, car aucun serveur, routeur ou autre entit puissante nest dploye ou
accessible. En raison de leur mobilit, les dispositifs dun MANET sont gnralement
lgers et sont aliments par des sources dnergie autonomes. En outre, les dispositifs
dun rseau mobile ad hoc sont gnralement peu coteux afin de permettre un large
usage. Ces caractristiques des dispositifs dun MANET conduisent plusieurs
contraintes de ressources, savoir:
puissance CPU limite ;
mmoire limite ;
charge de la batterie limite ;
faible protection physique.
Ces contraintes limitent fortement les capacits de calcul et de communication des
appareils et donc de l'ensemble du rseau mobile ad hoc. Pour illustrer certaines
contraintes de ressources, nous listons les spcifications techniques de quelques
dispositifs mobiles dans le Tableau 2.2.

Tableau 2. 2 : Spcifications techniques de quelques dispositifs de MANETs

En raison de la puissance CPU limite, certaines oprations de calcul intensif peuvent
tre impossibles sur un dispositif de MANET. Mme si ces oprations sont possibles, le
nombre d'excutions devrait tre limit. En outre, les programmes complexes ou les
grands ensembles de donnes du systme ncessitent trop d'espace mmoire. En
gnral, les technologies de calcul et de stockage voluent rapidement. Toutefois, les
progrs technologiques pour une longue dure de vie des sources dnergie autonomes
CPU Batterie Mmoire
Ordinateurs de
poche
PCs / PDAs
Intel XScale
PXA270, 520 MHz
Ion Battery :
100 mW 10W
64 MB
RAM,
192 ROM
Ordinateur
portable
Intel Core 2 Duo, 2
GHz
High Capacity Ion
Battery, 10W 120W
~ 60
200 HD,
2 4 GB
RAM
17

sont comparativement beaucoup plus lents. En outre, les batteries peuvent ne pas tre
rechargeables dans le rseau, et un nud est exclu du rseau une fois que sa batterie est
dcharge. Nous concluons par consquent que lnergie est de loin la plus rare des
ressources dans les MANETs, et donc la conservation de celle-ci est cruciale. Lnergie
peut tre conserve en limitant le nombre de paquets transmis et reus ainsi que le
nombre et le type de calcul excut. Notons que la transmission de paquets est
lopration consommant le plus dnergie.
Enfin, nous constatons que la compromission de nuds est trs probable parce que les
nuds offrent une faible protection physique et sont facilement accessibles par les
utilisateurs malveillants.
Aprs avoir tudi les proprits des technologies de communication employes et des
dispositifs de MANET nous sommes maintenant en mesure de dfinir les MANETs.
Dfinition : Les MANETs sont des rseaux sans fil qui sont forms spontanment par
un groupe de nuds mobiles sans l'aide de toute infrastructure centralise. Une fois que
le rseau est form toutes les tches sont effectues de manire auto organise. Les
nuds communiquent via des liens sans fil courte porte, o chaque nud agit comme
un routeur permettant ainsi le routage multi sauts afin d'accrotre les portes de
communication des nuds.

2.3 Proprits des MANETs

De la dfinition ci-dessus dcoulent les proprits suivantes des MANETs [3]:
absence dinfrastructure ;
transitoire ;
dynamique ;
sans fil ;
multi sauts ;
nuds de rseau mobiles ;
nuds de rseau de ressources limites (nergie, CPU, mmoire) ;
nuds de rseau avec des contraintes similaires.
18

La premire proprit signifie que les nuds du rseau doivent prendre en charge toutes
les oprations de rseau et se rfre la proprit dauto organisation. Notons que celle-
ci peut tre assouplie au cours de certaines phases du rseau ou dans certaines
applications comme nous en discutons dans la sous section 2.4. Les MANETs sont
transitoires, car ils sont forms spontanment dans un but prcis ou pour offrir un
certain service. Les rseaux sont dynamiques parce que les nuds peuvent joindre ou
quitter le rseau tout moment. Comme indiqu dans les sous sections 2.1 et 2.2, les
nuds sont mobiles, de ressources limites, communiquent via des canaux sans fil
courte porte, utilisent le routage multi sauts afin d'accrotre leurs gammes de
communication et ont des contraintes similaires.

2.4 Phases de mise en uvre du rseau

Nous distinguons deux phases pour la mise en uvre des MANETs:
1. phase d'initialisation du rseau ;
2. phase de fonctionnement du rseau.
Au cours de la premire phase, tous les nuds qui sont prsents au moment de la
formation du rseau sont initialiss [3]. L'initialisation est effectue par un tiers de
confiance (Trusted Third Party, TTP) et comprend la distribution des paramtres du
systme et des cls cryptographiques chaque nud. Les TTPs peuvent tre des entits
centrales externes ou des entits distribues internes composes d'un groupe de nuds
du rseau. Nous discutons des TTPs externes et internes plus en dtail dans la section
suivante. En principe, tous les paramtres ncessaires l'excution de protocoles rseau,
y compris les protocoles de scurit, doivent tre distribus tous les nuds prsents au
cours de l'initialisation du rseau. Aprs l'initialisation du rseau, de nouveaux nuds
peuvent sy joindre, ou des nuds prsents peuvent quitter le rseau tout moment dans
la phase de fonctionnement du rseau. Notons que les nouveaux nuds qui rejoignent le
rseau aprs la phase d'initialisation du rseau doivent galement obtenir les paramtres
systme et des cls cryptographiques. Les initialisations de nuds peuvent se produire
en dehors du rseau, c'est--dire, avant que les nuds ne rejoignent le rseau, ou au sein
du rseau par d'autres nuds du rseau. Au cours de la phase de fonctionnement du
19

rseau, deux ou plusieurs nuds peuvent excuter les protocoles rseau en utilisant les
paramtres et les cls qui ont t tablis au cours de linitialisation du rseau.

2.5 Vulnrabilits, Menaces et Attaques dans les MANETs

Une approche de conception de mcanismes de scurit pour un systme consiste
dterminer les menaces auxquelles le systme fait face et les attaques possibles tant
donnes les vulnrabilits. La conception de mcanismes de scurit doit donc assurer
que le systme est labri de ces vulnrabilits, menaces et attaques.
La premire vulnrabilit des MANETs est lie la technologie sans fil sous-jacente
[5]. Quiconque possdant le rcepteur adquat peut potentiellement couter ou perturber
les messages changs. Et ceci, mme s'il se trouve dans un lieu public, l'extrieur du
btiment o se droulent les changes.
Les nuds eux-mmes sont des points de vulnrabilits du rseau car un attaquant peut
compromettre un lment laiss sans surveillance.
L'absence d'infrastructure fixe pnalise l'ensemble du rseau dans la mesure o il faut
faire abstraction de toute entit centrale de gestion pour l'accs aux ressources.
Les mcanismes de routage sont d'autant plus critiques dans les rseaux ad hoc que
chaque entit participe l'acheminement des paquets travers le rseau. De plus, les
messages de routage transitent sur les ondes radio.
Enfin, ces rseaux hritent de toutes les vulnrabilits propres aux technologies sans fil
WLAN et WPAN.
Dans le cas des menaces de type actif, l'attaquant se donnera les moyens d'agir sur la
gestion, la configuration et l'exploitation du rseau. Il peut injecter son propre trafic,
modifier le fonctionnement d'un nud, usurper l'identit d'un lment valide, rejouer
des messages, modifier des messages transitant sur le rseau ou provoquer un dni de
service.
Les attaques fortement probables ou faisables, et qui constituent un risque non
ngligeable pour les MANETs, sont les suivantes [5] :
20

Les dnis de services, denial of services (DoS) apparaissent comme les attaques
les plus faciles raliser par un attaquant. La criticit de telles attaques dpend
fortement du contexte d'utilisation mais n'est jamais compltement ngligeable ;
Les attaques passives d'coute et d'analyse du trafic constituent une menace
certaine pour la confidentialit et l'anonymat ;
L'usurpation de l'identit d'un nud permet de nombreuses attaques actives
rendant particulirement critique la protection des mcanismes de routage ;
L'attaque physique d'un lment valide entrane la compromission du nud, et
se rvle comme tant un point faible des rseaux ad hoc ;
Lattaque sur les mcanismes de routage apparat comme tant particulirement
critique. Si aucun contrle n'est fait sur la provenance et l'intgrit des messages
de routage du rseau ad hoc, un nud malicieux pourra facilement causer des
perturbations au rseau.

21

III. LA GESTION DES CLES DANS
LES RESEAUX MOBILES AD HOC

Dans cette section nous donnons un aperu sur la gestion des cls dans les MANETs.
Nous proposons dabord une vue densemble sur le mcanisme de gestion des cls pour
la scurit rseau et une brve tude sur les approches adoptes pour celui-ci dans les
rseaux traditionnels filaires.

3.1 La gestion des cls pour la scurit rseau

Les nuds dans un rseau doivent tre en mesure de communiquer de manire scurise
les uns avec les autres. Pour scuriser la communication entre deux entits, ces
dernires doivent avoir une valeur secrte ou une cl. Pour rendre cette communication
scurise possible, il est ncessaire, pour les nuds, d'avoir accs aux cls
cryptographiques.
La gestion des cls dans les rseaux a une importance cruciale. En cas d'utilisation de
systmes cryptographiques, comme le chiffrement ou les signatures numriques pour
protger la fois le contrle et le trafic de donnes, un service de gestion de cls est
toujours requis. Les diffrentes manires de scuriser les communications concernent
les entits partageant une cl ou les entits possdant des cls diffrentes. La gestion des
cls est le processus par lequel les cls sont distribues aux nuds dans le rseau, et la
faon dont elles sont encore mises jour, si ncessaire, effaces, rvoques ou stockes.
La gestion des cls peut concerner plusieurs tapes, sagissant de systmes cl
symtrique ou asymtrique.
Il s'agit notamment de [6]:
1 linitialisation des utilisateurs du systme ;
2 la cration, la distribution et l'installation des cls cryptographiques ;
3 lorganisation de lutilisation des cls cryptographiques ;
4 la mise jour, la rvocation et la destruction des cls cryptographiques ;
22

5 larchivage des cls cryptographiques.
Le but de cette premire tape est l'amorage du systme. Cela pourrait inclure diverses
autres oprations non cryptographiques, telles que la vrification de linformation sur
les utilisateurs, la fourniture didentits aux utilisateurs du systme, la vrification des
logiciels ncessaires pour participer au processus de gestion des cls, etc. Cette partie
est suivie par la cration et la distribution des cls cryptographiques, qui peuvent se
faire de manire centralise ou dcentralise. Les cls qui ont t distribues sont alors
installes sur les diffrents nuds.
Lors de la troisime phase les cls cryptographiques sont utilises pour protger la
communication entre les diffrents nuds. Cela se fait en utilisant des cls pour chiffrer
les donnes et contrler le trafic chang entre les diffrents nuds du rseau.
La quatrime tape est cruciale pour faire face diverses menaces qui pourraient aboutir
une compromission des cls. Cela pourrait conduire un manque de confidentialit ou
d'authenticit, ainsi qu l'utilisation non autorise des cls. Dans ce cas, des processus
de gestion doivent veiller ce que les cls compromises soient annules (rvoques). En
outre, il peut parfois tre ncessaire de remplacer les cls compromises. Bien sr, le
remplacement des cls compromises n'est pas ncessaire pour les nuds sous le
contrle de l'adversaire. Enfin, la cinquime tape pourrait tre ncessaire dans le cas o
les cls cryptographiques sont sauvegarder.
La majorit des mcanismes utiliss pour fournir les services de scurit ncessite
l'utilisation de cls cryptographiques, qui doivent tre partages entre les parties
communicantes. Les processus de gestion de cls impliquent des techniques diffrentes
lors de lexamen des systmes cryptographiques symtriques et asymtriques, des
rseaux filaires ou sans fil.
Lapproche typique de gestion des cls dans les rseaux traditionnels filaires est base
sur lutilisation dun tiers de confiance (Trusted Third Party, TTP).

3.1.1 Trusted Third Parties (TTPs)

Nous faisons la distinction entre TTP externe, interne, central et distribu [3]. Un TTP
externe ou off-line TTP est une entit en dehors du rseau qui a la confiance de tous les
23

nuds du rseau. Le TTP peut consister en une seule entit centrale ou n entits
distribues. La dernire mise en uvre est parfois choisie afin d'accrotre la confiance
au TTP, car la confiance peut tre maintenue, mme si certains des TTPs peuvent ne pas
tre dignes de confiance.
Un TTP interne est un TTP distribu compos de n nuds de rseau, o n ,
tant le nombre total de nuds dans le rseau. Ici, le pouvoir et les capacits d'un TTP
sont distribus n nuds de rseau. La distribution du pouvoir est souhaitable afin
d'viter un unique point de dfaillance. Cela est ncessaire dans les MANETs cause de
la probabilit de compromissions de nuds. Il ya deux cas possibles de TTPs internes
distribus: TTP distribu avec des nuds spciaux et TTP distribu avec des nuds
rseau conventionnels.
Dans le premier cas n nuds spciaux, qui sont plus puissants que les autres n
nuds du rseau en termes de calcul et de la charge de la batterie, reprsentent le TTP.
Ces nuds ont t initialiss au cours de la phase d'initialisation du rseau. Toutefois,
cette approche est en contradiction avec la proprit 8 de notre liste des proprits dun
MANET notamment l'hypothse que les nuds dun MANET prsentent des
contraintes similaires.
Dans le second modle, tout groupe de n nuds de rseau peut tre choisi pour
reprsenter le TTP. Notons que, tout en permettant plus de fonctionnalits et de
flexibilit, les TTPs distribus on-line imposent toujours un lot supplmentaire de calcul
et de cot de communication au rseau en raison de l'usage de systmes de seuil.
Un TTP peut avoir plusieurs rles dans un rseau, par exemple, un TTP peut initialiser
les nuds avec les cls ncessaires au cours de l'initialisation du rseau ou avant quils
ne rejoignent le rseau, distribuer des cls de session aux nuds qui souhaitent
communiquer de manire scurise les uns avec les autres durant le fonctionnement du
rseau, ou aider vrifier les certificats de cls publiques en fournissant des listes de
rvocation de certificats.
Key Distribution Center (KDC), Key Tranlation Center (KTC) et Certificate Authorities
(CA) sont des exemples de TTP. KDC et KTC sont destins aux systmes cls
symtriques
et CA est destin aux systmes cls publiques.
24

3.1.2 Public Key Infrastructure (PKI)

L'utilisation de la cryptographie cl publique ncessite que l'authenticit de la cl
publique puisse tre tablie. Une approche simple exige que deux utilisateurs qui
souhaitent communiquer changent leurs cls publiques de manire authentifie. Cela
demanderait la distribution initiale de n (n-1) cls publiques [2]. Cependant, par le biais
dun TTP qui distribue des certificats seule sa cl publique doit tre distribue chacun
des utilisateurs.
Une PKI fournit les mcanismes ncessaires la gestion des certificats et comprend les
lments illustrs la Figure 3.1.

Figure 3. 1: Principaux composants d'une PKI.

Une entit finale est soit un utilisateur de certificats soit un sujet auquel un certificat a
t dlivr. L'autorit de certification (CA) est le composant responsable de la
dlivrance et de la rvocation des certificats, alors que l'autorit d'enregistrement (RA)
est charge d'tablir l'identit du sujet du certificat et la correspondance entre lui et sa
cl publique. Les fonctions d'enregistrement peuvent tre excutes par la CA, et donc
la RA est une composante optionnelle. Les services de base suivant devraient tre
fournis par les composants PKI dcrits ci-dessus:
Inscription ;
Initialisation ;
Certification ;
Mise jour de cls ;
25

Rvocation ;
Avis de rvocation et de distribution de certificats.
Dautres services qui peuvent tre fournis par la PKI comprennent la rcupration de
cls,
la gnration de cls, la non rpudiation etc.

3.2 Gestion des cls dans les rseaux ad hoc

La gestion des cls dans les rseaux ad hoc est plus difficile compare la gestion des
cls dans les rseaux traditionnels filaires. Dans [2] il est montr que cette difficult est
principalement lie deux facteurs notamment :
les exigences en infrastructure des solutions traditionnelles ;
la facilit de mise en uvre des attaques de scurit dans les
MANETs.
En effet les solutions traditionnelles de gestion des cls prsentent des exigences en
infrastructure qui les rendent inappropries aux rseaux ad hoc. Lutilisation dun TTP
pour fournir les services de gestion des cls implique la prsence dune infrastructure
administrative. Mme en cas de prsence de celle-ci, les solutions qui sont bases sur
lusage dun TTP rencontrent des problmes. Un des problmes les plus vidents est
quelles dpendent de la disponibilit dun serveur central. Cependant, en raison de
labsence dinfrastructure de routage et dune topologie hautement dynamique dans les
MANETs, une telle disponibilit ne peut pas tre assure. Enfin lexistence dun serveur
ne peut pas tre assure dans certaines applications MANET.
Une des menaces les plus videntes dans les MANETs est celle de lcoute clandestine,
puisque toutes les communications sont ralises via des canaux sans fil. Toutefois une
menace plus srieuse, et qui complique davantage le problme de laccord de cls, est
celle des attaques actives. En raison de labsence dinfrastructure de routage, les nuds
participent la retransmission des messages pour le compte dautres nuds comme
dcrit dans la section prcdente. Une consquence directe en est quun attaquant peut
facilement modifier les messages et excuter une attaque man-in-the-middle.
26

Puisque les nuds des rseaux ad hoc sont souvent mobiles et plus exposs que les
nuds dun rseau traditionnel, le risque de compromission doit gnralement tre
considr comme suprieur. Ainsi toute solution de gestion des cls dans les MANETs
doit disposer dun mcanisme de rvocation. Cela implique aussi que lapproche
directe, amliorant la disponibilit dun TTP en le distribuant de multiples nuds, est
inapproprie. La raison est que cela affaiblit la scurit puisquelle expose plus les TTPs
aux attaques. Si lun de ces TTPs est compromis, la scurit de lensemble du rseau
lest aussi. Dans le cas o le TTP est une CA une approche plus fiable est dutiliser un
systme de partage secret seuil pour partager le secret entre un nombre de nuds dans
le rseau. La compromission dau plus k-1, k tant le seuil du partage secret, laisse
toujours la scurit du service intacte.
Les menaces mentionnes ci-dessus ne sont pas seulement prsentes dans les MANETs,
elles existent aussi dans les rseaux traditionnels. Toutefois leffort requis pour les
raliser est considrablement plus rduit dans les MANETs que dans les rseaux
traditionnels.
Ainsi les solutions qui ont t proposes pour les rseaux filaires ne sont pas toujours
applicables aux rseaux ad hoc.

3.2.1 Proprits dun mcanisme de gestion des cls dans les MANETs

Pour tout mcanisme de gestion des cls dans les rseaux mobiles ad hoc il est
souhaitable quil soit [7]:
Dcentralis : Le service de gestion des cls ne doit pas sappuyer sur un nud
de confiance central suppos tout le temps tre prsent. Puisque la connectivit
des nuds dans un rseau ad hoc peut se rompre facilement, le service entier
peut tre interrompu sil est reli un nud unique. Ainsi un service de gestion
de cls fiable a besoin dtre distribu sur plusieurs nuds. A cause de la liaison
pair pair des nuds dans un rseau ad hoc, il est prfrable que les cls ne
soient pas tablies par une seule entit, mais plutt collectivement par les
nuds ;
27

Dynamique : Le service de gestion des cls doit tre en mesure de grer le dpart
des nuds existants et larrive de nouveaux nuds dans le rseau, sans recourir
une complte r excution du protocole de gestion de cls. Idalement, les
nouveaux nuds ne doivent pas tre capables de gagner laccs linformation
change dans le pass, tandis que les nuds quittant ne doivent pas tre
capables de gagner accs linformation affrente aux futures sessions. Ainsi il
devient essentiel que les cls soient changes pour fournir lindpendance des
cls travers diffrentes sessions dans le rseau ;
Efficace : Le service doit tre assez simple de telle sorte que les nuds
dpensent seulement une fraction de leur temps pour ltablissement des
fonctions clefs.

3.2.2 Les approches de gestion des cls dans les MANETs

Les protocoles qui dpendent de lutilisation dun TTP ne sont pas appropris au
scnario des rseaux ad hoc. La raison principale est labsence dinfrastructure fiable
dans les MANETs [4]. Cependant quelques propositions bases sur la modification de
cette approche ont t faites. De telles propositions ont t faites spcialement pour les
systmes cls publiques dans les rseaux ad hoc.
Une autre approche a t propose pour les systmes cls symtriques. Elle est base
sur lutilisation dun contexte pralable. Dans ce cas, il est suppos que presque tous les
nuds se partagent un contexte pralable au mme moment, avant que lopration
rseau ne commence. Ce contexte pralable est gnralement sous la forme dune cl
secrte pr distribue avant le dploiement du rseau. Bien entendu lexigence que tous
les nuds se partagent un contexte pralable pour le dploiement peut ne pas toujours
tre praticable.
Une troisime approche base sur lauto organisation peut tre trs utile. Dans ce cas les
nuds dploys dans le rseau ne dpendent pas dun contexte pralable partag. Une
hypothse de base commune plusieurs de ces propositions est relative lexistence
dun canal de communication authentifi.
28

Une autre approche est dpendante de lutilisation de systmes cl publique base sur
lidentit. Dans ce cas la cl publique dun nud du systme est drive de lidentit de
celui-ci.

Conclusion

Dans cette premire partie nous avons dcrit les concepts de base de la scurit rseau.
Ces derniers, plus particulirement les concepts de la cryptographie, sont importants
pour la fourniture de services de scurit dans un environnement de rseau sans fil ad
hoc. Les techniques cryptographiques peuvent tre utilises pour fournir la
confidentialit, lauthentification et lintgrit dans un tel environnement. Un problme
majeur li lutilisation des techniques cryptographiques dans un tel environnement est
la gestion des cls cryptographiques.
Ltude et lanalyse des rseaux mobiles ad hoc ont permis de faire ressortir les
proprits qui rendent lapplication de scurit dans les MANETs une tche difficile.
Un dfi principal dans la conception de ces rseaux est leur vulnrabilit aux attaques de
scurit.
Nous avons donn un aperu gnral sur le processus et les approches de gestion des
cls dans les rseaux traditionnels filaires. Ceci a mis en vidence la difficult de les
appliquer lenvironnement des MANETs. La gestion des cls dans les MANETs est
plus complexe et cela est principalement d deux facteurs : labsence dinfrastructures
et la facilit de mise en uvre des attaques de scurit dans les MANETs.
De cette tude nous concluons que les approches proposes pour les rseaux
traditionnels ne sont pas appropries aux rseaux ad hoc. Cependant des modifications
ont t apportes certaines dentre elles, notamment pour les systmes cl publique
dans le but de les adapter aux MANETs. Dautres approches, bases sur lutilisation
dun contexte pralable, sur lauto organisation et sur lidentit, ont t galement
proposes.
DEUXIEME PARTIE : Prsentation et analyse des protocoles de gestion des cls dans les MANETs

29

Deuxime partie

PRESENTATION ET ANALYSE
DES PROTOCOLES DE GESTION
DES CLES DANS LES MANETs


30

IV. PROTOCOLES DE GESTION
DES CLES DANS LES
RESEAUX MOBILES AD HOC

La gestion des cls est un service cryptographique de base requis avant que tout autre
service de scurit ne puisse tre dploy dans le rseau.
Dans cette deuxime partie nous prsentons les solutions qui ont t proposes dans le
cadre de la gestion des cls dans les rseaux ad hoc. Nous considrons le problme de la
gestion des cls dans les rseaux ad hoc et prsentons une analyse des protocoles qui ont
t proposs.

4.1 Classification des protocoles de gestion des cls dans les
MANETs

Les protocoles de gestion des cls peuvent tre classs de diffrentes faons [8]. Ils
peuvent tre regroups en deux grandes catgories : les systmes contributifs et les
systmes distributifs.
La catgorie distributive englobe les protocoles selon lesquels chaque cl provient d'un
seul nud. Les nuds peuvent trs bien cooprer au cours de la distribution des cls,
mais chacune delle provient d'une source unique.
Les systmes distributifs peuvent tre centraliss, ou distribus. Dans ce dernier cas,
chaque nud gnre une cl et essaie de la distribuer aux autres.
Dans les systmes contributifs, la cl est le rsultat d'un effort de collaboration de
plusieurs nuds. Cette classification reflte le mieux l'origine des cls dans les
protocoles tudis, et est illustre la Figure 4.1.

31

Figure 4. 1 : Classification des protocoles de gestion des cls dans les MANETs.

Les protocoles contributifs sont caractriss par l'absence d'un TTP charg de la
gnration et de la distribution des cls cryptographiques. Toutes les parties
communicantes cooprent pour mettre en place (c'est--dire "tomber daccord" sur) une
cl secrte symtrique. Le nombre de participants varie de deux parties (tablissement
d'une cl de paire) plusieurs parties (mise en place d'une cl de groupe).
Il existe beaucoup de protocoles contributifs, cependant un seul d'entre eux notamment
A-G a t conu spcifiquement en prenant en compte les rseaux ad hoc [8].
Les protocoles distributifs comportent une ou plusieurs entits de confiance et
comprennent la fois des protocoles cl publique et des protocoles cl symtrique.
En ralit les rseaux ad hoc exigent que l'entit de confiance puisse tre tablie de
manire impromptue pendant l'initialisation du rseau. Les protocoles cl publique
bass sur le certificat exigent des cls publiques qui seront distribues de manire
permettre au nud rcepteur de vrifier l'authenticit de la cl. Face cette exigence la
solution pour le rseau cbl est une PKI. Les protocoles cl publique bass sur
lidentit [9] reprsentent un nouveau type de protocole cl publique. Ils permettent
dutiliser les identits de lutilisateur comme des cls publiques. Toutefois, une entit de
confiance est ncessaire afin de gnrer et de distribuer les cls prives correspondant
aux diverses identits. L'entit de confiance est galement requise pour la rvocation, et
peut signer une liste didentits rvoques. Comme avec les systmes traditionnels cl
publique, il a t suggr d'tendre l'entit de confiance sur plusieurs nuds. Les

32

protocoles symtriques ont pour but de distribuer un ou plusieurs secrets partags
travers des canaux scuriss.

4.2 Les protocoles contributifs
Les principaux protocoles contributifs tudis dans le cadre de la gestion des cls dans
les MANETs sont les suivants : Diffie-Hellman (D-H), Ingemarsson, Tang and Wong
(ING), Hypercube and Octopus (H&O) et Password Authenticated key Agreement (A-
G).

4.2.1 DiffieHellman (D-H)
D-H [10] tablit une cl symtrique unique entre les deux parties. Il est bas sur le
calcul des logarithmes discrets et sur la difficult de ce calcul.
Les parties impliques sont d'accord sur un grand nombre premier p et un gnrateur g.
Chaque partie choisit au hasard un secret,
A
S et
B
S , et transmet les valeurs publiques,
p g
A
S
mod et p g
B
S
mod , comme indiqu sur la Figure 4.2. Lutilisateur A lve le
nombre reu de l'autre la puissance
A
S et lutilisateur B procde de la mme manire
avec
B
S . Le rsultat donne une cl secrte p g
B
S
A
S
mod , seulement partage par les
deux participants.

Figure 4. 2 : Fonctionnement du protocole D-H.

4.2.2 Ingemarsson, Tang, and Wong (ING)
ING [11] fournit une cl de groupe symtrique en tendant les deux participants du
protocole
D-H n participants. La Figure 4.3 montre les principes de fonctionnement avec quatre
nuds. Tous les nuds sont organiss en un anneau logique. Aprs n - 1 rounds, chaque

33

nud peut calculer la cl secrte. Chaque round comporte une exponentiation effectue
par chaque nud, et la valeur obtenue doit tre transmise au prochain nud dans
lanneau logique.

Figure 4. 3 : Fonctionnement du protocole ING.

4.2.3 Hypercube and Octopus (H&O)
H&O [12] permet de rduire le nombre de rounds et dexponentiations d'ING de n d
(
d
n 2 = ) en organisant les nuds dans un hyper cube, c'est--dire un cube d
dimensions. La Figure 4.4 illustre H&O dans un rseau avec quatre (
2
2 ) nuds. A
l'tape 1, les nuds 1 et 2 effectuent un accord de cls D-H. Les nuds 3 et 4 font de
mme. Les cls symtriques cres l'tape 1 sont utilises comme valeurs secrtes
dans un nouvel accord de cls D-H l'tape 2: les nuds 1 et 4 effectuent un accord de
cls D-H et les nuds 2 et 3 font de mme. H&O se compose en ralit de deux
protocoles: Hypercube et Octopus. Hypercube - illustr la Figure 4.4 - assume que le
nombre de participants est une puissance de 2. Octopus tend Hypercube pour permettre
un nombre arbitraire de nuds.

Figure 4. 4 : Fonctionnement des protocoles H&O et A-G.

34

4.2.4 Password Authenticated Key Agreement (A-G)
A-G [13] est le seul des protocoles contributifs tudis qui a t conu spcifiquement
pour les rseaux ad hoc. Fondamentalement A-G est H&O tendu avec authentification
par mot de passe, comme indiqu sur la Figure 4.4. Il assume que l'ensemble des
participants lgitimes a reu un mot de passe off-line. Les nuds doivent prouver la
connaissance du mot de passe lors de laccord de cls entre deux participants D-H du
protocole H&O. La Figure 4.4 montre laccord de cls entre deux nuds par mot de
passe authentifi. Le mot de passe est utilis pour crypter la valeur publique et aussi un
challenge initial dans un protocole challenge-response. A-G double le nombre de
messages et augmente la complexit du calcul compar H&O.

4.3 Les protocoles distributifs
Cette sous section tudie les protocoles distributifs de gestion de cls pour les systmes
cl publique et pour les systmes cl symtrique.

4.3.1 Les protocoles distributifs cl publique

Les principaux protocoles distributifs cl publique tudis dans le cadre de la gestion
des cls dans les MANETs sont les suivants : Partially Distributed Certificate Authority
(PDCA), Mobile Certificate Authority (MOCA), Secure and Efficient Key Management
(SEKM), Ubiquitous Security Support (UBIQ), Autonomous Key Management (AKM),
Self-Organized Key Management (PGP-A), Composite Key Management for Ad Hoc
Networks (COMP), Mobility-Based Key Management (MOB) et Identity-Based Public
Key (IBC-K).

4.3.1.1 Partially Distributed Certificate Authority (PDCA)
PDCA [14] suppose une PKI, et propose un cadre permettant de fournir une tolrance
permanente lintrusion, et des fonctionnalits robustes de CA pour les rseaux ad hoc.
La cl prive CA est rpartie sur un ensemble de nuds serveurs par l'intermdiaire d'un
(k, n) systme de partage secret [15]. La cl prive CA est partage entre n nuds de

35

manire ce que au moins k dentre eux doivent cooprer afin de la dvoiler. Trouver la
cl prive S de la CA revient trouver f (0), tant donn un polynme f (x) de degr k -
1, et sachant k valeurs, par exemple, f (1), f (2),, f (k). Interrog, chaque serveur
gnre une signature partielle du certificat en utilisant sa part de la cl prive dans un
systme de signature seuil [16]. Un serveur agissant en qualit de combinateur
recueille les signatures partielles valables et produit un certificat sign valide.
PDCA propose le rafrachissement de parts pour contrer les adversaires mobiles, c'est--
dire ceux qui compromettent temporairement un serveur, et par la suite attaquent le
prochain. Des systmes de partage secret proactifs [17] permettent aux actionnaires
(dtenteurs dune part) d'actualiser priodiquement leurs parts grce une collaboration.
Un adversaire doit ainsi compromettre plus de k parts entre les rafrachissements afin de
compromettre le systme. Seules les parts dtenues par les serveurs changent et pas le
secret original.
Si (
n
s s s ,..., ,
2 1
) est un (k, n) partage de S, (
n
a a a ,..., ,
2 1
) un (k, n) partage de A alors
(
n n
a s a s a s + + + ,..., ,
2 2 1 1
) est un partage secret de S + A [18]. Choisir A = 0 donne
un nouveau partage de S. Le systme est rendu robuste face aux absences de parts ou
leur invalidit par le biais d'un partage secret vrifiable [19]: une information extra
publique tmoigne de la justesse de chaque part, sans que cette dernire ne soit
divulgue. Bien que cela ne soit pas prcis, le systme s'appuie sur un distributeur
central de confiance pour amorcer le service de gestion de cls et dcider des nuds qui
doivent agir en tant que serveurs.
PDCA suppose un protocole de routage sous-jacent non scuris. Selon [14], les nuds
ne peuvent pas obtenir la cl publique des autres nuds ou tablir une communication
sre avec eux si le service CA est indisponible.
Chaque nud doit contacter la CA en vue d'obtenir ses certificats initiaux, et de recevoir
la cl publique de la CA. Il en est de mme si le nud, pour une raison quelconque, a
perdu sa cl prive ou a eu son certificat rvoqu. Toutefois, pour obtenir un nouveau
certificat, le nud doit tre authentifi par le service CA ce qui ncessite une forme de
contact physique entre le nud et la CA. Le certificat met jour les appels de service
CA. Le service CA est ncessaire pour la rvocation et la distribution des listes de
rvocation de certificats (CRLs).

36

4.3.1.2 Mobile Certificate Authority (MOCA)
MOCA [20, 21] est en fait une extension de PDCA [14]. L'accent est mis sur les
services CA distribus et sur la communication entre les nuds et les serveurs, c'est--
dire les autorits de certification mobiles (Mobile Certificate Authorities MOCAs).
Considrant que PDCA ne prcise pas la manire de slectionner les serveurs CA,
MOCA suggre que les nuds qui prsentent la meilleure scurit physique et des
ressources de calcul devront servir de MOCAs. Le systme MOCA, en outre, dplace
la fonction de combinateur de PDCA des serveurs CA vers le nud sollicitant.
L'avantage est lobtention dun systme moins vulnrable, puisque les nuds ne
dpendent plus de la disponibilit des serveurs CA pour combiner les signatures
partielles dun certificat. Un protocole de certification MOCA, MP, est propos pour
assurer une communication efficace entre les clients et les serveurs MOCAs. Selon MP,
les demandes de certificats doivent tre envoyes b MOCAs spcifiques qui, partir
dentres fraches de routage ou dune courte distance, sont susceptibles d'tre
accessibles. Avec un systme seuil (k, n), k MOCAs sont requis pour remplir un
service de certification. Pour accrotre la probabilit de recevoir au moins k rponses : b
= k + a. Quand la disponibilit baisse, le protocole est analogue PDCA. Il est suppos
que MP tient jour ses propres tables de routage et co-existe avec un protocole de
routage ad hoc standard.

4.3.1.3 Secure and Efficient Key Management (SEKM)
SEKM [22] suggre essentiellement que les serveurs de MOCA forment un groupe
multicast. L'objectif est la mise jour efficace de parts secrtes et de certificats. Un
nud diffuse une demande de certificat au groupe de serveurs CA. Le premier serveur
qui reoit la demande gnre une signature partielle, et transmet la demande aux k + a
serveurs supplmentaires. Seules k signatures partielles sont requises. Les autres sont
pour la redondance dans le cas o certaines sont perdues ou endommages. SEKM
n'indique pas la faon dont un serveur peut affirmer qu'il est le premier recevoir la
demande de rafrachissement et lancer les k + a expditions. Dans l'ensemble, SEKM
a les mmes caractristiques que MOCA.


37

4.3.1.4 Ubiquitous Security Support (UBIQ)
UBIQ [23] est un systme CA seuil entirement distribu. Similaire aux protocoles
CA partiellement distribus PDCA, MOCA, et SEKM, il s'appuie sur un systme de
signature seuil avec un partage secret (k, n) de la cl prive CA. A la diffrence des
systmes CA partiellement distribus, tous les nuds obtiennent une part de la cl
prive CA. Une coalition de k voisins dun saut forme une CA locale. Il ne ncessite pas
de protocole de routage sous-jacent. La mobilit peut aider trouver le nombre requis
de nuds CA.
UBIQ prescrit le rafrachissement de parts. Quand ils reoivent un certificat valable, les
nuds gagnent la confiance en l'ensemble du rseau. Tout nud titulaire d'un certificat
peut obtenir une part de la cl prive CA. Une nouvelle part secrte est calcule en
ajoutant les parts partielles reues partir d'une coalition de k voisins. Les premiers
nuds reoivent leurs certificats auprs d'un distributeur avant de rejoindre le rseau.
Aprs que k nuds aient t initialiss, le distributeur est supprim. La rfrence [24]
propose plusieurs parts par nud pour russir avec moins de k voisins. Rpartir les
fonctionnalits CA renforce la disponibilit des parts de la cl prive. Toute entit
capable de collecter k parts ou plus peut reconstituer la cl prive CA. Comme tout
systme cl publique se fondant sur une entit de confiance, il n'est pas facile de
modifier la paire de cls CA prive / publique durant l'opration.
Dans [25], il est avanc que UBIQ peut succomber une attaque Sybil [26] o un seul
nud prend plus d'une identit. Avec lauthentification off-line des nouveaux nuds et
les certificats servant de preuve de fiabilit, ce nest gure une menace raliste [8]. Une
rvocation sre et efficace reste un dfi non rsolu.

4.3.1.5 Autonomous Key Management (AKM)
AKM [18] fournit une auto organisation et une CA seuil entirement distribue. Avec
quelques nuds dans le rseau, le systme est analogue UBIQ. Chaque nud reoit
une part de la cl prive CA. Comme le nombre de nuds augmente, une hirarchie de
parts de la cl est mise en place. Les nouveaux nuds reoivent alors une part de la part
de la cl prive CA dj reue par les nuds participant leur initialisation. La paire de
cls CA publique / prive racine est amorce par un groupe de nuds voisin travers le

38

partage secret vrifiable distribu [27]: chacun des n voisins choisit une valeur secrte
i
S , et distribue des parts secrtes de celle-ci aux autres voisins en utilisant un systme
de partage secret (k, n). Lauthentification off-line est ajoute. La somme des valeurs
secrtes individuelles S correspond la cl prive CA.

) ... (
3 2 1 n
S S S S S + + + + = (1)
La cl publique CA correspondante est gale
S
g . En supposant que les nuds
publient les valeurs publiques individuelles,
i
S
g , la cl publique peut tre dduite sans
rvler la cl prive CA en multipliant les valeurs individuelles.

n
S
S S
S
g g g g * ... * *
2 1
=
(2)

Avec moins de k nuds, il ya trop peu de nuds pour fournir le service CA. Les
certificats signs avec les cls rgionales ont moins d'assurance que ceux signs avec la
cl CA. Un certificat de haute assurance exige des signatures partielles de nuds dans
diffrentes rgions. Ce systme suppose que le rseau volue partir de nuds qui ont
lanc le service AKM.
En AKM, chaque nud maintient une liste de rvocation de certificats CRL. AKM ne
spcifie pas une large diffusion rseau concernant les informations de rvocation. Un
certificat est rvoqu lorsque au moins k voisins ont affich des accusations contre lui.
D'un point de vue scuritaire, on peut se demander dans quelle mesure un certificat
sign par la cl prive CA devrait tre rvoqu par un groupe dtenant une seule part de
celle-ci. Les nuds sont supposs se dissocier dune rgion et s'associer avec une
nouvelle lorsqu'ils se dplacent d'une rgion du rseau vers une autre. Implicitement, les
nuds doivent maintenir une vue de la hirarchie de cls et tre en mesure de dtecter
les frontires rgionales. Avec les nuds mobiles et l'instabilit des liens, la manire de
mettre cela en uvre nest pas vidente [8]. Le systme exige des nuds de collaborer
sur des modifications dans les rgions et sur la hirarchie de cls. Les nuds malicieux
ou dfectueux peuvent retarder ces oprations.


39

4.3.1.6 Self-Organized Key Management (PGP-A)
Dans [25], Capkun, Buttyn et Hubaux proposent le protocole PGP-A de gestion de cls
entirement auto-organis. Cest un systme PGP [28] adapt aux rseaux ad hoc. La
fonctionnalit CA est entirement distribue. Tous les nuds ont les mmes rles. Ils
gnrent leur propre paire de cls prive / publique et dlivrent des certificats pour les
nuds envers qui ils ont confiance. Les certificats sont stocks dans les nuds plutt
que dans des dpts centraliss. PGP-A suppose que la confiance est transitive.
Les nuds fusionnent leurs dpts de certificats, et tentent de trouver une chane
vrifiable de certificats. Lalgorithme Maximum Degree algorithm est propos pour
construire un graphe de certificats avec une haute connectivit, mme si les tailles des
dpts de certificats des utilisateurs sont petites en raison du phnomne small world,
disant que tout le monde peut tre atteint par une courte chane de connaissances
sociales.
Les certificats sont rvoqus grce des messages de rvocation venant de leur
metteur, ou sont implicitement rvoqus l'expiration. Les renouvellements exigent
des contacts avec l'metteur. Les certificats sont galement changs priodiquement
entre les nuds voisins. Lvaluation des dates d'expiration et des changes priodiques
exige une sorte de synchronisation entre les nuds.
PGP-A implicitement requiert un protocole de routage dj en cours d'excution. La
confiance pourrait tre tablie par le biais de contacts physiques. Toutefois, l'interaction
humaine afin de garder le service rseau en cours dexcution, nest pas souhaitable. Le
comportement malicieux ou la dfectuosit des nuds nempche pas les autres nuds
d'changer des certificats. Un nud compromis divulgue uniquement les cls quil
dtient. Tout de mme, un nud compromis pourrait tre utilis pour dlivrer des
certificats permettant d'autres nuds illgitimes d'accder au rseau.
Il n'y a qu'une garantie probabiliste que la chane de confiance puisse tre trouve entre
les parties qui souhaitent communiquer. D'autre part, la transitivit de la confiance,
combine la dpendance l'gard du phnomne small world, implique que tout le
monde va vite finir par faire confiance tous. Le rsultat est la non rsistance
lintrusion. Une alternative serait de limiter le nombre maximum de sauts, et de

40

permettre aux nuds de diffrencier le niveau de confiance qu'ils placent sur les
diffrents certificats, comme il est suggr dans COMP [29].

4.3.1.7 Composite Key Management for Ad Hoc Networks (COMP)
COMP [29] combine la CA seuil partiellement distribue de MOCA [20, 21] avec le
chanage de certificats de PGP-A [25]. L'objectif est de procurer une scurit renforce
avec PGP-A, et daccrotre la disponibilit du service CA par rapport au systme
MOCA. Les nuds qui ont t certifis par la CA sont autoriss dlivrer des
certificats d'autres. Les nuds demandant un service de certification doivent d'abord
essayer les CA MOCA. En cas d'chec, ils doivent chercher des voisins qui ont t
certifis par la CA. Selon la configuration, les nuds avec de longues chanes de
certificats vers la CA peuvent galement tre autoriss dlivrer des certificats
d'autres. Chaque certificat dans COMP inclut une valeur de confiance qui reflte le
niveau de confiance que lmetteur de certificats accorde la liaison entre l'identit du
nud et la cl (0 = pas confiance, 1 = pleine confiance). La multiplication des valeurs
de confiance, donne une mesure du niveau de confiance dans une chane de certificats.
Les courtes chanes de certificats sont gnralement prfres aux longues. La
probabilit davoir dans la chane un ou plusieurs nuds compromis crot lorsque la
longueur de la chane augmente.
Similaire PGP-A, COMP suppose la transitivit du niveau de confiance. Les valeurs
de confiance permettent une fine valuation de la confiance, et les nuds n'ont pas
faire pleinement confiance la CA. Toutefois, la conclusion d'un bon niveau de
confiance est difficile. COMP n'indique pas comment les metteurs de certificats
devraient accomplir cette tche. Les nuds malicieux ou compromis peuvent dans
certains cas affecter la pleine confiance des nuds non fiables. Nanmoins, la
tolrance lintrusion saccrot par rapport au pur systme PGP-A, puisque COMP
limite la longueur maximale des chanes de certificats.
Lauthentification off-line inclut typiquement l'interaction humaine. Linteraction avec
un voisin est moins exigeante compar UBIQ qui exige la participation de plusieurs
voisins.

41

La rvocation n'est pas traite dans COMP. Il est raisonnable que le nud qui a mis un
certificat soit en droit de le rvoquer. Mais donner des nuds ordinaires lautorisation
de rvoquer les certificats mis par la CA uniquement parce quils dtiennent un
certificat sign par la CA rend le systme vulnrable aux nuds malicieux ou
compromis. Le fait de permettre un seul nud de dlivrer des certificats est en
contradiction avec la rsolution CA distribue.
Une recherche de voisins certifis par la CA dans le but d'obtenir un premier certificat
ncessite la connaissance de la cl publique CA. Ainsi, un certain moment, il doit
exister un canal authentifi entre le nud cherchant et la CA. Le premier canal
authentifi est obtenu par le biais du contact physique, do une courte porte ct
canal.

4.3.1.8 Mobility-Based Key Management (MOB)
MOB [30, 31] cherche imiter le comportement humain: si des utilisateurs veulent
communiquer de manire scurise, ils ont juste se rapprocher les uns des autres afin
d'changer des informations. Des associations de scurit sont tablies entre les paires
de nuds qui sont proches. Le systme peut tre entirement auto organis (self-
organising) comme MOB-so, ou se prvaloir d'une autorit autonome (off-line
authority) dans le cas de MOB-a. MOB-so peut donc tre fond sur des cls
symtriques ou publiques. MOB-a est intrinsquement bas sur la cl publique. Une
diffrence majeure entre MOB-a et MOB-so rside au niveau de l'implication humaine.
Dans MOB-so, les utilisateurs doivent authentifier physiquement la paire communicante
avant d'tablir une association de scurit. Les rfrences de scurit - les triplets - sont
ensuite changes via une connexion scurise courte porte ct canal. Les triplets
incluent lidentifiant de lutilisateur, la cl et l'adresse du nud. Les nuds signent et
changent galement une dclaration qui prouve quune association de scurit a t
mise en place entre les deux.
MOB-so accepte un niveau de transitivit de la confiance: des associations de scurit
peuvent tre tablies grce des amis. C'est--dire, les nuds qui ont tabli des
associations de scurit avec les deux nuds en question. MOB-a suppose des
certificats pr distribus et suggre que l'change des rfrences de scurit soit restreint

42

au voisinage dun saut. Dans MOB-so et MOB-a, seules les cls dtenues par le nud
spcifique sont compromises lorsqu un nud est captur. Les nuds malicieux ou
dfectueux n'empchent pas les autres d'changer des rfrences de scurit. Lautorit
autonome suppose par MOB-a n'implique pas de rvocation. Les auteurs suggrent que
les nuds compromis doivent rvoquer leurs propres certificats. Cependant, il peut tre
difficile de savoir si une compromission a eu lieu ou non.
La rvocation par soupon reprsente une vulnrabilit. Elle peut constituer une menace
pour la disponibilit. Par ailleurs, si le nud a t captur, il ne peut plus fonctionner
selon le protocole.

4.3.1.9 Identity-Based Public Key (IBC-K)
La cryptographie base sur lidentit [9], introduite par Shamir, supprime le besoin de
certificats. Les identits sont gnralement courtes, du moins par rapport aux certificats
avec une taille de plusieurs kilobits. En supposant que les informations qui sont
transfres par dfaut dans les messages de routage puissent tre utilises comme cls
publiques, les protocoles bass sur lidentit peuvent avoir une extensibilit meilleure
compars aux approches bases sur le certificat traditionnel. Cela rend les protocoles
bass sur l'identit intressants en ce qui concerne la bande passante limite des rseaux
ad hoc.
Shamir construit un systme de signature base sur lidentit IBS (Identity-based
signature). Pour vrifier une signature, il suffit de connatre l'identifiant de l'expditeur
ainsi que les paramtres publics du systme. Les paramtres publics du systme sont
dfinis par le gnrateur de cls prives PKG (Private Key Generator) pendant la mise
en place du systme. Les paramtres publics du systme comprennent la cl publique du
PKG et les informations sur l'espace du message. Le PKG gnre galement les cls
prives de signature correspondant l'identifiant de lutilisateur. Pendant la phase
d'installation (setup phase), le PKG choisit une cl secrte master key et gnre les
paramtres publics du systme correspondant. Ensuite, dans la phase d'extraction, il
dlivre les cls prives. Les cls prives sont uniquement donnes par les identifiants et
le master key du PKG. Plusieurs systmes IBS sont proposs par la suite. Quelques
exemples sont trouvs dans [32-34]. Boneh et Franklin [35] introduisent le premier

43

systme pratique de chiffrement bas sur lidentit IBE (Identity-based encryption). Ce
systme a ensuite t tendu par Lynn [36] pour fournir lauthentification de message,
sans frais supplmentaires. Le texte chiffr se sert de code d'authentification de
message.
Le PKG reprsente un point de dfaillance. Si la cl prive master key du PKG est
compromise, l'ensemble du systme est compromis. Pour contrer cette tendance, Boneh
et Franklin [35] proposent la diffusion de la cl master key du PKG sur plusieurs lieux
en utilisant la cryptographie seuil. Khalili, Katz, et Arbaugh [37] ont propos une
technique de gestion de cls (IBC-K) pour les rseaux ad hoc combinant la
cryptographie base sur lidentit avec la cryptographie seuil [16]. Les nuds qui
initialisent le rseau ad hoc forment un seuil PKG, diffusant la cl prive PKG master
key sur lensemble initial de nuds par un systme seuil (k, n). Ceci limine le PKG
qui est le seul point de dfaillance, et augmente la tolrance lintrusion. Cela rend le
service robuste dans le sens o un adversaire doit compromettre un minimum de k
nuds afin de rcuprer la cl secrte master key. Cela rduit galement la vulnrabilit,
puisque le service est disponible aussi longtemps que k nuds PKG se comportant
correctement sont proches.
Afin de recevoir la cl prive correspondant une certaine identit, un nud doit
prsenter son identit k (ou plus) des n nuds PKG. Le nud reoit une part de la cl
prive venant de chacun d'eux. Grce k parts correctes, le nud peut ensuite calculer
sa cl prive personnelle. Toutefois, l'authentification off-line et mutuelle est dans tous
les cas ncessaire entre les nuds entrants et un quelconque nud PKG dlivrant une
cl prive ou une part de la cl. Un canal scuris est ncessaire cet effet. Cela
implique un contact physique ou un canal de communication ddi courte porte.
La connectivit multi sauts n'est pas assez bonne; elle permettrait lcoute passive
indiscrte ainsi que des attaques de type man-in-the-middle. Lorsque le temps est limit,
l'interaction physique avec un nombre de nuds PKG gographiquement distribus n'est
pas une bonne solution. La rvocation de cls explicite reste un problme non rsolu. Il
n'est pas facile de distribuer des listes de rvocation (retirer les identifiants) et de
sassurer que tous les nuds sont informs. Une autre alternative consiste changer le
master key du PKG et les paramtres systme. Toutes les cls prives sont calcules

44

partir de ces paramtres. Essentiellement, une mise jour de la cl PKG rend obsoltes
toutes les cls dans le systme.

4.3.2 Les protocoles distributifs cl symtrique

Les principaux protocoles distributifs cl symtrique tudis dans le cadre de la
gestion des cls dans les MANETs sont les suivants : Preshared Group Key (PSGK),
Simple Key Management Protocol (SKiMPy), Self-Healing Session Key Distribution (S-
HEAL) et Logical Key Hierarchy (LKH)

4.3.2.1 Preshared Group Key (PSGK)
C'est un vieux protocole de gestion de cls avec un KDC (Key Distribution Center) pr
distribuant une cl symtrique tous les membres du groupe. Un KDC peut galement
fournir des cls uniques pour deux parties, mais ici l'accent est mis sur les cls de
groupe. La cl symtrique de groupe peut tre utilise pour "signer" les informations de
routage avec une somme de contrle cryptographique qui est un code d'authentification
de message (MAC). PSGK manque de tolrance lintrusion dans le sens o la scurit
succombe un seul nud captur. Mais si la politique de scurit le permet, il s'agit
d'une solution simple. En supposant un KDC off-line et des cls pr distribues, le
protocole prsente une bonne extensibilit. Il est l'abri des nuds dfectueux et
malicieux. L'authentification off-line doit tre ajoute. Avec une seule cl de groupe, il
nest pas facile dexclure les nuds compromis. PSGK n'a pas t conu spcialement
pour les rseaux ad hoc. Elle est incluse ici car plusieurs des protocoles symtriques
tudis reprsentent essentiellement des extensions ce protocole.

4.3.2.2 Simple Key Management Protocol (SKiMPy)
SKiMPy [38] cherche tablir une cl symtrique tendue pour la protection des
informations de routage de la couche rseau ou des donnes utilisateurs de la couche
application. Lors de linitialisation du MANET, tous les nuds gnrent une cl
symtrique alatoire et la passent en annonce dans les voisinages dun saut par le biais
de messages hello messages . La meilleure cl (par exemple celle qui a le plus faible

45

numro didentifiant, etc.), est choisie comme tant la cl de groupe locale. Elle est
transmise aux nuds ayant de moins bonnes cls par le biais d'un canal scuris tabli
l'aide de certificats pr distribus. La procdure est rpte jusqu' ce que la "meilleure"
cl ait t partage avec l'ensemble des nuds du MANET.
Une fois tablie, la cl de groupe sert de preuve de fiabilit. SKiMPy propose des mises
jour priodiques de cette cl de groupe pour contrer la cryptanalyse. Les cls mises
jour sont drives de la cl de groupe initiale. Un protocole de routage dj en cours
d'excution nest pas ncessaire, puisque linformation cl est change seulement entre
voisins. SKiMPy implique un dlai pour rpandre la meilleure cl vers tous les nuds.
Pourtant, lactuelle meilleure cl locale peut tre utilise pour communiquer de manire
scurise jusqu' ce que la "dernire" cl soit reue.
Les nuds malicieux ou dfectueux peuvent perturber laccord de cls locale, par
exemple en annonant une cl meilleure, mais sans rpondre. Les auteurs indiquent que
les entits ayant des fonctions ou des grades pourraient tre habilites administrer les
certificats.
Toutefois, la rvocation on-line n'est pas possible avant que le rseau ait t initialis.
Comme le rseau est initialis, la cl de groupe symtrique est galement mise en place.
Une fois que la cl symtrique a t reue, il n'existe pas de moyen efficace pour
exclure le nud de toute participation ultrieure. La cl de groupe (ou une cl drive
de celle-ci) sert maintenant comme preuve de fiabilit. Ainsi, SKiMPy augmente la
complexit par rapport PSGK, en consquence il ne renforce pas la scurit.

4.3.2.3 Self-Healing Session Key Distribution (S-HEAL)
S-HEAL [39] est un protocole de distribution de cls de groupe symtriques avec la
rvocation, conu pour les rseaux avec des liens peu fiables. Le concept exige des
secrets pr partags et un gestionnaire de groupe qui diffuse la cl de groupe actuelle K
"masque" par un polynme h (x), donne par f (x) = h (x) + K. Les secrets individuels
h (i) sont pr distribus (i renvoie lidentifiant du nud). Chaque nud membre peut
alors extraire la cl en cours en valuant l'expression reue en x = i et en soustrayant la
valeur secrte: f (i) - h (i) = K.
La rvocation est permise en remplaant le polynme h (x) avec un polynme bivariant

46

s (x, y). Le gestionnaire de groupe diffuse maintenant la cl actuelle K masque comme
f (N, x) = s (N, x) + K. Afin dextraire la cl, les nuds doivent d'abord rcuprer le
polynme s (x, i), et l'valuer par rapport s (N, i). Ensuite, ils doivent soustraire le
rsultat obtenu partir de s (N, x) + K, valu par rapport x = i K = f (N, i) - s (N, i).
L'ide est que seuls les nuds non rvoqus doivent tre en mesure de rcuprer le
polynme s (x, i). Etant donn s de degr t, t + 1 valeurs sont ncessaires afin de trouver
s (x, i). La valeur N et les secrets individuels, s (i, i) sont prs distribus. Les autres t
valeurs, s (r1, x), s (r2, x) s (rt, x) qui sont ncessaires pour rvler s (x, i) sont
intgres dans le message de mise jour de cls du gestionnaire de groupe. Si les nuds
rvoqus sont inclus dans l'ensemble (r1, r2 rt), ces nuds vont seulement acqurir t
des t + 1 valeurs requises. En consquence, ils ne seront pas en mesure d'extraire la
nouvelle cl de groupe.
La dpendance de S-HEAL vis--vis du gestionnaire de groupe pour fournir la cl de
groupe initiale le rend inapplicable pour la protection des informations de routage. La
cl de groupe est ncessaire l'amorage du service rseau, mais S-HEAL demande un
service rseau dj en cours d'excution pour distribuer la cl de groupe.
Nanmoins, S-HEAL peut potentiellement tre utilis pour la rvocation et la
modification de la cl, en supposant quun service rseau protg ait t amorc avec
une cl de groupe initiale pr distribue (PSGK). Il aurait permis d'amliorer la
tolrance l'intrusion compar au pur PSGK. La rsistance face aux pertes de paquets
pourrait tre renforce en retransmettant priodiquement la dernire mise jour de cls
plutt que d'attendre la prochaine mise jour de cls, comme le laisse entendre [39].

4.3.2.4 Logical Key Hierarchy (LKH)
Les cls de groupe peuvent tre mises jour par force brute; le gestionnaire du groupe
distribue la nouvelle cl de groupe, crypte avec une cl spare (individuelle) pour
chaque nud. En substance, LKH reprsente une famille de protocoles qui amliorent
l'extensibilit de cette mthode de force brute, en organisant les cls dans une hirarchie
logique et en donnant aux nuds des cls supplmentaires. LKH a t prsent par
Wong, Gouda, et Lam [40] et Wallner, Harder, et Agee [41]. Son principe de
fonctionnement est illustr la Figure 4.5.

47

Figure 4. 5 : Logical key hierarchy.

Tous les membres du groupe (N1-N8) possdent la cl de groupe
12345678
K . La cl de
sous groupe
1234
K est partage par les membres N1-N4, et
12
K est commune N1 et
N2.
8 1
K K fait rfrence aux cls individuelles. En supposant que le nud N8 doit
tre rvoqu, l'ensemble des cls de groupe et de sous-groupe connues pour N8
(
12345678
K ,
5678
K ,
78
K ) devrait tre mis jour. N7 partage toutes les cls
intermdiaires de la feuille la racine avec N8. N7 doit donc recevoir les cls mises
jour cryptes avec sa cl individuelle. Les nouvelles cls de groupe et de sous-groupe
peuvent tre distribues N5 et N6 chiffre avec leur cl en commun:
56
K . N1-N4,
le gestionnaire de groupe envoie la nouvelle cl de groupe
1234567
K crypte avec
1234
K . Ainsi, la bande passante et le cot de calcul sont pargns comparativement aux
mises jour cryptes avec les cls individuelles. Larbre de cls peut tre binaire ou k-
aire, et quilibr ou dsquilibr.
LKH peut prsenter un intrt en tant qu'extension de PSGK des fins de rvocation.
En supposant que le service rseau a t initialis (avec l'aide de la cl de groupe pr
distribue); LKH peut tre utilis pour exclure les nuds compromis.


48

V. ANALYSE DES PROTOCOLES DE
GESTION DES CLES DANS LES
RESEAUX AD HOC

Pour mener bien cette analyse nous dfinissons dabord un ensemble de critres qui
sont utiliss par la suite pour valuer les protocoles tudis dans la section prcdente.

5.1 Critres dvaluation des protocoles

Nous avons identifi les caractristiques suivantes concernes par l'valuation des
protocoles de gestion des cls pour l'environnement ad hoc [8]: applicabilit, scurit,
robustesse et extensibilit.

Applicabilit
Elle se rfre la possibilit de mettre en pratique les protocoles de gestion des cls
tudis dans lenvironnement des MANETs. Elle dpend des hypothses fondamentales
telles que la nature du rseau (planifi ou rellement ad hoc), la taille du rseau, la
mobilit des nuds, la porte gographique et le niveau requis de l'implication humaine.
Scurit
L'authentification et la tolrance lintrusion constituent une proccupation de premier
plan pour empcher aux nuds non autoriss de recevoir les principaux lments qui
peuvent ensuite tre utiliss pour prouver le statut de membre lgitime du rseau.
Personne ne doit fournir des cls prives ou dlivrer des certificats d'autres, moins
que ceux-ci naient t authentifis.
La tolrance lintrusion signifie que le systme de scurit ne doit pas succomber un
seul ou un petit nombre de nuds compromis. Les autres questions centrales de scurit
sont la gestion de la confiance et la vulnrabilit. Les relations de confiance peuvent

49

changer au cours de la dure de vie du rseau. Le systme doit permettre l'exclusion des
nuds compromis. Afin de juger de la scurit d'un systme de gestion de cls, les
vulnrabilits ventuelles doivent tre indiques prcisment. Les longueurs des cls
cryptographiques et les algorithmes d'une solidit suffisante sont pris en charge.
Robustesse
Le systme de gestion des cls doit survivre malgr les attaques par dni de service et
les nuds indisponibles. Les oprations de gestion de cls doivent pouvoir tre
acheves en dpit des nuds dfectueux et de ceux prsentant un comportement
malicieux, c'est--dire ceux qui s'cartent dlibrment du protocole. Les oprations
ncessaires de gestion de cls causes par des changements dynamiques de groupe
doivent sexcuter en temps voulu. Les oprations de gestion de cls ne doivent pas
exiger un rseau tendu et la stricte synchronisation.
Extensibilit
Les oprations de gestion de cls doivent se terminer dans les dlais malgr un nombre
variable de nuds et leur densit.

5.2 Evaluation des protocoles de gestion des cls dans les
MANETs

Le service idal de gestion de cls pour les rseaux ad hoc doit:
tre constitu la vole, ne jamais exposer ou distribuer les cls
cryptographiques aux nuds non autoriss ;
veiller ce que la scurit du systme ne succombe pas face un petit nombre
de nuds compromis ;
permettre la mise jour facile de cls et leur rinitialisation ;
permettre le retrait de cls, lorsque les nuds sont compromis ou des cls
doivent tre rvoques pour dautres raisons ;
tre robuste face aux nuds malicieux et dfectueux ;
assez bien voluer pour manier les tailles de rseau attendues et les densits de
nuds, et grer efficacement les scissions et les raccordements de rseau.

50

5.2.1 Evaluation des protocoles contributifs
Les capacits des diffrents protocoles contributifs sont dcrites ci-dessous

Applicabilit
Tous les protocoles contributifs sadaptent bien avec l'environnement ad hoc, dans le
sens o ils sauto organisent.

Scurit
La scurit de tous les protocoles contributifs repose sur le problme du logarithme
discret.
Toutefois, le problme du logarithme discret naide pas lorsqu'il existe d'autres failles de
scurit comme c'est le cas de D-H, ING et H&O. En effet aucun deux ne considre
l'authentification. Les cls tablies par ces protocoles ne peuvent pas tre utilises pour
diffrencier les nuds lgitimes (dignes de confiance) et illgitimes d'un rseau ad hoc.
Leurs concepteurs ont laiss des proprits de scurit comme l'authentification, tout en
mettant l'accent sur les changements de groupe, mais font valoir que l'authentification
pourrait facilement tre ajoute. A-G est le seul qui montre comment prendre en
considration l'authentification tout en restant un vritable protocole contributif. Le
systme d'authentification de A-G exige que tous les nuds se runissent dans la
gamme du canal emplacement limit utilis pour distribuer le mot de passe.
Cependant, le mot de passe peut aussi tre pr distribu dans le cas d'un rseau ad hoc
planifi.
Les protocoles contributifs noffrent pas de tolrance lintrusion. Quand un nud est
captur par un adversaire, la cl de groupe est compromise et la scurit choue.
Cependant on peut dire que D-H offre une forme de tolrance lintrusion dans le sens
o il sagit dun protocole deux participants. La compromission dun nud
compromet seules les cls entre ce nud et les paires communicantes. Les cls entre les
autres nuds ne sont pas dvoiles.
Avec labsence dentits de confiance dans les protocoles contributifs il est
gnralement laiss au nud de juger qui faire confiance.

51

Avec labsence dauthentification D-H, ING et H&O sont vulnrables aux attaques
man-in-the-middle. ING est vulnrable lcoute clandestine puisquil est possible de
calculer la cl partir des informations changes entre les nuds [54]. Tous les
protocoles reposant sur une organisation spcifique des nuds sont vulnrables aux
attaques contre le systme dorganisation et aux attaques DoS lances en direction dun
quelconque nud durant ltablissement de cls.

Robustesse
Les protocoles contributifs manquent de rsistance face au comportement malicieux et
la dfectuosit des nuds. Aucun des protocoles contributifs ne sattaque pas la
manire de grer les failles et les nuds qui ne se comportent pas conformment au
protocole.
Les protocoles contributifs visant tablir une cl de groupe ncessitent un changement
de la cl pour adjoindre de nouveaux membres. Tel est aussi le cas lorsquil sagit
dexclure un ancien membre puisquil nexiste pas dautres moyens pour rvoquer ou
remplacer les anciennes cls.

Extensibilit
De manire gnrale les protocoles contributifs offrent une pauvre extensibilit. Comme
il a t dj soulign larrive de nouveaux membres dans le groupe nest pas facilement
gr puisquil engendre un changement de la cl de groupe.
Les capacits des diffrents protocoles contributifs sont rsumes dans le Tableau 5.1.


52

Tableau 5. 1: Rsum de lvaluation des protocoles contributifs

D-H ING H&O A-G
Applicabilit
Rseau Auto
organis
Auto
organis
Auto
organis
Auto
organis

Scurit
Authentification Non Non Non Mot de
passe
Tolrance
lintrusion
Oui Non Non Non
Gestion de la
confiance
Nuds Non Non Organisateur

Vulnrabilits

MIM
Organisation
de nuds,
MIM,
nuds
malicieux
Organisation
de nuds,
MIM,
nuds
malicieux
Organisation
de nuds,
nuds
malicieux
Robustesse
Nuds
malicieux et
dfectueux
Oui Non Non Non
Changements
de groupe
Non
adress
Changement
de cl
Changement
de cl
Changement
de cl
Extensibilit
Non
adresse
Pauvre Pauvre Pauvre

5.2.2 Evaluation des protocoles distributifs
Les capacits des protocoles distributifs cl publique et de ceux cl symtrique
tudis sont dcrites ci-dessous.
5.2.2.1 Evaluation des protocoles distributifs cl publique
Applicabilit
PDCA, MOCA, SEKM et UBIQ ncessitent tous une CA racine pour amorcer le
systme de gestion de cls et sont ainsi appropris aux rseaux ad hoc planifis. AKM,
PGP-A fournissent des systmes de gestion de cls entirement auto organiss en
distribuant entirement les fonctionnalits CA et en permettant aux nuds dassurer eux
mme lamorage du systme de gestion de cls. MOB peut tre utilis pour les

53

systmes entirement auto organiss (MOB-so) ou pour ceux planifis (MOB-a). IBC-K
rend les certificats obsoltes en maintenant les bnfices des systmes cl publique
dans un rseau ad hoc planifi/auto organiss.
COMP combine PGP-A et MOCA. Ce qui fait son applicabilit pour les rseaux ad hoc
planifis/auto organis.

Scurit
Une fois les certificats dlivrs, ceux-ci sont utiliss par les nuds pour
lauthentification. Dans IBC-K les signatures par cl prive servent de la mme
manire. Cependant les nuds doivent aussi tre authentifis avant lobtention du
certificat initial ou avant que la cl prive ne soit reue.
PDCA, MOCA, SEKM, UBIQ et AKM proposent tous un cadre permettant de fournir
une tolrance lintrusion et des fonctionnalits CA robustes pour les rseaux ad hoc en
sappuyant sur un systme seuil CA distribu, c'est--dire un systme dont la cl
prive CA est distribue aux nuds suivant un seuil k bien dfini. Leurs systmes de
scurit reposent sur la non rvlation de la cl prive CA. Avec les systmes seuil
proposs plus de k nuds doivent tre compromis ou doivent collaborer dans le but de
rvler la cl prive CA. De manire similaire IBK-C rpartit le master key du PKG sur
plusieurs nuds des fins de tolrance lintrusion. Cependant il ya une insuffisance
avec IBK-C compar aux protocoles traditionnels cl publique. Les cls prives sont
donnes de manire dterministe par lidentifiant et la cl prive master key du PKG.
Un adversaire capable de collecter plusieurs cls prives, par exemple en
compromettant plusieurs nuds ou en prsentant de nombreux identifiants, peut russir
la cryptanalyse de la cl prive master key du PKG. MOB (MOB-so, MOB-a) fournit
galement une bonne tolrance lintrusion car seules les cls dtenues par le nud
spcifique sont compromises lorsque le nud est captur. Dans PGP-A il ny a pas de
systme global de protection. Un nud compromis peut tre utilis pour dlivrer des
certificats permettant ainsi dautres nuds illgitimes daccder au rseau. PGP-A
offre alors une tolrance lintrusion limite. COMP renforce la scurit de PGP-A et
augmente la tolrance lintrusion en combinant PGP-A et MOCA.

54

Dans PGP-A il est laiss chaque nud de juger qui faire confiance et qui dlivrer
un certificat. Chaque nud surveille les graphes de certificats dans le but de dvoiler
tous les certificats conflictuels par exemple les certificats faisant correspondre une cl
publique diffrents identifiants ou plusieurs cls au mme identifiant. Il est toutefois
laiss au nud de juger quelle information se fier. Dans COMP la gestion de la
confiance est assure par la CA et les nuds certifis CA. Les nuds qui ont t
certifis par la CA sont autoriss dlivrer des certificats dautres. Cependant les
nuds demandant un service de certification doivent dabord essayer les CA MOCA.
Selon la configuration les nuds avec de longues chanes de certificats vers la CA
peuvent galement tre autoriss dlivrer des certificats dautres. En fait dans
COMP chaque certificat inclut une valeur de confiance qui reflte le niveau de
confiance que lmetteur de certificats accorde la liaison entre lidentit du nud et la
cl. MOB, plus prcisment MOB-so, laisse la gestion de la confiance aux nuds. Les
utilisateurs doivent authentifier physiquement la paire communicante avant dtablir
une association de scurit. Les nuds signent et changent galement une dclaration
qui prouve quune association de scurit a t mise en place entre eux. MOB-so
accepte un niveau de transitivit de la confiance. MOB-a suppose des certificats pr
distribus et ne prcise pas qui gre la confiance. Dans les autres protocoles la gestion
de la confiance est assure par les nuds CA/PKG rpartis. Cependant aucun de ces
protocoles ne dtaille le processus de gestion de la confiance.
Dans PDCA il nest pas prcis comment les serveurs choisissent qui doit agir en tant
que combinateur. Tout serveur jouant le rle de combinateur est un point de
vulnrabilit. UBIQ, qui sappuie sur les identifiants pour lauthentification est
vulnrable aux attaques capables dusurper les identits. Dans AKM lorsque le nombre
de dactionnaires dans une rgion quelconque atteint le niveau spcifique, la rgion est
divise. Il ya alors mise en place dune nouvelle cl rgionale. Les rgions sont
galement fusionnes. Avec moins de k il ya trop peu de nuds pour fournir le service
CA. Par consquent AKM prsente des vulnrabilits face aux changements de rgions.
COMP na pas de rsistance face aux nuds malicieux ou compromis. En effet ces
nuds peuvent dans certains cas affecter la pleine confiance des nuds non fiables.
Ainsi COMP prsente des vulnrabilits lies la gestion distribue de la confiance. La

55

cryptanalyse de la cl prive du systme travers la connaissance des cls prives est
une faiblesse des systmes bass sur lidentit comme IBC-K.
Lautorit off-line suppose par MOB-a nimplique pas de rvocation. Les auteurs
suggrent que les nuds compromis doivent rvoquer leurs propres certificats.
Cependant il peut tre difficile de savoir si une compromission a eu lieu ou non. La
rvocation par soupon reprsente une vulnrabilit. Elle peut constituer une menace
pour la disponibilit. MOB implique un long dlai pour tablir les associations de
scurit avec tous les partenaires de communication. Ce qui peut constituer une
vulnrabilit.
La rvocation et la distribution dinformations de rvocation constituent des points de
vulnrabilit pour tous les protocoles distributifs cl publique tudis.
A lexception de PGP-A, la scurit de tous les protocoles distributifs cl publique
tudis repose sur le secret de la cl prive CA/PKG. Une mise jour de cette cl
requiert une nouvelle cl publique distribuer tous les nuds dans le rseau. Il ny a
par consquent pas de moyen facile pour changer la paire de cls de lentit de
confiance durant le fonctionnement du rseau. Cela reprsente un inconvnient pour
tous les protocoles cl publique dpendant dune entit de confiance.

Robustesse
Tous les protocoles distributifs cl publique tudis lexception de AKM et COMP
offrent des mcanismes pour rsister face aux nuds malicieux ou dfectueux.. Si
certaines CA dans les protocoles seuil sont indisponibles ou dlivrent des signatures
partielles invalides, il est toujours possible de calculer une signature valide aussi
longtemps que k+1 ou plus signatures correctes peuvent tre recueillies. La situation est
similaire pour les oprations PKG distribues dans IBC-K. AKM exige des nuds de
collaborer pour des modifications dans les rgions et pour la hirarchie de cls. Les
nuds malicieux ou dfectueux peuvent retarder ces oprations. Ainsi AKM prsente
une rsistance limite face aux nuds malicieux ou dfectueux. Il en est de mme pour
COMP comme il a t dj soulign.
Les protocoles distributifs cl publique grent plus facilement les changements de
groupe compars aux protocoles contributifs, dautant plus quils ne ncessitent pas de

56

changement de cls. Un nud prsentant une signature valide est automatiquement
accept comme membre lgitime. En ce qui concerne lvaluation des signatures IBC-K
est plus efficace, puisquil ne ncessite pas lchange de certificats. La signature et
lidentit du nud sont suffisantes pour cette valuation.

Extensibilit
Gnralement les protocoles distributifs cl publique tudis offrent une extensibilit
limite, lie laccroissement du cot communicationnel en cas daugmentation du
nombre de nuds dans le rseau. Le cot est souvent relatif aux demandes de service
CA.
UBIQ amliore cette extensibilit en limitant les demandes de service CA au voisinage
dun saut. IBC-K aussi amliore cette extensibilit en rendant les certificats obsoltes et
en utilisant les informations transfres par dfaut dans les messages de routage comme
cl publique.
Les capacits des diffrents protocoles distributifs cl publique sont rsumes dans le
Tableau 5.2.


57

Tableau 5. 2 : Rsum de lvaluation des protocoles distributifs cl publique

P
D
C
A

M
O
C
A

S
E
K
M

U
B
I
Q

A
p
p
l
i
c
a
b
i
l
i
t
s
e
a
u

P
l
a
n
i
f
i

P
l
a
n
i
f
i

P
l
a
n
i
f
i

P
l
a
n
i
f
i
/

A
u
t
o

o
r
g
a
n
i
s
c
u
r
i
t

A
u
t
h
e
n
t
i
f
i
c
a
-
t
i
o
n

O
f
f
-
l
i
n
e

O
f
f
-
l
i
n
e

O
f
f
-
l
i
n
e

O
f
f
-
l
i
n
e

T
o
l
r
a
n
c
e

i
n
t
r
u
s
i
o
n

B
o
n
n
e

B
o
n
n
e

B
o
n
n
e

C
o
n
v
e
n
a
b
l
e

G
e
s
t
i
o
n

c
o
n
f
i
a
n
c
e

C
A

C
A

C
A

C
A
,

k

v
o
i
s
i
n
s

d
u
n

s
a
u
t

V
u
l
n
r
a
b
i
l
i
t
s

C
o
m
b
i
n
a
t
e
u
r
,

d
i
s
t
r
i
b
u
t
i
o
n

C
R
L
s
,

M
a
j
.

c
l

C
A

D
i
s
t
r
i
b
u
t
i
o
n

C
R
L
s
,

M
a
j
.

c
l

C
A

D
i
s
t
r
i
b
u
t
i
o
n

C
R
L
s
,

M
a
j
.

c
l

C
A

D
i
s
t
r
i
b
u
t
i
o
n

C
R
L
s
,

A
t
t
a
q
u
e
s

S
y
b
i
l
,

M
a
j
.

c
l

C
A

R
o
b
u
s
t
e
s
s
e

N
u
d
s

m
a
l
i
c
i
e
u
x

e
t

d
f
e
c
t
u
e
u
x

B
o
n
n
e

B
o
n
n
e

B
o
n
n
e

B
o
n
n
e

C
h
a
n
g
e
m
e
n
t
s

d
e

g
r
o
u
p
e

C
e
r
t
i
f
i
c
a
t

+

C
R
L

C
e
r
t
i
f
i
c
a
t

+

C
R
L

C
e
r
t
i
f
i
c
a
t

+

C
R
L

C
e
r
t
i
f
i
c
a
t

+

C
R
L

E
x
t
e
n
s
i
b
i
l
i
t

P
a
u
v
r
e

L
i
m
i
t
e

L
i
m
i
t
e

C
o
n
v
e
n
a
b
l
e


58

A
K
M

P
G
P
-
A

C
O
M
P

M
O
B

I
B
C
-
K

A
p
p
l
i
c
a
b
i
l
i
t
s
e
a
u

A
u
t
o

o
r
g
a
n
i
s

A
u
t
o

o
r
g
a
n
i
s

P
l
a
n
i
f
i
/

A
u
t
o

o
r
g
a
n
i
s

M
O
B
-
a

:

P
l
a
n
i
f
i

M
O
B
-
s
o

:

A
u
t
o

o
r
g
a
n
i
s

P
l
a
n
i
f
i
/

A
u
t
o

O
r
g
a
n
i
s
c
u
r
i
t

A
u
t
h
e
n
t
i
f
i
c
a
-
t
i
o
n

O
f
f
-
l
i
n
e

O
f
f
-
l
i
n
e

O
f
f
-
l
i
n
e

O
f
f
-
l
i
n
e
/
c
o
t

c
a
n
a
l

O
f
f
-
l
i
n
e

T
o
l
r
a
n
c
e

i
n
t
r
u
s
i
o
n

C
o
n
v
e
n
a
b
l
e
/
B
o
n
n
e

L
i
m
i
t
e

L
i
m
i
t
e
/

C
o
n
v
e
n
a
b
l
e

B
o
n
n
e

B
o
n
n
e

G
e
s
t
i
o
n

c
o
n
f
i
a
n
c
e

C
A
,

k

v
o
i
s
i
n
s

d
u
n

s
a
u
t

N
u
d
s

C
A

+

N
u
d
s

c
e
r
t
i
f
i
s

C
A

M
O
B
-
a

:

C
A

O
f
f
-
l
i
n
e

M
O
B
-
s
o

:

N
u
d
s

P
K
G

V
u
l
n
r
a
b
i
l
i
t
s

C
h
a
n
g
e
m
e
n
t
s

d
e

r
g
i
o
n
,

i
s
t
r
i
b
u
t
i
o
n

C
R
L
s
,

V
o
i
s
i
n
s

d
u
n

s
a
u
t

<

k
,

M
a
j
.

c
l

C
A

N
u
d
s

c
o
m
p
r
o
m
i
s
,

d
i
s
t
r
i
b
u
t
i
o
n

C
R
L
s

N
u
d
s

c
o
m
p
r
o
m
i
s
,

g
e
s
t
i
o
n

c
o
n
f
i
a
n
c
e

d
i
s
t
r
i
b
u
e
,

d
i
s
t
r
i
b
u
t
i
o
n

C
R
L
s
,

M
a
j
.

c
l

C
A

R
v
o
c
a
t
i
o
n
,

d
l
a
i
s

d
u
s

l
a

r
e
s
t
r
i
c
t
i
o
n

s
u
r

l
e
s

c
h
a
n
g
e
s

d
e

r
r
e
n
c
e
s

d
e

s
c
u
r
i
t
,

M
a
j
.

c
l

C
A

D
i
s
t
r
i
b
u
t
i
o
n

I
R
L
s
,

M
a
j
.

c
l

P
K
G

R
o
b
u
s
t
e
s
s
e

N
u
d
s

m
a
l
i
c
i
e
u
x

e
t

d
f
e
c
t
u
e
u
x

L
i
m
i
t
e

B
o
n
n
e

L
i
m
i
t
e

B
o
n
n
e

B
o
n
n
e

C
h
a
n
g
e
m
e
n
t
s

d
e

g
r
o
u
p
e

C
e
r
t
i
f
i
c
a
t

+

C
R
L
/
a
c
c
u
s
a
t
i
o
n
s

+

t
a
i
l
l
e

r
g
i
o
n

C
e
r
t
i
f
i
c
a
t

+

C
R
L

C
e
r
t
i
f
i
c
a
t

+

C
R
L

C
e
r
t
i
f
i
c
a
t

+

C
R
L

I
R
L

E
x
t
e
n
s
i
b
i
l
i
t

L
i
m
i
t
e

P
a
u
v
r
e

L
i
m
i
t
e

L
i
m
i
t
e

C
o
n
v
e
n
a
b
l
e


59

5.2.2.2 Evaluation des protocoles distributifs cl symtrique

Applicabilit
SKiMPy suppose des certificats pr distribus pour ltablissement du canal scuris
servant de support de communication pour le processus de slection de la meilleure cl
[5]. S-HEAL et LKH exigent des secrets pr partags et un gestionnaire de groupe pour
la diffusion des cls de groupe [5]. Ainsi SKiMPy, S-HEAL et LKH sont appropris
aux rseaux ad hoc planifis.

Scurit
SKiMPy se base sur le certificat pour ltablissement dun canal scuris mais aussi sur
la cl de groupe qui sert de preuve de fiabilit une fois tablie. LKH aussi utilise la
possession de la cl de groupe comme preuve de fiabilit. S-HEAL prsente une lacune
lie labsence dauthentification de la source des missions en provenance du
gestionnaire de groupe.
Avec SKiMPy une fois que la cl symtrique est reue par un nud, il nexiste pas de
moyen efficace dexclure ce dernier de toute participation ultrieure. Ainsi SKiMPy
offre une tolrance lintrusion limite.
S-HEAL et LKH fournissent des mcanismes de changement de cls et de rvocation et
ainsi permettent damliorer la tolrance lintrusion dans les systmes cl
symtrique. Pour S-HEAL et LKH la gestion de la confiance est assure par le
gestionnaire de groupe. Dans SKiMPy cette tche est assure soit par une autorit off-
line soit par des nuds spciaux pour ladministration des certificats.
S-HEAL et LKH prsentent des vulnrabilits face aux nuds malicieux et la
dpendance vis--vis dun gestionnaire de groupe. Le gestionnaire de groupe reprsente
un unique point de dfaillance. La rplication du gestionnaire de groupe pour la fiabilit
est dune valeur limite pour les rseaux ad hoc. En fait cette rplication exige des
serveurs synchroniss et augmente le nombre de cibles pour les attaques de scurit. Les
nuds malicieux peuvent agir en tant que gestionnaire de groupe et entraner des
perturbations.

60

SKiMPy prsente des vulnrabilits face la rvocation de cls car il ne permet pas
lexclusion des nuds en possession de la cl symtrique. Les certificats sont utiliss
pour assurer lauthentification. Ainsi lautorit de certification, participe la gestion de
la confiance dans SKiMPy, et peut constituer un point de dfaillance, do lexistence
de vulnrabilits de ce protocole lies la CA.

Robustesse
S-HEAL et LKH noffrent pas de rsistance face aux nuds malicieux car ils
prsentent des vulnrabilits lies la prsence de ces derniers dans le rseau. SKiMPy
propose des mises jour priodiques de la cl de groupe pour contrer la cryptanalyse, ce
qui peut renforcer sa rsistance face aux nuds malicieux.
Un changement de groupe d larrive ou au dpart de nuds implique un
changement de la cl de groupe pour S-HEAL et LKH.

Extensibilit
De manire gnrale les protocoles distributifs cl symtrique offrent une extensibilit
convenable. Dans SKiMPy cette extensibilit est favorise, car les nuds saccordent
localement sur la meilleure cl et donc laugmentation du nombre de nuds ninflue pas
sur le fonctionnement du protocole. Pour S-HEAL les tailles des messages et le nombre
de messages de mise jour de cls sont indpendants du nombre de nuds dans le
rseau. En substance LKH reprsente une famille de protocoles qui amliorent
lextensibilit de la mthode de mise jour de cls de groupe par force brute en
organisant les cls dans une hirarchie logique. Ainsi LKH prsente une extensibilit
convenable.
Les capacits des diffrents protocoles distributifs cl symtrique sont rsumes dans
le Tableau 5.3.


61

Tableau 5. 3: Rsum de lvaluation des protocoles distributifs cl symtrique

S
K
i
M
P
y

S
-
H
E
A
L

L
K
H

A
p
p
l
i
c
a
b
i
l
i
t
s
e
a
u

P
l
a
n
i
f
i

P
l
a
n
i
f
i

P
l
a
n
i
f
i
c
u
r
i
t

A
u
t
h
e
n
t
i
f
i
c
a
-
t
i
o
n

C
e
r
t
i
f
i
c
a
t
s
,

p
o
s
s
e
s
s
i
o
n

d
e

c
l

N
o
n

a
d
r
e
s
s
e

P
o
s
s
e
s
s
i
o
n

d
e

c
l

T
o
l
r
a
n
c
e

i
n
t
r
u
s
i
o
n

L
i
m
i
t
e

C
o
n
v
e
n
a
b
l
e

C
o
n
v
e
n
a
b
l
e

G
e
s
t
i
o
n

d
e

l
a

c
o
n
f
i
a
n
c
e

O
f
f
-
l
i
n
e

/

N
u
d
s

s
p
c
i
a
u
x

G
e
s
t
i
o
n
n
a
i
-
r
e

d
e

g
r
o
u
p
e

G
e
s
t
i
o
n
n
a
i
r
e

d
e

g
r
o
u
p
e

V
u
l
n
r
a
b
i
l
i
t
s

R
v
o
c
a
t
i
o
n
,

M
a
j
.

P
r
i
o
d
i
q
u
e
s

d
e

c
l
s

C
A

G
e
s
t
i
o
n
n
a
i
r
e

d
e

g
r
o
u
p
e
,

a
s
s
o
c
i
a
t
i
o
n
s

n
u
d
s

>

t

G
e
s
t
i
o
n
n
a
i
r
e

d
e

g
r
o
u
p
e

R
o
b
u
s
t
e
s
s
e

N
u
d
s

m
a
l
i
c
i
e
u
x

e
t

d
f
e
c
t
u
e
u
x

C
o
n
v
e
n
a
b
l
e

P
a
u
v
r
e

P
a
u
v
r
e

C
h
a
n
g
e
-
m
e
n
t
s

d
e

g
r
o
u
p
e

N
o
n

a
d
r
e
s
s
s

C
h
a
n
g
e
-
m
e
n
t
s

d
e

c
l
s

C
h
a
n
g
e
-
m
e
n
t
s

d
e

c
l
s

E
x
t
e
n
s
i
b
i
l
i
t

C
o
n
v
e
n
a
b
l
e

C
o
n
v
e
n
a
b
l
e

C
o
n
v
e
n
a
b
l
e


62

Les tableaux ci-dessous donnent une aperue sur les rsultats de notre analyse en listant
les diffrents avantages et inconvnients des diffrents protocoles de gestion des cls
tudis pour les MANETs.

Tableau 5. 4 : Avantages et inconvnients des protocoles distributifs cl publique

P
r
o
t
o
c
o
l
e
s

d
i
s
t
r
i
b
u
t
i
f
s

c
l

p
u
b
l
i
q
u
e

Avantages

Inconvnients

P
D
C
A

- authentification par
certificat et CA off-
line ;
- bonne tolrance
lintrusion.

- ncessite un protocole de routage dj en
cours dexcution ;
- difficults dans le choix des paramtres n,
k et T ;
- manque de prcisions sur le processus de
gestion de la confiance ;
- vulnrabilits lies aux mises jour de la
cl prive CA ;
- lourdes charges de calcul ;
- absence de mcanisme efficace de
rvocation.

M
O
C
A
,

S
E
K
M

line ;
- bonne tolrance
lintrusion ;
- amlioration de la
communication entre
client et serveur
MOCA.
U
B
I
Q

line ;
- fournit une auto
organisation ;
- amliore
lextensibilit.

- difficults dans le choix du paramtre k ;
cl prive CA ;
- vulnrabilits aux attaques Sybil ;
- lourds calculs ;
- absence de mcanisme efficace de
rvocation.

63

A
K
M

line ;
- fournit une auto
organisation ;
- amliore la tolrance
lintrusion / UBIQ.

- vulnrabilits face aux changements de
rgion ;
cl prive CA ;
- problme li la rvocation.
P
G
P
-
A

- fournit une entire
auto organisation.

- authentification moins fiable ;
- ncessite un protocole de routage dj en
cours dexcution ;
- accroissement du cot
communicationnel ;
- tolrance lintrusion limite ;
- problme li la rvocation.
C
O
M
P

- amliore la tolrance
lintrusion / PGP-A ;
- accrot la disponibilit
du service CA /
MOCA.

- hrite des proprits dfaillantes
dauthentification ;
- difficults dans le choix des paramtres n,
k ;
- gestion de la confiance dist. ;
cl prive CA ;
- lourdes charges de calcul ;
- absence de mcanisme de rvocation.
M
O
B

- bonne tolrance
lintrusion.

- dlai d ltablissement des associations
de scurit ;
- dpendance vis--vis de la mobilit ;
- absence de mcanisme de rvocation.

64

I
B
C
-
K

- supprime le besoin des
certificats ;
- amliore
lextensibilit.

- Problme li lauthentification de
lidentit dun nud ;
cl prive PKG ;
- vulnrabilits lies la distribution du
PKG ;
- hrite des faiblesses de la cryptographie
base sur lidentit.

n : nombre de nuds partageant la cl prive CA ; k : seuil du partage secret ; T : priode de
renouvellement des parts secrtes.

Tableau 5.5: Avantages et inconvnients des protocoles distributifs cl symtrique

P
r
o
t
o
c
o
l
e
s

d
i
s
t
r
i
b
u
t
i
f
s

c
l

s
y
m
t
r
i
q
u
e

Avantages Inconvnients

S
K
i
M
P
y

certificat et possession de
la cl de groupe ;
- prvient la cryptanalyse
de la cl de groupe.

- dlai li la mise en place de la
meilleure cl ;
- tolrance lintrusion limite ;
- vulnrabilits face la rvocation.

S
-
H
E
A
L

- mcanisme de rvocation
fourni ;
- extensibilit convenable.

- Authentification non adresse ;
- Vulnrabilits lies la dpendance
vis--vis dun gestionnaire de groupe.

L
K
H

possession de la cl de
groupe ;
- mcanisme de rvocation
fourni ;
- extensibilit convenable.

- Vulnrabilits lies la dpendance
vis--vis dun gestionnaire de groupe ;


65

Tableau 5. 6: Avantages et inconvnients des protocoles contributifs

P
r
o
t
o
c
o
l
e
s

c
o
n
t
r
i
b
u
t
i
f
s

Avantages Inconvnients

D
-
H

- offre une forme de tolrance
lintrusion.

- absence de mcanisme
dauthentification.

I
N
G

- absence de mcanisme
dauthentification ;
- dpendance vis--vis dun
systme dorganisation des
nuds ;
- manque de tolrance lintrusion ;
- pauvre extensibilit.

H
&
O

- rduit le nombre de rounds et
dexponentiations dING.

A
-
G

- prise en compte de
lauthentification.

- dpendance vis--vis dun
systme dorganisation des
nuds ;
- manque de tolrance lintrusion ;
- pauvre extensibilit ;
- augmentation du nombre de
messages et de la complexit du
calcul / H&O

Conclusion

Dans cette partie nous avons prsent une vue densemble du fonctionnement des
protocoles de gestion des cls dans les rseaux ad hoc. Nous constatons que la majorit
des protocoles proposs sont destins aux systmes cl publique. Pour les systmes
cl symtrique la littrature dcrit souvent les protocoles destins aux Wireless sensor
networks, c'est--dire les rseaux de capteurs. Les protocoles distributifs cl publique

66

doivent tre considrs en faisant la distinction entre ceux qui sont bass sur le certificat
et ceux bass sur lidentit.
Nous avons effectu une analyse de ces diffrents protocoles, en nous basant sur un
ensemble de critres dvaluation.
Cette analyse montre quaucun protocole nest intrinsquement suprieur aux autres.
Toutefois elle nous a permis de dresser le tableau ci-dessous, prsentant les ractions
des diffrents protocoles tudis face aux diffrents problmes quun un service idal de
gestion des cls doit traiter.

Tableau 5. 7 : Rsum de lanalyse des protocoles de gestion des cls dans les MANETs

P
r
o
t
o
c
o
l
e
s

d
e

g
e
s
t
i
o
n

d
e
s

c
l
s

d
a
n
s

l
e
s

M
A
N
E
T
s

Problmes
A
u
t
h
e
n
t
i
f
i
c
a
t
i
o
n

T
o
l
r
a
n
c
e

i
n
t
r
u
s
i
o
n

E
x
c
l
u
s
i
o
n

d
e
s

n
u
d
s

c
o
m
p
r
o
m
i
s

R
s
i
s
t
a
n
c
e

/

n
u
d
s

m
a
l
i
c
i
e
u
x

o
u

E
x
t
e
n
s
i
b
i
l
i
t

M
i
s
e
s

j
o
u
r

d
e

c
l
s

p
r
i
v
e
s

C
A

/

P
K
G

PDCA Oui Oui Non Oui Non Non
MOCA Oui Oui Non Oui Non

Non
SEKM Oui Oui Non Oui Non Non

UBIQ

Oui

Oui

Non

Oui

Oui

Non
AKM Oui Oui Non Non Non Non
PGP-A Non Non Non Oui Non NA
COMP Oui Oui Non Non Non Non
MOB Oui Oui Non Oui Non Non
IBC-K Oui Oui Non Oui Oui Non

SKiMPy Oui Non Non Oui Oui Non

67

S-HEAL NA Oui Oui Non Oui NA
LKH Oui Oui Oui Non Oui NA

D-H Non Oui NA Oui NA NA
ING Non Non NA Non Non NA
H&O Non Non NA Non Non NA
A-G Oui Non NA Non Non NA

Au vu de ces rsultats, il est impossible de concevoir un systme de scurit ne
comportant aucune faille. Ainsi, en guise de contribution nous proposons une solution
une des insuffisances soulignes lors de notre analyse. Nous proposons un mcanisme
de rvocation de certificats un des protocoles cl publique afin de fournir ce
dernier un moyen dexclure les nuds en cas de compromission.

TROISIEME PARTIE : Proposition dun mcanisme de rvocation de certificats pour UBIQ

68

Troisime partie

PROPOSITION DUN MECANISME
DE REVOCATION DE
CERTIFICATS POUR LE
PROTOCOLE UBIQ


69

VI. MECANISME DE REVOCATION
DE CERTIFICATS POUR LE
PROTOCOLE UBIQ

Lanalyse des protocoles de gestion des cls dans les MANETs montre que la
rvocation de cls reste un problme non rsolu pour tous les protocoles distributifs
cl publique.
Dans cette partie nous proposons un mcanisme de rvocation de certificats pour un des
protocoles bass sur PKI tudis ainsi quun ensemble de tests dont le but est de valider
cette proposition.

6.1 Rvocation des cls pour les protocoles cl publique

La rvocation de cls publiques doit tre traite au sein du rseau, car les nuds doivent
tre en mesure de vrifier immdiatement l'tat de celles-ci.
Lanalyse des protocoles de gestion des cls dans les rseaux ad hoc a montr que le
problme majeur des protocoles distributifs cl publique est la rvocation des cls. La
rvocation des cls est un des mcanismes utiliss pour adresser les menaces que la
gestion des cls doit traiter notamment :
- La compromission de la confidentialit des cls ;
- La compromission de lauthenticit des cls ;
- Lusage non autoris de cls.

6.1.1 Travaux relatifs la rvocation des cls pour les protocoles cl
publique


70

6.1.1.1. Mcanismes pour les protocoles bass sur le certificat

Plusieurs mcanismes bass sur PKI ont t introduits pour les MANETs, par exemple
[14, 55, 56], ou certains dentre eux utilisent des systmes seuil (k, n) pour
implmenter des CAs distribues on-line [14, 55]. Dans [14] il est suggr de rvoquer
les certificats de manire collaborative, mais aucun algorithme nest prsent. En fait le
mcanisme de rvocation dans cette solution ncessiterait des signatures seuil, ce qui
est lourd en terme de calcul.
Dans [55], un mcanisme daccusation selon lequel chaque nud observe les nuds de
son voisinage pour un comportement malicieux est brivement esquiss. En se basant
sur ces observations les nuds envoient leurs accusations signes leur voisinage m
sauts. Tous les rcepteurs vrifient les accusations et en consquence mettent jour
leurs listes daccusation. Si le nombre daccusations pour un nud est suprieur un
seuil , le certificat est rvoqu.
Dans [56], un mcanisme de rvocation de certificats est prsent pour les MANETs. Il
utilise un systme daccusation avec seuil . Lopration suppose une CA off-line qui
dlivre des certificats tous les nuds avant que ceux-ci ne rejoignent le rseau. Toutes
les accusations sont frquemment diffuses sur lensemble du rseau. Le mcanisme de
rvocation utilise un systme de pondration daccusations pour dcider si un certificat
est rvoquer. Ici, au lieu de calculer la somme des accusations, les accusations sont
pondres selon le nombre daccusations faites par un nud, le nombre daccusations
qui ont t signales contre ce nud etc. Quand un nouveau nud se connecte au
rseau, il reoit les tables daccusation en provenance de tous les nuds du rseau. Les
messages daccusation dans [56] ne sont pas scuriss en gnral et les auteurs
suggrent de vrifier les incohrences dans les tables daccusation reues, et de se fier
aux accusations en provenance dexpditeurs avec une valeur de confiance suffisante.

6.1.1.2 Mcanisme pour les protocoles bass sur lidentit

Rcemment, deux protocoles cryptographiques bass sur l'identit (Identity-Based
Cryptograghy IBC) ont t introduits pour scuriser les rseaux mobiles ad hoc [57].

71

Toutefois, ces protocoles ne prvoient pas de mcanismes de rvocation et de
renouvellement des cls. La rfrence [57] propose le premier mcanisme de rvocation
de cls pour les protocoles bass sur lidentit spcialement conus pour les MANETs.

6.1.2 Mcanisme de rvocation pour les protocoles bass sur lidentit

Jusquici dans tous les protocoles cryptographiques bass sur lidentit, c'est--dire les
protocoles gnraux et ceux spcialement conus pour les MANETs, la rvocation se
rfrait ladjonction dune date dexpiration la cl publique [57]. Cela nest pas
suffisant car les nuds doivent tre capables de rvoquer les cls avant quelles
nexpirent, par exemple dans le cas de la compromission dune cl ou dun
comportement malveillant.
La rfrence [57] fournit un mcanisme de rvocation auto organis dans lequel chaque
nud surveille le comportement des nuds situs lintrieur de sa gamme de
transmission et propage de manire scurise ses observations. La cl publique dun
nud est rvoque si un nombre minimum de nuds laccuse.
Le mcanisme est efficace parce quil utilise des cls pr partages pour scuriser les
messages daccusation et de rvocation. Les messages sont envoys au voisinage m
sauts au lieu du rseau en entier. Le mcanisme peut tre adapt aux protocoles de
gestion des cls bass sur PKI dans les MANETs.
Les protocoles bass sur lidentit fournissent un systme de gestion de cls efficace qui
aident dans la rduction du cot de la communication, du temps de calcul et du volume
de mmoire. La fonction principale des protocoles cryptographiques bass sur lidentit
est lutilisation de cls publiques auto authentifies, ce qui rend lusage des certificats
superflu. La cl publique
i
Q

dun nud
i
D

est pr dtermine, la cl prive
i
d

est
drive de
i
Q et dune cl secrte master secret key s

seulement connue par le KGC
(Key Generator Center),
i i
sQ d = . Le KGC gnre et distribue les cls prives durant
linitialisation de tous les nuds du rseau. Dans les protocoles cryptographiques bass
sur lidentit chaque nud du rseau est en mesure de driver la cl publique
i
Q dun
partenaire de communication
i
D dans le rseau, par exemple ) (
1 i i
ID H Q = [57]. Cela ne

72

ncessite aucun change de donnes. De plus toutes les paires de nuds
i
D et
j
D
dans les protocoles IBC bass sur le couplage sont en mesure de calculer une cl secrte
de paire pr partage
j i
K
,
[57] de faon non interactive comme dcrit par la formule
(4).

) , ( ) , (
, j i j i j i
d Q Q d K = =
(4)

o (.) est une fonction qui prend deux paramtres et satisfait les proprits telles que la
bilinarit, la non dgnrescence et la calculabilit. Elle est nomme bilinear mapping
[3].
Pour le calcul de la cl, chaque nud calcule (.) partir de sa propre cl prive
i
d et la
cl publique
j
Q

de lautre nud.

Les hypothses ncessaires pour le rseau et les nuds peuvent tre rsums comme
suit :
1. il existe des liens de communication bidirectionnels ;
2. il existe des systmes de surveillance dj mis en place sur les nuds ;
3. chaque nud a une identit unique ;
4. les nuds connaissent les identits de leurs voisins dun saut ainsi que la
distance pour un saut ;
5. Les nuds connaissent les identits de tous les nuds de leur voisinage m
sauts ;
6. les nuds obtiennent une paire de cls publique/prive auprs dun KGC off-
line avant de rejoindre le rseau.

6.1.2.1 Fonctionnement du mcanisme de rvocation

Le mcanisme comprend trois algorithmes [57] :
les nuds observent les nuds de leurs voisinage pour un comportement suspect
en utilisant lAlgorithme1 : Neighborhood watch ;

73

les nuds doivent tre capables de rvoquer leur propre cl publique en utilisant
lAlgorithme2 : Harakiri ;
les nuds sinforment les uns les autres de manire scurise propos
dobservations suspectes et gnrent chacun une liste de rvocation de cls dans
lalgorithme3 : Accusation.

Algorithme1 : Neighborhood watch

Le Neighborhood watch est un contrle local dans lequel chaque nud
i
ID

surveille son
voisinage dun saut
i
N - ensemble des nuds situs lintrieur de la gamme ou porte
de transmission du nud
i
ID

- pour un comportement suspect. Le comportement
suspect peut tre des paquets frquemment envoys ou un grand nombre de messages
envoys. Pour cette raison les nuds observent leurs voisins et vrifient si ces derniers
expdient des messages qui taient adresss dautres. Le comportement suspect peut
avoir diffrentes causes, par exemple un nud a t compromis et est maintenant
contrl par un utilisateur malicieux, ou un nud est goste et au lieu dexpdier les
messages il prfre conserver son nergie.
Pour une reprsentation facile et sans perte de la gnralit nous dnotons les voisins
dun saut de
i
ID

par
i
N
j
ID

avec { }
i
N j ,..., 1

ou
i
N

est le nombre de voisins dun
saut du nud
i
ID [57]. Lutilisateur
i
ID

stocke des valeurs daccusation
i
j i
a
,
pour
chaque
i
N
j
ID avec une date dexpiration
i
j
t et la version
i
j
v de la cl publique
courante
j
Q . Un nud
i
ID fixe ses valeurs daccusation 1
,
=
i
j i
a

si
i
ID

observe que
j
ID
se comporte de manire suspecte, autrement 0
,
=
i
j i
a . Les valeurs daccusation cres
par
i
ID partir de son Neighborhood watch peuvent tre reprsentes sous la forme
dune matrice daccusation
i
AM .


74

,
,
,
1 , 1 1 1
|
|
|
|
|
|
|
\
|

=
i
i
N i
i
i
N
i
i
N
i
N
i
i
i i
i
a v t ID
a v t ID
AM

avec { } { }
i
i
j i
N j a ,..., 1 et 1 , 0
,
. Chaque vecteur ligne ) (
j
i
ID r

ou
i
j
r dans
i
AM ,
correspond un voisin
i
N
j
ID . Il contient son identit, la valeur daccusation
i
j i
a
,

affecte sa cl publique
j
Q , la date dexpiration
i
j
t et la version
i
j
v

de
j
Q . Nous nous
rfrons la troisime colonne dans
i
AM comme vecteur colonne
i
i
c , qui est le vecteur
contenant toutes les accusations faites par
i
ID . Les valeurs daccusation sont mises
jour chaque fois que
i
ID observe un comportement suspect. Une fois la valeur
i
j i
a
,

fixe 1, elle nest pas remise zro tant quune nouvelle cl publique '
j
Q nest pas
reue.

Algorithme2 : Harakiri

Quand un nud
i
ID ralise que sa cl prive
i
d a t compromise, il diffuse un harakiri
message
i
hm sous le format suivant :

hopcount) , revoque" " ), v , (t , Q , d , (ID hm
i i i i i i
=
,

son voisinage m sauts not par
i
N m . Ce voisinage est constitu par lensemble
des nuds situs une distance infrieure ou gale m fois la porte de transmission du
nud
i
ID . Initialement
i
ID

fixe le hopcount m et envoie le message tous ses voisins
dun saut. Les rcepteurs
j
ID vrifient lauthenticit du harakiri en contrlant si

) , (
, j i i j
Q d K =
(5)

75

est vraie. Le contrle vrifie si la cl prive diffuse
i
d correspond rellement la cl
publique
i
Q . Ainsi
j
ID vrifie sil est en possession de la cl publique
i
Q et de la cl
pr partage
i j
K
,
, et si tel est le cas il utilise
i j
K
,
pour vrifier si (5) est vraie. Si
j
ID
nest pas en possession de ces cls, il calcule en premier
i
Q conformment

) ( H
1 i i i i
v t ID Q =

(6)

pour vrifier si
i
ID

et
i
Q correspondent. En cas de succs de la vrification,
j
ID drive
i j
K
,
conformment (4) et vrifie alors si (5) est vraie. Si tel est le cas, le rcepteur
j
ID met jour sa valeur daccusation
1
,
=
j
i i
a
, dcrmente le hopcount et diffuse le
message nouveau. Autrement,
i
hm est ignor. La diffusion est rpte jusqu ce que
lon ait hopcount = 0. Cela assure que tous les nuds dans le voisinage m sauts du
nud compromis
i
ID ont reu le harakiri message et ainsi sont informs concernant la
compromission dune cl.

Algorithme3 : Accusation

Dans cet algorithme chaque nud
i
ID cre sa propre liste de rvocation de cls
i
KRL
pour son voisinage m sauts. Nous dcrivons comment les listes de rvocation sont
cres (Alg.3.1), propages de manire scurise ( Alg.3.2) et comment les nuds
utilisent les listes de rvocation et les harakiri messages reus pour mettre jour leur
propre liste de rvocation (Alg.3.3) [57].

Algorithme3.1 : Cration de liste de rvocation de cls
Chaque nud
i
ID cre une liste de rvocation de cls
i
KRL sous le format suivant :


76

|
|
|
|
|
|
|
\
|

=
i
i
M
i
M
i
i
M
i
i
M
i
i
M
i
i
M
i
M
i
i
M
i i i i
i
a a R v t ID
a a R v t ID
KRL
, 1 ,
, 1 1 , 1 1 1 1 1
) , (
) , (

Avec { } { }
i
i
k j
M k j a ...., 1, , et - 1, , 0
,
o
i
M

est le nombre de nuds dans le
voisinage m sauts
i
N m de
i
ID incluant
i
ID

lui-mme. La valeur daccusation
i
k j
a
,

qui est gale "-" indique que
j
ID et
k
ID sont plus de m sauts lun par rapport
lautre. Ainsi chacun de ces nuds ne peut pas se prononcer sur la fiabilit de lautre.
Chaque vecteur ligne
i
j
r dans
i
KRL correspond un nud
i
N m ID
j
, o la ligne
contient les valeurs daccusation
i
k j
a
,
de tous les nuds
i
N m ID
k
contre un nud
j
ID . Chaque vecteur colonne ) (
j i
ID c

ou
i
j
c dans
i
KRL contient toutes les accusations
i
j k
a
,
portes par le nud
j
ID

contre tous les nuds
i
N m ID
k
. Lindex i

montre
que les valeurs sont celles courantes dans la liste de rvocation de
i
ID .
Le premier champ dans chaque ligne
i
j
r de
i
KRL

contient lidentit du nud
j
ID . Le
second champ contient la date dexpiration
i
j
t et la version
i
j
v de la cl publique la plus
courante
j
Q que connat
i
ID . Le troisime champ contient un indicateur
i
j
R qui,
lorsquil est fix 1, indique que le nud
i
ID

considre la cl publique
j
Q

du nud
j
ID

comme rvoque. Les champs allant de 4 la fin contiennent les valeurs
daccusation
i
i
M j
i
j
a a
, 1 ,
,...,
, ou la valeur
1
,
=
i
k j
a
indique que le nud
k
ID accuse le
nud
j
ID , sinon
0
,
=
i
k j
a

sinon. Les indicateurs de rvocation
i
j
R dans la liste de
rvocation de cls
i
KRL

de
i
ID

sont fixs, c'est--dire 1 =
i
j
R si une des quatre
conditions suivantes est vraie:


77

Condition 1 :
1
,
=
i
i j
a
, cela signifie que le nud
i
ID

observe lui-mme le
comportement malicieux du nud
j
ID

durant le neighborhood
watch (Alg.1). Ce qui implique que
j
ID

et
i
ID

sont des voisins
dun saut ;
Condition 2 :
i
j
t

est expire, cela signifie que la copie courante de la cl
publique
j
Q de
j
ID est expire ;
Condition 3 :
1
,
=
i
j j
a
, cela signifie que
i
ID

a reu un harakiri message
authentique
j
hm

de
j
ID ;
Condition 4 :
> =
=
i
M
k
i
k j
i
j
a A
1
,

pour tout k

tel que 0 =
i
k
R

; cela consiste
additionner toutes les valeurs daccusation
i
k j
a
,
du vecteur ligne
i
j
r

des nuds non rvoqus
k
ID

et vrifier si la somme est
suprieure . En dautres termes la cl publique
j
Q

est
rvoque si le nud
i
ID

reoit plus de

accusations partir
dun nud fiable
k
ID

contre un nud suspect
j
ID .
Si aucune des ces quatre conditions nest satisfaite, alors 0 =
i
j
R , cela signifie que
j
ID
et sa cl publique courante sont considrs comme fiables.

Algorithme 3.2 : Propagation daccusations
Dans cet algorithme les nuds propagent de manire scurise les accusations travers
le rseau. Chaque fois quun nud
i
ID met jour sa matrice daccusation
i
AM ,
puisque ayant observ un certain comportement suspect dans son neighborhood watch,
i
ID envoie un message daccusation ses voisins dun saut. De la mme manire,
chaque fois que
i
ID met jour sa liste de rvocation de cls
i
KRL , car ayant reu des
accusations partir dautres nuds,
i
ID envoie un message daccusation ses voisins.
Les messages daccusation envoys par
i
ID ont le format suivant :


78

)) , ( , ) , ( (

,
, i i i i
j i
K j i
am ID am ID f am =
pour tout
i
N
j
ID

o
i
i
AM am = pour des mises jour partir du neighborhood watch de
i
ID , et
i
i
KRL am = pour des mises jour de liste de rvocation causes par des messages
daccusation reus par
i
ID en provenance dautres nuds.
Optionnellement,
i
am
contient uniquement les valeurs mises jour pour rduire la
bande passante. Les messages daccusation
j i
am
,
sont scuriss en utilisant les cls pr
partages
j i
K
,
pour tout
i
N
j
ID et sont alors envoys chaque voisin dun saut
j
ID .
Les cls pr partages servent comme entre dune fonction de hachage scurise
) ( f pour authentifier le message. Aprs avoir reu
j i
am
,
, un nud voisin
j
ID vrifie le
message reu en utilisant sa cl pr partage
i j
K
,
. En cas de succs,
j
ID met jour sa
liste de rvocation de cls
j
KRL

conformment, comme expliqu dans lalgorithme 3.3.

Algorithme 3.3 : Mise jour de listes de rvocation de cls
Chaque fois quun nud
i
ID reoit un harakiri message
j
hm
partir de
j
ID , il vrifie
le message comme dcrit dans lAlg.2 et en cas de succs, le nud
i
ID fixe
1
,
=
i
j j
a

et
ainsi
1 =
i
j
R

dans sa liste de rvocation
i
KRL (voir Cond. 3 dans lAlg.3.1). Si un nud
i
ID reoit un message daccusation
i j
am
,
partir dun voisin dun saut
j
ID ,
i
ID

excute les tapes suivantes pour mettre jour sa liste de rvocation de cls
i
KRL :

Etape 1 : Vrifier si
0 =
i
j
R
, c'est--dire si
i
ID

considre le nud
j
ID comme
fiable ; si tel est le cas continuer lexcution, sinon ignorer
i j
am
,
et
arrter ;
Etape 2 : Vrifier lauthenticit de
i j
am
,
en utilisant la cl pr partage
j i
K
,

comme dcrit dans lAlg.3.2 ; en cas de succs continuer lexcution,
sinon ignorer
i j
am
,
et arrter ;

79

Etape 3 : Extraire le vecteur colonne
j
j
c de
j
AM ou
j
KRL

de
i j
am
,
pour mettre
jour le vecteur colonne
i
j
c dans
i
KRL , c'est--dire adopter les
valeurs daccusation du neighborhood watch de
j
ID . Notons que
i
ID
utilise uniquement les valeurs daccusation adresses aux nuds de
son propre voisinage m sauts, les autres valeurs daccusation son
ignores. Si
j
j
AM am =

arrter, sinon continuer lexcution ;
Etape 4 : Ignorer toutes les colonnes
j
k
c de
j
KRL pour :
- i k = car il sagit du propre vecteur daccusation de
i
ID ;
- j k = car dj utilis ltape 3 ;
- l k = pour tout 1 =
i
l
R avec { }
i
M l ,..., 1 car
i
ID ne fait plus
confiance au nud
l
ID ;
- r k = pour tout les
i r
am
,
dj accepts ltape 2 ;
- s k = pour tout
i
N m ID
s
, c'est--dire les nuds qui sont situs
plus de m sauts.
Sauver toutes les autres colonnes
j
k
c .
Maintenant
i
ID rpte les tapes allant de 1 4 pour tous les messages daccusation
reus
i j
am
,
. Considrons que
i
ID a sauv
k
d

vecteurs colonnes
j
k
c partir de
k
d nuds
j
ID diffrents pour le mme
k
ID dans ltape 4. Pour tout >
k
d , tant un seuil de
scurit,
i
ID excute ltape 5 ci-dessous.
Etape 5 : Utiliser tous les
k
d

vecteurs colonnes
j
k
c sauvs ltape 4 pour
mettre jour le vecteur colonne
i
k
c de
i
KRL . La mise jour est faite
en utilisant le vote majoritaire pour chaque lment du vecteur
colonne. La majorit pour chaque valeur daccusation
j
k l
a
,
avec
{ }
i
M l ,..., 1

est calcule comme suit :


80

{ } { }
{ } { }
<
>
=

=
=
autrement. ,
; ,..., 1 et ,..., 1 avec , 2 / , 0
; ,..., 1 et ,..., 1 avec , 2 / , 1
,
1
,
1
,
,
i
k l
k i
k
d
j
k
j
k l
k i
k
d
j
k
j
k l
i
k l
a
d j M l d a si
d j M l d a si
a

Pour la simplicit nous supposons que
i
ID a sauv
k
d
vecteurs
colonnes
i
k
c partir de
k
d
voisins
j
ID avec { }
k
d j ,..., 1 ltape 4,
avec

k
d
.
Seules les valeurs
j
k l
a
,
pour les nuds
l
ID du voisinage m sauts de
i
ID
sont considres, les autres valeurs sont ignores. Si aucune majorit ne
peut tre trouve, la valeur daccusation reste inchange. Le nud
i
ID
rpte ceci pour tous les vecteurs colonnes
i
k
c pour lesquels le nombre de
vecteurs collects
j
k
c

est strictement suprieur .

6.1.2.2 Critique du mcanisme de rvocation propos pour les protocoles bass sur
lidentit

Le mcanisme dcrit pour les protocoles bass sur lidentit prsente une efficacit due
lusage des cls pr partages, mais aussi la propagation des messages vers le
voisinage m sauts au lieu de la propagation vers le rseau entier. Cependant il ne peut
pas tre directement appliqu aux protocoles bass sur le certificat. Cela est
principalement d deux facteurs notamment :
1. lusage des cls publiques auto authentifies dans les protocoles bass sur
lidentit ;
2. lusage des cls pr partages pour scuriser les messages daccusation.

En effet dans les protocoles bass sur lidentit les cls publiques des utilisateurs et leur
identit nont pas besoin dtre lies par les certificats. Ainsi les cls publiques dans les

81

protocoles bass sur lidentit sont auto authentifies, ce qui nest pas le cas dans les
autres types de protocoles o lauthenticit des cls publiques ncessite dtre tablie.
Une fois cette authenticit tablie grce aux certificats numriques, il nest plus possible
de rvoquer les cls sans passer par la rvocation des certificats.
En outre le mcanisme de rvocation de cls propos pour les protocoles bass sur
lidentit suppose lexistence de cls pr partages utilises pour scuriser les messages
daccusation. Chaque paire de nuds est en mesure de calculer une cl secrte de paire
pr partage de manire non interactive comme montr par la formule (4). Lusage des
cls secrtes pr partages est surtout favoris par la possibilit de les calculer de
manire non interactive. Ceci permet de rduire la charge globale de calcul et de
communication dans le rseau.
Notons que les cls secrtes de paire peuvent aussi tre drives dans les systmes bass
sur PKI [3]. Cependant ces cls ncessitent lchange authentique des cls publiques
(utilisant les certificats de cls publiques) et ne sont pas drives de manire non
interactive. Par consquent lusage des cls secrtes pr partages prsente peu dintrt
dans les systmes bass sur PKI.
Ainsi le mcanisme dcrit pour les protocoles bass sur lidentit ncessite certaines
modifications afin de ladapter aux protocoles traditionnels bass sur le certificat.

6.2 Proposition dun mcanisme de rvocation pour le
protocole Ubiquitous Security Support (UBIQ)

Notre proposition consiste adapter la solution propose dans [57] et prsente au
paragraphe 6.1.2 lun des protocoles de gestion des cls bass sur PKI notamment
UBIQ.
Ladaptation consistera surtout :
1. fournir un mcanisme permettant la rvocation des certificats la place de la
rvocation des cls publiques ;
2. remplacer lusage des cls pr partages par celui des signatures numriques
pour assurer lauthenticit des messages daccusation.


82

En effet avec les systmes bass sur PKI les certificats garantissent la fiabilit des cls
publiques. Ainsi lon ne peut parler de la rvocation des cls publiques sans passer par
la rvocation des certificats. Dans un systme bas sur PKI rvoquer une cl publique
revient donc rvoquer le certificat utilis pour garantir sa fiabilit.
Dans la solution propose dans [57], lutilisation des cls pr partages est surtout
favorise par la possibilit de calculer ces dernires de faon non interactive. Ce qui ne
prsente pas dintrt avec les systmes qui ne sont pas bass sur lidentit.

6.2.1 Choix du protocole UBIQ

Notre choix de UBIQ repose surtout sur les aspects suivants :
1. problme de la rvocation avec les protocoles de gestion des cls bass sur le
certificat ;
2. problmes relatifs aux approches conventionnelles ;
3. certaines caractristiques du protocole UBIQ (Ubiquit, Robustesse).
Lanalyse des protocoles de gestion des cls a montr que le problme cit en 1.) reste
un cas non rsolu pour les protocoles cl publique, plus particulirement ceux bass
sur le certificat. Ltude des travaux relatifs la rvocation montre que la solution de
rvocation [55] propose pour le protocole UBIQ prsente des lacunes et donc jusquici
il nexiste pas de solution.
Le protocole UBIQ se fonde sur une approche diffrente de celles utilises par les
protocoles conventionnels qui prsentent certains problmes notamment ceux souligns
en 2.). En effet les approches communes, notamment centralises et hirarchiques, ne
sont pas adaptes aux rseaux mobiles de grande taille. Dans lapproche centralise, une
seule autorit de certification CA fournit les services de certification pour le rseau
entier, ainsi dans un large rseau mobile le problme li lextensibilit est vident. De
plus pour laspect scurit la CA sera expose comme tant un unique point de
dfaillance en cas de panne, de compromission ou dattaque de type DoS.
Dans une approche hirarchique le rseau entier est logiquement partitionn en
domaines o des CAs locales sont dployes. Cest aussi lapproche discute dans [14]
o des CAs collaboratives sont dployes comme point daccs pour des services de

83

scurit. Cette approche semble adapte un large rseau mobile. Cependant plusieurs
caractristiques des rseaux mobiles, par exemple la grande mobilit, la rendent
inefficace. De plus dans les rseaux ad hoc la CA locale peut tre multi sauts et peut
galement se dplacer. Cela cause non seulement un repartitionnement dynamique du
rseau mais galement rend plus complexe le problme de la localisation dune CA
locale. Chaque CA locale est expose comme unique point de compromission ou
dattaque de type DoS.
UBIQ distribue les fonctions dautorit de certification laide dun mcanisme de
partage secret seuil selon lequel chaque entit dtient une part secrte et des entits
multiples dans un voisinage local fournissent conjointement des services complets. Ce
qui assure lubiquit du protocole. Aussi UBIQ met jour les parts secrtes pour
accrotre la robustesse.

6.2.2 Fonctionnement du mcanisme de rvocation de certificats
propos

Les hypothses suivantes ncessaires pour le rseau et les nuds sont poses selon
celles donnes pour le mcanisme dcrit dans [57] et cites au paragraphe 6.1.2 :
1. il existe de liens de communication bidirectionnels ;
2. il existe des systmes de surveillance dj mis en place sur les nuds ;
3. chaque nud a un certificat numrique unique ;
4. les nuds connaissent la distance pour un saut ;
5. les nuds dtiennent les certificats de tous les nuds de leur voisinage m
sauts ;
Les deux premires hypothses sont ncessaires pour permettre aux nuds de surveiller
leurs voisins dun saut. Les liens bidirectionnels sont des hypothses usuelles requises
pour plusieurs protocoles MANET des couches infrieures comme AODV (Ad hoc On-
Demand Distance Vector) et autres protocoles de routage bass sur celui-ci. La
troisime hypothse est ncessaire pour identifier de manire unique le certificat dun
nud. La quatrime hypothse est requise car les nuds voisins ont besoin dtre
identifi sans ambigut avant que lon ne puisse les marqus comme suspects ou fiables

84

dans le mcanisme de rvocation. La cinquime hypothse est ncessaire pour permettre
aux nuds de dcider concernant les valeurs daccusation quils doivent considrer afin
de mettre jour leurs listes de rvocation.
Comme nous lavons dj soulign le mcanisme permet la rvocation des cls
publiques travers la rvocation de certificats et utilise les systmes de signature
numrique pour assurer lauthenticit des messages daccusation. Il comporte trois
algorithmes.
La diffrence avec les algorithmes dj exposs rside au niveau de :
lutilisation des listes de rvocation de certificats la place des listes de
rvocation de cls ;
lutilisation des signatures numriques la place des cls pr partages pour
scuriser les messages daccusation.

Algorithme1 : Neighborhood watch

Le Neighborhood watch est un contrle local dans lequel chaque nud
i
ID

surveille ses
voisins dun saut nots par
i
N
j
ID avec { }
i
N j ,..., 1 , o
i
N est le nombre de voisins
dun saut du nud
i
ID . Lutilisateur
i
ID stocke des valeurs daccusation
i
j i
a
,
pour
chaque nud
i
N
j
ID avec une priode de validit
i
j
vp

du certificat de celui-ci. Un
nud
i
ID fixe ses valeurs daccusation 1
,
=
i
j i
a

sil observe que
j
ID se comporte de
manire suspecte, autrement 0
,
=
i
j i
a . Les valeurs daccusation cres par
i
ID partir de
son Neighborhood watch peuvent tre reprsentes sous forme de matrice
daccusation
i
AM .

,
1 , 1 1
|
|
|
|
|
|
|
\
|

=
i
i
N i
i
i
N
i
N
i
i
i
i
a vp Cert
a vp Cert
AM


85

{ } { } ,..., 1 et 1 , 0 avec
, i
i
j i
N j a . Chaque vecteur ligne ) (
j
i
ID r

ou
i
j
r dans
i
AM ,
correspond un voisin

i
N
j
ID . Il contient le numro de srie du certificat
j
Cert du
nud
j
ID , sa priode de validit
i
j
vp et la valeur daccusation
i
j i
a
,
affecte
j
Cert .
Nous nous rfrons la troisime colonne dans
i
AM comme vecteur colonne
i
i
c , qui
contient toutes les accusations faites par
i
ID . Les valeurs daccusation sont mises jour
chaque fois que
i
ID observe un comportement suspect. Une fois que
i
j i
a
,
est fix, la
valeur nest pas remise zro tant quun nouveau certificat '
j
Cert contenant une
nouvelle cl publique '
j
Q nest pas reu.

Algorithme2 : Harakiri

Quand un nud
i
ID ralise que sa cl prive
i
d a t compromise, il diffuse un harakiri
message
i
hm sous le format suivant :

) sign , hopcount) , revoque" " , vp , ((Cert hm
i i i i
=
,

travers son voisinage m sauts not par
i
N m . Ce voisinage est constitu par
lensemble des nuds situs une distance infrieure ou gale m fois la porte de
transmission du nud
i
ID . Initialement
i
ID

fixe le hopcount m et envoie le message
tous ses voisins dun saut. Les rcepteurs
j
ID vrifient lauthenticit et lintgrit du
harakiri en utilisant la signature reue
i
sign . Ainsi
j
ID vrifie la signature
i
Sign avec
la cl publique
i
Q contenue dans le certificat
i
Cert .
Le contrle vrifie si le nud
i
ID est rellement le propritaire du certificat inclus dans
le harakiri message et sil a la possession de la cl prive
i
d correspondant la cl
publique
i
Q . En cas de succs de la vrification,
j
ID met jour sa valeur daccusation
1
,
=
j
i i
a
, dcrmente le hopcount et diffuse le message nouveau. Autrement,
i
hm est
ignor. La diffusion est rpte jusqu ce que lon ait hopcount = 0. Cela assure que

86

tous les nuds dans le voisinage m sauts du nud compromis
i
ID ont reu le harakiri
message et sont ainsi informs de la compromission dune cl.

Algorithme3 : Accusation

Cet algorithme dcrit la cration de listes de rvocation de certificats, la propagation
scurise et la mise jour de ces listes.

Algorithme3.1 : Cration de liste de rvocation de certificats
La diffrence par rapport lAlgorithme 3.1 du paragraphe 6.1.2.1 rside au niveau des
deux premires colonnes de la matrice reprsentant la liste de rvocation de certificats.
Ici la premire colonne contient les numros de srie des certificats des diffrents nuds
du voisinage m sauts au lieu de leurs identits. La deuxime colonne comporte la
priode de validit de ces certificats au lieu de la date dexpiration et de la version de la
cl publique des diffrents nuds du voisinage m sauts.
Chaque nud
i
ID cre une liste de rvocation de certificats
i
CRL selon le format
suivant :

|
|
|
|
|
|
|
\
|

=
i
i
M
i
M
i
i
M
i
i
M
i
i
M
i
M
i
i
M
i i i
i
a a R vp Cert
a a R vp Cert
CRL
, 1 ,
, 1 1 , 1 1 1 1

avec
{ } { }
i
i
k j
M j a ...., 1, k , et - 1, , 0
,

ou
i
M

est le nombre de nuds dans le
voisinage m sauts
i
N m de
i
ID , incluant
i
ID lui-mme. La valeur daccusation
=
i
k j
a
,
indique que
j
ID et
k
ID sont plus de m sauts lun par rapport lautre. Ainsi
chacun de ces nuds ne peut pas se prononcer sur la fiabilit de lautre. Chaque vecteur
ligne
i
j
r dans
i
CRL correspond un nud

i
N m ID
j
.
i
j
r contient les valeurs

87

daccusation
i
k j
a
,
de tous les nuds
i
N m ID
k
contre le nud
j
ID . Chaque vecteur
colonne
i
j
c dans
i
CRL contient toutes les accusations
i
j k
a
,
portes par le nud
j
ID

contre tous les nuds
i
N m ID
k
. Lindex i montre que les valeurs sont celles
courantes dans la liste de rvocation de
i
ID .
Le premier champ dans chaque ligne
i
j
r de
i
CRL

contient le numro de srie du
certificat
j
Cert

du nud
j
ID . Le second champ contient la priode de validit
i
j
vp de
j
Cert . Le troisime champ contient un indicateur
i
j
R qui, lorsquil est fix 1, indique
que le nud
i
ID

considre le certificat
j
Cert du nud
j
ID

comme rvoqu. Les champs
allant de 4 la fin

contiennent les valeurs daccusation
i
i
M j
i
j
a a
, 1 ,
,...,
, o la valeur
1
,
=
i
k j
a
indique que le nud
k
ID accuse le nud
j
ID , et
0
,
=
i
k j
a

sinon. Les
indicateurs de rvocation
i
j
R dans la liste de rvocation de certificats
i
CRL de
i
ID

sont
fixs, c'est--dire 1 =
i
j
R si une des quatre conditions suivantes est vraie :
Condition 1 :
1
,
=
i
i j
a
, cela signifie que le nud
i
ID

observe lui-mme le
comportement malicieux du nud
j
ID

durant le neighborhood
watch (Alg.1). Ce qui implique que
j
ID

et
i
ID

sont des voisins
dun saut ;
Condition 2 :
i
j
vp est expire, cela signifie que la copie courante du certificat
j
Cert

de
j
ID est expire;
Condition 3 :
1
,
=
i
j j
a
, cela signifie que
i
ID

a reu un harakiri message
authentique j
hm
de
j
ID ;
Condition 4 :
> =
=
i
M
k
i
k j
i
j
a A
1
,

pour tout k , tel que 0 =
i
k
R ; cela consiste
additionner toutes les valeurs daccusation
i
k j
a
,
du vecteur ligne
i
j
r

des nuds non rvoqus
k
ID

, et vrifier si la somme est

88

suprieure . En dautres termes le certificat
j
Cert

est rvoqu
si le nud
i
ID reoit plus de accusations partir dun nud
fiable
k
ID

contre un nud suspect
j
ID .

est un seuil de scurit
dtermin comme dcrit au paragraphe 6.2.3.2.
Si aucune des ces quatre conditions nest satisfaite, alors 0 =
i
j
R ; c'est--dire
j
ID et sa
cl publique courante sont considrs comme fiables.

Algorithme 3.2 : Propagation daccusations
i
ID met jour sa matrice daccusation
i
AM , car ayant
observ un certain comportement suspect dans son neighborhood watch, il envoie un
message daccusation ses voisins dun saut. De manire similaire, chaque fois que
i
ID
met jour sa liste de rvocation de certificats
i
CRL , car ayant reu des accusations
partir dautres nuds, il envoie un message daccusation ses voisins. Les messages
daccusation envoys par
i
ID ont le format suivant :

) , ) , ((
, i i i j i
sign am Cert am =
pour tout
i
N
j
ID

o
i
i
AM am =

pour des mises jour partir du neighborhood watch de
i
ID , et
i
i
CRL am =

pour des mises jour de liste de rvocation causes par des messages
daccusation reus par
i
ID en provenance dautres nuds. Les messages daccusation
j i
am
,
sont scuriss en utilisant la signature
i
sign du nud
i
ID

et sont alors envoys
chaque voisin dun saut

j
ID . Aprs avoir reu
j i
am
,
, un nud voisin
j
ID vrifie le
message reu en utilisant la signature
i
sign . En cas de succs,
j
ID met jour sa liste de
rvocation de certificats
i
CRL

conformment, comme expliqu dans lalgorithme 3.3.


89

Algorithme 3.3 : Mise jour de listes de rvocation de certificats
La diffrence par rapport lAlgorithme 3.3 du paragraphe 6.1.2.1 se situe au niveau de
la vrification de lauthenticit des messages daccusation (Etape 2). Ici nous utilisons
la signature numrique la place de la cl pr partage pour cette vrification.
i
ID reoit un harakiri message
j
hm
partir de
j
ID , il vrifie
le message comme dcrit dans lAlg.2, et en cas de succs, le nud
i
ID fixe
1
,
=
i
j j
a
et
ainsi
1 =
i
j
R
dans sa liste de rvocation
i
CRL (voir Cond. 3 dans lAlg.3.1). Si un nud
i
ID reoit un message daccusation
i j
am
,
partir dun voisin dun saut
j
ID , alors il
excute les tapes suivantes pour mettre jour sa liste de rvocation de certificats
i
CRL :
Etape 1 : Vrifier si
0 =
i
j
R
, c'est--dire si
i
ID

considre le nud
j
ID comme
fiable ; si tel est le cas continuer lexcution, sinon ignorer
i j
am
,
et
arrter ;
Etape 2 : Vrifier lauthenticit de
i j
am
,
en utilisant la signature
i
sign comme
dcrit dans lAlg.3.2 ; en cas de succs continuer lexcution, sinon
ignorer
i j
am
,
et arrter ;
Etape 3 : Extraire le vecteur colonne
j
j
c de
j
AM ou
j
CRL

de
i j
am
,
pour mettre
jour le vecteur colonne
i
j
c dans
i
CRL , c'est--dire adopter les
valeurs daccusation du neighborhood watch de
j
ID . Notons que
i
ID
utilise uniquement les valeurs daccusation adresses aux nuds de
son propre voisinage m sauts, les autres valeurs daccusation son
ignores. Si
j
j
AM am =

arrter lexcution, sinon continuer ;
Etape 4 : Ignorer toutes les colonnes
j
k
c de
j
CRL pour :
- i k = , car il sagit du propre vecteur daccusation de
i
ID ;
- j k = , car dj utilis dans ltape 3 ;

90

- l k = , pour tout 1 =
i
l
R avec { }
i
M l ,..., 1 car
i
ID ne fait plus
confiance aux nuds
l
ID ;
- r k = , pour tout les
i r
am
,
dj accepts ltape 2 ;
- s k = , pour tout
i
N m ID
s
, c'est--dire les nuds qui sont situs
plus de m sauts.
Sauver toutes les autres colonnes
j
k
c .

Maintenant
i
ID rpte les tapes allant de 1 4 pour tous les messages daccusation
i j
am
,

reus. Considrons que
i
ID a sauv
k
d

vecteurs colonnes
j
k
c partir de
k
d

nuds
j
ID diffrents pour le mme
k
ID ltape 4. Pour tout
>
k
d
,
i
ID excute
ltape 5.

est un seuil de scurit dtermin comme dcrit au paragraphe 6.2.3.2.
Etape 5 : Utiliser tous les
k
d

vecteurs colonnes
j
k
c sauvs ltape 4 pour
mettre jour le vecteur colonne
i
k
c de
i
CRL . La mise jour est faite
en utilisant le vote majoritaire pour chaque lment du vecteur
colonne. La majorit pour chaque valeur daccusation
j
k l
a
,
avec
{ }
i
M l ,..., 1

est calcule comme suit :

{ } { }
{ } { }
<
>
=

=
=
. autrement ,
; ,..., 1 et ,..., 1 avec , 2 / , 0
; ,..., 1 et ,..., 1 avec , 2 / , 1
,
1
,
1
,
,
i
k l
k i
k
d
j
k
j
k l
k i
k
d
j
k
j
k l
i
k l
a
d j M l d a si
d j M l d a si
a


91

Pour la simplicit nous avons suppos que
i
ID a sauv
k
d
vecteurs
colonnes
i
k
c partir de
k
d
voisins
j
ID avec { }
k
d j ,..., 1 ltape 4,
avec

k
d
.
Seules les valeurs
j
k l
a
,
pour les nuds
l
ID du voisinage m sauts
de
i
ID sont considres, les autres sont ignores. Si aucune majorit
ne peut tre trouve, la valeur daccusation reste inchange. Le nud
i
ID rpte ceci pour tous les vecteurs colonnes
i
k
c pour lesquels le
nombre de vecteurs collects
j
k
c est > .

6.2.3 Analyse du mcanisme de rvocation de certificats
Lanalyse consiste montrer comment notre contribution supprime ou diminue les
failles de scurit inhrentes UBIQ. Pour cela nous essayons tout dabord didentifier
les attaques qui exploitent ces failles.

6.2.3.1 Identification des attaques qui exploitent les failles de scurit inhrentes
UBIQ

Ltude des protocoles de gestion des cls a montr que UBIQ prsente certaines failles
de scurit. Ici nous identifions les attaques qui exploitent ces failles et montrons
comment notre proposition supprime ou diminue limpact de ces failles.

Le protocole UBIQ dpend dune autorit off-line pour lauthentification des
nuds. Pour paralyser le fonctionnement du protocole un adversaire peut
employer des attaques de type DoS visant empcher ou limiter l'accs
lautorit off-line ;
UBIQ se base sur une hypothse contraignante (pour chaque nud le nombre
de voisins dun saut est suprieur ou gal au seuil k) et manque de moyen
pour ajuster le seuil k en cas de variation de densit dans le rseau. Une

92

attaque DoS visant modifier celle-ci empchera la satisfaction de cette
hypothse ;
Le protocole dpend fortement de la coopration des nuds pour lobtention
dune signature complte dun certificat ainsi que la mise jour de parts
secrtes. Il est alors possible pour un adversaire dutiliser cette collaboration
pour mettre en uvre les attaques suivantes : Dos, coute clandestine,
usurpation, modification, et attaque physique dun lment valide afin de
mettre en pril la scurit du systme ;
Le protocole implique des charges de calcul et de communication
contraignantes pour les priphriques dun MANET do la vulnrabilit
une attaque Dos.

6.2.3.2 Analyse du mcanisme de rvocation de certificats propos
La faille de scurit selon laquelle UBIQ dpend de la coopration des nuds pour la
gestion de la scurit des cls implique des vulnrabilits qui peuvent tre adresses par
la rvocation.
En effet ces vulnrabilits peuvent conduire la compromission de la confidentialit et
de lauthenticit des cls.
Le neighborhood watch de notre mcanisme peut dtecter la compromission et
lgosme des nuds qui sont trs frquents dans lenvironnement des MANETs.
Dans notre proposition les certificats des nuds malicieux sont dabord rvoqus
localement par les voisins dun saut et ventuellement par tous les nuds du voisinage
m sauts. Ainsi les utilisateurs malveillants qui contrlent les nuds compromis sont
exclus du rseau car ils ne peuvent plus solliciter de nouveaux certificats puisque cela
ncessite lauthentification auprs de lautorit off-line.
Dautre part, les nuds gostes sont encourags participer en expdiant les messages
daccusation des autres nuds car autrement ils sont forcs renouveler frquemment
leur cl, ce qui est plus coteux.
Les nuds malicieux ne peuvent pas manipuler simplement des accusations portes
contre eux-mmes parce quils seraient dtects par le neighborhood watch et une
tentative serait empche en utilisant des votes majoritaires de lAlgorithme 3.3 pour les

93

accusations. Un adversaire mobile
i
ID peut se dplacer chaque fois que le nombre
daccusations portes contre lui approche . Un adversaire mobile peut aussi se
dplacer vers un nouveau voisinage situ plus de m sauts, de sorte que personne nait
une valeur daccusation pour lui. Cependant dans les deux cas ses voisins actuels dun
saut dtectent rapidement son comportement malveillant et rvoquent localement son
certificat. Avec les accusations se propageant vers tous les voisins m sauts,
ladversaire devra se dplacer plus rapidement que la propagation. Ainsi le pouvoir des
adversaires mobiles de lancer une attaque est assez limit puisquils doivent se dplacer
frquemment et assez rapidement, et ne peuvent pas demeurer sur le mme
emplacement pour une longue priode.
Les paramtres de scurit

et
sont utiliss pour empcher les attaques par coalition

de nuds malicieux et permettent de neutraliser les inexactitudes du mcanisme de
surveillance implment dans les nuds. Il existe des limites universelles pour ces
paramtres savoir
i
M 1 et
i
N 1 avec
i
M le nombre de nuds dans le
voisinage m sauts du nud
i
ID

et
i
N le nombre de voisins dun saut du nud
i
ID

[3].
Typiquement pour le fonctionnement du mcanisme de rvocation
i
M << mais la
valeur relle de dpend de lhostilit et de la topologie du rseau. La rfrence [3]
donne des bornes plus prcises pour la slection de ces paramtres telles que les
attaques par coalition de nuds soient prvenues. Ces bornes sont dcrites par les
relations (7) et (8) :

i
N / ] 1 2 / [ + <
(7)

i
N / < (8)

o est un autre paramtre donn par :

i
n
i
m
n n =
(9)


94

avec
i
m
n
: le nombre de nuds malicieux voisins dun saut du nud
i
ID ,

i
n
n : le nombre de nuds malicieux non dtects voisins dun saut du nud
i
ID ,
Les nuds malicieux peuvent essayer de contourner le paramtre de scurit

en
inventant identits diffrentes. Cependant cela est empch par lautorit off-line qui
est suppose vrifier lidentit de chaque nud avant la dlivrance dun certificat.
En dfinitive on peut dire que la scurit du mcanisme de rvocation propos dpend
des paramtres suivants :
le paramtre de scurit qui protge les nuds contre les fausses
accusations ;
le paramtre qui constitue le seuil requis pour la rvocation de certificats ;
le paramtre m qui peut protger le systme contre les adversaires mobiles
lorsque celui-ci est ajust.

6.2.4 Cot du programme

Nous valuons la performance du programme reprsentant notre algorithme de
rvocation en valuant sa complexit temporelle. Cette complexit dtermine le temps
ncessaire lexcution de notre algorithme. Ainsi dans notre valuation nous comptons
le nombre doprations lmentaires au cours de lexcution de notre programme. Les
oprations lmentaires considres sont :
- la comparaison ;
- laffectation ;
- les oprations : addition (+), multiplication (*), soustraction (-), division ( / )
etc.
Nous nous intressons la complexit au pire des cas ou complexit maximale. Celle-ci
tant le temps dexcution maximum pour des donnes de taille n.
En pratique, on choisit comme taille la ou les dimensions les plus significatives.
Exemple si le problme est modlis par :
- des polynmes : le degr, le nombre de coefficients non nuls ;
- des tableaux : le nombre dlments ;
- des matrices : les dimensions n, m.

95

Nous avons dtermin la complexit des diffrents sous programmes proposs. Ceci
nous a permis dvaluer la complexit ) (n T de tout le programme au pire des cas.
Nous avons eu comme rsultat:

112 133 88 12 ) (
2 3
+ + + = n n n n T

Le rsultat obtenu montre que ) (n T et
3
n sont de mme ordre de grandeur
asymptotique. ) (n T est en ) (
p
n avec 3 > p , lalgorithme est alors dit polynomial et
est encore efficace pour n pas trop grand.


96

VII. TESTS ET VALIDATION DU
MECANISME DE REVOCATION DE
CERTIFICATS

Notre objectif est de valider notre proposition. Pour ce faire nous proposons
limplmentation de notre proposition en C en crivant un programme nomm
Rvocation incluant les fonctions suivantes (voir Annexe):

maMatriceAM ( ) qui permet de marquer un nud suspect dans la matrice
daccusation AM donne en paramtre conformment lAlgorithme 1;
messageHarakiri ( ) qui retourne le contenu dun message harakiri
conformment lAlgorithme 2. Elle prend en paramtre le numro de srie
du certificat de celui qui envoie le message, ainsi que le nombre de sauts que
le message doit atteindre ;
maCRL ( ) qui permet dappliquer les rgles de rvocation la liste de
rvocation de certificats donne en paramtre conformment lAlgorithme
3.1. Elle prend aussi en paramtre un certificat qui indique lappartenance de
la liste de rvocation de certificats;
messageAMmisajour ( ) donne le contenu dun message daccusation en cas
de mise jour de matrice daccusation conformment lAlgorithme 3.2. Elle
prend en paramtre le certificat de celui qui envoie le message daccusation
ainsi que sa matrice daccusation AM ;
messageCRLmisajour ( ) similaire messageAMmisajour mais concerne les
mises jour de liste de rvocation de certificats ;
receptionHarakiri ( ) prend en paramtre un message harakiri et la liste de
rvocation du destinataire. Elle permet la mise jour de cette dernire aprs
rception dun message harahiri conformment lAlgorithme 3.3;

97

etape1a4 ( ) et etape4fin ( ) suivent les diffrentes tapes de lAlgorithme 3.3
pour mettre jour la liste de rvocation du destinataire aprs rception dun
message daccusation ;
intermediaireEtape5 ( ) et MatricePourVote ( ) fournissent les oprations
ncessaires avant le passage ltape 5 de lAlgorithme 3.3 ;
etape5 ( ) prend en paramtre la liste de rvocation du destinataire, c'est--
dire le rcepteur du message daccusation, et termine la mise jour de cette
dernire.

Les tests russissent lorsque :
le nud source du message daccusation est considr comme fiable, c'est--
dire na pas t rvoqu de la liste de rvocation du destinataire par
consquent 1
i
j
R dans la matrice reprsentant cette liste;
lissue des diffrentes tapes du processus de mise jour de la liste de
rvocation de certificats nous obtenons une mise jour de la liste de
rvocation du destinataire manifeste par la mise jour des valeurs
daccusation conformment lAlgorithme 3.3.

Les tests chouent lorsque :
le nud source du message daccusation nest plus considr comme lgitime
c'est--dire lorsque le nud source du message daccusation est rvoqu de la
liste de rvocation du nud destinataire. Ce qui correspond 1 =
i
j
R ;
lorsque le rsultat escompt nest pas obtenu, c'est--dire lorsque la mise jour
de la liste de rvocation du destinataire ne sest pas effectue conformment
lAlgorithme 3.3.


98

7.1 Simulation du processus de maintien des listes de
rvocation de certificats jour

Nous reprenons lexemple utilis par la rfrence [57] pour illustrer le fonctionnement
du mcanisme de rvocation de certificats propos.
Nous prsentons un scnario de rseau simple constitu de six nuds
i
ID avec { } 6 ... 1 i
comme montr sur la Figure 7.1. Ces nuds maintiennent des listes de rvocation de
certificats pour les nuds situs m sauts. Nous fixons les paramtres 2 = m , 3 = et
2 = conformment lexemple dcrit dans [57].

Figure 7. 1: Exemple de reprsentation de rseau

A linstant initial
0
t chaque nud
i
ID { } 6 ... 1 i du rseau a une liste de rvocation de
certificats
i
CRL qui scrit comme suit :


99

|
|
|
|
|
|
\
|
=
0 0 0 0 0 0 2009 5000
0 0 0 0 0 0 2011 4000
0 0 0 0 0 0 2009 3000
2 0 0 0 0 0 2010 2000
0 0 0 0 0 0 2009 1000
1
CRL

|
|
|
|
|
\
|
=
0 0 0 0 0 2011 4000
0 0 0 0 0 2009 3000
0 0 0 0 0 2010 2000
0 0 0 0 0 2009 1000
2
CRL

|
|
|
|
|
|
|
|
\
|
=
0 0 0 0 2 2 0 2012 6000
0 0 0 0 2 0 0 2009 5000
0 0 0 0 0 0 0 2011 4000
0 0 0 0 0 0 0 2009 3000
2 2 0 0 0 0 0 2010 2000
2 0 0 0 0 0 0 2009 1000
3
CRL

|
|
|
|
|
|
|
|
\
|
=
0 0 0 0 2 2 0 2012 6000
0 0 0 0 2 0 0 2009 5000
0 0 0 0 0 0 0 2011 4000
0 0 0 0 0 0 0 2009 3000
2 2 0 0 0 0 0 2010 2000
2 0 0 0 0 0 0 2009 1000
4
CRL

|
|
|
|
|
|
\
|
=
0 0 0 0 2 0 2012 6000
0 0 0 0 0 0 2009 5000
0 0 0 0 0 0 2011 4000
0 0 0 0 0 0 2010 3000
2 0 0 0 0 0 2009 1000
5
CRL

|
|
|
|
|
\
|
=
0 0 0 0 0 2012 6000
0 0 0 0 0 2009 5000
0 0 0 0 0 2011 4000
0 0 0 0 0 2009 3000
6
CRL

Les dimensions des matrices
i
CRL

sont dtermines par le nombre de nuds dans le
voisinage m sauts de chaque nud
i
ID .
Les valeurs de la premire et de la deuxime colonne des listes de rvocation de
certificats
i
CRL reprsentent respectivement les numros de srie des certificats des
nuds du rseau et les priodes de validit de ces certificats exprimes par la dernire
anne de validit. Elles sont choisies de manire arbitraire.
A linstant initial
0
t , toutes les valeurs daccusation sont fixs 0 exceptes les valeurs
daccusation
i
k j
a
,

pour lesquelles les nuds
j
ID et
k
ID sont plus de m sauts lun par
rapport lautre. Celles-ci sont arbitrairement fixes 2. Cependant il est possible de
choisir au autre entier suprieur 2.
On considre que les messages daccusation se propagent de manire priodique avec
une priode
.
Nous proposons une srie de tests ou expriences, dont le but est de montrer le
processus permettant de maintenir les listes de rvocation de certificats jour, suite la
propagation de messages daccusation dans le rseau (expriences 1, 2 et 3).


100

7.1.1 Exprience 1 : Accusation du nud
5
ID

A linstant t =
0
t +
:
Le nud
5
ID envoie un message daccusation
5
am ses voisins dun saut
4
ID et
6
ID .
Dans ce message il accuse le nud
3
ID et fixe la valeur daccusation
5
5 , 3
a 1 dans sa
liste de rvocation de certificats et rvoque le certificat de ce nud , ce qui fixe la valeur
5
3
R 1.
Comme donnes dentre nous avons la liste de rvocation du nud
5
ID ainsi que celles
des nuds
4
ID et
6
ID avant mise jour.

|
|
|
|
|
|
\
|
=
0 0 0 0 2 0 2012 6000
0 0 0 0 0 0 2009 5000
0 0 0 0 0 0 2011 4000
0 1 0 0 0 1 2010 3000
2 0 0 0 0 0 2009 1000
5
CRL

|
|
|
|
|
|
|
|
\
|
=
0 0 0 0 2 2 0 2012 6000
0 0 0 0 2 0 0 2009 5000
0 0 0 0 0 0 0 2011 4000
0 0 0 0 0 0 0 2009 3000
2 2 0 0 0 0 0 2010 2000
2 0 0 0 0 0 0 2009 1000
4
CRL

|
|
|
|
|
\
|
=
0 0 0 0 0 2012 6000
0 0 0 0 0 2009 5000
0 0 0 0 0 2011 4000
0 0 0 0 0 2009 3000
6
CRL

La fonction messageCRLmisajour ( ) est appele dans le programme pour signifier la
rception dun message daccusation contenant la liste de rvocation du nud
5
ID par le
nud
4
ID .
Lappel des fonctions etape1a4 ( ) et etape1a4fin ( ) doit permettre lexcution des
tapes de lAlgorithme 3.3 ncessaires pour la mise jour de la liste de rvocation du
nud destinataire
4
ID .
- Ltape 1 de la fonction etape1a4 ( ) doit sauver le message daccusation
5
am car dans
4
CRL 0
4
5
= R ;

101

- Ltape 3 est excute par lappel de la fonction etape1a4fin ( ), celle-ci
doit utiliser le vecteur colonne
5
5
c de
5
CRL pour mettre jour le vecteur
colonne
4
5
c de
4
CRL .
Le rsultat attendu est la matrice suivante :

|
|
|
|
|
|
|
|
\
|
=
0 0 0 0 2 2 0 2012 6000
0 0 0 0 2 0 0 2009 5000
0 0 0 0 0 0 0 2011 4000
0 1 0 0 0 0 0 2009 3000
2 2 0 0 0 0 0 2010 2000
2 0 0 0 0 0 0 2009 1000
4
CRL

Le mme processus doit tre excut pour donner :

|
|
|
|
|
\
|
=
0 0 0 0 0 2012 6000
0 0 0 0 0 2009 5000
0 0 0 0 0 2011 4000
0 1 0 0 0 2009 3000
6
CRL

Aprs excution des fonctions nous obtenons les rsultats suivants :

Figure 7. 2 : Liste de rvocation envoye par
5
ID et reue par
4
ID et
6
ID .

Figure 7. 3 : Liste de rvocation du nud
4
ID aprs mise jour.

102

6
ID aprs mise jour.

Nous constatons que les listes de rvocation des nuds
4
ID et
6
ID ont t mises jour.
Les valeurs daccusation
4
5 , 3
a et
6
5 , 3
a sont fixes 1 respectivement dans
4
CRL et
6
CRL .
Ainsi les rsultats correspondent ceux qui taient attendus.
7.1.2 Exprience 2 : Propagation dun message daccusation

A linstant t =
0
t + 2 :
Le nud
4
ID envoie un message daccusation au nud voisin
1
ID . Ce message
concerne une mise jour de liste de rvocation de certificats et constitue la suite de la
mise jour prcdemment dcrite.
Puisque la source de cette mise jour provient dun nud qui nappartient pas au
voisinage dun saut du nud
1
ID , la mise jour du vecteur colonne
1
5
c se fera par vote
majoritaire. Pour cela la majorit pour chaque valeur daccusation doit tre calcule
comme dcrit ltape 5 de lAlgorithme 3.3. Cependant le nombre de vecteurs
colonnes sauvs pour le mme nud
5
ID est infrieur au minimum requis c'est--dire
2 1
5
= < = d . Par consquent la mise jour de la liste de rvocation du nud
1
ID ne
sera pas effectue.

7.1.3 Exprience 3 : Accusations des nuds
2
ID ,
3
ID

et

4
ID

A linstant t =
0
t + , tant un entier tel que 2 > :

103

Le nud
1
ID met jour sa liste de rvocation
1
CRL aprs avoir reu les messages
daccusation
4 3 2
, , am am am de ses voisins dun saut.
Nous donnons en entre la liste de rvocation du nud
1
ID avant la mise jour, ainsi
que celles des nuds
4
ID et
3
ID mises jour.

|
|
|
|
|
|
\
|
=
0 0 0 0 0 0 2009 5000
0 0 0 0 0 0 2011 4000
1 0 0 0 0 0 2009 3000
2 0 0 0 1 1 2010 2000
0 0 0 0 0 0 2009 1000
1
CRL

|
|
|
|
|
|
|
|
\
|
=
0 0 1 1 2 2 1 2012 6000
1 0 1 1 2 0 1 2009 5000
1 1 0 0 0 0 0 2011 4000
2 0 0 0 1 0 0 2009 3000
2 2 1 1 0 1 1 2010 2000
2 1 0 0 1 0 0 2009 1000
3
CRL

|
|
|
|
|
|
|
|
\
|
=
0 1 1 1 2 2 1 2012 6000
1 0 1 1 2 0 1 2009 5000
1 0 0 0 0 0 0 2011 4000
2 1 0 0 1 0 0 2009 3000
2 2 1 1 0 1 1 2010 2000
2 0 0 0 1 0 0 2009 1000
4
CRL

Dans le programme principal nous trouvons :
- lappel de la fonction messageCRLmisajour ( ) selon lAlgorithme 3.2 ;
- lappel des fonctions etape1a4 ( ), etape1a4fin ( ), MatricePourVote ( ) et
etape5 ( ) selon lAlgorithme 3.3.
La fonction messageCRLmisajour ( ) a t appele deux fois dans le programme
principal pour signifier la rception de deux messages daccusation par le nud
1
ID .
Ces messages proviennent des nuds
3
ID et
4
ID et concernent des mises jour de liste
de rvocation de certificats.
Les fonctions etape1a4 ( ), etape1a4fin ( ) et etape5 ( ) vont se charger de lexcution
des diffrentes tapes de lalgorithme 3.3 pour la mise jour de la liste de rvocation de
certificats du nud
1
ID .
Aprs excution des fonctions nous attendons les rsultats suivants :


104

- Ltape 1 de la fonction etape1a4 ( ) doit sauver les messages daccusation
3
am et
4
am car dans
1
CRL 0
1
3
= R et 0
1
4
= R ;
- Ltape 3 est excute par lappel de la fonction etape1a4fin ( ), celle-ci
doit utiliser les vecteurs colonnes
3
3
c de
3
CRL et
4
4
c de
4
CRL pour mettre
jour les vecteurs colonnes
1
3
c et
1
4
c respectivement de
1
CRL ;
- Ltape 4 de la fonction etape1a4 ( ) doit permettre dcarter partir de
3
CRL les vecteurs colonnes suivants :

3
1
c car 1 = = i k ;

3
2
c car 1
1
2
= R ;

3
3
c car 3 = = j k ;

3
4
c car
4
am a t accept dans ltape 2 ;
Ainsi seul le vecteur colonne
3
5
c de
3
CRL doit tre sauv. Pour des arguments
similaires seul
4
5
c doit tre sauv de
4
CRL .
Puisque le nombre de colonnes sauves pour le mme nud
5
ID est gal au
minimum requis c'est--dire 2 2
5
= = d nous continuons avec le vote
majoritaire. Pour cela nous faisons appel aux fonctions intermediaireEtape5 ( ) et
MatricePourVote ( ).
- La fonction etape5 ( ) doit utiliser les deux vecteurs colonnes
3
5
c et
4
5
c
sauvs pour
5
ID et mettre jour le vecteur colonne correspondant
1
5
c ce
qui complte la mise jour de
1
CRL .

|
|
|
|
|
|
|
|
\
|
=
0
0
1
0
2
1
3
5
c
,
|
|
|
|
|
|
|
|
\
|
=
1
0
0
1
2
0
4
5
c
,
|
|
|
|
|
|
\
|
=
0
0
1
2
0
1
5
c

La fonction doit alors donner le rsultat suivant :


105

|
|
|
|
|
|
\
|
=
0 1 1 0 0 0 2009 5000
0 0 0 0 0 0 2011 4000
1 0 0 0 0 0 2009 3000
2 1 1 0 1 1 2010 2000
0 0 0 0 0 0 2009 1000
1
CRL

Aprs excution des fonctions prcdemment cites nous avons les rsultats suivants :

Figure 7. 5 : Listes de rvocation reues par le nud
1
ID

La Figure 7.5 montre les listes de rvocation mises jour envoyes respectivement par
les nuds
3
ID et
4
ID au nud
1
ID .
Les valeurs daccusation fixes 1 sont issues des mises jour successives subies par
les listes de rvocation de certificats des nuds
3
ID et
4
ID .
Aprs rception des deux listes de rvocation mises jour, le nud
1
ID excute les
tapes prcdemment dcrites.
La Figure 7.6 montre respectivement les listes de rvocation venant des nuds
3
ID et
4
ID aprs rception et traitement par
1
ID .


106

Figure 7. 6 : Traitement des listes de rvocation reues par le nud
1
ID

1
ID fait le traitement de la liste de rvocation reue du nud
3
ID en cartant les
vecteurs colonnes suivants :

3
1
c car 1 = = i k ;

3
2
c car 1
1
2
= R ;

3
3
c car 3 = = j k ;

3
4
c car
4
1
ID fait aussi le traitement de la liste de rvocation reue du nud
4
ID et carte les
vecteurs colonnes suivants :

4
1
c car 1 = = i k ;

4
2
c car 1
1
2
= R ;

4
3
c car
3

4
4
c car 4 = = j k ;

Une colonne carte est remplace par :
|
|
|
|
|
|
|
|
\
|
5
5
5
5
5
5
. La valeur 5 remplaant les valeurs
daccusation est choisie de manire arbitraire. Cependant nous pouvions aussi choisir un

107

autre entier nappartenant pas lensemble { } 2 1, , 0 . Ceci dans le but de faire la
diffrence entre les vecteurs colonnes carts et ceux qui ne le sont pas.
La Figure 7.7 montre ltat des matrices accusatrices aprs rception et traitement des
mises jour de listes de rvocation.

Figure 7. 7 : Etat des matrices accusatrices

Les matrices du vote majoritaire ou matrices accusatrices restent inchanges si
aucune colonne na t sauve pour le nud correspondant.
Ici les matrices accusatrices des nuds
2
ID ,
3
ID et
4
ID restent ltat initial car
aucune colonne nest sauve pour ces nuds.
Seule la matrice accusatrice du nud
5
ID a t modifie car pour ce dernier il existe
des colonnes sauves. Cette matrice a permis deffectuer les oprations de ltape 5
de lalgorithme 3.3.
La Figure 7.8 donne le rsultat obtenu aprs mise jour de la liste de rvocation du
nud
1
ID .


108

1
ID aprs mise jour.

Le rsultat montre que des mises jour ont t effectues, car les valeurs
daccusation
1
3 , 2
a et
1
3 , 5
a du vecteur colonne
1
3
c sont maintenant fixes 1, de mme
que les valeurs
1
4 , 2
a et
1
4 , 5
a du vecteur colonne
1
4
c . Le vecteur colonne
1
5
c est rest
inchang car sa mise jour demande un vote majoritaire. Cependant aucune
majorit na pu tre trouve pour les diffrentes valeurs daccusation de
1
5
c .
Le rsultat obtenu correspond ainsi ce qui tait attendu c'est--dire:

|
|
|
|
|
|
\
|
=
0 1 1 0 0 0 2009 5000
0 0 0 0 0 0 2011 4000
1 0 0 0 0 0 2009 3000
2 1 1 0 1 1 2010 2000
0 0 0 0 0 0 2009 1000
1
CRL

7.2 Evolution de la scurit du mcanisme propos en fonction
du nombre de sauts

Le nombre de sauts m fix pour les listes de rvocation de certificats ou porte de
propagation des messages daccusation est un paramtre qui affecte la performance du
rseau. Plus le nombre m est petit, moins un message besoin dtre retransmis vers le
prochain saut. Ainsi les petites valeurs de m diminuent la charge du rseau en terme de
bande passante et despace mmoire. Cependant en prsence dadversaires mobiles dans
le rseau, les petites valeurs de m peuvent causer des problmes de scurit. Un exemple
est illustr dans le cas o un nud
i
ID veut communiquer avec un autre nud
j
ID alors

109

quil na aucune information de rvocation propos de ce dernier parce que celui-ci est
en dehors de son voisinage m sauts. Le nud
i
ID doit alors solliciter des informations
de rvocation auprs dun autre nud
k
ID

situ la fois dans son voisinage m sauts et
dans celui de
j
ID .
Nous jugeons que la scurit du systme peut tre renforce en ajustant le nombre m de
sorte que chaque nud ait le maximum dinformation de rvocation propos des autres
nuds sur sa liste de rvocation de certificats.
Nous disons quun nud
j
ID est contrl par le nud
i
ID si la liste de rvocation du
nud
i
ID contient des informations de rvocation propos du nud
j
ID .
Pour tudier lvolution de la scurit du mcanisme de rvocation en fonction du
nombre de sauts m fix pour les listes de rvocation de certificats, nous introduisons un
nouveau paramtre
i c
T
,
appel taux de contrle du nud
i
ID . Ce paramtre correspond
la proportion de nuds contrls par le nud
i
ID value par rapport au nombre total
de nuds dans le rseau. Il est utilis pour exprimer le nombre total de nuds pour
lesquels
i
ID stocke des information de rvocation et permet de comparer ce nombre au
nombre total de nuds prsents dans le rseau.
Nous avons ainsi :

N m T
i i c
/
,
=
(10)

avec :
i
m = nombre de nuds du voisinage m sauts du nud
i
ID ,
N = nombre total de nuds dans le rseau.
i c
T
,
permet aussi de calculer le taux de contrle moyen
cm
T
pour chaque nud dans le
rseau.
cm
T
est alors obtenu en divisant la somme des
i c
T
,
, { } N i ,..., 1 par le nombre
total de nuds dans le rseau.


110

=
=
=
=
+ + + =
N
i
i cm
N
i
i c cm
N c c c cm
N N m T
N T T
N T T T T
1
1
,
, 2 , 1 ,
/ ] / [
/ ] [
/ ] ... [

do
2
1
/ ) ( N m T
N
i
i cm
=
=
(11)

Le but de lexprience 4 est dtudier lvolution de la scurit du systme en fonction
du nombre m.

7.2.1 Exprience 4 : Evolution du taux de contrle moyen en fonction
du nombre de sauts

Nous reprenons le scnario prcdemment dcrit et montrons comment le taux de
contrle moyen pour chaque nud volue en fonction du nombre de sauts m fix pour
les listes de rvocation de certificats.
La Figure 7.9 montre un exemple de rseau simple constitu de six nuds.

Figure 7. 9: Exemple de rseau

Soit
m i
v
,
le voisinage m sauts du nud
i
ID
incluant
i
ID
lui-mme.

111

Pour m = 1
Nous avons :
{ }
4 3 2 1
, , ,
1 , 1
ID ID ID ID v = 4
1
= m
{ }
2 1
,
1 , 2
ID ID v = 2
2
= m
{ }
4 3 1
, ,
1 , 3
ID ID ID v = 3
3
= m
{ } 3
4 1 , 4
5
, ,
4 1
= = m v ID ID ID
{ } 4
5 1 , 5
6
,
5
, ,
4 3
= = m v ID ID ID ID
{ } 2
6 1 , 6
6
,
5
= = m v ID ID
% 50 2 / 1 36 / 18 36 / ) 2 4 3 3 2 4 ( / ) (
2
6 5 4 3 2 1
= = = + + + + + = + + + + + = N m m m m m m T
cm

Pour m = 2
Nous avons :
{ }
5
, , , ,
4 3 2 1
2 , 1
ID ID ID ID ID v = 5
1
= m
{ }
4
,
3
, ,
2 1
2 , 2
ID ID ID ID v = 4
2
= m
{ }
6
,
5
, , ,
2
,
4 3 1
2 , 3
ID ID ID ID ID ID v = 6
3
= m
{ } 6
4 2 , 4
6
,
5
, ,
3
,
2
,
4 1
= = m v ID ID ID ID ID ID
{ } 5
5 2 , 5
6
,
5
, , ,
1 4 3
= = m v ID ID ID ID ID
{ } 4
6 2 , 6
6
,
5
,
4
,
3
= = m v ID ID ID ID

% 33 . 83 6 / 5 36 / 30 36 / ) 4 5 6 6 4 5 ( / ) (
2
6 5 4 3 2 1
= = = + + + + + = + + + + + = N m m m m m m T
cm

Pour m = 3
Nous avons :
{ } 6
1 3 , 1
6
,
5
, ,
3
,
2
,
4 1
{ } 5
2 3 , 2
5
, ,
3
,
2
,
4 1
{ } 6
3 3 , 3
6
,
5
, ,
3
,
2
,
4 1

112

{ } 6
4 3 , 4
6
,
5
, ,
3
,
2
,
4 1
{ } 6
5 3 , 5
6
,
5
, ,
3
,
2
,
4 1
{ } 5
6 3 , 6
6
,
5
, ,
3
,
4 1

% 44 . 94 36 / 34 36 / ) 5 6 6 6 5 6 ( / ) (
2
6 5 4 3 2 1
= = + + + + + = + + + + + = N m m m m m m T
cm

Pour m = 4
Nous avons :
{ } 6
1 4 , 1
6
,
5
, ,
3
,
2
,
4 1
{ } 6
2 4 , 2
5
, ,
3
,
2
,
4 1
{ } 6
3 4 , 3
6
,
5
, ,
3
,
2
,
4 1
{ } 6
4 4 , 4
6
,
5
, ,
3
,
2
,
4 1
{ } 6
5 4 , 5
6
,
5
, ,
3
,
2
,
4 1
{ } 6
6 4 , 6
6
,
5
, ,
3
,
4 1

% 100 36 / 36 36 / ) 6 6 6 6 6 6 ( / ) (
2
6 5 4 3 2 1
= = + + + + + = + + + + + = N m m m m m m T
cm

Pour m > 4
Nous avons :
i
m = 6 pour tout { } 6 5, 4, 3, 2, , 1 i . Ainsi
% 100 36 / 36 36 / ) 6 6 6 6 6 6 ( / ) (
2
6 5 4 3 2 1
= = + + + + + = + + + + + = N m m m m m m T
cm

La Figure 7.10 donne lvolution du taux de contrle moyen en fonction du nombre de
sauts m fix pour les listes de rvocation de certificats.


113

Figure 7. 10 : Evolution du taux de contrle moyen en fonction du nombre de sauts.

Nous constatons que lorsque 4 < m , il existe encore pour les adversaires mobiles des
chances de rester non dtects car % 100 <
cm
T . Pour 4 m nous avons % 100 =
cm
T .
Ainsi partir de m = 4 les adversaires mobiles nont plus aucune chance de rester non
dtects dans le rseau puisque en moyenne chaque nud a le contrle de lensemble
des nuds du rseau.
Nous pouvons dduire de ces rsultats que le nombre m peut tre ajust pour renforcer
la scurit de notre mcanisme. Par consquent m peut tre considr comme un
paramtre de scurit.

Conclusion

Dans cette dernire partie nous avons propos un mcanisme de rvocation de certificats
en adaptant une solution dj propose pour les systmes bass sur lidentit lun des
protocoles bas sur PKI notamment UBIQ.
Le mcanisme est extensible grce ses paramtres de performance et de scurit m,
et . Plus la valeur de m est grande plus les chances des adversaires mobiles de rester
non dtects sont rduites, tandis que les petites valeurs accroissent la performance en
terme de bande passante et despace mmoire. Les paramtres de scurit et

0%
50%
100%
150%
1 2 3 4
Nombre de sauts dfini pour les listes de rvocation de
certificats
Taux de contrle moyen

114

protgent le systme contre les fausses accusations et empchent les attaques par
coalition de noeuds.
Notre mcanisme de rvocation de certificats est compltement auto organis et ainsi est
indpendant dune CA externe off-line ou distribue on-line. En outre il fournit un
moyen sr pour les nuds de rvoquer leur propre cl, et prsente des cots de
communication plus rduits en raison de la propagation des messages vers le voisinage
m sauts au lieu du rseau entier.
Nous avons fourni limplmentation de notre mcanisme de rvocation en C et propos
une srie de tests.
Les rsultats des tests montrent que les nuds du rseau peuvent maintenir leurs listes
de rvocation de certificats jour suite la propagation de messages daccusation. Ainsi
chaque nud du rseau mettra en uvre le mcanisme de rvocation en excutant
localement le programme.
Nous avons aussi expriment lvolution de la scurit du mcanisme en jouant sur le
nombre de sauts m fix pour les listes de rvocation de certificats. Les rsultats
indiquent que le nombre m peut tre considr comme un paramtre de scurit qui
protge le systme lorsque celui-ci est ajust contre les adversaires mobiles.
Ainsi nous pouvons conclure que nos expriences ont montr des rsultats positifs pour
le mcanisme de rvocation de certificats propos.
CONCLUSION GENERALE
115

Conclusion Gnrale

Dans ce manuscrit nous avons abord un des problmes majeurs lis la fourniture de
service de scurit dans les rseaux mobiles ad hoc : celui de la gestion des cls
cryptographiques.
Nous avons men une tude des protocoles de gestion des cls proposs pour les
MANETs en donnant une vue densemble sur le fonctionnement de chaque protocole
puis en proposant une analyse de ces derniers. A ce niveau nous avons vu que malgr le
nombre de protocoles proposs les problmes non rsolus sont multiples. Et parmi ces
derniers nous pouvons citer labsence dun mcanisme efficace de rvocation pour les
protocoles distributifs cl publique. Les principaux rsultats de notre travail sont les
suivants :

1. Nous avons men une analyse des principaux protocoles de gestion des cls pour
en faire ressortir les insuffisances surtout en terme de scurit Ceci nous a
permis de dgager des problmes de scurit non rsolus ce jour pour ces
diffrents protocoles, ouvrant ainsi des voies pour des tudes et ralisations
futures.

2. Dans le but dapporter une solution un des problmes soulevs, nous avons
propos un mcanisme de rvocation de certificats pour un des protocoles
CONCLUSION GENERALE
116

distributifs cl publique notamment UBIQ. La solution, qui est une adaptation
dun mcanisme existant, se base sur lutilisation des listes de rvocation de
certificats et des signatures numriques la place, respectivement, des listes de
rvocation de cls et des cls pr partages, afin de scuriser les messages
daccusation. Notre mcanisme prsente les avantages suivants:
Les nuds peuvent efficacement et de manire scurise rvoquer leurs
propres cls en cas de compromission ;
Le mcanisme de rvocation de certificats est compltement auto
organis et ainsi est indpendant dune CA externe off-line ou distribue
on-line ;
Le mcanisme de rvocation de certificats a des cots de communication
plus rduits car les messages sont propags vers le voisinage m sauts
au lieu du rseau entier.

3. Nous avons conu et ralis un programme de simulation de la solution
propose qui nous a permis de tester la validit de la solution par une srie
dexpriences. Les rsultats des tests ont confirm les fonctionnalits de la
solution propose. Ce programme a un intrt pratique car il pourrait tre intgr
dans un futur logiciel de simulation pour la scurit rseau, ce type doutil
faisant souvent dfaut dans le domaine.

Notons toutefois, que de nombreux problmes restent encore non rsolus dans le
domaine de la gestion des cls dans les MANETs. Labsence dauthentification pour les
protocoles contributifs, les vulnrabilits lies la dpendance vis--vis dun
gestionnaire de groupe pour les protocoles distributifs cl symtrique en constituent
des exemples.

Nous nous proposons comme perspectives de recherche dvaluer la scurit et la
performance du mcanisme propos. Le comportement des algorithmes peut tre tudi
davantage lors des simulations, par exemple en faisant varier les paramtres de scurit
et mais aussi le paramtre de performance m afin dtudier le compromis entre la
CONCLUSION GENERALE
117

scurit et la performance. Le dlai de propagation des messages daccusation dans le
voisinage m sauts doit aussi tre tudi en incluant le temps total allant de
lobservation dun comportement malicieux la rvocation effective dun certificat.

REFERENCES
118

Rfrences :

[1] Bouassida M. S., Scurit des communications de groupe dans les rseaux ad hoc, Ph.
D. Thesis, Universit Henri Poincar - Nancy I, 2006.
URL: http://tel.archives-ouvertes.fr/docs/00/13/47/32/PDF/manuscrit.pdf

[2] Fokine K., Key Management in Ad Hoc Networks, Linkoping Univ. (Sweden) Master's
Thesis, 2002. URL: http://www.diva-portal.org/diva/getDocument?urn_nbn_se_liu_diva-
1351-1fulltext.pdf

[3] Hoeper K., Authentication and Key Exchange in Mobile Ad Hoc Networks, Waterloo,
Canada, Thesis, 2007. URL:
http://uwspace.uwaterloo.ca/bitstream/10012/3228/1/hoeper_thesis.pdf

[4] Anjum, F., Mouchtaris, P., Security for wireless ad hoc networks, Wiley, 2007, 247 p.

[5] Gayraud V., Nuaymi L., Dupont F., Gombault S., Tharon B., La scurit dans les
rseaux sans fil ad hoc, 2003. URL:
http://actes.sstic.org/SSTIC03/Securite_des_reseaux_sans_fil_ad_hoc/SSTIC03-article-
Gayraud-Securite_des_reseaux_sans_fil_ad_hoc.pdf

[6] Menezes A. J., van Oorschot P. C., Vanstone S. A., Handbook of Applied
Cryptography, CRC Press, 1996, 816 p.

[7] Bhaskar R, Protocoles cryptographiques pour les rseaux ad hoc, Ph. D. Thesis, Ecole
Polytechnique, June 2006. URL:
http://citeseerx.ist.psu.edu/showciting;jsessionid=7DB992849060197B158D8C3D0FCD3
605?cid=875745

[8] Hegland A. M., Winjum E., Mjlsnes S. F., Rong C. , Kure . and Spilling P., A Survey
of Key Management in Ad hoc Networks, IEEE Communications Surveys & Tutorials,
Vol. 8, no. 3, 3rd quarter, 2006. URL:
http://www.comsoc.org/livepubs/surveys/public/2006/jul/pdf/hegland.pdf

[9] Shamir A., Identity-Based Cryptosystems and Signature Schemes, 1984. URL:
http://www.iseca.org/downloads/Shamir47.pdf

[10] Diffie W., and Hellman M. E., New Directions in Cryptography, IEEE Trans. Info.
Theory, vol. IT-22, no. 6, Nov. 1976, pp. 64454. URL: http://www-
ee.stanford.edu/%7Ehellman/publications/24.pdf

[11] Ingemarsson I., Tang D., and Wong C., A Conference Key Distribution System, IEEE
Trans. Info. Theory, vol. 28, no. 5, Sept. 1982, pp. 714720.
URL: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1056542

[12] Becker K. and Wille U., Communication Complexity of Group Key Distribution,
Proc. 5th ACM Conf. Comp. and Commun. Security, 1998, pp. 16. URL:
http://www.dcc.fc.up.pt/~acm/cc/

REFERENCES
119

[13] Asokan N. and Ginzboorg P., Key Agreement in Ad Hoc Networks, Computer
Commun., vol. 23, no. 17, Nov. 2000, pp. 162737. URL:
http://asokan.org/asokan/research/index.html

[14] Zhou L. and Haas Z. J., Securing Ad Hoc Networks, IEEE Network Mag., vol. 13, no.6,
Nov./Dec. 1999, pp. 2430. URL: http://www.cs.cornell.edu/home/ldzhou/adhoc.pdf

[15] Shamir A., How to Share a Secret, Commun. ACM, vol. 22, Nov. 1979, pp. 612613.
URL: http://www.cs.tau.ac.il/~bchor/Shamir.html

[16] Desmedt Y. G., Threshold Cryptography, European Trans. Telecommun., vol. 5, no. 4,
July 1994, pp. 449457. URL: http://ww2.cs.fsu.edu/~hoang/draft/publication.html

[17] Herzberg A. et al., Proactive Secret Sharing or: How to Cope with Perpetual
Leakage, Proc. Crypto95, 1995, pp. 33952. URL: http://www.schneier.com/biblio/all-
authors-Y.html

[18] Zhu B. et al., Efficient and Robust Key Management for Large Mobile Ad Hoc
Networks, Computer Networks, vol. 48, no. 4, July 2005, pp.65782. URL:
http://www3.ntu.edu.sg/DRM/papers/Efficient%20and%20robust%20key%20managemen
t%20for%20large%20mobile%20ad%20hoc%20networks.pdf

[19] Pedersen T., Non-Interactive and Information-Theoretic Secure Verifiable Secret
Sharing, Proc. CRYPTO91, 1991, pp. 129140. URL:
http://www.cs.cornell.edu/courses/cs754/2001fa/129.PDF

[20] Yi S. and Kravets R., Key Management for Heterogeneous Ad Hoc Wireless
Networks, University of Illinois at Urbana-Champaign, 2002. URL: http://www-
sal.cs.uiuc.edu/~rhk/pubs/tr-2290-1734.pdf

[21] Yi S., and Kravets R., MOCA: MObile Certificate Authority for Wireless Ad Hoc
Networks, Report No. UIUCDCS-R-2004-2502, UILU-ENG-2004-1805, University of
Illinois at Urbana-Champaign, 2003. URL:
http://mobius.cs.uiuc.edu/publications/pki03.pdf

[22] Wu B. et al., Secure and Efficient Key Management in Mobile Ad Hoc Networks,
Proc. IPDPS05, 2005.
URL: http://www.cse.fau.edu/~jie/research/publications/Publication_files/security05.pdf

[23] Kong J. et al., Providing Robust and Ubiquitous Security Support for Mobile Ad-Hoc
Networks, Proc. 9th Intl. Conf. Network Protocols (ICNP01), 2001, pp. 25160.
URL:
http://coblitz.codeen.org:3125/citeseer.ist.psu.edu/cache/papers/cs/26747/http:zSzzSzww
w.cs.ucla.eduzSz~hluozSzresearchzSz..zSzpublicationszSzsecjournal.pdf/songwu01provi
ding.pdf

[24] Joshi D., Namuduri K., and Pendse R., Secure, Redundant, and Fully Distributed Key
Management Scheme for Mobile Ad Hoc Networks: An Analysis, EURASIP J.
Wireless Commun. and Net., vol. 5, no. 4, Sept. 2005, pp. 57989.
URL: http://www.hindawi.com/GetArticle.aspx?doi=10.1155/WCN.2005.579

REFERENCES
120

[25] Capkun S., Buttyn L., and Hubaux J. P., Self-Organized Public-Key Management for
Mobile Ad Hoc Networks, IEEE Trans. Mobile Computing, vol. 2, no.1, Jan.Mar. 2003,
pp. 113.
URL: http://www.syssec.ethz.ch/research/IEEETMC03.pdf

[26] Douceur J. R., The Sybil Attack, 1st Intl. Wksp. Peer-to-Peer Systems (IPTPS02),
2002, pp. 25160. URL: http://research.microsoft.com/~johndo/IPTPS2002.pdf

[27] Gennaro R. et al., Secure Distributed Key Generation for Discrete-Log Based
Cryptosystems, Proc. EUROCRYPT99, 1999.
URL :
http://citeseer.ist.psu.edu/cache/papers/cs/8419/http:zSzzSztheory.lcs.mit.eduzSz~stasioz
SzPaperszSzvss.pdf/secure-distributed-key-generation.pdf

[28] Zimmermann P., PGP Users Guide, Cambridge, MA: MIT Press, 1994.

[29] Yi S., and Kravets R., Composite Key Management for Ad Hoc Networks, Proc.
Mobiquitous04, 2004. URL: http://mobius.cs.uiuc.edu/publications/mobiq04.pdf

[30] Capkun S., Hubaux J. P., and Buttyn L., Mobility Helps Security in Ad Hoc Networks,
Proc. MobiHoc 03, 2003. URL: http://www.sigmobile.org/mobihoc/2003/papers/p46-
capkun.pdf

[31] Capkun S., Hubaux J. P., and Buttyn L., Mobility Helps Peer-to-Peer Security, IEEE
Trans. Mobile Comp., vol. 5, no. 1, Jan. 2006, pp. 4351.
URL: http://www.syssec.ethz.ch/research/mobility_journal.pdf

[32] Fiat A., and Shamir A., How to Prove Yourself: Practical Solutions to Identification
and Signature Problems, Proc. Crypto 86, 1987, pp. 18694.
URL:
http://citeseer.ist.psu.edu/cache/papers/cs/27589/http:zSzzSzdsns.csie.nctu.edu.twzSzrese
archzSzcryptozSzHTMLzSzPDFzSzC86zSz186.PDF/fiat87how.pdf

[33] Cha J.C., and Cheon J.H., An Identity-Based Signature from Gap DiffieHellman
Groups, Cryptology eprint Archive, Report 2002/18, 2002. URL:
http://eprint.iacr.org/2002/018.ps

[34] Waters B., Efficient Identity-Based Encryption Without Random Oracles, Proc.
Eurocrypt 2005. URL: http://eprint.iacr.org/2004/180.pdf

[35] Boneh D. and Franklin M., Identity-Based Encryption from the Weil Pairing, Proc.
Crypto 2001, 2001, pp. 21329. URL: http://crypto.stanford.edu/~dabo/papers/ibe.pdf

[36] Lynn B., Authenticated Identity-Based Encryption, Cryptology ePrint Archive, iacr
(Intl. Assn for Cryptological Research), 2002. URL: http://eprint.iacr.org/2002/072.pdf

[37] Khalili A., Katz J., and Arbaugh W. A., Towards Secure Key Distribution in Truly Ad-
Hoc Networks, Proc. IEEE Wksp. Securityand Assurance in Ad hoc Networks, 2003.
URL: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.6.2960

REFERENCES
121

[38] Puzar M. et al., SKiMPy: A Simple Key Management Protocol for MANETs in
Emergency and Rescue Operations, Proc. ESAS05, 2005.
URL: http://www.eurecom.fr/util/publidownload.fr.htm?id=1749

[39] Staddon J. et al., Self-Healing Key Distribution with Revocation, Proc. IEEE Symp.
Security and Privacy, 2002.
URL:
http://citeseer.ist.psu.edu/cache/papers/cs/29682/http:zSzzSzwww.cs.ucdavis.eduzSz~fran
klinzSz.zSz.zSzpubszSzselfheal.pdf/staddon02selfhealing.pdf

[40] Wong C.K., Gouda M., and Lam S. S., Secure Group Communications Using Key
Graphs, Proc. SIGCOMM 98, 1998. URL: http://www.ece.cmu.edu/~adrian/731-
sp04/readings/WGL-keydist.pdf

[41] Wallner D., Harder E., and Agee R., Key Management for Multicast: Issues and
Architectures, IETF RFC 2627, 1999. URL: http://www.rfc-
archive.org/getrfc.php?rfc=2627

[42] Rhee K. H., Park Y. H., and Tsudik G., An Architecture for Key Management in
Hierarchical Mobile Ad-hoc Networks, J. Commun. and Networks, vol. 6, no. 2, June
2004, pp. 15662.
URL: http://www.ics.uci.edu/~gts/paps/jcn-2004.pdf

[43] Rhee K.-H., Park Y. H., and Tsudik G., A Group Key Management Architecture for
Mobile Ad-hoc Wireless Networks, J. Inform. Sci. Eng., vol. 21, no. 2, Mar. 2005, pp.
41528.
URL: http://www.iis.sinica.edu.tw/page/jise/2005/200503_09.pdf

[44] Balenson D., McGrew D., and Sherman A., Key Management for Large Dynamic
Groups: One-Way Function Trees and Amortized Initialization, IETF Internet-Draft,
August 25, 2000, draft-irtf-smug-groupkeymgmt-oft-00.txt. URL:
http://www.tools.ietf.org/html/draft-irtf-smug-groupkeymgmt-oft-00

[45] McGrew D. A., and Sherman A. T., Key Establishment in Large Dynamic Groups
Using One-Way Function Trees, IEEE Trans. Software Eng., vol. 29, no. 5, May 2003,
pp. 44458.
URL: http://www.cs.vu.nl/~crispo/teaching/atcs/EKD/OTF.pdf

[46] Canetti R. et al., Multicast Security: A Taxonomy and Efficient Constructions, Proc.
INFOCOMM99, 1999. URL :
http://citeseer.ist.psu.edu/cache/papers/cs/4047/http:zSzzSzwww.bell-
labs.comzSzuserzSzgarayzSzmulticast.pdf/canetti99multicast.pdf

[47] Perrig A., D. Song, and J. D. Tygar, ELK, a new Protocol for Efficient Large-Group
Key Distribution, Proc. IEEE Symp. Security and Privacy, 2001.
URL:
http://citeseer.ist.psu.edu/cache/papers/cs/21979/http:zSzzSzparis.cs.berkeley.eduzSz~per
rigzSzprojectszSzelkzSzelk.pdf/perrig01elk.pdf

REFERENCES
122

[48] Rafaeli S., Mathy L., and Hutchison D., EHBT: An Efficient Protocol for Group Key
Management, LNCS, vol. 2233, 2001, pp. 15971.
URL: http://citeseer.ist.psu.edu/cache/papers/cs/22764/http:zSzzSzwww-
mice.cs.ucl.ac.ukzSzngc2001zSzpaperszSzrafaeli.pdf/rafaeli01ehbt.pdf

[49] Pietro R. D., Mancini L. V., and Jajodia S., Efficient and Secure Keys Management for
Wireless Mobile Communications, Proc. POMC 02, 2002.
URL : http://www.eyes.eu.org/publications/p06-mancini.pdf

[50] Poovendran R., and Baras J. S., An Information Theoretic Analysis of Root-Tree
Based Secure Multicast Key Distribution Schemes, LNCS, vol. 1666, 1999, pp. 624
38.
URL: http://www.ee.washington.edu/research/nsl/papers/CRYPTO-99.pdf

[51] Selcuk A., McCubbin C., and Sidhu D., Probabilistic Optimization of LKH-Based
Multicast Key Distribution Schemes, IETF Internet-Draft, Jan. 2000, draft-selcuk-
probabilistic-lkh-00.txt.
URL: http://www.securemulticast.org/draft-selcuk-probabilistic-lkh-00.txt

[52] Winjum E. et al., A Performance Evaluation of Security Schemes proposed for the
OLSR Protocol, Proc. MILCOM 05, 2005.
URL: http://ieeexplore.ieee.org/xpl/freeabs_all.jsp?arnumber=1606013
[53] Wong C. K., and Lam S.S., Keystone: A Group Key Management Service, Proc. ICT,
2000.
URL:
http://citeseerx.ist.psu.edu/viewdoc/summary;jsessionid=A2A6F83805047967BA3C9389
9DC19604?cid=2133781

[54] Burmester M., and Desmedt Y., A secure and efficient conference key distribution
system, Advances in Cryptology - EUROCRYPT'94, Springer-Verlag, 1994, p. 275-286.
URL: http://www.cs.fsu.edu/~langley/Eurocrypt/Eurocrypt%20-
%20OCR%20version%20-%202003%2008%2028.pdf

[55] Luo H., Zerfos P., Kong J., Lu S. and Zhang L., Self -Securing Ad Hoc Wireless
Networks, Seventh IEEE Symposium on Computers and Communications
(ISCC02),2002

[56] Crpeau C. and Davis C.R., A Certificate Revocation Scheme for Wireless Ad Hoc
Networks, Proceedings of ACM Workshop on Security of Ad Hoc and Sensor Networks
(SASN '03), ACM Press, isbn 1-58113-783-4, pp.54-61, 2003.
URL: http://www.cs.mcgill.ca/~carlton/papers/revocationSF1.pdf

[57] Hoeper K. and Gong G., Key Revocation for Identity-Based Schemes in Mobile Ad
Hoc Networks, International Conference on AD-HOC Networks & Wireless (AD HOC
NOW `06, LNCS 4104, Springer Verlag, pp. 224-237, 2006.
URL: http://comsec.uwaterloo.ca/~ggong/publication/2006/IBCrevocation_hoeper_f.pdf

[58] van der Merwe J., Key Management in Mobile Ad Hoc Networks, MScEng
dissertation, in School of Electrical, Electronic and Computer Engineering, University of
KwaZulu-Natal (UKZN), South-Africa, 2005.
REFERENCES
123

URL:
http://www.ee.ukzn.ac.za/postgrad/vdirs/vdMerwe/webpage/homepage_files/thesis/vande
rMerweMScEngThesis.pdf

[59] Hu Y.-C., Johnson D. B., and Perrig A., Ariadne: A Secure OnDemand Routing
Protocol for Ad Hoc Networks, in proc. Eighth ACM International Conf. on Mobile
Computing and
Networking (Mobicom02), September 2002.

[60] Dahill B., Levine E., Royer E., and Shields C., A Secure Routing Protocol for Ad Hoc
Networks, University of Massachusetts, Technical Report UM-CS-2001-037, August
2001.
URL:http://citeseer.ist.psu.edu/old/694791.html
ANNEXE
124

Annexe
Code en C du mcanisme de
rvocation de certificats

#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include <time.h>
#define cert C
#define hhhhhh harakiri
#define lescertificats
#define N1 50
#define M 100
#define matrice matrice
#define AMmisajour AMmaj
#define vecteur vecteur
#define vote vote
struct certificat
{float numseriecert;
float validite;
};
struct hhhhhh
{
float mess[M];
};
struct matrice
{
float lamatrice[N1][M];
};
struct AMmisajour
{ float numserie;
float matriceAccusation[N1][M];
float signature;
};
struct vecteur
{float accuse;
float valeur;
};
struct vote
{float numserie;
float nombre;
int indicateur;
};
typedef struct certificat cert;
typedef struct hhhhhh hhhhhh;
typedef struct matrice matrice;
typedef struct AMmisajour AMmisajour;
typedef struct vecteur vecteur;
typedef struct vote vote;
int N, N11, N12, N13, auth, epsilone=2, nbsaut=2,
delta=2;
matrice monCRL, sonCRL, sonCRL1, matri, matri1,
matri2, matri3, int2000, int3000, int4000, int5000,
noeud1,noeud3,noeud4;
vecteur tab[N1];
C monvoisinage[4];
C sonvoisinage3[5];
C sonvoisinage4[5];
C moncertificat;
vote tab1[N1];
float tabmessrecu[N1];
float tabligneecartee[N1];
void initialiserLeReseau(){
C lescerts[N];
lescerts[0].numseriecert=1000;
lescerts[0].validite=2009;
}
matrice creerMaMatriceAM(float numserie)
{
int i,j,k,n;
float num,val;
matrice AM;
ANNEXE
125

C tab[10];
printf( " \t \t Matrice d'accusation du noeud
identifier par %.f", numserie);

printf("\n Donner le nombre de noeud du
voisinage a un saut \t");
scanf("%d",&nbrenoeudvoisunsaut);
for(i=0; i<nbrenoeudvoisunsaut; i++)
{printf("\n donner le numero de serie de
l'element %d \t",i);
scanf("%f",&num);
printf("\n donner la validite de l'element %d \t",
i);
scanf("%f",&val);
tab[i].numseriecert = num;
tab[i].validite = val;}

for(k=0; k<nbrenoeudvoisunsaut; k++)
{
AM.lamatrice[k][0] = tab[k].numseriecert;
AM.lamatrice[k][1] = tab[k].validite;
AM.lamatrice[k][2] =0;
}
{for(i=0; i<3; i++)
{printf(" \t %.f ",AM.lamatrice[k][i]);
}
printf(" \n");
}
return AM;
}
matrice maMatriceAM( matrice * AM)
{
int i,j,k;
printf(" \n donner le numero de serie du noeud
suspect");
scanf("%d",&j);
{ if((*AM).lamatrice[k][0]==j)
(*AM).lamatrice[k][2]=1;}
{for(i=0; i<3; i++)
{printf(" \t %.f ",(*AM).lamatrice[k][i]);
}
printf(" \n"); }

return *AM;
}
harakiri messageHarakiri(float numserie, float
hopcount)
{
float sign;
harakiri hm1;
sign=(float)rand();
hm1.mess[0] = numserie;
hm1.mess[1] = hopcount;
hm1.mess[2] = sign;
// printf("le message a envoye est %.f \t %.f \t %.f \t
",hm1.mess[0], hm1.mess[1], hm1.mess[2]);
return hm1;
}
AMmisajour messageAMmisajour(C moncert,
matrice AM)
{
AMmisajour AMmis;
int i, k;
AMmis.numserie=moncert.numseriecert;
AMmis.signature= (float)rand();
for(i=0; i<N; i++)
{for(k=0; k<3; k++)

AMmis.matriceAccusation[i][k]=AM.lamatrice[i][k];
}
return AMmis;
}
AMmisajour messageCRLmisajour(C moncert,
matrice CRL)
{
AMmisajour CRLmis;
int i, k;
CRLmis.numserie=moncert.numseriecert;
CRLmis.signature= (float)rand();
for(i=0; i<=N; i++)
{for(k=0; k<=N+3; k++)
ANNEXE
126

CRLmis.matriceAccusation[i][k]=CRL.lamatrice[i][k
];
}
i=0;
while(i<=N)
{ if(tabmessrecu[i]==0.0)
tabmessrecu[i]=moncert.numseriecert;
else
tabmessrecu[i+1]=moncert.numseriecert;
i++;
}
printf("\n");
printf(" \t \t Matrice CRL mise a jour reue");
printf("\n");
printf("\n");
for(i=0; i<=N; i++)
{for(k=0; k<=N+3; k++)
printf("%.f \t",
CRLmis.matriceAccusation[i][k]);
printf("\n");}
return CRLmis;
}
matrice intermediaireEtape5(float
numserieAccusateur, C monvoisinage[N])
{ int i,k;
matrice mma;
mma.lamatrice[0][0]=numserieAccusateur;

mma.lamatrice[1][0]=moncertificat.numseriecert;
for(i=2;i<=N+1;i++)
mma.lamatrice[i][0]=monvoisinage[i-
2].numseriecert;
for(k=1;k<=N;k++)
mma.lamatrice[0][k]=monvoisinage[k-
1].numseriecert;
for(i=1;i<=N+1;i++)
{for(k=1;k<=N;k++)
mma.lamatrice[i][k]=3;}
printf("\n");
/* for(i=0;i<=N;i++)
{for(k=0;k<=N;k++)
printf("%.f \t",mma.lamatrice[i][k]);
printf("\n");} */
return mma;
}
harakiri receptionHarakiri(harakiri hm, matrice *
maCRL2)
{ int i,a;
harakiri hm2;
printf("Le message reu est %.f \t %.f \t %.f \t
",hm.mess[0], hm.mess[1], hm.mess[2]);
if(hm.mess[1]!=0)
{//printf("\n %.f",hm.mess[1]);
hm2.mess[0]=hm.mess[0];
hm2.mess[1]=hm.mess[1]-1;
hm2.mess[2]=hm.mess[2];
for(i=0;i<=N;i++)
{if((*maCRL2).lamatrice[i][0]==hm.mess[0])
{(*maCRL2).lamatrice[i][2]=1;
(*maCRL2).lamatrice[i][i+3]=1;}
}
printf("\n Le message a envoyer est %.f \t %.f \t
%.f \t ",hm2.mess[0], hm2.mess[1], hm2.mess[2]);}
else
{ printf("Le nombre de saut voulu est atteint");
for(i=0;i<=N;i++)

{if((*maCRL2).lamatrice[i][0]==hm.mess[0])
{(*maCRL2).lamatrice[i][2]=1;
(*maCRL2).lamatrice[i][i+3]=1;}
}
}
}
return hm2;
}
matrice creerMaCRL(C moncert, C
monvoisinage[N])
{
int i,j,k,l,n,n1,n2;
float num,val;
// float AM[10][10];
C tab[10];
matrice CRL;
ANNEXE
127

printf( " \t \t Liste de revocation du noeud
identifier par %.f \n \n", moncert.numseriecert);

CRL.lamatrice[0][0]=moncert.numseriecert;
CRL.lamatrice[0][1]=moncert.validite;

for(i=1; i<=N; i++)
{
CRL.lamatrice[i][0] = monvoisinage[i-
1].numseriecert;
CRL.lamatrice[i][1] = monvoisinage[i-
1].validite;
}
for(k=4; k<=N+3; k++)
CRL.lamatrice[0][k]=0;
for(i=0; i<=N; i++)
CRL.lamatrice[i][2]=0;
for(i=1; i<=N; i++)
CRL.lamatrice[i][3]=0;
for(i=1; i<=N; i++)
{for(k=4; k<=N+3; k++)
CRL.lamatrice[i][k]=0; }
for(i=1; i<=N; i++)
CRL.lamatrice[i][i+3]=0;

return CRL;
}
matrice maCRL(C moncert, matrice * CRL)
{ int i,j,k,l,m;
//condition 1
for(i=0; i<=N; i++)
{if((*CRL).lamatrice[i][0]==
moncert.numseriecert)
{for(l=0; l<=N; l++)
{if((*CRL).lamatrice[l][i+3]==1)
(*CRL).lamatrice[l][2]=1;}}}
//condition 2
for(i=0;i<=N;i++)
{if((*CRL).lamatrice[i][1]<=2008)
(*CRL).lamatrice[i][2]=1;
}
//condition 3 (voir reception harakiri)
//condition 4
for(i=0; i<=N; i++)
{ m=0;
for(k=3; k<=N+3; k++)
{if((*CRL).lamatrice[i][k]==1)
{ m=m+1;
if(m >= delta)
(*CRL).lamatrice[i][2]=1; } }
}
for(i=0; i<=N; i++)
{if((*CRL).lamatrice[i][0]==
moncert.numseriecert)
(*CRL).lamatrice[i][2]=0;
}

return *CRL;
}
matrice etape1a4(matrice *maCRL1, AMmisajour
messageCRLmisajour1)
{ int i,k,l,an, an1, numline;
matrice matr;
//Etape1
numline=0;
for(i=0;i<N;i++)
{if(messageCRLmisajour1.numserie ==
(*maCRL1).lamatrice[i][0])
numline=i;
}
//Etape2
printf("\n");
if((*maCRL1).lamatrice[numline][2]==0)
{ //Etape3
printf("\n");
for(i=0;i<=N11;i++)

{if(messageCRLmisajour1.matriceAccusation[i][0]=
= messageCRLmisajour1.numserie)
an=i+3;}
for(k=0;k<=N11;k++)

{tab[k].accuse=messageCRLmisajour1.matriceAccus
ation[k][0];
ANNEXE
128

tab[k].valeur=messageCRLmisajour1.matriceAccusat
ion[k][an];
}

for(i=0;i<=N;i++)

{if((*maCRL1).lamatrice[i][0]==messageCRLmisajo
ur1.numserie)
an1=i+3;}
for(k=0;k<=N;k++)
{for(l=0; l<=N11; l++)

{if((*maCRL1).lamatrice[k][0]==tab[l].accuse)

(*maCRL1).lamatrice[k][an1]=tab[l].valeur;
}
}

//Etape4
//colonne k=i ecartee
for(i=0;i<=N11;i++)

{if(messageCRLmisajour1.matriceAccusation[i][0]
== moncertificat.numseriecert)
{for(l=0;l<=N11;l++)

messageCRLmisajour1.matriceAccusation[l][i+3]=5;
//5 pour colonne ecartee
}
} //juste
//colonne k=j ecartee
for(i=0;i<=N11;i++)
{
if(messageCRLmisajour1.matriceAccusation[i][0]==
messageCRLmisajour1.numserie)
{for(l=0;l<=N11;l++)

}
} //juste

//colonne k=l ecartee
for(k=0;k<N;k++)
{if((*maCRL1).lamatrice[k][2]==1)
{for(i=0;i<=N11;i++)

{if(messageCRLmisajour1.matriceAccusation[i][0]
== (*maCRL1).lamatrice[k][0])
{for(l=0;l<=N11;l++)

}
}
}
} //juste

//colonne k=s ecartee
/* k=1;
while(k<=N11)
{for(i=1;i<=N;i++)

{if(messageCRLmisajour1.matriceAccusation[k][0]=
=maCRL1.lamatrice[i][0])
continue;
else
{for(l=0;l<=N11;l++)

messageCRLmisajour1.matriceAccusation[l][k+3]=5;
}
}
k++;
}
*/
//colonne k=r ecartee

}

for(i=0;i<=N11;i++)
{for(k=0;k<=N11+3;k++)

matr.lamatrice[i][k]=messageCRLmisajour1.matrice
Accusation[i][k];
}
ANNEXE
129

}

return matr;
}
void MatricePourVote(matrice mat, C soncertificat)
{int i,k,l,k1,an;

for(k1=1;k1<=N+1;k1++)

{if(int2000.lamatrice[0][k1]==soncertificat.numserie
cert)
an=k1; //an est le num de colonne de
celui qui a envoy le message
}
for(i=1;i<=N11;i++)
{if(mat.lamatrice[i][0]==int2000.lamatrice[0][0]
&& (mat.lamatrice[0][i+3]!=5))
{for(k=0;k<=N11;k++)
{for(l=1;l<=N+1;l++)

{if(mat.lamatrice[k][0]==int2000.lamatrice[l][0])

int2000.lamatrice[l][an]=mat.lamatrice[k][i+3];
}
}
}
}

for(k1=1;k1<=N+1;k1++)

cert)
an=k1;
}
for(i=1;i<=N11;i++)

{if((mat.lamatrice[i][0]==int3000.lamatrice[0][0])
{for(k=0;k<=N11;k++)
{for(l=1;l<=N+1;l++)


}
}
}
}

for(k1=1;k1<=N+1;k1++)

cert)
an=k1;
}
for(i=1;i<=N11;i++)

{for(k=0;k<=N11;k++)
{for(l=1;l<=N+1;l++)


}
}
}
}

for(k1=1;k1<=N+1;k1++)

cert)
an=k1;
}
for(i=1;i<=N11;i++)

{for(k=0;k<=N11;k++)
{for(l=1;l<=N+1;l++)
ANNEXE
130


}
}
}
}
}
matrice etape1a4fin(C soncertificat, matrice
ma1,float tableau[N1])
{int i,k,l;
for(k=0;k<=N11;k++)
{for(i=0;i<=N;i++)
{if(ma1.lamatrice[k][0]==tableau[i])
{for(l=0;l<=N11;l++)
ma1.lamatrice[l][k+3]=5;
}
}
}
printf("\n");
printf("Apres transformation la matrice du noeud
identifie par %.f devient:",
soncertificat.numseriecert);
printf("\n");
printf("\n");
for(i=0;i<=N11;i++)
{for(k=0;k<=N11+3;k++)
printf("%.f \t",ma1.lamatrice[i][k]);
printf("\n");
}
return ma1;
}
matrice etape5(matrice * maCRL1)
{int i, k, an, nb, dka;

printf("\n");

for(i=0; i<=N; i++)
{tab1[i].numserie=8;
tab1[i].nombre=8;
tab1[i].indicateur=8;
}
////////////////////
for(i=1;i<=N;i++)
{ nb=0;
for(k=1;k<N;k++)
{if(int2000.lamatrice[i][k]==1)
nb=nb+1;}
tab1[i-1].numserie=int2000.lamatrice[i][0];
tab1[i-1].nombre=nb;
for(k=1;k<N;k++)
{ break;
tab1[i-1].indicateur=1;}
else
{continue;
if(k==N-1)
tab1[i-1].indicateur=0;
}
}
}
printf("\n");

for(k=1;k<=N;k++)
{ dka=0;
for(i=1;i<=N+1;i++)
{if(int2000.lamatrice[i][k]!=3)
dka=dka+1;}
}

for(i=0;i<N;i++)
{if((*maCRL1).lamatrice[i][0]==2000)
an=i+3;
}
for(i=0;i<N;i++)
{if((tab1[i].numserie ==
(*maCRL1).lamatrice[i][0]) && (tab1[i].nombre >
dka/2) && (dka >= epsilone) &&
(tab1[i].indicateur==0) && (dka!=0))
(*maCRL1).lamatrice[i][an]=1;
else
{if((tab1[i].numserie
==(*maCRL1).lamatrice[i][0]) && (tab1[i].nombre <
ANNEXE
131

dka/2) && (dka >= epsilone) &&
(tab1[i].indicateur==0) && (dka!=0))
}
}
//////////////////////////
for(i=1;i<=N;i++)
{ nb=0;
for(k=1;k<N;k++)
nb=nb+1;}
for(k=1;k<N;k++)
{ break;
else
{continue;
if(k==N-1)
}
}
}
for(k=1;k<=N;k++)
{ dka=0;
for(i=1;i<=N+1;i++)
dka=dka+1;}
}

for(i=0;i<N;i++)
an=i+3;
}
for(i=0;i<N;i++)
dka/2) && (dka >= epsilone) && (dka!=0))
else
}
}
//////////////////////
for(i=1;i<=N;i++)
{ nb=0;
for(k=1;k<N;k++)
nb=nb+1;}
for(k=1;k<N;k++)
{ break;
else
{continue;
if(k==N-1)
}
}
}
for(k=1;k<=N;k++)
{ dka=0;
for(i=1;i<=N+1;i++)
dka=dka+1;}
}

for(i=0;i<N;i++)
an=i+3;
}
for(i=0;i<N;i++)
else
ANNEXE
132

}
}
///////////////////////
for(i=1;i<=N;i++)
{ nb=0;
for(k=1;k<N;k++)
nb=nb+1;}
for(k=1;k<N;k++)
{ break;
else
{continue;
if(k==N-1)
}
}
}
for(k=1;k<=N;k++)
{ dka=0;
for(i=1;i<=N+1;i++)
dka=dka+1;}
}

for(i=0;i<N;i++)
an=i+3;
}
for(i=0;i<N;i++)
else
dka/2) && (dka >= epsilone))
}
}
printf(" \t \t La liste de revocation du noeud1 mise
a jour est:");
printf("\n");
printf("\n");
for(i=0;i<N;i++)
{for(k=0;k<N+3;k++)
printf("%.f \t ",(*maCRL1).lamatrice[i][k]);
printf("\n"); }

return *maCRL1;
}
int main(int argc, char *argv[])
{ C c3,c4;
AMmisajour AMmis, CRLmis, CRLmis1;
matrice mmm;
//C sonvoisinage3[4];
monvoisinage[0].numseriecert=2000;
monvoisinage[0].validite=2010;

int i,k,l,k1,an;
// harakiri t,t1;

moncertificat.numseriecert=1000;
moncertificat.validite=2009;
//monCRL =
maCRL(moncertificat,monvoisinage);
sonvoisinage3[0].numseriecert=1000;
sonvoisinage3[0].validite=2009;
ANNEXE
133



N=5;
int2000=intermediaireEtape5(2000,
monvoisinage);
monvoisinage);
monvoisinage);
monvoisinage);
// cas de l'article
// liste de rvocation du noeud 1
noeud1.lamatrice[0][0]=1000;
noeud1.lamatrice[0][2]=0; noeud1.lamatrice[0][3]=0;

ANNEXE
134



c3.numseriecert=3000;
c3.validite=2009;
c4.numseriecert=4000;
c4.validite=2011;
N11=5;
printf("\t \t Liste de revocation du noeud1");
printf("\n");
printf("\n");
for(i=0;i<N;i++)
{for(k=0;k<N+3;k++)
printf(" %.f \t", noeud1.lamatrice[i][k]);
printf("\n");}

//sonCRL = maCRL(c2,sonvoisinage3);
CRLmis= messageCRLmisajour(c3,noeud3);
printf("\n");
matri = etape1a4(&noeud1, CRLmis);
printf("\n");
CRLmis1=messageCRLmisajour(c4,noeud4);
printf("\n");
matri1 = etape1a4(&noeud1, CRLmis1);
// sonCRL1= maCRL(c4,sonvoisinage3);
printf("\n");
matri2=etape1a4fin(c3,matri, tabmessrecu);
printf("\n");
matri3=etape1a4fin(c4,matri1,tabmessrecu);
printf("\n");
printf("Les matrices du vote majoritaire");
printf("\n");
MatricePourVote(matri2, c3);
printf("\n");
MatricePourVote(matri3, c4);
printf("\n");

for(i=0;i<=N;i++)
{for(k=0;k<N;k++)
printf("%.f \t",int2000.lamatrice[i][k]);
ANNEXE
135

printf("\n");}
printf("\n");
for(i=0;i<=N;i++)
{for(k=0;k<N;k++)
printf("\n");}
printf("\n");
for(i=0;i<=N;i++)
{for(k=0;k<N;k++)
printf("\n");}
printf("\n");
for(i=0;i<=N;i++)
{for(k=0;k<N;k++)
printf("\n");}

mmm = etape5(&noeud1);

getch();
return 0;
}

Mon Livre

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Mon Livre

Transféré par

Droits d'auteur :

Formats disponibles

DEDICACE

A la mmoire de mon cher oncle Lamine Sarr.

sont utiliss pour empcher les attaques par coalition

Vous aimerez peut-être aussi