Verification

Published on January 2017 | Categories: Documents | Downloads: 70 | Comments: 0 | Views: 625
of 4
Download PDF   Embed   Report

Comments

Content

La vérification des protocoles de sécurité
3.1. Principe de la vérification
La vérification a pour but de tester la robustesse et l’applicabilité de protocoles de
sécurité, en somme, vérifié si le protocole de sécurité satisfait aux besoins de
sécurité attendus. On distingue globalement deux méthodes de vérification : la
méthode " force brute ", et la méthode " formelle ".
1. La méthode force brute » considère les fonctions cryptographiques comme des
opérations sur un ensemble de bits .Les propriétés de sécurité sont définies en terme
de probabilité de succès d’une attaque. Un intrus, représenté par une "machine de
Turing " ayant accès à un vaste champ de connaissances, a pour but de trouver la clé
et de décrypter le message. Le protocole sera considéré comme sécurisé si l’intrus ne
parvient pas à trouver cette clé, ou s’il épuise toutes ses capacités .L’approche "force
brute" détermine tous les polynômes d’attaques probables. Cependant les preuves
sont difficiles à automatiser, ce qui rend cette méthode caduque.
2. La méthode " formelle ", contrairement à la méthode précédente, suppose que
la cryptographie est parfaite. Elle stipule que message crypté ne peut être décrypté
qu’en appliquant la clé de cryptage appropriée. L’intrus est modélisé par un agent
qui scrute le réseau, mais n’est pas capable de faire une analyse cryptographique
(appelée aussi cryptanalyse). Dans l’approche formelle, la description du protocole,
les propriétés de sécurité et les connaissances de l’intrus sont définies explicitement.
Les outils de vérification formelle testent le protocole de sécurité en présence de
l’intrus. S’il n’est pas sécurisé, ils fournissent un contre-exemple pour montrer
comment le protocole viole les niveaux de sécurité souhaités. Fournir un contreexemple est un moyen facile de montrer comment une attaque peut être menée
contre un protocole.
Dans la suite nous nous intéresserons à divers outils de vérification formelle de
protocoles de sécurité, afin de mener une étude comparative entre certains de ces
outils.

3.2. Etat de l’art des outils de vérification formelle
En matière de vérification formelle de protocoles, il existe principalement deux
classes de techniques : les techniques algorithmiques appelées aussi de "pressebouton", et les techniques dites de preuve.

3.2.1. Techniques dites “ de preuve“

 La méthode "du raisonnement logique" [PBP+] : C’est la première des
méthodes utilisées en matière de vérification automatique de protocoles. On peut
citer 3 techniques essentielles :
 La BAN : dont les auteurs sont Mike BURROWS, Martin ABADI, Roger NEEDHAM
.C’est la plus importante des techniques de raisonnement. Elle décrit les principes de
communication et les évalue grâce à des règles d’inférence. Ces raisonnements
logiques aboutissent à assertion finale qui permet de juger si un protocole est correct
ou pas.
La GNY (extension la BAN) : dont les auteurs sont Gong, Needham et Yahalom. Plus
sophistiquée et complexe, elle améliore la BAN en mettant en exergue la différence
entre le contenu d’un message et sa signification. Mais cette méthode ne s’est
appliquée qu’à l’authentification du fait du très grand nombre de règles d’inférence.
 La BGNY (extension du GNY) : de Backin, c’est une extension du GNY. Elle permet
de spécifier les propriétés du protocole à des niveaux intermédiaires (insertion de
d’opérations de hachage, algorithmes d’échange de clés…)
L’approche par preuve de théorèmes : Elle est basée sur un raisonnement
mathématique formel sur un système. Les outils développés pour cette méthode
utilisent la HOL (High Order Method) et la FOL (First Order Method ).On peut citer
quelques uns de ces outils : ACL2 theorem proover, Isabelle theorem proover…Cette

approche permet d’obtenir une preuve formelle, mais n’est pas totalement
automatisée, d’où le problème de perte de temps .

3.2.2. Techniques dites de presse-bouton
 L’exploration d’états

Dans cette approche, on recherche toutes les exécutions possibles du protocole, en
vérifiant chaque état accessible qui satisfait certaines conditions. La vérification
"non-bornée" considère une infinité de principes et une infinité de sessions. L’espace
des états généré par l’analyse d’un protocole peut être infini, on parle alors
d’explosion d’état. Dans "La vérification bornée", le nombre de principes et de
sessions est fixé. La méthode de vérification recherche alors un état particulier ou les
propriétés de sécurité sont violées et génère un contre-exemple en exploitant une
trace depuis cet état jusqu’à un état initial.
C’est sur cette approche que reposent tous les outils de vérification automatique de
protocoles. De toutes les techniques évoquées, seule la dernière sera utilisée dans le
cadre de notre projet. En effet, d’une part les techniques de preuve nécessitent une
très grande connaissance en théories mathématiques et cryptographiques afin
d’établir les démonstrations et prouver les résultats. D’autre part, les outils de
vérification automatique sont pédagogiquement adaptés à une introduction à la
vérification de protocoles.

3.2.3. Etude Comparative
Une comparaison d’outils de vérification formelle est donnée dans le tableau 2.La
comparaison faite est essentiellement basée sur 3 critères : la falsification, qui met
en exergue la capacité qu’a l’outil de fournir une réponse quand un protocole a des
failles ; la vérification bornée ou non bornée, et enfin la terminaison, qui indique que
la procédure de vérification se termine avec succès ou non. Un autre critère de
comparaison additionnel est celui de la disponibilité de l’outil (gratuit ou payant).
Tableau 2 : comparaison d’outils de vérification formelle

A la lecture du tableau, il ressort visiblement que deux outils sont les plus efficaces
en matière de vérification formelle, d’après les critères que nous avons énumérés
précédemment : AVISPA ET SCYTHER. Pour notre projet, nous avons utilisé l’outil
AVISPA pour trois raisons principales :
 disponible dans une salle de recherche au sein du groupe LEOPART à l’ENAC
 compatible avec l’outil graphique SPAN utilisé
 Syntaxe beaucoup plus intuitive et simple que celle de SCYTHER

3.3. Introduction à l’outil de vérification formelle automatique
AVISPA
AVISPA a été développé en 2004 par Basin et Al dans le cadre d’un projet européen.
C’est un outil d’analyse automatique destiné à aider à la validation de protocoles. Il
possède deux enjeux majeurs : être performant, tout en garantissant l’accessibilité
aux non-spécialistes du domaine. L’outil est utilisable sur des protocoles à petite et
moyenne échelle (tels fournis dans la librairie de Clark/Jacob), ainsi que des
protocoles de sécurité Internet à grande échelle.
Le protocole à vérifier est spécifié dans un langage de haut niveau: le HLPSL. La
spécification est réécrite dans un format intermédiaire IF grâce à un traducteur.
AVISPA utilise 4 autres outils (les back-ends) qui prennent en entrée le format IF, et
qui offrent la possibilité de faire 4 analyses différentes du même protocole. N’importe
quel langage convertible en format intermédiaire IF peut être vérifié par AVISPA.

3.3.1. Architecture logicielle

3.3.2. Back-ends AVISPA
Les back-ends intégrés à AVISPA permettent de vérifier les propriétés de sécurité,
selon les besoins. Ils prennent en entrée le format intermédiaire IF.
 OFMC (On-the-Fly Model Checker) : il est utilisé pour un protocole dans lequel
les propriétés algébriques des fonctions cryptographiques sont importantes.
 CL-AtSe : est basé sur les contraintes. Il procède à une simplification du protocole
d’origine en éliminant les états redondants par application de propriétés heuristiques.
Sa modularité permet d’intégrer facilement d’autres spécifications de fonctions
cryptographiques.
 SATMC utilise un état transitoire et recherche les éventuelles violations d’un
protocole donné. Ceci lui permet de générer une formule représentant la violation et
la transforme en attaque.
 T4SP montre la vulnérabilité d’un protocole ou la prédit en faisant une estimation
minutieuse des capacités de l’intrus.

3.3.3. Outil graphique SPAN
Le rôle de SPAN (Security Animator for AVISPA)[GGH] est d’aider à la conception des
spécifications formelles. SPAN permet d’animer les spécifications HLPSL, i.e. de
produire interactivement des MSC (Message Sequence Charts) [HT03] qui peuvent
être vus comme une trace "Alice & Bob" d’une spécification HLPSL. Dans le cadre de
droite (1) ainsi que dans la fenêtre à gauche (2), SPAN affiche les messages déjà
envoyés. Dans le cadre de gauche (3), on voit les transitions possibles(les envois de
messages) qu’on peut déclencher d’un double-clique. S’il n’y a plus de transitions,
c’est qu’on est arrivé à la fin du protocole ou qu’il y a une erreur dans la spécification
HLPSL.

Sponsor Documents

Or use your account on DocShare.tips

Hide

Forgot your password?

Or register your new account on DocShare.tips

Hide

Lost your password? Please enter your email address. You will receive a link to create a new password.

Back to log-in

Close