Outils de démonstration automatique

Plusieurs outils de démonstration automatique ont été mis au point ces dernières années. Ils se sont développés un peu partout en France, en Europe et dans le monde. Citons tout particulièrement les outils de preuve automatique CASPER [Low98], CASPEL [Mill] et EVA.

Mais ces outils ne vérifient actuellement qu’une seule propriété de sécurité : le secret. Autrement dit, tous les modèles de protocoles cryptographiques utilisés par les démonstrateurs, font l’hypothèse du chiffrement parfait [Dela03]. Sans avoir la clé de déchiffrement, on ne peut obtenir aucune information sur un texte chiffré.

EVA propose trois outils CPV [Goub00], HERMES [Bozg03] et SECURIFY [Securify- TR13] de démonstration automatique. Dans ce paragraphe, nous ne présentons que SECURIFY et HEMES.

7.4.3.1 Securify

Securify [Securify-TR7] [Securify-TR13] permet une vérification automatique de la propriété de secret en se basant sur le modèle de Millen-Rueß présenté brièvement ci-dessous. La procédure de preuves est constituée de trois conditions suffisantes et une procédure de recherche en arrière.

« Si aucun de nos lemmes ‘de base’ ne permet de conclure au secret, on recherche alors toutes les instances des règles qui ont pu engendrer une partie des prémisses de la règle déjà considérée, et ainsi de suite. »

Cet outil a été entièrement programmé en Ocaml puis il a été intégré au langage LEVA. Le comportement de l’outil est sous trois formes :

o L’outil donne une réponse « oui » lorsque la propriété du secret à protéger est garantie dans le modèle Millen-Rueß.

o L’outil donne une réponse « echec » si la méthode de preuve échoue, on ne peut pas

conclure si le protocole est sûr ou nom. Cependant, l’arbre d’échec de la preuve peut assez souvent permettre de construire une attaque et montrer ainsi que le protocole n’est pas correct.

Securify prend en entrée un fichier .cpl, dérivé par le parseur LEVA d’un fichier .eva dans lequel est décrit le protocole ainsi que les propriétés qu’il doit vérifier. Il permet également à l’utilisateur d’obtenir les graphes successifs des preuves (ou de l’echec des preuves) qui ont permis d’obtenir la réponse oui ou « don’t know ». Ces graphes permettent de comprendre pourquoi la preuve du secret a réussit ou a échoué.

7.4.3.2 Hermes

Hermes [Bozg03] permet de prouver la propriété de secret de manière complètement automatique, pour un nombre non borné de sessions et de participants. Pour vérifier le protocole (figure 7-1), cet outil commence à extraire la propriété du secret et la spécification du protocole (module 1). Ensuite, il calcule une abstraction de la propriété et du protocole (module 2) puis complète l’ensemble des secrets en générant des contraintes qui définissent les conditions dans lesquelles le protocole peut être utilisé sans risque d’invalider les propriétés de secret (module 3). Un calcul symbolique des messages accessibles est ensuite effectué.

Figure 7-1. L’architecture de l’outil Hermes et la connexion au traducteur EVATRANS

L’outil produit également des traces qui justifient l’ajout de chaque nouveau secret et de chaque nouvelle contrainte. Ces traces correspondent à des tentatives d’attaques.

Le principe de vérification implanté dans HERMES est décrit en détail dans [Bozg02], nous en donnons ici une présentation succincte nécessaire à l’interprétation des résultats. Les contraintes calculées par le module 3 d’Hermes s’interprètent comme des limites imposées sur les connaissances de l’intrus au moment de débuter une session du protocole. La section 8.2 présente un exemple de contraintes. Ces contraintes sont établies de manière à garantir que les messages échangés par des participants honnêtes au cours d’une session du protocole jouée en parallèle avec un nombre arbitraire d’autres sessions, ne permettent pas à l’intrus de découvrir les secrets échangés par les participants honnêtes.

Protocole Informel Traduction Protocole Millen-Rueß Algorithme

Oui Échec

La méthode de calcul des contraintes du module 3 s’applique aussi bien à un nombre arbitraire de sessions parallèles (entrée a) qu’à un nombre fini de sessions parallèles (entrée b). Dans le premier cas, le module 2 d’Hermes construit une abstraction qui satisfait la propriété suivante. Si la propriété abstraite est vérifiée pour le protocole abstrait alors la propriété de secret est satisfaite par le protocole concret pour un nombre arbitraire de sessions. Ces dernières sont exécutées en parallèle par un nombre arbitraire de participants générant un nombre arbitraire de données fraîches (nonces et clés).

7.4.3.3 Principe de Hermes

HERMEScalcule des conditions suffisantes pour garantir que les messages échangés au cours d’une session du protocole ne peuvent être exploités pour déduire des secrets. L’outil est basé sur la notion de messages capables de garder un secret, appelés messages protecteurs. Il s’agit des messages de la forme {X}K, c’est-à-dire cryptés au moyen d’une clé dont l’inverse n’est pas connu de l’Intrus. Les messages protecteurs se déduisent des clés déclarées secrètes dans les hypothèses du protocole.

Étant donné un protocole, un ensemble S de secrets et un ensemble d’hypothèses sur les clés

secrètes, HERMEScalcule, d’une part, un ensemble de messages qui protègent les secrets

échangés au cours du protocole ; et d’autre part, il ajoute aux secrets les messages qui permettent de construire une attaque. Il s’agit en particulier des messages dans lesquels les secrets ne sont pas protégés. À l’issue du calcul dont la terminaison est assurée par un

opérateur de convergence forcée (widening), HERMESretourne un ensemble de secrets S’ qui

contient les secrets de départ et un ensemble de messages protecteurs H’. Les résultats H’ et S’ définissent les conditions dans lesquelles le protocole peut être utilisé sans risque. La propriété de secret est garantie si, dans les messages initialement connus de l’Intrus, les secrets S’ sont protégés par les messages H’.