Contrainte en forme normale

Le but de l’application de toutes les r`egles d´efinies dans la Section 5.8.2 est d’arriver `a un syst`eme de contraintes dites en forme normale, i.e. sur lesquelles aucune r`egle n’est applicable. Le but d’avoir un tel syst`eme est d’en tester la satisfaisabilit´e afin de trouver une solution d´ecrivant une attaque. Nous donnons dans cette section la d´efinition de contrainte en forme normale qui sera utilis´ee dans le Chapitre 6. Nous appliquons ensuite nos r`egles d’inf´erence sur l’exemple du protocole Asokan-Ginzboorg en pr´esentant les contraintes en forme normale trouv´ees.

D´efinition 5.8.4.1 Contrainte en forme normale.

Une contrainte en forme normale est une contrainte de type : (Xi∈ F orgec(E, K)), ou X ∈ F orgec(E, K), ou (Xi = u), ou (X = u)sm, ou (∀j Xi6= u) ou encore (Y /∈ F orgec(E, K)), avec X ∈ X , Y ∈ X ∪ XI, Xi∈ XI, u ∈ T , j ∈ V arI(u), E ⊂ T et K ⊂ T

Nous montrerons dans le Chapitre 6 que `a chaque ´etape d’une ex´ecution du protocole, le syst`eme de contraintes normalis´ees (obtenues quand aucune r`egle n’est applicable) contient uniquement des contraintes en forme normale.

Exemple 5.8.4.2 Application au protocole de Asokan-Ginzboorg.

Consid´erons la sp´ecification du protocole de Asokan-Ginzboorg donn´ee par l’Exemple 5.4.2.1. Nous nous int´eressons uniquement `a l’´etape (S, 1) de cette sp´ecification :

mpair(i, hL, {Ei}pi) ∈ F orge(E1, K1). Supposons que E1 = {mpair(t, hl, {e}pi)} et E = ∅.

mpair(i, hL, {Ei}pi) ∈ F orge(E1, ∅)

−→−→(mpair(i, hL, {Ei}pi) ∈ F orgec(E1, ∅))

−→−→∨ (mpair(i, hL, {Ei}pi) ∈ Sub(mpair(t, hl, {e}pi), E1, E, ∅)) par application de la R`egle [5.9]

−→−→∀i ((hL, {Ei}pi ∈ F orge(E1, ∅)) ∨ (mpair(i, hL, {Ei}pi) = mpair(t, hl, {e}pi)) −→−→∀i∨ (mpair(i, hL, {Ei}pi) ∈ Subd(mpair(t, hl, {e}pi), E1, E, ∅)))

par application des R`egles [5.13] et [5.15]

−→−→∀i ∀j ((hL, {Ei}pi ∈ Sub(mpair(t, hl, {e}pi), E1, E, ∅)) ∨ (hL, {Ej}pi = hl, {e}pi)

−→−→∀i ∀j ∨ (mpair(i, hL, {Ei}pi) ∈ Subd(hl, {e}pi, E1, E, ∅)) ∨ (hL, {Ei}pi ∈ F orgec(E1, ∅))) par application des R`egles [5.9], [5.19], [5.15], [5.22] et [5.24]

−→−→∀i ∀j ((L ∈ F orge(E1, ∅) ∧ {Ei}p ∈ F orge(E1, ∅)) ∨ ((L = l)sm∧ Ej = e) −→−→∀i ∀j ∨ (hL, {Ei}pi ∈ Sub(hl, {e}pi, E1, E, ∅)))

5.9. Conclusion 153

−→−→∀i ∀j ((L ∈ F orge(E1, ∅) ∧ Ei ∈ F orge(E1, ∅) ∧ p ∈ F orge(E1, {Ei}p)) −→−→∀i ∀j ∨ (L ∈ F orge(E1, ∅) ∧ {Ei}p∈ Subd(mpair(t, hl, {e}pi), E1, E, ∅)) −→−→∀i ∀j ∨ ((L = l)sm_{∧ E}

i = e) ∨ ((L = l)sm∧ Ej = e))

par application des R`egles [5.9], [5.11], [5.15], [5.22], [5.23], [5.16], [5.17] et [5.20] −→−→∀i ∀j ((L ∈ F orge(E1, ∅) ∧ Ei = e) ∨ ((L = l)sm∧ Ei= e) ∨ ((L = l)sm∧ Ej = e)) par application des R`egles [5.15], [5.19], [5.16], [5.17], [5.20], [5.22] et [5.23]

−→−→∀i ∀j ((L ∈ F orge(E1, ∅) ∧ (Ei= e)m) ∨ ((L = l)sm∧ (Ei= e)m) −→−→∀i ∀j ∨ ((L = l)sm∧ (Ej = e)m))

par application de la R`egle [5.4]

5.9

Conclusion

Nous avons propos´e dans ce chapitre une approche pour la v´erification de protocoles de groupe, caract´eris´es par le nombre de participants non born´e qu’ils impliquent, et plus g´en´erale- ment pour la v´erification de protocoles manipulants des listes param´etr´ees. L’intuition derri`ere cette approche est de consid´erer une classe de protocoles de groupe o`u il existe deux types de participants : un leader (ou serveur) et un certain nombre de participants ordinaires qui ont des comportements similaires vis-`a-vis de la r´eception et de l’envoi des messages. Nous mod´elisons en cons´equence tous les participants ordinaires en un seul participant sp´ecial appel´e simulateur. Nous avons introduit une transformation pour les protocoles de groupe qui permet de passer du mod`ele asynchrone au mod`ele synchrone d’un protocole. Certes cette transformation n’est pas toujours compl`ete, i.e. nous pouvons perdre d’´eventuelles attaques, mais si nous trouvons une attaque dans notre mod`ele synchrone alors il s’agit d’une vraie attaque. Nous avons aussi pr´ecis´e les conditions de l’´equivalence entre ces deux mod`eles, sous couvert d’une pr´e-analyse du protocole.

Il est `a noter que, mis `a part celui des protocoles de groupe, ce mod`ele peut ˆetre aussi utilis´e dans d’autres domaines tels que les services Web o`u les messages peuvent contenir des listes non born´ees de nœuds XML encrypt´es. Dans ce cas, aucun changement du mod`ele n’est n´ecessaire. Nous avons donc pr´esent´e notre mod`ele synchrone pour les protocoles de groupe qui g´en´eralise les mod`eles classiques tels que [89] en incluant des listes non born´ees dans les messages. Pour pouvoir g´erer ces listes, un nouvel op´erateur a ´et´e introduit. Il est not´e mpair et d´esigne une liste construite sur une racine unique (pattern). L’ajout na¨ıf de cet op´erateur m`ene `a l’ind´ecidabilit´e du probl`eme de l’ins´ecurit´e, ce qui nous a conduit `a introduire une classe de protocoles appel´ee la classe des protocoles bien tagu´es avec clefs autonomes, qui est d´ecidable.

Nous avons expos´e ensuite les diff´erentes contraintes que nous utilisons, pour enfin d´etailler nos r`egles d’inf´erence portant sur des syst`emes de contraintes (i.e. la repr´esentation formelle d’un ensemble infini d’´etats du protocole). Ces diff´erentes r`egles d’inf´erence permettent de d´efinir la proc´edure de v´erification de la s´ecurit´e pour la classe des protocoles bien tagu´es avec clefs autonomes que nous introduirons dans le prochain chapitre (Chapitre 6). Nous montrerons que le syst`eme de r`egles, sur lequel se base cette proc´edure, est d´esormais correct et complet. Nous prouverons que l’application de ces r`egles pour un syst`eme de contraintes termine et que la forme normale obtenue peut ˆetre test´ee pour la satisfaisabilit´e. Ainsi, nous pr´esenterons dans le chapitre prochain une proc´edure de d´ecision pour cette classe.

6

D´ecidabilit´e pour les protocoles

param´etr´es bien tagu´es `a clefs

autonomes

Sommaire

6.1 Introduction . . . 155 6.2 V´erification des protocoles bien tagu´es avec clefs autonomes . . . . 156 6.3 Quelques d´efinitions pour les preuves . . . 159 6.4 Correction et compl´etude . . . 160 6.4.1 Propri´et´es de notre syst`eme d’inf´erence . . . 160 6.4.2 Correction et compl´etude des r`egles . . . 166 6.5 Notre mod`ele est une extension des mod`eles classiques . . . 174 6.5.1 Poids des termes, contraintes ´el´ementaires, blocs et syst`emes de contraintes175 6.5.2 Terminaison pour les protocoles sans indices et sans mpair . . . 176 6.6 Terminaison pour les protocoles bien tagu´es avec clefs autonomes . 177 6.6.1 Propri´et´es de notre syst`eme d’inf´erence li´ees aux indices . . . 178 6.6.2 Une borne pour les indices g´en´er´es par le syst`eme d’inf´erence . . . 184 6.6.3 Terminaison pour les protocoles bien tagu´es avec clefs autonomes . . . . 195 6.7 Test de satisfaisabilit´e . . . 198 6.7.1 Premi`ere ´etape : la normalisation . . . 199 6.7.2 Deuxi`eme ´etape : la transformation des contraintes F orgec . . . 202 6.7.3 Troisi`eme ´etape : l’existence d’une valeur emax du param`etre n . . . 206 6.8 Etude de cas . . . 208´ 6.8.1 Asokan-Ginzboorg `a une seule session . . . 208 6.8.2 Asokan-Ginzboorg `a deux sessions en parall`ele . . . 210 6.9 Conclusion . . . 211

6.1

Introduction

Nous avons propos´e dans le chapitre pr´ec´edent un mod`ele synchrone pour les protocoles de groupe qui peut ˆetre aussi utilis´e pour tout autre protocole utilisant des listes param´etr´ees par leur longueur. La gestion de ces listes a ´et´e assur´ee par l’ajout d’un op´erateur appel´e mpair qui mod´elise une liste de termes ayant une forme commune (le mˆeme pattern). Cependant, le

156 Chapitre 6. D´ecidabilit´e pour les protocoles param´etr´es bien tagu´es `a clefs autonomes probl`eme de l’ins´ecurit´e pour ce mod`ele avec cet op´erateur s’av`ere ind´ecidable. Nous avons donc introduit une classe de ces protocoles appel´ee la classe des protocoles bien tagu´es avec clefs autonomes. Nous avons ensuite pr´esent´e le syst`eme de contraintes que nous consid´erons et qui sera manipul´e par l’ensemble de r`egles d’inf´erence que nous avons propos´e.

Ce chapitre constitue une suite du pr´ec´edent, puisque son objectif est de proposer une proc´edure de d´ecision pour la classe de protocoles introduite dans ce dernier, i.e. la classe des protocoles bien tagu´es avec clefs autonomes.

Nous commen¸cons donc par d´efinir en Section 6.2 la proc´edure de v´erification consid´er´ee qui se base essentiellement sur l’application des r`egles introduites dans le chapitre pr´ec´edent, et qui r´esout le probl`eme de l’ins´ecurit´e des protocoles. Nous ´enoncerons dans la mˆeme section les r´esultats obtenus pour cette proc´edure, et en particulier le r´esultat de d´ecidabilit´e pour la classe consid´er´ee.

Dans la Section 6.3, nous revenons sur quelques d´efinitions pr´esent´ees dans le chapitre pr´ec´edent et utilis´ees dans les diff´erentes preuves des sections qui suivent. Nous prouverons par la suite en Section 6.4 que l’ensemble de nos r`egles sont correctes et compl`etes. Nous justi- fierons en Section 6.5 que notre mod`ele est effectivement une extension des mod`eles classiques des protocoles cryptographiques en prouvant que, en l’absence d’indices ou de mpair pouvant g´en´erer des indices, nos r`egles d’inf´erence terminent. Dans la Section 6.6, nous montrerons la ter- minaison pour la classe des protocoles bien tagu´es avec clefs autonomes. Nous prouverons aussi en Section 6.7 que la normalisation d’un syst`eme de contraintes par notre ensemble de r`egles conduit `a des contraintes en forme normale dont on peut tester la satisfaisabilit´e. Nous obtien- drons ainsi un r´esultat de d´ecidabilit´e pour la classe consid´er´ee, celle des protocoles bien tagu´es avec clefs autonomes. Nous donnons dans la Section 6.8 des exemples test´es par application de notre proc´edure.