Protocole A-GDH.2

Le protocole A-GDH.2 [8] comme le protocole GDH.2 met en communication n participants afin de calculer une clef commune `a tous les membres appel´ee clef du groupe. Il doit assurer aussi l’authentification de la clef de groupe. Le fonctionnement est similaire `a celui du protocole GDH.2 (Voir Section 4.7.2) `a la diff´erence que, pour le dernier participant, les messages sont exponenti´es par son contribution `a la clef du groupe (comme le protocole GDH.2) et les clefs partag´ees avec les autres participants.

Analyse du protocole A-GDH.2.

La violation de la propri´et´e trait´ee dans le paragraphe 4.7.2 permet `a l’intrus d’avoir la vue de la clef du groupe du participant attaqu´e. Cette vue n’est pas n´ecessairement la vue de la clef du groupe de tous les membres. Ainsi, l’intrus peut communiquer avec le membre attaqu´e ou se faire passer pour lui. Cet intrus est g´en´eralement un attaquant de l’ext´erieur.

Pour le protocole A-GDH.2 (voir Figure 4.12 pour une session particuli`ere de ce protocole), l’intrus ne peut pas g´en´erer une attaque de la mani`ere d´ecrite dans la Section 4.7.2 puisque le dernier participant Pn exponentie les composantes, non plus par rn seulement mais aussi par une clef partag´ee entre lui et le membre concern´e.

P1 α, αr1 _αr2_{, α}r1_{, α}r1r2 P3 P4 αr2r3_{, α}r1r3 αr1r2_{, α}r1r2r3 αr2r3r4k14_{, α}r1r3r4k24_{, α}r1r2r4k34 P2

Fig. _{4.12 – Le protocole A-GDH.2 avec 4 participants}

Ainsi, l’intrus est contraint d’ˆetre `a l’int´erieur du groupe pour pouvoir mener une attaque. Son objectif n’est plus alors d’avoir la vue d’un participant puisqu’il fait partie du groupe (il a le droit donc d’avoir la clef du groupe). N´eanmoins, il peut nuire au groupe en faisant en sorte que les membres du groupe aient chacun diff´erente de la clef. L’objectif de l’intrus est alors de subdiviser le groupe en sous groupes de telle sorte que lui seul puisse communiquer (ait la mˆeme vue de la clef) avec tous les membres sans que les membres partagent la mˆeme clef.

Nous nous inspirons de l’attaque trouv´ee pour GDH.2 `a 4 participants. Nous consid´erons donc le protocole A-GDH.2 `a quatre participants o`u l’intrus joue le rˆole du troisi`eme participant.

4.8. Conclusion 117 P1 α, αr1 _αr2_{, α}r1_{, α}r1r2 I P4 αr2rI_{, α}r1rI αr1r2_{, α}r1r2rI αr2rIr4k14_{, α}r1rIr4k24_{, α}r1r2r4kI4

P2

αr1r2

Fig. _{4.13 – Attaque sur A-GDH.2 avec 4 participants}

L’intrus se focalise sur le dernier participant P4. Il modifie la derni`ere composante du mes- sage attendu par P4 en la rempla¸cant par l’avant derni`ere composante. P4 exponentie les trois premi`eres composantes par r4 et la clef partag´ee avec les participants concern´es. Il utilise la derni`ere composante pour g´en´erer sa vue de clef en l’exponentiant par r4. `A la fin de cette ex´ecution, les vues des participants (y compris l’intrus) sont :

– Vue de P1 : αr1r2rIr4. – Vue de P2 : αr1r2rIr4. – Vue de P4 : αr1r2r4.

– Vues de I : αr1r2rIr4 _{et α}r1r2r4_.

L’intrus r´eussit donc `a diviser le groupe en deux parties : la premi`ere partie comprend seulement le participant P4 et la deuxi`eme comprend le reste du groupe. En plus, l’intrus a les deux vues. Ainsi, il contrˆole toutes les communications.

G´en´eralisation de l’attaque sur A-GDH.2.

Nous consid´erons le protocole A-GDH.2 avec n participants : P1, .., Pn. L’intrus fait partie du groupe et il a pour rang i : I = Pi. L’intrus se focalise sur le dernier message destin´e au dernier participant. Ce message X comprend n composantes X = X1..Xn. Le dernier participant va exponentier les n − 1 composantes de ce message par rn et par la clef du participant correspon- dant. Ainsi, la composante Xi va ˆetre exponenti´ee par rnkni. Au lieu d’envoyer le message X = X1, .., Xi, .., Xn, l’intrus envoie le message X = X1, .., Xi, .., Xi `a Pn. Pn envoie comme r´eponse le message X′ _{= exp(exp(X}

1, rn), kn1), .., exp(exp(Xi, rn), kni), .., exp(exp(Xn−1, rn), kn(n−1)) et g´en`ere comme clef de groupe exp(Xn, rn). `A partir du message X′, l’intrus a la composante exp(exp(Xi, rn), kni). Il peut donc r´ecup´erer exp(Xi, rn) = exp(Xn, rn). Ainsi, il poss`ede la vue de la clef du participant Pn. Ensuite, pour les autres membres, puisque l’intrus n’a pas touch´e `a l’ex´ecution normale par rapport `a ces membres, ils partagent la mˆeme clef exp(exp(X1, rn), r1) = exp(exp(Xi, rn), ri) = exp(exp(Xn−1, rn), rn−1). L’intrus poss`ede donc les vues des deux parties de groupe.

4.8

Conclusion

Nous avons pr´esent´e dans ce chapitre une ´etude qui s’applique aux protocoles de groupe, et plus g´en´eralement aux protocoles contribuants, i.e. les protocoles o`u les participants contribuent ensemble afin d’atteindre `a un but (par exemple, g´en´erer une clef de session). Elle permet de

118 Chapitre 4. D´etection de types d’attaques sur les protocoles de groupe mod´eliser les protocoles eux-mˆemes, mais surtout de d´ecrire leurs caract´eristiques ainsi que les propri´et´es de s´ecurit´e qu’ils doivent satisfaire. Notre objectif ´etait de consid´erer une classe plus g´en´erale que celle des protocoles GDH. La formalisation pr´esent´ee permet d’´eviter toute am- bigu¨ıt´e sur la d´efinition des probl`emes de s´ecurit´e pos´es, et donc de garantir que les recherches de failles s’effectuent sur de bonnes bases. Nous avons illustr´e ces travaux sur quatre protocoles connus d´efectueux en se basant sur des sc´enarii d’attaques. Les protocoles ´etudi´es sont les pro- tocoles A-GDH.2 et SA-GDH.2, Asokan-Ginzboorg et Bresson-Chevassut-Essiari-Pointcheval.

Nous avons ´egalement pr´esent´e une strat´egie de recherche d’attaques qui s’applique aux protocoles de groupe. Cette strat´egie combine le mod`ele de [101] avec le mod`ele de services. En effet, elle utilise le mod`ele de services pour d´eduire les contraintes relatives `a la violation de la ou des propri´et´es de s´ecurit´e `a v´erifier. Ces contraintes sont utilis´ees avec les contraintes du protocole pour obtenir une trace d’ex´ecution d’une ´eventuelle attaque.

Nous avons appliqu´e notre strat´egie sur trois protocoles : le protocole Asokan-Ginzboorg et les protocoles GDH.2 et A-GDH.2. Nous avons trouv´e une attaque d’accord de clefs pour le pro- tocole de Asokan-Ginzboorg. Cette attaque consid`ere une ex´ecution de deux sessions parall`eles `a deux participants chacune. Pour le protocole GDH.2, pour une ex´ecution `a quatre participants, nous avons trouv´e deux attaques d’authentification. La premi`ere est par rapport au troisi`eme participant et la deuxi`eme attaque est par rapport au quatri`eme participant. Ces deux attaques ont ´et´e g´en´eralis´ees pour construire des attaques `a n participants. Concernant le protocole A- GDH.2, pour une ex´ecution `a quatre participants, l’intrus arrive `a diviser le groupe en deux sous-groupes ayant chacun une vue de la clef diff´erente de l’autre. En plus, l’intrus poss`ede ces deux vues de clefs. Cette attaque est aussi g´en´eralis´ee pour une attaque `a n participants.

La m´ethode de falsification de protocoles propos´ee peut donc chercher d’´eventuelles attaques concernant les diff´erentes propri´et´es de s´ecurit´e des protocoles de groupe d´efinies par le mod`ele de services. N´eanmoins, bien que la plupart des attaques trouv´ees pour les protocoles ´etudi´es ont pu ˆetre g´en´eralis´ees `a n participants, l’entr´ee de notre m´ethode, comme la plupart des techniques d’autres outils de recherche d’attaques, reste toujours des instances du protocole ´etudi´e avec un nombre fini de participants. Cependant, la fixation du nombre de participants `a l’avance fait perdre d’´eventuelles attaques. En plus, comme toute m´ethode de falsification de protocoles en g´en´eral, l’absence d’attaques pour un protocole ´etudi´e ne signifie pas que le protocole est correct. Le but du chapitre suivant est de proposer une m´ethode pour v´erifier les protocoles de groupe pour un nombre quelconque de participants.

5

Un mod`ele synchrone pour la

v´erification de protocoles param´etr´es

Sommaire

5.1 Introduction . . . 119 5.2 Etude de cas : Asokan-Ginzboorg . . . 121´ 5.3 Du mod`ele asynchrone vers le mod`ele synchrone . . . 122 5.3.1 Contexte . . . 122 5.3.2 Transformation du mod`ele asynchrone vers le mod`ele synchrone . . . 123 5.3.3 Application `a notre ´etude de cas . . . 125 5.4 Mod`ele de protocole . . . 126 5.4.1 Termes, taggage et indices . . . 126 5.4.2 Sp´ecification du protocole . . . 128 5.4.3 Mod`ele de l’intrus . . . 129 5.4.4 D´erivations, attaques . . . 129 5.5 Equivalence entre le mod`´ ele asynchrone et le mod`ele synchrone . . 130 5.6 R´esultat d’ind´ecidabilit´e et restrictions . . . 131 5.6.1 Ind´ecidabilit´e du probl`eme d’ins´ecurit´e pour les protocoles param´etr´es . 131 5.6.2 La classe des protocoles bien tagu´es avec clefs autonomes . . . 134 5.7 Contraintes et syst`eme de contraintes . . . 136 5.7.1 Pr´eliminaires . . . 136 5.7.2 Contraintes ´el´ementaires et contraintes n´egatives . . . 137 5.7.3 Blocs de contraintes et syst`eme de contraintes . . . 140 5.8 Syst`eme de r`egles d’inf´erence . . . 141 5.8.1 Quelques notions n´ecessaires . . . 142 5.8.2 Les r`egles d’inf´erence . . . 143 5.8.3 Les r`egles d’inf´erence et le taggage . . . 151 5.8.4 Contrainte en forme normale . . . 152 5.9 Conclusion . . . 153

5.1

Introduction

Nous nous sommes int´eress´es dans le Chapitre 4, `a la falsification de protocoles de groupe vis-`a-vis d’une vari´et´e de propri´et´es de s´ecurit´e. Nous avons pu trouver des failles pour diff´erents

120 Chapitre 5. Un mod`ele synchrone pour la v´erification de protocoles param´etr´es protocoles de groupe par application de notre m´ethode de recherche d’attaques. Cependant, notre proc´edure avait comme entr´ee des instances bien particuli`eres de protocoles o`u le nombre de participants est fix´e d’avance. Notre m´ethode peut donc manquer des attaques n´ecessitant plus de participants. Par cons´equent, ne pas trouver une attaque par notre m´ethode n’entraˆıne pas la correction du protocole.

Or, nous avons pr´esent´e ´egalement en chapitre 3 les probl`emes que peut poser la v´erification des protocoles de groupe. En particulier, mis `a part leurs propri´et´es de s´ecurit´e sophistiqu´ees, et plus sp´ecifiquement pour les protocoles d’accord de clefs, la clef de groupe se base essentiel- lement sur les contributions de tous les membres du groupe. La mod´elisation de ces protocoles n´ecessite donc le traitement de listes non born´ees. Leur v´erification se confronte alors au fait que ces protocoles peuvent avoir un nombre arbitrairement important d’´etapes vu que le nombre de participants est `a priori non born´e. Ensuite, certains participants tels que les serveurs ou les leaders manipulent des listes d’informations provenant des autres participants. Ils se trouvent donc contraints `a traiter ces listes de mani`ere r´ecursive ou it´erative afin de r´ecup´erer les contri- butions des autres participants ou de construire des messages destin´es `a chacun d’eux.

Toutes ces caract´eristiques des protocoles de groupe permettent de coder facilement des probl`emes ind´ecidables. Cependant, comme d´etaill´e en chapitre 3, peu de travaux ont trait´e ces probl´ematiques, `a savoir des protocoles avec nombre non born´e de participants et avec des calculs r´ecursifs. L’analyse formelle d’un tel protocole remonte `a Paulson [77] avec une ´etude du protocole RA (Recursive Authentication) [23]. Cependant, si le protocole est d´efectueux, il n’y a pas de m´ecanisme automatique permettant de retrouver l’attaque correspondante. D’autres travaux ont vu le jour r´ecemment. Cependant, certains travaux [59, 60, 99] ont utilis´e unique- ment des clefs atomiques. D’autres n’ont consid´er´e que le cas d’un intrus passif [57].

Le but de ce chapitre est de proposer un mod`ele synchrone (voir [27] et [28]) pour les protocoles param´etr´es avec un nombre fini de sessions. Ce mod`ele est une extension de mod`eles classiques de v´erification de protocoles tels que [89] afin de pouvoir manipuler des listes de messages dont la longueur est donn´ee comme param`etre. Mis `a part les protocoles de groupe, la manipulation de listes existe aussi dans diff´erents domaines. Nous pouvons citer par exemple les protocoles de web services o`u des listes de messages sont souvent utilis´ees (voir exemple 5.1.0.1). Exemple 5.1.0.1 Le besoin de manipuler des listes se ressent aussi pour ce cas tr`es basique d’op´eration effectu´ee par un participant honnˆete. Ce participant re¸coit une liste m1, .., mn de messages dont la longueur n n’est pas connue `a l’avance et r´epond par l’envoi d’un message construit `a base des informations qu’il vient de recevoir :

h{m1}k, .., {mn}ki −→ f (hm1, .., mni)

Dans cette ´etape, le participant d´ecrypte les diff´erents messages de la liste qu’il vient de recevoir en utilisant la clef publique de l’´emetteur. Il construit apr`es le message `a envoyer en utilisant la liste m1, .., mn de messages r´ecup´er´es et la fonction f .

Notons que l’action basique pr´esent´ee dans l’Exemple 5.1.0.1 est utilis´ee notamment dans les services web o`u les messages peuvent contenir des listes de nœuds XML encrypt´es. En outre, notre mod`ele permet aussi de g´erer les protocoles de groupe qui impliquent un nombre non born´e de participants, et pouvant par la suite ˆetre vus comme des protocoles param´etr´es par leur nombre de participants. Notons aussi que notre ´etude de cas de protocoles de groupe (le protocole Asokan-Ginzboorg) suit l’action de base de l’Exemple 5.1.0.1.

5.2. ´Etude de cas : Asokan-Ginzboorg 121