Du mod`ele asynchrone vers le mod`ele synchrone

Nous pr´esentons dans cette section le mod`ele synchrone que nous consid´erons comme classe de d´epart pour notre proc´edure de d´ecision adapt´ee aux protocoles de groupe.

5.3.1 Contexte

Nous examinons dans cette section la classe des protocoles d’´etablissement de clefs avec les deux grandes cat´egories suivantes. La premi`ere cat´egorie est celle d’accord de clefs o`u un nombre non born´e de participants se met d’accord sur une clef de groupe pour s´ecuriser leurs commu- nications. Cette clef se base sur les contributions de tous les membres du groupe. La deuxi`eme cat´egorie est celle de la distribution de clefs o`u une entit´e centrale, qui est g´en´eralement le serveur, contrˆole la g´en´eration et la mise `a jour de la clef de groupe et la distribue `a tous les membres du groupe.

Pour ces deux cat´egories et dans plusieurs cas de ce genre de protocoles, il existe deux types de participants. D’une part, il y a des participants ordinaires qui ont pratiquement les mˆemes actions, i.e. ont le mˆeme comportement vis `a vis des messages re¸cus et des messages envoy´es en r´eponse. D’autre part, il y a des participants sp´eciaux qui ont des comportements diff´erents des autres participants ordinaires. Nous pouvons citer l’exemple du leader ou encore du serveur. Un tel participant doit ˆetre capable de recevoir et traiter plusieurs messages provenant de diff´erents participants. Il doit aussi pouvoir composer des messages bas´es sur les informations existant dans les messages qu’il vient de recevoir pour pouvoir envoyer les messages compos´es aux diff´erents participants.

Nous nous int´eressons `a la communication entre l’ensemble P1, .., Pn−1 des participants or- dinaires et le leader ou le serveur Pn. Il existe deux situations dans ce contexte.

Premi`ere situation

Dans la premi`ere situation illustr´ee par la Figure 5.1, le leader communique avec tous les participants ordinaires. Il attend les contributions de tous ces participants. Il calcule apr`es la clef de groupe ou une information pouvant g´en´erer cette clef pour enfin envoyer cette information (ou clef) `a tous les participants. Ainsi, les communications sont restreintes, dans ce cas, aux communications entre le leader Pn et chacun des participants ordinaires Pi. Comme exemple de protocoles pr´esentant ce genre de situations, nous pouvons citer le protocole de Asokan- Ginzboorg [6].

Deuxi`eme situation

Dans la seconde situation illustr´ee par la Figure 5.2, le groupe est mod´elis´e sous forme de chaˆıne o`u chaque participant ordinaire communique sa contribution `a son voisin. Quant au dernier participant des participants ordinaires Pn−1, il communique le message compos´e par toutes les contributions de tous les participants pr´ec´edents au leader. Ensuite, le leader envoie la clef du groupe ou une information qui m`ene `a cette clef `a tous les participants ou bien au dernier des participants ordinaires qui, lui, transfert cette information au reste du groupe. Comme exemples de tels protocoles, nous pouvons citer les protocoles GDH.2 [8] et RA [23].

5.3. Du mod`ele asynchrone vers le mod`ele synchrone 123

..

..

Fig. _{5.1 – Protocoles de groupe : premi`ere situation}

...

...

P1 Pi Pi+1 Pn Pn

Fig. _{5.2 – Protocoles de groupe : deuxi`eme situation}

5.3.2 Transformation du mod`ele asynchrone vers le mod`ele synchrone

L’id´ee de base de notre approche est de compresser les messages qui sont re¸cus par (ou en- voy´es `a) plusieurs participants ordinaires, i.e. ayant des comportements similaires vis `a vis d’un mˆeme message re¸cu. Ceci permet `a un participant de recevoir tous les messages qu’il doit rece- voir en une seule fois avant de les traiter pour composer le message `a envoyer. Cette approche doit tenir compte du fait que, dans certains cas, le message envoy´e est destin´e `a plusieurs par- ticipants au d´epart. Afin de pouvoir traiter cette probl´ematique, nous proposons de r´eorganiser le protocole et plus pr´ecis´ement l’ensemble de participants. Nous proposons de repr´esenter tous les participants ordinaires par un seul participant assez sp´ecial que nous nommons le simulateur. Nous nous int´eressons `a la premi`ere situation d´ecrite dans le premier paragraphe de la Sec- tion 5.3.1. Nous nous focalisons sur la communication entre l’ensemble des participants ordinaires et le leader afin de d´eduire la transformation qui m`ene `a une communication entre le leader et un simulateur qui simulerait l’ensemble de ces participants ordinaires.

Commen¸cons par ´etudier le point de vue d’un participant Pi. Ce participant attend un message Ri et r´epond par le message Si. Le message Ri provient n´ecessairement du leader. Nous distinguons deux cas. Dans le premier cas, le leader envoie la mˆeme information `a tous les participants. Comme exemple de ce cas, nous pouvons citer l’envoi d’une clef `a utiliser pour le chiffrement des contributions, comme c’est le cas du protocole Asokan-Ginzboorg lors de l’envoi du message {e}_p. Dans ce cas, la r´eception de chacun de ces messages peut ˆetre aussi vue comme la r´eception par le simulateur d’un seul message sous forme de liste compos´ee `a partir du mˆeme message re¸cu par tous les participants. Dans le second cas, le leader envoie une information diff´erente `a chacun des participants ordinaires. Le message qui serait re¸cu par le simulateur est alors une liste des messages (R1, .., Rn−1) re¸cus par les diff´erents participants qu’il simule. Le

124 Chapitre 5. Un mod`ele synchrone pour la v´erification de protocoles param´etr´es message Si est destin´e au leader et contient g´en´eralement une contribution (une information priv´ee) `a la clef de groupe ou une confirmation d’une information d´ej`a re¸cue. Dans ces deux cas, il existe une information priv´ee pour chaque participant. Cependant, mis `a part la ou les information(s) priv´ee(s) du message `a envoyer par un participant honnˆete, tous les messages ont la mˆeme forme, ou structure. Ainsi, si nous simulons cette phase d’envoi des diff´erents messages Si, i = 1, .., (n − 1) par les participants ordinaires, nous obtenons l’envoi, par le simulateur, d’un seul message (S1, .., Sn−1). Nous illustrons dans la Figure 5.3 une ´etape du simulateur pr´esentant la transformation de plusieurs ´etapes des participants ordinaires P1, .., Pn−1, qui sont similaires modulo les informations priv´ees de chacun des participants.

Ri Rn−1 R1 S1 Si Sn−1 hR1, .., Rn−1i hS1, .., Sn−1i P₁ Pi Pn−1

Fig. _{5.3 – Une ´etape pour le simulateur dans le mod`ele synchrone}

Nous nous focalisons maintenant sur le point de vue du leader Pn. Il re¸coit diff´erents messages Rni qui proviennent des participants ordinaires Pi. Cette action peut ˆetre vue comme ´etant la

r´eception d’un seul message Rn sous forme d’une liste compos´ee des messages re¸cus et donc de la forme Rn1, .., Rn_n−1. Si le leader initialise la communication, alors le message qu’il envoie

ne contient aucune information priv´ee, ce qui correspond `a un seul message envoy´e `a tout le monde. Cet acte peut ˆetre alors vu comme ´etant la r´eception, par le simulateur, d’une liste construite d’un mˆeme message (celui envoy´e par le leader). Si, par contre, le leader compose un message destin´e `a chacun des participants et contenant des informations priv´ees relatives `

a chacun d’eux, alors le message re¸cu par le simulateur serait une liste compos´ee de tous ces messages. Nous illustrons dans la Figure 5.4 une ´etape pour le leader dans le nouveau mod`ele synchrone.

En r´esum´e, nous avons le contexte suivant. D’une part, il y a un ensemble de participants P1, . . . , Pn−1 qui r´eagissent de mani`ere similaire vis `a vis d’un mˆeme message. Ils envoient leur contribution `a la clef de groupe au leader (ou serveur). Ils re¸coivent des informations du leader leur permettant de g´en´erer cette mˆeme clef. Une ´etape du simulateur simule donc l’ensemble des ´etapes d´ecrivant la mˆeme action effectu´ee par les diff´erents participants. D’autre part, le leader re¸coit toutes les contributions en une seule fois du simulateur et envoie les messages destin´es aux diff´erents participants en une seule liste au simulateur. La transformation du mod`ele asynchrone en un mod`ele synchrone abstrait, donc de tous les participants ordinaires P1, .., Pn en un seul agent, est illustr´ee par la Figure 5.3.2.

5.3. Du mod`ele asynchrone vers le mod`ele synchrone 125 Rni hSn1, .., Sn_n−1i R n1 Rnn− 1 Sni S_n n −1 Sn1 hRn1, .., Rn_n−1i Pn

Fig. _{5.4 – Une ´etape pour le leader dans le mod`ele synchrone}

Leader ... ... Leader Version Initiale ... ... Simulateur Version Synchrone P1 Pi Pn P1 hR1, .., Rni hS1, .., Sni Si S1 Sn R1 Ri Rn Pi Pn

Fig. _{5.5 – Transformation du mod`ele asynchrone en mod`ele synchrone}

5.3.3 Application `a notre ´etude de cas

Revenons `a notre exemple : le protocole de Asokan-Ginzboorg. Nous pr´esentons dans cette section la version synchrone de cet exemple. Le simulateur est not´e par S et il simule les agents P1, . . . , Pn. L’agent L simule le leader Pn+1. La version synchrone est donn´ee par l’Exemple 5.3.3.1.

Exemple 5.3.3.1 Dans cet exemple, nous pr´esentons la version synchrone de notre ´etude de cas donn´ee par l’Exemple 5.2.0.2.

1. L −→ S : hhl, {e}pi, .., hl, {e}pii

2. S −→ L : hha1, {hr1, s1i}ei, .., han, {hrn, sni}eii 3. L −→ S : h{hhs1, .., sni, s′i}r1, .., {hhs1, .., sni, s

′_i} rni

4. S −→ L : hha1, {hs1, h(hhs1, .., sni, s′i)i}f (hhs1,..,sni,s′i)i, ..,

han, {hsn, h(hhs1, .., sni, s′i)i}f (hhs1,..,sni,s′i)ii

o`u l est l’identit´e du leader qui est dans la version initiale an+1, et s′ sa contribution. Notons que chaque composante du message envoy´e `a l’´etape 3 est form´e de deux parties : la premi`ere partie correspond `a l’ensemble des contributions des participants. Quant `a la deuxi`eme partie, elle correspond `a la contribution du serveur.

126 Chapitre 5. Un mod`ele synchrone pour la v´erification de protocoles param´etr´es