Notre protocole

AVISPA a ensuite été lancé sur la modélisation de la section 5.3.2.3 en ne donnant aucune connaissance supplémentaire particulière à l’attaquant. intruder_knowledge={jn, a1, a2, a3,a,inv(pki),pkjn, pka, pka1,

pka2, pka3, pkac, pki} Ainsi, l’attaquant a connaissance :

– des différents agents (a, a1, a2, a3), – de sa paire de clés, pki et inv(pki)

– et des clés publiques : pka, pka1, pka2, pka3 et pkac.

Contrairement à ce qui était attendu, AVISPA a renvoyé « UNSAFE » pour cette modélisation. Il considère que l’attaquant peut s’authentifier à la place de JN au près de AAA2.

On trouvera figure 5.7 le résultat d’AVISPA et figure 5.8 l’animation qu’en propose SPAN.

Le déroulement est présenté ci-dessous, on a eu soin tout en maintenant la numérotation des « steps » successives présentées par SPAN, de rappeler dans quelle étape du protocole (cf. section 4.4.3 du chapitre 4) elle se situe :

• Étape 1 :

❜ Step1, Step5, Step7 - JN envoie son identifiant en direction de AAA2(en minuscule sur la figure 5.8). L’attaquant, qui se trouve sur le parcours, bloque ce message et le modifie. Il bloque ensuite les messages destinés aux pairs AAA1 et AAA3.

❜ Step2 - L’attaquant envoie le message dans lequel il a changé l’adresse IP de l’émetteur en son adresse au pair AAA2.

• Étape 2 :

❜ Step3 - Le pair AAA2 envoie un défi (nombre aléatoire) dummy_nonce en direction du JN. Ce message parvient en fait à l’attaquant.

❜ Step4, Step6, Step8 - L’attaquant envoie à JN les nombres aléatoires en se faisant passer successivement pour AAA1, AAA3 et AAA2.

• Étape 3 :

❜ Step9 - JN envoie en direction de chacun des pairs ses informations d’authentification en direction de AAA2. Ce message est intercepté par l’attaquant.

5.4 Exploitation des résultats 115

Figure 5.7 – Résultat donné par AVISPA

❜ Step10 - L’attaquant envoie ce message en direction de AAA2 en ayant modifié l’adresse de l’émetteur.

• Étape 4 :

❜ Step11 - AAA2 croit authentifier JN alors que la source du message est l’attaquant. Il construit un(e part de) jeton correctement adressé(e) à ce dernier et lié(e) cryptographiquement à son adresse.

L’analyse de la faille trouvée appelle plusieurs considérations. Tout d’abord, AVISPA ne prenant pas en compte la multiplicité des pairs, travaille comme s’il s’agit de mettre en défaut un seul d’entre eux (ici AAA2). Il est ainsi capable de mettre en évidence une sorte d’« attaque de l’homme du milieu ». Telle qu’elle est décrite, elle ne pourrait fonctionner dans le protocole présenté à moins que l’attaquant ne puisse se faire passer comme homme du milieu sur chacun des chemins menant du JN à l’un quelconque des pairs. On pourrait dire qu’AVISPA nous a permis de mettre en évidence une attaque possible contre le protocole que nous appellerons l’attaque de l’homme du centre. En pratique, celle-ci n’est donc possible que si l’attaquant se trouve placé pendant assez longtemps à un point d’articulation du graphe des routes (cf. section 4.5.1.1 du chapitre 4). Nous considérons, notamment en raison du mouvement, que cette éventualité est hautement improbable.

Figure 5.8 – Animation SPAN

Pour autant, la version du protocole testée ci-dessus n’en est pas moins falsi- fiable. L’exigence raisonnable d’une sécurité totale amène à modifier le message transmis aux pairs à l’étape 3. Initialement, il était (cf. section 4.4.3 du chapitre 4) :

certJN, RJN, R, IDi, tJN, signJN(RJN, Ri, IDi) Nous le modifions en :

certJN, RJN, R, IDi, tJN, signJN(RJN, Ri, IDi, CGAJN)

Ce simple changement de signature interdit désormais à l’homme du centre de modifier les adresses CGA des messages qu’il intercepte puis transmet. Il est à noter que cette légère modification se fait sans rallongement aucun des messages transmis.

5.4.2.1 Trois pairs corrompus

Pour tester la cohérence de la modélisation, nous avons décidé de faire comme si les trois pairs d’authentification avaient été corrompus. Nous avons donc donné à l’attaquant la connaissance des clés privées des pairs, et donc de la clé du pair AAA global :

5.4 Exploitation des résultats 117 Comme nous pouvions l’attendre AVISPA déclare le protocole « UNSAFE » et soulève le fait que l’ataquant peut s’authentifier sur JN à la place de AAA :

Figure 5.9 – Résultat donné par AVISPA

Steps 1 et 2 : l’attaquant récupère le nombre aléatoire RAAA (avec la valeur dummy_nonce) depuis AAA1.

Steps 3 à 8 : L’attaquant se fait passer pour les pairs AAAi et renvoie RAAA à JN.

Steps 9 et 10 : JN envoie à AAA1 son certificat, RJN, l’identifiant du pair AAA global et les 2 nombres aléatoires concaténés à cet identifiant, chiffrés avec la clé publique de JN. Mais l’attaquant intercepte ce message.

Steps 11 à 16 : L’attaquant envoie des faux messages à JN. JN crois que ces mes- sages contiennent les parts de signatures des pairs AAAi.

Steps 17 JN relaye les fausses parts de signatures à l’attaquant en pensant commu- niquer avec le pair AAA.

Steps 18 L’attaquant renvoie le bon message signé avec la clé privée du pair AAA, et s’authentifie par la même en tant que AAA sur JN.

On voit que les steps 17 et 18 n’existeraient pas dans la réalité. Cependant, le résultat aurait été le même, JN aurait recombiné les signatures de Shoup en step 16 et l’attaquant aurait réussi à s’authentifier en tant que AAA.

5.4.2.2 Un seul pair corrompu

Nous avons fait un dernier test en considérant que seul le pair AAA1 avait été corrompu, et en ne donnant donc que la clé privée de AAA1 à l’attaquant :

intruder\_knowledge=\{jn, a1, a2, a3, a, i,d,pkjn, pka, pka1, pka2, pka3, pkac, pki,pkd,ipcgajn,

Figure 5.10 – Résultat donné par AVISPA

On voit sur la figure 5.10 qu’AVISPA renvoie la valeur « SAFE », ce qui correspond bien à ce que l’on attendait de ce protocole distribué.

5.5 Conclusion

Tout au long de ce chapitre, nous avons pu mettre en œuvre un outil state-of- the-art d’analyse de la sécurité des protocoles. Nous avons ainsi mis en évidence que cet outil n’est pas adapté à l’étude de protocoles à interlocuteurs multiples et à fortiori de protocoles mettant en œuvre une cryptographie à seuil. Cette inadéquation nous a amené à devoir faire des efforts d’ingéniosité pour dévelop- per dans le cadre du langage HLPSL une modélisation approchée du protocole étudié. Une telle situation n’est pas souhaitable. Le but des outils de preuve automatique étant par essence d’automatiser le processus.

Malgré ces défauts et les difficultés qui en ont découlé, l’utilisation d’une validation formelle a fait la preuve de sa puissance et par là même de son intérêt

5.5 Conclusion 119 en mettant en évidence dans une version préliminaire du protocole une faiblesse qui nous avait sur l’instant échappé. Nous avons ressenti la réelle nécessité d’un outil formel plus développé mais la recherche menée à travers la littérature ne nous a pas permis de découvrir un tel programme ni même d’articles de recherche théorisant le sujet. Quoiqu’il en soit, au terme de cette partie nous somme désormais en situation de dire que le protocole d’authentification, tel qu’il vient d’être rectifié, est un protocole solide. Il reste à étudier sa mise en œuvre dans un réseau. Cela sera l’objet de la partie suivante.

Troisième partie

Évaluation du protocole

Chapitre 6

Évaluation du temps

d’authentification

Sommaire

6.1 Introduction . . . 123 6.2 Modélisation et simulation : terminologie . . . 124 6.3 Quelques définitions . . . 125 6.4 Modèle mathématique et calculs . . . 127 6.4.1 Calcul du temps de transfert sur un lien à un seul saut128 6.4.2 Calcul du temps de transfert sur un lien à sauts mul-

tiples . . . 130 6.4.3 Prise en compte du hasard . . . 130 6.4.4 Calcul du temps d’authentification . . . 133 6.4.5 Résultats . . . 135 6.5 Modèles emboîtés et simulations . . . 138

6.5.1 Considérations techniques, paramétrages et condi- tions de validation . . . 138 6.5.2 Scénario statique . . . 139 6.5.3 Ajout de mouvements déterministes . . . 143 6.5.4 Prise en compte des temps de calculs cryptographiques147 6.6 Conclusion . . . 147

6.1 Introduction

Un des indicateurs de performance d’un protocole destiné à fonctionner dans un réseau est la durée de son exécution. Cette valeur est déterminante dans l’adoption de ce protocole ou son abandon. Au chapitre 4, nous avons conçu un protocole d’authentification. Nous avons aussi fait appel au protocole SEND et à l’extension Ext-SEND, que nous avons définie, pour réaliser le service d’au- torisation. Dans ce chapitre, nous proposons d’évaluer le temps nécessaire pour accomplir une authentification et nous laissons de côté l’évaluation du temps d’autorisation. La raison de ce choix est liée au mode de communication one- to-many du protocole d’authentification qui est manifestement plus complexe à

appréhender que celui one-to-one utilisé par les protocoles SEND et Ext-SEND. De plus, alors que le protocole d’authentification est à quatre étapes, chaque étape comportant plusieurs messages envoyés ou reçus par les pairs AAA impli- qué1_{, SEND et Ext-SEND sont à deux étapes seulement, chaque étape consis-} tant en un seul message envoyé ou reçu. Par ailleurs, plusieurs travaux ont déjà porté sur le protocole SEND [70] [95] [96] [97] et, plus généralement, sur des protocoles one-to-one à deux messages, aller et retour, dans les MANETs [98].

S’agissant d’étude de performances impliquant des objets réels devant ef- fectivement fonctionner, il est clair qu’il y aura finalement lieu de les réaliser. Pourtant, l’évolution scientifique et technique de ces cinquante dernières années a toujours consisté à pousser plus loin les calculs, en les prolongeant par des simulations numériques de plus en plus intensives basées sur des modèles de plus en plus réalistes. D’une certaine façon, le temps des maquettes est révolu et les premières réalisations sont extrêmement proches des objets commerciali- sés. Nous nous inscrivons dans cette même optique et proposons tout d’abord un modèle dont les propriétés s’évaluent simplement au moyen de l’analyse ma- thématique puis un modèle beaucoup plus proche de la réalité mais dont les propriétés ne sont accessibles qu’à travers la simulation.