La spécification basée sur les rôles a été proposée en [1–3] pour spécifier un protocole d’une façon intuitive et en tenant compte des connaissances de chaque agent. Elle s’effectue en deux phase. La
première phase consiste à extraire les rôles relatifs à chaque agent. À partir des rôles, on définit les rôles généralisés selon les connaissances de chaque agent.
3.3.1 Protocole
Formellement, un protocole p est décrit par la grammaire BNF suivante :
p ::= he : A −→ B : mi | p.p
Un protocole est une succession d’étapes d’envoi et de réception de messages entre agents. Chaque étape a un identifiant unique e, un émetteur A, un récepteur B, et un message transmis m.
3.3.2 Rôles
Un rôle est une abstraction du protocole où l’emphase est mise sur un seul agent. Les rôles sont extraits à partir du protocole selon les étapes suivantes :
1. pour chaque agent, on extrait à partir du protocole toutes les étapes auxquelles il participe. En outre, on ajoute le même identifiant de session i à toutes ces étapes. À chaque message frais, on ajoute i en exposant pour noter que ces messages changent de valeurs d’une exécution à une autre du protocole ;
2. on introduit explicitement un intrus I pour exprimer que les messages envoyés par tout agent honnête sont reçus par l’intrus, et les messages reçus par tout agent honnête sont envoyés par l’intrus ;
3. on extrait les préfixes des rôles qui ont comme dernière étape un envoi de message. Un préfixe dénote qu’un intrus ou un agent régulier peut participer à une partie du rôle et non à tout le rôle ; 4. les rôles d’un protocole p sont notés par R(p).
3.3.3 Rôles généralisés
À partir des rôles, on définit les rôles généralisés qu’on note par RG(p) où p est le protocole. Un
rôle généralisé est une abstraction d’un rôle où quelques messages sont remplacés par des variables. Intuitivement, on remplace un message ou un composant de message par une variable libre non typée si l’agent ne peut pas faire de vérification dessus et il doute de sa structure, de son contenu, et de son origine. Certaines autres variables ne peuvent être remplacées que par des identités. On note par :
1. X , l’ensemble de variables libres non typées, dénotées par X, Y , etc., qui peuvent prendre n’importe quelle valeur ;
2. IX, l’ensemble de variables de type identité, dénotées par A, B, etc., qui ne peuvent prendre
Exemple 3.3.1.
On considère le protocole NSL suivant :
1, A −→ B : {Na.A}kb
2, B −→ A : {B.Na}ka.{B.Nb}ka
3, A −→ B : A.B.{Nb}kb
Les rôles du protocole NSL est l’ensemble R(pNSL) = {A1, A2, B1, B2}. Ils sont définis dans Table3.1.
Ses rôles généralisés est l’ensemble RG(pNSL) = {A1G, AG2, BG1, B2G}. Ils sont définis dans Table3.2.
A1= i.1 A −→ I(B) : {Ni a.A}kb A2= i.1 A −→ I(B) : {Ni a.A}kb i.2 I(B) −→ A : {B.Ni a}ka.{B.N i b}ka
i.3 A −→ I(B) : A.B.{Nbi}kb
B1= i.1 I(A) −→ B : {Ni a.A}kb i.2 B −→ I(A) : {B.Ni a}ka.{B.N i b}ka B2= i.1 A −→ I(B) : {Ni a.A}kb i.2 I(B) −→ A : {B.Ni a}ka.{B.N i b}ka
i.3 A −→ I(B) : A.B.{Ni b}kb
TABLE3.1 – Rôles du protocole NSL
Comme on peut le constater dans Table3.2, la nonce Nbi que l’agent A devrait recevoir de B a été remplacée par une variable X puisque A ne connait pas préalablement le contenu et ne peut effectuer aucune vérification dessus. De même, la nonce Naique l’agent B devrait recevoir de A a été remplacée par une variable Y pour les mêmes raisons. Les origines des messages -de point de vue d’un agent donné- ainsi que les destinations sont toujours supposées l’intrus.
3.3.4 Trace valide
Une trace valide d’un protocole est une exécution possible du protocole. Elle provient généralement de l’entrelacement de plusieurs rôles généralisés substitués en respectant les types de variables. La
A1
G= i.1 A −→ I(B) : {Nai.A}kb
A2
G= i.1 A −→ I(B) : {Nai.A}kb
i.2 I(B) −→ A : {B.Ni
a}ka.{B.X}ka
i.3 A −→ I(B) : A.B.{X}kb
B1
G= i.1 I(A) −→ B : {Y.A}kb
i.2 B −→ I(A) : {B.Y }ka.{B.Nbi}ka B2
G= i.1 A −→ I(B) : {Y.A}kb
i.2 I(B) −→ A : {B.Y }ka.{B.Nbi}ka i.3 A −→ I(B) : A.B.{Nbi}kb
TABLE3.2 – Rôles généralisés du protocole NSL
définition formelle d’une trace valide nous ramène aux définitions intermédiaires suivantes :
1- Étape de communication : une étape de communication est soit une étape d’envoi soit une étape de réception. Elle est formellement définie par la grammaire BNF suivante :
step ::= hj.i, A −→ I(B) : mi|hj.i, I(A) −→ B : mi
Où j est l’identifiant de la session et i est l’identifiant de l’étape.
2- Trace : une trace ρ est le résultat d’une séquence d’étapes. Elle est formalisée par la grammaire BNF suivante :
ρ ::= ε | step | ρ.step Où ε est la trace vide.
3- Identifiants d’une session : Chaque étape dans une trace possède un identifiant de session. L’en- semble des identifiants de la session Sρassociée à une trace ρ est construit comme suit :
Sε = ∅
Sρ.hj.i,A−→I(B):mi = Sρ∪ {j}
Sρ.hj.i,I(A)−→B:mi = Sρ∪ {j}
4- Sessions entrelacées : Un intrus, quand il manœuvre un protocole, n’exécute les sessions régulières ni au complet ni dans l’ordre. La trace qui résulte de cette manœuvre est un entrelacement d’étapes de
plusieurs sessions. Chacune possède son identifiant. On définit l’identifiant d’une session entrelacée associée à une trace ρIdcomme suit :
εId = ε
(ρ.hj.i, A −→ I(B) : mi)Id = ρId si Id 6= j (ρ.hj.i, I(A) −→ B : mi)Id = ρId si Id 6= j
(ρ.hId.i, A −→ I(B) : mi)Id = ρId.hId.i, A −→ I(B) : mi (ρ.hId.i, I(A) −→ B : mi)Id = ρId.hId.i, I(A) −→ B : mi
Où ε est la trace vide qui peut être éliminée quand elle est suivie ou précédée d’une trace non vide.
5- Def/Use : Les connaissances de l’intrus changent d’une étape à une autre. Après l’exécution d’une trace, l’intrus acquiert de nouvelles connaissances via le réseau ou forme lui-même de nouveaux messages. On définit Def(ρ) les connaissances (messages) reçues par l’intrus après l’exécution d’une trace ρ, et Use(ρ) les messages que l’intrus a pu former après l’exécution de cette trace. Use(ρ) et Def(ρ) sont définies comme suit :
Def(ε) = ∅
Def(ρ.hj.i, A −→ I(B) : mi) = Def(ρ) ∪ {m} Def(ρ.hj.i, I(A) −→ B : mi) = Def(ρ)
Use(ε) = ∅ Use(ρ.hj.i, A −→ I(B) : mi) = Use(ρ) Use(ρ.hj.i, I(A) −→ B : mi) = Use(ρ) ∪ {m}
Pour simplifier l’écriture, on note Use(ρ) par ρ+et Def(ρ) par ρ−.
6- Trace C-bien-définie : Une trace est dite C-bien-définie quand l’intrus est capable de définir tous les messages contenus dans la trace avant de les envoyer. C’est-à-dire, pour toute trace ρ = ρ1.e.ρ2, on
a :
ρ1+|=K(I)e−
Où e est une étape de communication et K(I) représente les connaissances de l’intrus dans un contexte de vérification C = hM, ξ, |=, K, Lw, p.qi.
7- Trace C-bien formée : Une trace est dite C-bien formée pour un protocole p quand elle est générée par entrelacement de rôles généralisés substitués. C’est-à-dire, pour une trace bien formée ρ, il existe un rôle généralisé r ∈ RG(p) et une substitution fermée σ tels que pour toute session i ∈ Sρ, on a :
8- Trace valide : ρ est une trace valide de p si ρ est C-bien-définie et ρ est C-bien formée. On note par [[p]] toutes les traces valides générées par un protocole p.
9- Préfixe d’une trace : Soit ρ1 et ρ2deux traces. ρ2 est un préfixe de ρ1 s’il existe une trace ρ3telle
que ρ1= ρ2.ρ3
10- Taille d’une trace : La taille d’une trace ρ, notée |ρ|, est définie comme suit :
|ε| = 0 |step| = 1
|ρ.ρ0| = |ρ| + |ρ0|