L’abstraction que nous allons décrire maintenant présente un point commun et une dif-férence majeure avec l’abstraction de la section précédente. Comme l’abstraction précédente, son but est de projeter l’ensemble des messages sur un ensemble fini. Elle a par contre l’avan-tage de procéder de manière beaucoup plus homogène. Comme pour l’abstraction précédente, nous allons partir de la [Σ•
P]-algèbre de la section 6.1 notée B et du morphisme surjectif asso-cié β : [CP] → B. Nous allons là encore nous baser sur cette construction pour produire une Σ•P-structure A.
[Σ•P]-algèbre [A]. B et [A] ne diffèrent que par l’interprétation des messages et des listes de messages. Nous ne décrirons donc que cette partie de A. À cet effet, posons :
V = 2ˆ BKey × BKey
AMsg = 2ˆ V \ {∅} AList[Msg] = 2ˆ AMsg
Un élément ({k1, . . . , kn}, k0) de V sera appelé une vue et noté k1⊗ . . . ⊗ kn⊸k0. Nous avons donc choisi d’interpréter un message dans A par un ensemble non vide de vues. On trouve les vues associées à un message en l’écrivant sous forme d’un arbre et en le parcourant de la racine aux feuilles : chaque fois qu’une construction de chiffrement est traversée, on garde la clé associée dans la partie gauche de la vue et, quand une feuille est atteinte, la clé qu’elle contient est placée dans la partie droite de la vue.
Exemple : Considérons le message :
les vues associées sont :
k0⊗ k1 ⊸k2
k0⊸k3 k0⊗ k4 ⊸k5 Les vues du message m traduisent le fait que :
– si on dispose de m, k0 et k1, alors on peut obtenir k2; – si on dispose de m et k0, alors on peut obtenir k3; – si on dispose de m, k0 et k4, alors on peut obtenir k5.
En revanche, l’ordre dans lequel ces clés ont été appliquées, ainsi que leur position par rapport
aux constructeurs de couples disparaissent.
Formellement, les vues associées à un message se calculent de la manière suivante (qui nous tiendra lieu de définition de β′
Msg) :
– l’ensemble des vues d’une clé k ∈ BKey considérée comme un message est : βMsg′ (k) ˆ= {⊸ k}
– si m, m′∈ BMsg, on pose :
βMsg′ (hm, m′i) ˆ= βMsg′ (m) ∪ βMsg′ (m′) – si m ∈ BMsg et k ∈ BKey, alors :
βMsg′ ({m}k) ˆ= {k ⊗ k1⊗ . . . ⊗ kn⊸k0 | k1⊗ . . . ⊗ kn⊸k0 ∈ β′Msg(m)} – le cas du constructeur de hachage, plus difficile, sera traité un peu plus tard.
Cette définition nous indique également comment interpréter les opérations sur les messages (excepté le hachage) dans A :
– le constructeur de couples est interprété par la réunion ensembliste ;
– le chiffrement par une clé k consiste à ajouter k dans la partie gauche de toutes les vues du message de départ.
Les opérations sur les listes de messages sont interprétées de manière naturelle, une fois de plus. Nous obtenons ainsi une [Σ•
P]-algèbre [A] ainsi qu’un morphisme surjectif β′ : B → [A]. On pose α ˆ= β′◦ β.
Σ•P-structure A. Cette abstraction identifie beaucoup plus d’éléments que les précédentes. Un ensemble de vues, même très simple comme {⊸ k} et même si inj(k) est vrai possède une infinité d’antécédents par α :
k, hk, ki, hk, hk, kii, . . .
de sorte que, sur les messages, inj sera toujours faux. Une conséquence de ceci est que ∈⊖
(entre messages et listes de messages) et ⊖ seront eux aussi toujours faux (en toute rigueur, il serait possible d’en donner une définition non triviale, mais peu intéressante puisque ce prédicat n’intervient pas dans les propriétés de sécurité. On peut trouver cette définition dans [BB01]). Pour ce qui est des autres prédicats de Σ•
P, nous savons déjà comment les abstraire, en utilisant le guide du chapitre précédent. Nous allons cependant donner une définition de ⊕, un peu différente de celle qui serait obtenue en appliquant la proposition 5.2.2, mais plus adaptée au formalisme des vues. Considérons donc un élément l ∈ AList[Msg] ainsi que m ∈ AMsg. On note l = {m′
1, . . . , m′k}, alors par définition de ⊕ :
On note sous forme d’ensemble de vues m = {v1, . . . , vn}. Si on pose m1 = {v1}, . . . , mn = {vn}, on a alors :
m = hm1, h. . . , mnii et d’après la définition de ⊕ :
l ⊕m ⇔ (l ⊕m1, . . . et l ⊕mn)
Par conséquent, l ⊕m est vrai si, et seulement si, chacune des vues de m peut être déduite de l’ensemble des vues des messages qui apparaissent dans l. À cet effet, définissons une relation entre ensembles de vues et vues au moyen des règles suivantes :
k1⊗ . . . ⊗ kn⊸k0∈ l l k1⊗ . . . ⊗ kn⊸k0 l k1⊗ . . . ⊗ kn⊸k0 l ⊸ k l k ⊗ k1⊗ . . . ⊗ kn⊸k0 l k ⊗ k1⊗ . . . ⊗ kn⊸k0 l ⊸ k−1 l k1⊗ . . . ⊗ kn⊸k0
Nous pouvons ensuite utiliser cette relation pour décider si l ⊕m compte tenu du fait que, si on pose :
l ˆ= [
m∈l
m les propositions suivantes sont équivalentes :
– l ⊕m ;
– quelle que soit v ∈ m, on a l v.
Revenons, pour terminer la présentation de cette abstraction au cas du constructeur de ha-chage. On peut en fait considérer que hacher un message est équivalent à le chiffrer avec une clé connue de tous les participants et sans inverse. Soit donc hk /∈ BKey et modifions la définition des vues comme suit :
V ˆ= 2BKey∪{hk}× BKey
Le constructeur de hachage sera alors interprété de la manière suivante : la vue de h(m) ∈ BMsg
est obtenue en ajoutant hk dans chaque partie gauche d’une vue de m. Comme hk n’est pas réellement une clé, on ne pourra jamais « déchiffrer » un message « chiffré » avec hk. Par contre il faut laisser la possibilité de « chiffrer » avec hk, par exemple au moyen de la règle :
l k1⊗ . . . ⊗ kn⊸k0 l hk ⊗ k1⊗ . . . ⊗ kn⊸k0
Discussion. Afin de mieux juger du pouvoir de cette abstraction, nous avons réalisé une implémentation. En effet, même si l’abstraction est correcte par construction, il est tout à fait possible qu’elle perde trop d’information pour être à même ensuite de prouver les propriétés de sécurité des protocoles considérés. Pour des raisons d’efficacité, cette implémentation présente quelques différences avec ce qui a été présenté ici. Signalons-le tout de suite : si cette abstraction retourne des résultats facilement compréhensibles, qui plus est en un temps raisonnable, elle s’avère impuissante face à un certain nombre de protocoles, en raison des approximations trop importantes qu’elle introduit. Nous allons expliquer tout ceci au moyen de quelques exemples.
Pour commencer, reprenons le protocole Andrew Secure RPC (page 67), cette fois-ci décrit formellement par les processus :
LA = (νA.n).chhA.a, {A.n}ˆ k(A.a,A.b)ii.
c(A.x).case A.x of {h{A.n}0, A.n′i}k(A.a,A.b). ch{{A.n′}0}k(A.a,A.b)i.
c(A.y).case A.y of {hA.k, 0i}k(A.a,A.b).0 LB = c(B.x).case B.x of hB.a, {B.n}ˆ k(B.a,B.b)i.
(νB.n′).ch{h{B.n}0, B.n′i}k(B.a,B.b)i. c(B.y).case B.y of {{B.n′}0}k(B.a,B.b). (νB.k).ch{hB.k, 0i}k(B.a,B.b)i.0
(remarquons que le dernier nonce, normalement envoyé par B à A, et qui apparaît dans le protocole pour des raisons de fraîcheur, a été ici remplacé par 0, pour simplifier). De ces processus, on déduit les règles de la figure 6.3.1 permettant de définir le prédicat tr⊕. Nous
(r0) tr⊕([], []) (rA1) tr⊕(l, l ′) ¬(N ∈⊖l′) tr⊕(hA, {N }k(A,B)i :: l, N :: l′) (rA2) tr⊕(l, l
′) hA, {N }k(A,B)i ∈ l l ⊕{h{N }0, N′i}k(A,B) tr⊕({{N′}0}k(A,B):: l, l′)
(rB1) tr⊕(l, l
′) l ⊕hA, {N }k(A,B)i ¬(N′∈⊖l′) tr⊕({h{N }0, N′i}k(A,B):: l, N′ :: l′) (rB2) tr⊕(l, l
′) l ⊕ hA, {N }k(A,B)i {h{N }0, N′i}k(A,B)∈⊕l l ⊕{{N′}0}k(A,B) ¬(K∈⊖l′) tr⊕({hK, 0i}k(A,B):: l, K :: l′)
Fig. 6.3.1 –Première définition du prédicat tr⊕ pour le protocole Andrew Secure RPC noterons ces règles de déduction respectivement r0, rA1, rA2, rB1 et rB2. L’étape préliminaire de projection est quelque peu différente de ce qui a été décrit auparavant. Ici elle consiste à :
– projeter les éléments de sorte Cst différents de i sur une constante a ;
– conserver trois éléments de sorte Nonce, k, n et n′ et projeter les autres sur 0.
Nous allons maintenant nous contenter des exécutions du protocole dans lesquelles n est créé au moyen de la règle rA1, n′ au moyen de la règle rB1 et k au moyen de la règle rB2. Ces trois constantes n, n′ et k étant arbitraires, ceci ne pose pas de problème. Dernière modification : nous allons remplacer les conditions de la forme m ∈⊕ l apparaissant dans les règles rA1, rA2, rB1, rB2 par l ⊕ m (ce qui est correct, puisque m ∈⊕l ⇒ l ⊕ m). Muni de ces hypothèses, nous sommes ramenés à considérer le prédicat tr⊕défini au moyen des règles de la figure 6.3.2. Nous avons séparé chacune des règles traduisant une création de nonce (par exemple rA1) en deux règles distinctes : la première (r′
A1 ici) correspond au cas où le nonce créé est préservé par l’abstraction, et la seconde (r′′
A1) pour le cas où c’est un autre nonce qui est créé. En ce qui concerne précisément ces deux règles, r′
A1 et r′′
(r0) tr⊕([], []) (r′A1) tr⊕(l, l ′) n /∈ l′ tr⊕(ha, {n}k(a,B)i :: l, n :: l′) tr⊕(l, l′) tr⊕(ha, {0}k(a,B)i :: l, 0 :: l′) (r ′′ A1) (rA2) tr⊕(l, l
′) l ⊕ha, {N }k(a,B)i l ⊕{h{N }0, N′i}k(a,B) tr⊕({{N′}0}k(a,B) :: l, l′) (r′B1) tr⊕(l, l ′) l ⊕ hA, {N }k(A,a)i n′ ∈ l/ ′ tr⊕({h{N }0, n′i}k(A,a):: l, n′ :: l′) tr⊕(l, l′) l ⊕hA, {N }k(A,a)i tr⊕({h{N }0, 0i}k(A,a):: l, 0 :: l′) (r ′′ B1) (rB2′ ) tr⊕(l, l
′) l ⊕hA, {N }k(A,a)i l ⊕{h{N }0, N′i}k(A,a) l ⊕{{N′}0}k(A,a) k /∈ l′
tr⊕({hk, 0i}k(A,a):: l, k :: l′) (r′′B2) tr⊕(l, l
′) l ⊕hA, {N }k(A,a)i l ⊕{h{N }0, N′i}k(A,a) l ⊕{{N′}0}k(A,a) tr⊕({h0, 0i}k(A,a):: l, 0 :: l′)
Fig. 6.3.2 – Deuxième définition du prédicat tr⊕ pour le protocole Andrew Secure RPC correct (mais on y perd en précision) de les appliquer une fois pour toutes, au tout début de l’exécution. Ceci revient à considérer simplement l’ensemble de règles de la figure 6.3.3. Il
(r0,A1)
tr⊕(ha, {n}k(a,a)i :: ha, {0}k(a,a)i :: ha, {n}k(a,i)i :: ha, {0}k(a,i)i :: [], n :: 0 :: []) (rA2) tr⊕(l, l
′) l ⊕ha, {N }k(a,B)i l ⊕{h{N }0, N′i}k(a,B) tr⊕({{N′}0}k(a,B) :: l, l′) (r′B1) tr⊕(l, l ′) l ⊕ hA, {N }k(A,a)i n′ ∈ l/ ′ tr⊕({h{N }0, n′i}k(A,a):: l, n′ :: l′) tr⊕(l, l′) l ⊕hA, {N }k(A,a)i tr⊕({h{N }0, 0i}k(A,a):: l, 0 :: l′) (r ′′ B1) (rB2′ ) tr⊕(l, l
′) l ⊕hA, {N }k(A,a)i l ⊕{h{N }0, N′i}k(A,a) l ⊕{{N′}0}k(A,a) k /∈ l′ tr⊕({hk, 0i}k(A,a):: l, k :: l′)
(r′′B2) tr⊕(l, l
′) l ⊕hA, {N }k(A,a)i l ⊕{h{N }0, N′i}k(A,a) l ⊕{{N′}0}k(A,a) tr⊕({h0, 0i}k(A,a):: l, 0 :: l′)
Fig. 6.3.3 –Dernière définition du prédicat tr⊕ pour le protocole Andrew Secure RPC ne nous reste donc plus qu’à calculer les exécutions abstraites engendrées par cet ensemble {r0,A1, rA2, rB1′ , rB1′′ , rB2′ , rB2′′ }. Parmi les règles de cet ensemble, r0,A1 peut s’appliquer une seule fois, au tout début. De même, r′
B1et r′
B2ne peuvent s’appliquer qu’une seule fois. Nous procéderons donc de la manière suivante :
– le point de départ est le couple p ˆ= (l, l′) engendré par la règle r0,A1; – on calcule p′, clôture de p par les règles rA2, r′′B1, r′′B2;
– on calcule P1 (respectivement P2), ensemble des exécutions obtenues à partir de p′ par une application de la règle r′
B1 (respectivement r′ B2) ; – on calcule P′
1 (respectivement P′
moyen des règles rA2, rB1′′ , rB2′′ ; – on calcule P′′
1 (respectivement P′′
2), ensemble des exécutions obtenues à partir des élé-ments de P′
1 et P′
2 par une application de la règle r′
B2 (respectivement r′ B1) ; – on calcule P en prenant la clôture de P′′
1 et P′′2 par les règles rA2, r′′B1, rB2′′ .
P représente alors les exécutions abstraites du protocole (plus exactement, chaque exécution abstraite du protocole correspond à un sous-ensemble d’un élément de P ). Le résultat retourné par notre implémentation se trouve à la figure 6.3.4 (nous avons omis les listes de nonces utilisés, qui sont utiles au cours de la construction des exécutions, mais ne présentent plus d’intérêt par la suite). Dans ce cas précis, la version abstraite de notre propriété de secret
{k(a, a) ⊸ n′, k(a, a) ⊸ k, ⊸ a, ⊸ i, ⊸ 0, ⊸ n, ⊸ k(i, a), k(a, a) ⊸ n, k(a, a) ⊸ 0} {⊸ n′, k(a, a) ⊸ k, ⊸ a, ⊸ i, ⊸ 0, ⊸ n, ⊸ k(i, a), k(a, a) ⊸ n, k(a, a) ⊸ 0}
{k(a, a) ⊸ n′, ⊸ k, ⊸ a, ⊸ i, ⊸ 0, ⊸ n, ⊸ k(i, a), k(a, a) ⊸ n, k(a, a) ⊸ 0} {⊸ n′, ⊸ k, ⊸ a, ⊸ i, ⊸ 0, ⊸ n, ⊸ k(i, a), k(a, a) ⊸ n, k(a, a) ⊸ 0}
Fig. 6.3.4 –Résultat retourné pour le protocole Andrew Secure RPC pour A, est :
secretA = ∀l, lˆ ′. tr⊕(l, l′) ∧ l ⊕ha, {n}k(a,a)i ∧
l ⊕ {h{n}0, n′i}k(a,a) ∧ l ⊕{hk, 0i}k(a,a) ⇒ ¬(l ⊕ k) Parmi les exécutions retournées par notre implémentation, celles vérifiant les prémisses de la propriété de secret sont celles qui contiennent k(a, a) ⊸ n, k(a, a) ⊸ n′ et k(a, a) ⊸ k. Il ne reste donc que :
{k(a, a) ⊸ n′, k(a, a) ⊸ k, ⊸ a, ⊸ i, ⊸ 0, ⊸ n, ⊸ k(i, a), k(a, a) ⊸ n, k(a, a) ⊸ 0} exécution dans laquelle k est secret.
Sur le protocole de Denning et Sacco (page 31), nous obtenons le résultat de la figure 6.3.5. Parmi ces exécutions, celles qui satisfont les prémisses de la propriété de secret sont celles qui
{k(a, s) ⊸ t, k(a, s) ⊸ k, k(a, s) ⊸ i, k(a, s) ⊸ a, k(a, s) ⊸ 0,
⊸a, ⊸ s, ⊸ i, ⊸ 0, ⊸ k(i, a), ⊸ k(i, s)} {⊸ t, k(a, s) ⊸ k, k(a, s) ⊸ i, k(a, s) ⊸ a, k(a, s) ⊸ 0,
⊸a, ⊸ s, ⊸ i, ⊸ 0, ⊸ k(i, a), ⊸ k(i, s)} {k(a, s) ⊸ t, ⊸ k, k(a, s) ⊸ i, k(a, s) ⊸ a, k(a, s) ⊸ 0,
⊸a, ⊸ s, ⊸ i, ⊸ 0, ⊸ k(i, a), ⊸ k(i, s)} {⊸ t, ⊸ k, k(a, s) ⊸ i, k(a, s) ⊸ a, k(a, s) ⊸ 0, ⊸ a, ⊸ s, ⊸ i, ⊸ 0, ⊸ k(i, a), ⊸ k(i, s)}
contiennent k(a, s) ⊸ k et k(a, s) ⊸ t, il ne reste donc que : {k(a, s) ⊸ t, k(a, s) ⊸ k, k(a, s) ⊸ i, k(a, s) ⊸ a, k(a, s) ⊸ 0,
⊸a, ⊸ s, ⊸ i, ⊸ 0, ⊸ k(i, a), ⊸ k(i, s)} Dans cette exécution, k est secret.
Explorons maintenant les limites de cette abstraction. Le protocole suivant est extrait de [BAN89] et est attribué par les auteurs à Yahalom :
Yahalom :
1. A → B : hA, NAi
2. B → S : hB, {hA, NA, NBi}KBSi
3. S → A : h{hB, KAB, NA, NBi}KAS, {hA, KABi}KBSi 4. A → B : h{hA, KABi}KBS, {NB}KABi
Sur ce protocole, notre implémentation nous fournit le résultat qui se trouve à la figure 6.3.6. Comme on peut le constater k n’est pas secret dans cette exécution. Regardons où
{k(a, s) ⊸ n′, k(a, s) ⊸ k, ⊸ k, k(a, s) ⊸ a, k(a, s) ⊸ s,
k(a, s) ⊸ i, k(a, s) ⊸ k(i, a), k(a, s) ⊸ k(i, s), k(a, s) ⊸ n, k(a, s) ⊸ 0,
⊸a, ⊸ s, ⊸ i, ⊸ k(i, a), ⊸ k(i, s), ⊸ n, ⊸ 0}
Fig. 6.3.6 – Résultat retourné pour le protocole de Yahalom
l’abstraction a pu perdre de l’information. À l’étape 3 du protocole, a reçoit le message h{ha, hk, hn, n′iii}k(a,s), xi et renvoie hx, {n′}ki (rappelons que, dans notre abstraction, il n’y a plus qu’un seul participant a). Comme on a :
α(h{ha, hk, hn, n′iii}k(a,s), xi) = α(h{ha, hn, hn′, kiii}k(a,s), xi)
a doit renvoyer, dans les exécutions abstraites du protocole, le message {k}n. Or n est connu de l’intrus, et par conséquent k n’est plus secret (dans notre abstraction).