De nombreux travaux ont ´et´e effectu´es pour v´erifier formellement les protocoles relativement classiques [5, 103]. Ces protocoles se caract´erisent par la manipulation d’un nombre fix´e de mes- sages ´echang´es au cours des sessions. Ces messages doivent aussi avoir une structure bien d´efinie et fix´ee. Parmi les moyens de mod´elisation de ces protocoles, on peut par exemple exprimer leurs ´etapes comme ´etant de simples r`egles de r´e´ecriture. Grˆace aux ´etudes de ces protocoles classiques, nous avons pu assister au d´eveloppement de plusieurs outils automatiques de v´erification de ces protocoles (par exemple [4]).
Cependant, dans [65], Meadows ´evoque d’autres protocoles plus compliqu´es pr´esentant un d´efi pour la v´erification. Il s’agit des protocoles de groupe dont le nombre de participants peut ˆetre arbitrairement grand. La v´erification de ces protocoles est confront´ee `a plusieurs probl`emes. En effet, comme nous venons de voir en Section 2.2.2, la s´ecurit´e des communications au sein des groupes n’est pas n´ecessairement une extension d’une communication s´ecuris´ee entre deux parties. Elle est beaucoup plus compliqu´ee. Une fois la communication commenc´ee, le groupe peut changer de structure en ajoutant ou en supprimant un ou plusieurs membres. Les services de s´ecurit´e sont alors plus ´elabor´es. Ensuite, vu que les besoins en s´ecurit´e sont g´en´eralement li´es aux protocoles, il est difficile de d´ecrire les propri´et´es que le protocole doit satisfaire. Cette phase de sp´ecification des propri´et´es est critique : toute erreur (de compr´ehension ou de formalisation de ces propri´et´es) peut engendrer de fausses failles de s´ecurit´e. En outre, la plupart des outils et des m´ethodes se sont concentr´es seulement sur les propri´et´es de s´ecurit´e li´ees `a l’atteignabilit´e telles que l’authentification ou le secret. Or, les protocoles de groupe consid`erent des propri´et´es de s´ecurit´e plus d´evelopp´ees (voir Section 2.4), li´ees `a la dynamique du groupe. Par exemple, v´erifier que, dans un protocole d’accord de clefs, tous les membres arrivent `a d´eduire la mˆeme clef du groupe.
Au contraire des protocoles dits classiques, les protocoles de groupe mettent en cause un nombre de participants non born´e. Mˆeme une ex´ecution l´egale d’un de ces protocoles peut mener `a un nombre non born´e d’´etapes, ce qui provoque une explosion du nombre d’´etats at-
3.2. Probl`emes li´es `a la v´erification des protocoles de groupe 41 teignables pour les techniques d’exploration d’´etats, souvent utilis´ees pour la v´erification des protocoles cryptographiques. En outre, la plupart des approches automatis´ees de v´erification de protocoles n´ecessitent un mod`ele concret. La taille du groupe doit alors ˆetre fix´ee `a l’avance. Or, cette contrainte restreint consid´erablement le nombre d’attaques d´etectables.
La caract´erisation des protocoles de groupe par le nombre non born´e de participants fait apparaˆıtre de nouveaux d´efits `a leur v´erification. En effet, g´erer un grand nombre de participants suppose implicitement qu’un ou plusieurs de ces participants ont `a g´erer un nombre non born´e de messages ´echang´es. Cette situation, illustr´ee par la Figure 3.1, repr´esente le cas d’un groupe form´e de deux parties : une compos´ee d’une seule entit´e principale, et une deuxi`eme partie compos´ee du reste du groupe. Les messages sont ´echang´es entre cette entit´e principale et chacun des autres participants de la deuxi`eme partie. Les participants de la deuxi`eme partie ne communiquent pas entre eux directement.
...
...
M1 Mi
Mn
Mn−1
Fig. 3.1 – Un groupe structur´e en deux parties
Comme exemple de protocoles pr´esentant cette situation, nous pouvons citer les protocoles de distribution de clefs d´ecrits en Section 2.3.1, mais aussi les protocoles d’accord de clefs d´ecrits en Section 2.3.3. Nous sommes donc dans un contexte de groupe de plusieurs participants vou- lant g´en´erer une clef commune. En outre, il existe une entit´e appel´ee le serveur ou le leader qui a pour rˆole de collecter toutes les contributions des diff´erents participants.
La gestion d’un nombre non born´e de messages peut aussi entraˆıner la n´ecessit´e de g´en´erer des messages `a structure non born´ee comme les listes et par la suite la n´ecessit´e de traitements it´eratifs de ces structures de donn´ees. Comme exemple de participants de protocole pouvant effectuer des traitements it´eratifs, nous trouvons le cas d’un serveur qui collecte les contributions des autres participants afin de g´en´erer la clef. Une fois, qu’il a r´ecup´er´e les messages contenant les contributions, il construit la clef ou une information menant `a la clef et envoie une liste de messages contenant cette information `a tous les participants. Comme exemple de protocole de cette cat´egorie, nous pouvons citer le protocole de Asokan-Ginzboorg [6] qui suit la structure illustr´ee par la Figure 3.1. Cet aspect de traitement de listes est omnipr´esent dans la plupart des protocoles de groupe d’autant plus que ces listes n´ecessitent parfois un traitement r´ecursif. Ce traitement a pour but de r´ecup´erer des informations des messages de la liste re¸cue afin de pouvoir g´en´erer le message que le participant veut envoyer. Ce genre de situation peut aussi exister dans le cas d’un groupe structur´e sous forme de chaˆıne, i.e. les messages sont ´echang´es d’un participant `a un autre. Cette situation est illustr´ee par la Figure 3.2. Un membre de groupe re¸coit un message de son voisin pr´ec´edant (`a gauche), ajoute son traitement `a ce message et l’envoie `a son prochain voisin (`a droite). Finalement, quand le dernier participant re¸coit le dernier message de cette chaˆıne, il g´en`ere le message `a envoyer et le transmet `a tous les participants.
Nous citons comme premier exemple pour cette situation, le protocole GDH (et les versions d´eriv´ees : A-GDH . . . ) du projet Cliques qui a pour objectif de g´en´erer une clef de groupe
42 Chapitre 3. V´erification de protocoles de groupe
...
...
M1 Mi
Mn
Mn−1
Fig.3.2 – Un groupe structur´e sous forme de chaˆıne
(voir Figure 2.5 de la Section 2.3.3). `A la r´eception d’un message dans la phase de contribution, chaque membre traite une liste de messages en exponentiant chaque composant de cette liste par sa contribution personnelle `a la clef du groupe. Le dernier membre re¸coit une liste de messages. Il calcule sa clef `a partir de la derni`ere composante de la liste re¸cue, exponentie chacune des composantes de cette liste par sa contribution `a la clef du groupe, et envoie cette nouvelle liste au reste du groupe.
Comme deuxi`eme exemple, nous citons le protocole RA (Recursive Authentication) [23] qui a pour but de permettre `a un serveur de distribuer une clef de session pour n’importe quel nombre de membres. Nous nous focalisons dans ce protocole, sur la seule action r´ecursive du serveur. Ce serveur re¸coit une liste de paires de requˆetes de participants qui veulent ´etablir une clef de session entre eux. Cette liste de paires de requˆetes est de taille variable et peut ˆetre large. Le serveur traite la liste d’une mani`ere it´erative, g´en`ere des clefs de session, une pour chaque paire de requˆetes, et les distribue. Par exemple, le serveur peut recevoir un message m de la forme m = hKc(C, S, Nc, hKb(B, C, Nb, hKa(A, B, Na, −))) qui repr´esente un ensemble de requˆetes de
paires de participants souhaitant l’obtention d’une clef de session. Dans ce message, Na, Nb, Nc sont des nonces g´en´er´ees respectivement par A, B et C. Les clefs Ka, Kb, Kc sont des clefs `a long terme partag´ees entre S et respectivement A, B et C. Le message hk(m) d´esigne le mes- sage hhash(k, m), mi. La constante − d´esigne la fin de la liste des requˆetes et donc la fin du traitement r´ecursif. Le serveur S doit traiter ce message d’une mani`ere r´ecursive afin de g´en´erer des certificats pour ces diff´erents participants. Il g´en`ere tout d’abord deux certificats pour S : {Kcs, S, Nc}Kc et {Kbc, B, Nc}Kc. Il g´en`ere par la suite deux certificats pour B : {Kbc, C, Nb}Kb
et {Kab, A, Nb}Kb. Finalement, il g´en`ere un certificat pour A : {Kab, B, Na}Ka.
En conclusion, la v´erification des protocoles de groupe n´ecessite le traitement de certains calculs it´eratifs et r´ecursifs, et donc fait partie de la v´erification des protocoles dits r´ecursifs. Il s’agit des protocoles o`u les pas comprennent des calculs r´ecursifs et/ou it´eratifs.
C’est le cas de la plupart des protocoles de groupe, que ce soient centralis´es pr´esent´es en Sec- tion 2.3.1, ou distribu´es d´ecrits en Section 2.3.3. En effet, pour le cas centralis´e, on trouve g´en´eralement des calculs `a la fois r´ecursifs et it´eratifs puisque le serveur attend toutes les requˆetes des diff´erents participants et puis proc`ede par calcul r´ecursif afin de calculer la clef du groupe ou encore une information commune au groupe. Quant au cas distribu´e, ce traitement est le mˆeme mais il est n´ecessaire au niveau de chaque membre du groupe. Comme exemples de protocoles r´ecursifs, on peut citer IKE, RA [23] ou encore GDH.2 [80].
La n´ecessit´e du traitement d’un nombre non born´e de messages ´echang´es ainsi que les calculs r´ecursifs et it´eratifs effectu´es par les participants ont fait que la v´erification des protocoles de groupe paraˆıt difficile. Il s’agit donc d’un d´efit `a relever par les m´ethodes de v´erification de protocoles cryptographiques, surtout que ces m´ethodes v´erifient des protocoles dont le nombre de messages dans une session est fixe et que la structure de ces diff´erents messages est toujours fixe au d´epart et finie.
3.3. ´Etat de l’art : r´esultats exp´erimentaux 43