Le problème d ’obtenir une clef de session sûre entre deux ordinateurs (et deux per
sonnes) est si important qu’il a mené à de nombreuses recherches. Une part des re
cherches a été dévouée au développement de protocoles tels que ceux examinés dans les paragraphes 3.1, 3.2, et 3.3. Ceci a conduit à de plus amples et plus intéressants problèmes: l’analyse formelle des protocoles d’authentification et d ’échange de clefs. On a trouvé des failles dans certains protocoles apparament sûrs des années après qu’ils furent proposés et les chercheurs voulaient des outils permettant de prouver la sécurité d ’un protocole dès le début. Bien que la plupart de ce travail puisse s’appliquer aux pro
tocoles cryptographiques en général, l’emphase en recherche concerne principalement l’authentification et l’échange de clefs.
3. E n c r y p te d K e y E x c h a n g e .
Il y a quatre approches fondamentales de l’analyse de protocoles cryptographiques [1053] :
1. Modéliser et vérifier le protocole en utilisant des languages de spécification et des outils de vérification qui ne sont pas spécifiquement dédiés à l’analyse de protocoles cryptographiques.
2. Développer des systèmes experts avec lequel un concepteur de protocoles peut inventer et tester différents scénarios.
3. Modéliser les nécéssités d’une famille de protocoles à l’aide de régies logiques sur l’anlyse de savoir et de croyance.
4. Développer une méthode formelle basée sur les propriétés de réécriture de termes algébriques dans les sytèmes cryptographiques.
Une discussion complète de ces quatres approches et des recherches qui tournent autour dépasse largement le sujet de ce livre. Voir [1055, 1357] pour une bonne introduction;
nous allons juste toucher du bout des doigts les avancées majeures dans le domaine.
La première approche traite un protocole cryptographique comme n’importe quel autre programme et s’occuppe de prouver son exactitude. Certains chercheurs présentent un protocole comme une machine à état fini [1455, 1357], d’autres utilisent des exten
sions du calcul des prédicats du premier ordre [823], et d ’autres encore analysent les protocoles à l’aide de languages de spécification [1568]. Toutefois, ce n’est pas pareil de prouver l’exactitude que de prouver la sécurité et cette approche ne permet pas de détecter de nombreux protocoles défectueux. Bien qu’elle fût largement étudiée en premier lieu, la plupart des travaux dans le domaine ont étés redirigés alors que la troisième approche gagnait en popularité.
La deuxième approche utilise des systèmes experts pour déterminer si le protocole peut atteindre un état indésirable (comme la divulgation d ’une clef par exemple). Si cette approche est plus apte à détecter les failles, elle ne garantie pas la sécurité et ne fournit pas non plus de technique pour découvrir des attaques. C ’est efficace pour déterminer si un protocole a une faille donnée mais pas pour trouver une faille inconnue dans un protocole. On trouvera des exemples d’une telle approche dans [997, 1525]; un système à base de règles développé par l’armée américaine qui s’appelle l’ « Interrogateur4 » est examiné dans [1098].
La troisième approche est de loin la plus populaire, elle fut lancée par Michael
Bu r r o w s, Martin Ab a d i et Roger Ne e d h a m. Ils ont développé un modèle de logique formelle pour l’analyse de savoir et de croyance appelé la lo g iq u e B A N [287, 288].
BAN est la logique la plus utilisée pour analyser les protocoles d’authentification. Elle repose sur l’hypothèse que l’authentification est une fonction dépendant de l’intégrité et de la fraîcheur, et elle permet de suivre la valeur de ces deux attributs au cours du protocole au moyen de règles logiques. Malgrès le développement de beaucoup de variantes et d ’extensions, la plupart des concepteurs de protocoles se réfèrent encore aux premiers travaux.
La logique B A N ne permet pas de prouver la sécurité; elle permet seulement de rai
sonner sur l’authentification. Cette logique est simple et immédiate, facile à appliquer
4. L’« I n te r r o g a to r » en anglais.
et pourtant utile pour détecter des failles. Certaines formulations de la logique B A N ressemblent à ceci:
Alice croit A . (Alice agit comme si X était vrai.)
Alice voit X . (Quelqu’un a envoyé à Alice un message contenant X . Celle-ci peut le lire et l’envoyer à nouveau — après un éventuel déchiffre
ment.)
Alice a dit X . (À un moment donné, Alice a envoyé un message conte
nant X . On ne sait pas quand il a été envoyé ou même s’il a été envoyé durant le protocole en cours. On sait seulement que Alice croyait X quand elle l’a dit.)
X est récent (ou frais). (A n’a jamais été envoyé dans un message à quelqu’instant que ce soit avant le protocole en cours.)
Et ainsi de suite. La logique B A N fournit aussi des règles pour raisonner sur des croyances à l’intérieur d’un protocole. En appliquant ces règles aux formulations lo
giques concernant le protocole, on peut prouver certaines choses ou répondre à certaines questions à propos du protocole. Par exemple, une des règles est celle de la signification d ’un message:
Si Alice croit qu’elle et Bernard partagent une clef secrète K et si Alice voit X chiffré avec K, et si Alice n’a pas chiffré X avec K , alors Alice croit que Bernard a dit X .
Une autre règle est celle de la vérification de nombre aléatoire
Si Alice croit que X n’a pu être prononcé que récemment et que Bernard a dit A , alors Alice croit que Bernard croit A .
Il y a quatre étapes dans une analyse avec B AN :
1. Décrire le protocole dans une forme idéalisée à l’aide de formulations logiques telles que les précédentes.
2. Ajouter toutes les hypothèses concernant l’état initial du protocol.
3. Insérer des formules logiques inhérentes aux formulations: des assertions à propos de l’état du système après chaque formulation.
4. Applliquer les règles logiques aux assertions et aux hypothèses pour trouver les croyances de chaque parti au cours du protocole.
Les auteur de la logique B A N « voient les protocoles idéalisés comme des spécifications plus claires et plus complètes que les descriptions traditionnelles de la littérature... » [287, 288]. D ’autres ne se laissent pas impressionner et critiquent cette étape car elle pourrait dénaturer le protocole réel [1161, 1614], Voir [225, 1563] pour une poursuite du débat. D ’autres détracteurs essayent de montrer que la logique B A N peut conduire pour certains protocoles à des caractéristiques clairement fausses [1161] — voir [289, 1513] pour une réfutation — et que la logique B A N concerne seulement la confiance et pas la sécurité [1513]. De plus amples débats se trouvent dans [1495, 707, 1011],
Malgrès ces critiques, la logique B A N est un succès. Elle a contribué à trouver des failles dans différents protocoles dont N E E D H A M -S C H R O E D E R et une première version d’un protocole C C IT T X .5 0 9 [308]. Elle a permis de montrer des redondances dans beau
coup de protocoles comme Ya h a l o m, Ne e d h a m- Sc h r o e d e r, et Ke r b e r o s. Bien des articles publiés font état de la sécurité de leurs protocoles grâce à la logique BAN [41, 1162, 80].
D’autres systèmes de logique ont étés publiés, certains sont des extensions de la logique BAN [647, 588,1562, 829], et les autres sont basés sur B A N pour palier à des faiblesses connues [1495, 1011]. La plus prisée parmi celles-là est G N Y [647] bien qu’elle présente certains défauts [41]. Des probabilités de croyance ont été ajoutées à la logique B A N avec un succès mitigé [296, 507]. D ’autres logiques formelles sont proposées dans [163, 799, 292]; dans [1518], les auteurs essayent de combiner les aspects de plusieurs logiques.
Enfin, il existe des logiques où les croyances peuvent changer avec le temps [1130, 1515].
Avec quatrième approche à l’analyse des protocoles cryptographiques, on modélise le protocole par un système algébrique, on exprime l’état de connaissance des participants en ce qui concerne le protocole, et on analyse alors s’il est possible d’ateindre certains états. Cette approche n’a pas connu autant d ’égards que les logiques formelles, mais ça ne saurait tarder. Michael Me r r i t t l’a utilisée le premier en montrant qu’un modèle algébrique permet d’analyser les protocoles cryptographiques. On trouvera d’autres approches dans [506, 1512, 1538, 1539, 1540, 1514, 1614],
L’Analyseur de Protocoles des laboratoires de recherche de la marine américaine5 est probablement l’application la plus réussie de ces techniques [1516, 824, 1054, 1517]; il a mis en évidence de nouvelles failles et d ’autre déjà connues dans quelques protocoles [1052, 1053, 1055]. L'Analyseur de Protocoles utilise des définitions d ’actions du type:
- Accepter (Bernard, Alice, A i, N ). (Bernard accepte le message A i comme prove
nant d ’Alice durant la manche N de Bernard.) - Apprendre(Estelle,A4). (Estelle apprend A4.)
- Envoyer(Alice, Bernard, Q, A i). (Alice envoie A4 à Bernard en réponse à la requête Q.)
Request(Bernard, Alice, Q, N ). (Bernard envoie Q à Alice durant la manche N de Bernard.)
A parjjr de ces actions, on peut spécifier des exigences. Par exemple:
- Si Bernard a accepté un message A4 de la part d ’Alice à un moment donné, alors Estelle n ’a appris A4 à aucun moment.
- Si Bernard a accepté un message A4 de la part d ’Alice dans la manche N de Bernard, alors Alice a envoyé A4 à Bernard en réponse à une requête survenue durant la manche N de Bernard.
Pour utiliser l’Analyseur de Protocoles, le protocole doit être spécifier avec les construc
teurs précédents. On distingue alors quatre phases dans l’analyse: la définition des règles de transition pour les participants honêtes, la description des opérations acces
sibles à tous les participants (honêtes ou malhonêtes), la description des blocs de base
5. N a vy R esea rch L a b o ra to ry (N R L ).
constituant le protocole, et la description des exigences. Le but de tout ceci est de montrer qu’un protocole donné remplit ses exigences. Les outils comme Y Analyseur de Protocoles pourrait éventuellement conduire à des protocoles dont la sécurité serait prouvée.
Alors que le gros du travail dans les méthodes formelles vise à appliquer les dites méthodes à des protocoles existants, d’autres travaux tendent à utiliser les méthodes formelles pour concevoir le protocole dès le départ. Les premiers pas dans cette direction sont dans [713]. L'Analyseur de Protocoles tente aussi d ’accomplir cela [1516, 224, 1517].
L’application de méthodes formelles aux protocoles cryptographiques reste une idée assez nouvelle et il est vraiment difficile de savoir où elle mène. Pour l’instant, le point sensible semble résider dans le processus de formalisation.
3.5 Cryptographie à clef publique à clefs multiples
Pour la cryptographie à clef publique, il y a deux clefs. Un message est chiffré avec l’une et déchiffré avec l’autre. En général, l’une des clefs est privée et l’autre est publique.
Toutefois, faisons maintenant l’hypothèse qu’Alice a une clef et Bernard l’autre. Alice peut chiffrer un message que seul Bernard pourra déchiffrer et Bernard peut chiffrer un message que seule Alice pourra lire.
Ce concept a été généralisé par Colin Bo y d [220]. Imaginez une variante de la crypto
graphie à clef publique avec trois clefs: K a , K b , K c , distribuées comme indiqué dans le tableau 3.2.
Ta b. 3 .2 - Clefs en possession de chacun des participants Participant : Clef(s) en sa possession :
Alice Ka
Bernard Kb
Christine K c
David Ka et Kb
Etienne Kb et K c
Francis Ka et K c
Alice peut chiffrer un message avec K a de manière qu’Étienne qui dispose de K b et de K c puisse le déchiffrer, de même que Bernard et Christine s’ils se mettent ensemble.
Bernard peut chiffrer un message afin que Francis puisse le lire et Christine peut chiffrer un message de façon que David puisse le lire. David peut chiffrer un message avec K a de manière qu’Etienne puisse le lire, avec K b de manière que Francis puisse le lire, ou encore avec K a et K b de manière que Christine puisse le lire. De même, Etienne peut chiffrer un message de telle manière qu’Alice, David ou Francis puissent le lire.
Les différentes possibilités sont résumées par le tableau 3 .3 et il n’y en a pas d’ autres.
Ce schéma peut être étendu à n clefs. Si un sous-ensemble de ces clefs est utilisé pour chiffrer le message, le complément de celui-ci (les clefs non utilisées pour le chiffrement)
Ta b. 3 .3 - Chiffrement à trois clefs
Chiffré avec les clefs : Doit être déchiffré avec les clefs :
Ka Kb et K c
Kb Ka et K c
K c Ka et Kb
Ka et Kb K C
Ka et K c Kb
Kb et K c Ka
est nécessaire pour déchiffrer le message.