Rapport de projet : Vérification formelle d'un protocole de ...

mellowfetaSecurity

Jun 19, 2012 (1 year and 10 months ago)

405 views

Rapport de projet

:

Nasser Fangayoumani Debras







1
/
37



















IENAC09L



Rapport de projet

:

Vérification formelle d’un protocole de

sécurité
à l’aide d’un outil

d’analyse automatique des
failles de sécurité



P
ar Hamdi NASSER, Michel F
ANGAYOUMANI
et Simon DEBRAS

Encadré par Nicolas
LARRIEU
, Slim

B
EN MAHMOUD
Rapport de projet

:

Nasser Fangayoumani Debras







2
/
37

Tables des matières


1.

Introduction

................................
................................
................................
.......

4

2.

Problématique

................................
................................
................................
...

5

2.1.

Attaques sur les protocoles cryptographiques

................................
..........

5

2.1.1.

Le chiffrement des messages

................................
................................

5

2.1.2.

Terminologie

................................
................................
.........................

5

2.1.3.

Protocoles cryptographiques et attaques

................................
............

6

2.2.

Exemple illustratif

: Attaque de Lowe sur NSPK
................................
.........

7

2.3.

Nécessité de vérification des protocoles de sécurité

................................
.

8

3.

La vérification des protocoles de sécurité

................................
.........................

8

3.1.

Principe de la vérification

................................
................................
..........

8

3.2.

Etat de l’art des outils de vérification formelle

................................
..........

9

3.2.1.

Techniques dit
es “

de preuve“

................................
.............................

9

3.2.2.

Techniques dites de presse
-
bouton

................................
....................

10

3.2.3.

Etude Comparative

................................
................................
.............

10

3.3.

Introduction à l’outil de vérification formelle automatique AVISPA

......

12

3.3.1.

Architecture logicielle

................................
................................
.........

12

3.3.2.

Back
-
ends AVISPA

................................
................................
...............

13

3.3.3.

Outil graphique SPAN

................................
................................
.........

13

3.3.4.

Syntaxes formelles HLPSL et CAS+

................................
......................

14

4.

Cas d’application

: présentation informelle du protocole SNSSP

....................

17

4.1.

Notions basiques en sécurité utilisées

................................
.....................

17

4.1.1.

Cryptographie symétrique

................................
................................
..

17

4.1.2.

Cryptographie asymétrique

................................
................................

18

4.1.3.

Certificats et a
utorités de certification

................................
...............

19

4.1.4.

Fonctions de hachage

................................
................................
.........

20

4.2.

Etude du protocole SNSSP

................................
................................
.......

21

4.3.

Version à base de clé de session

................................
..............................

23

4.4.

Version à base de certificat

................................
................................
.....

24

5.

Vérification form
elle du protocole SNSSP

................................
.......................

25

5.1.

Hypothèses sur les capacités d’un intrus

................................
.................

25

5.1.1.

Introduction au modèle de l’intrus
Dolev
-
Yao
................................
....

25

5.2.

Spécification formelle du protocole SNSSP en langage CAS+ et codes HLPSL
générés
………………………………………………………………………………………………………………………
26

5.2.1.

Version à base de certificat

................................
................................
.

26

Rapport de projet

:

Nasser Fangayoumani Debras







3
/
37

5.2.2.

Version à base de clé de session

................................
.........................

27

5.3.

Résultats et discussion

................................
................................
.............

29

5.4.

Scénarios d’attaques complémentaires

................................
...................

32

5.4.1.

Besoin

................................
................................
................................
..

32

5.4.2.

U
tilisation de l’environnement de simulation d’attaque dans AVISPA
32

6.

Conclusion et perspectives

................................
................................
..............

35


Rapport de projet

:

Nasser Fangayoumani Debras







4
/
37

1.

Introduction

Avec l’évolution des nouvelles technologie
s, et l’expansion croissante des
transmission
s

numériques,

il
devient nécessaire de sécuriser

les réseaux de transmissions de
données. C’est pourquoi des moyens cryptographiques sont mis en
œuvre
afin de
garantir
des principes essentiels tels que l’authent
icité du message, l’intégrité ou encore le secret.
Avec le développem
ent des moyens de paiement par I
nternet, il devient alors nécessaire de
garantir la sécurité des données personnelles

!

On voit donc se créer de nombreux protocoles cryptographiques perm
ettant de
sécuriser les données envoyées. Cependant, la difficulté de la conception de ces protocoles
tient au fait que les messages échangés peuvent être écoutés, interceptés et modifiés par un
tiers. Ainsi des chaînes télévision tels que
"

canal
+

"

ou e
ncore
"

canal satellite

"

sont
souvent piraté
e
s. De nouvelles failles apparaissent


continuellement sur des protocoles qui
ont pourtant fait leurs preuves et sont utilisés quotidiennement. C’est ainsi, qu’on a trouvé
une faille
,

aujourd’hui très connu
e
, da
ns le protocole
de
Needham Shroder
NSPK

[
NSPK]
,

appelée «

man in the middle

» que nous ne détaillerons
plus tard

dans le rapport
.

Apparaît alors le besoin de
vérifier la
robustesse

de

ces
protocoles avant de les
mettre en service. C’est pourquoi depuis u
ne dizaine d’année les logiciels de vérification
formelle des protocoles cryptographiques se développent à une grande vitesse. Des outils de
vérification formelle tels que AVISPA

[
HS
]

(Automated Validation of Internet Security
Protocols and Applications)

o
u e
ncore Hermes

ont alors vu le jour et utilisent des langages
de programmation
plus ou moins complexe comme
HLPSL

(High
-
Level

Protocol Specification
Langage)

[CCC+]
.

Le sujet de notre projet
est

la vérification formelle d’un protocole de sécurité SNSSP
(S
ecure Negociation of Supported Security Protocol)

[BMLPV
]
,

défini dans le cadre d’un
projet annexe dans lequel le laboratoire LEOPART est impliqué,
à l’aide de l’outil d’analyse
automatique des failles de sécurité AVISPA. Pour simplifier l’utilisation d’AV
ISPA, le logiciel
SPAN

[
SG
]

nous fournissait à la fois une interface graphique et la possibilité d’utiliser un
langage plu
s instinctif et simpliste que HLSPS
L

qui est

CAS
+

[
CAS]
.

Nous allons donc dans un premier temps poser la problématique du sujet (2),
qui
permettra de justifier la nécessité d’utiliser la vérification des protocoles de

(3)
. Nous
présenterons ensuite le protocole SNSSP et les choix que nous avons fait pour tester ce
protocole (5) pour enfin
vérifier

la solidité
du protocole

avec l’aide
des
outils cités
précédemment (6).

Rapport de projet

:

Nasser Fangayoumani Debras







5
/
37

2.

Problématique

2.1.

Attaques sur les protocoles cryptographiques

2.1.1.

Le chiffrement des messages

Le chiffrement des messages est au centre

de la cryptographie. Le principe du
chiffrement est de partir d’un
message initial, de lui
appliquer

une ou plusieu
rs
"

tra
nsformation

"

pour ensuite donner

ce que l’on appelle le message chiffré.
On parle alors
de
clé

de chiffrement.
U
tilisé depuis
l’antiquité
,

le chiffrement

des messages permet de
transférer une information de manière secrète
. Ainsi,
le premier chiffrement connu

est le
chiffre de César (en référence à Jules César),

qui utilise

un si
mple chiffrement par décalage

sur l’alphabet

(
par exemple

:
A devient B, B devient C Etc.).
Le déchiffrement des messages
corr
espond à l’opération
inverse

: à

partir du message chiffré, retrouvé le message d’origine.

Deux types de chiffrement sont à différencier, le chiffrement symétrique et
asymétrique. Ils seront détaillés plus tard dans le rapport.

2.1.2.

Terminologie

Pour comprendre
les protocoles et l
es attaques sur les protocoles

cryptographiques,
il est d’abord nécessaire de comprendre la terminologie et les notations

utilisées
.
Pour
simplifie
r
, les notations les plus utilisées sont celles du type Alice
(A)
-
Bob
(B)

(on se référera à
ce tabl
eau pour la

suite
du rapport
)
:

Soient

:

Tableau 1

: Terminologie cryptographique

Notation

Signification

m, m1 ou m2

message

K

clé

A ou B


Agent

{m1, m2}

concaténation de m1 et m2

{m}K

message m crypté avec la
clé

K

KA

clé

publique

de A

KA'

clé

privée de A

KAB

clé

de session entre A et B

A
-
>B : m

envoi par A du message m à B

I(A)
-
>B : m

envoi de m par I se faisant passer pour A auprès de B


La
clé

publi
que

K
A

d’un agent A est par
défaut

disponible pour tous les agents du
réseau alors que la
clé

privée

K
A
’ n’est connue que de l’agent lui
-
même. Quant à la
clé

de
session K
AB
entre deux agents A et B, elle n’est supposée connue que par A et B.

On peut par exemple donner deux grands princip
es simples en cryptographie
asymétrique

:

Rapport de projet

:

Nasser Fangayoumani Debras







6
/
37



La signature
des messa
ges
permettant de garantir l’authentification de
l’expéditeur

(ex

: A
-
> B

: {m}K
A

). En effet, étant
donné que A est le seul à connaî
tre la
clé

K
A
’, il est le seul à pouvoir générer un tel message qui pourra être lu par B en utilisant la
clé

publique K
A.

Le chiffrement du message avec une
clé

publique permettant de garantir le secret du
message (ex

: B
-
>A

: {m}K
A

). Ainsi seul A pourra lire le message m en utilisant sa
clé

privée
K
A
’.
1

Ces notations permettent alors de décrire à la fois les protocoles et

les attaques de
manière plus simple et intuitive
.


2.1.3.

Protocoles cryptographiques et attaques

Un protocole cryptographique est un ensemble de
messages échangés

sur le réseau
afin de réaliser une certaine fonctionnalité (cryptographique). Dans la typologie hab
ituelle,
chaque programme correspond à un rôle du protocole. Les agents, c’est
-
à
-
dire les machines
ou les personnes susceptibles de mettre en œuvre le protocole peuvent jouer plusieurs rôles
simultanément. Dans la plupart des protocoles, les processus sont

groupés naturellement en
sessions : chaque session correspond à une instance de la fonctionnalité désirée du
protocole.

Contrairement à la pensée publique, les attaques sur les protocoles cryptographiques
ne
sont pas dues principalement à
des outils d’ana
lyses pour déchiffrer les messages


chiffrés

(utilisation de la cryptanalyse)

mais sur des principes beaucoup plus simple tel que
l’interception de messages ou encore le renvoi d’un message intercepté, à un agent
différent. L’intrus aura alors les capacité
s d’un intrus du type Dolev
-
Yao

(expliqué plus loin).


Ainsi, les attaques sur les protocoles cryptographiques sont uniquement dues aux
déficiences du protocole face à des attaques de logique. Des protocoles qu’on l’on pensait
entièrement sécurisés sont pa
rfois mis à mal par des attaques
de logique
des fois très
simple
s
.
Nous allons par exemple illustrer le cas du protocole de Needham
-
Shroeder (NSPK)
attaqué pa
r la désormais célèbre attaque "

man in the middle

"

décrit en 1995 par Gavin
Lowe
.





1

Pour plus de précisions sur la cryptographie asymétrique et la cryptographie symétrique se
réfé
rer aux parties 4.1.1 et 4.1.2.


Rapport de projet

:

Nasser Fangayoumani Debras







7
/
37


2.2.

Exemple illu
stratif

: Attaque de Low
e

sur NSPK

L’objectif du protocole NSPK est une identification mutuelle de deux agents A et B
communiquant sur un même réseau. Il existe deux versions de ce protocole, l’une utilisant
des
clé
s de session et l’autre à l’aide de
clé
s
publiques. Nous nous intére
ssons ici qu’au cas
asymétrique

à bas e de
clé
s privées. Décrivons tout d’abord la syntaxe du protocole

(en
supposant que A connait déjà la
clé

public de B et B celle de A):

A envoie à B un Nonce A (très grand nombre

généré aléa
toirement
)et son identifiant A
chiffré avec la
clé

public de B

:

1 : A
-
>B

: {N
A
,A}
K
B

Après avoir
déchiffré

avec sa
clé

privée, B répond à A en lui renvoyant N
A

et N
B
chiffré

avec
K
A

:

2

:

B
-
>A

: {N
A
,N
B
}
K
A


Après avoir
déchiffré

avec la

clé

privée K
A


,

A a
ccuse réception de N
B

et prouve donc à B
qu’il peut le déchiffrer

:

3

: A
-
>B

: {N
B
}

K
B

A l’aide des Nonces N
A

et N
B
les deux agents ont donc réussi à s’authentifier l’un à
l’autre. D’apparence ce protocole semble entièrement sûr
,

cependant nous allons voi
r que
l’attaque
"

man in the middle

"
est possible
. Elle consiste à introduire ce que l’on peut
appeler un
intrus

qui va tenter de se faire passer pour un autre agent auprès d’une entité (ici
I se fait passer pour A). Voici l’attaque en question, nous verr
ons ensuite comment
réagissent les deux entités en question

:


Dans un premier tem
ps, I persuade A

d’initier une session avec lui.

A envoi à I un Nonce N
A
et son identifiant A chiffré avec la
clé

publique de I K
I

:

1

: A
-
>I

: {N
A
,A}K
I

Au lieu de répondr
e à A, I envoie à B
, le même Nonce N
A

avec l’identifiant de A mais cette
fois ci chiffré avec la
clé

publique de B

:

2

: I(A)
-
>B

: {N
A
,A}K
B

Voyant cela B déchiffre le message, et renvoie à I (qu’il croit être A)

les deux Nonces
chiffrés avec K
A
, I ne pou
rra donc pas déchiffrer le message (puisqu’il ne dispose pas de
K
A
’)

3

: B
-
>I(A)

: {N
A
,N
B
}K
A


Rapport de projet

:

Nasser Fangayoumani Debras







8
/
37

I rejoue alors le message à A

:

4

: I
-
>A

: {N
A
,N
B
}K
A

A confond donc NB avec NI et s’est donc authentifié avec I, e
t

renvoi
e

donc N
B
chiffré avec
K
I

5

: A
-
>I

: {N
B
}K
I


I peut donc déchiffrer N
B
, et
renvoyer N
B

chiffré avec K
B

:

6

: I(A)
-
>B

: {N
B
}K
B

Au final, A s’est bien authentifié avec l’agent qu’il souhaitait c'est
-
à
-
dire I, sans se
rendre compte que N
B

a été généré par l’agent B. Et B pense communiquer avec A
alors qu’il
communique avec I. Ce protocole n’est donc pas sûr. Il a pourtant été utilisé pendant de
nombreuses années avant que quelqu’un parvienne à trouver cette faille

!


2.3.

Nécessité de vérification des protocoles de sécurité

Comme vu précédemment, les

failles dans les protocoles
cryptographiques exploiten
t
essentiellement des erreurs

logiques
. C’est pourquoi depuis le années 90 des outils de
vérifications
automatiques comm
e AVISPA ou Hermes ont vu le jour pour vérifier la
robustesse

des protocoles de s
écurité.


3.

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écuri

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ésen
té 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é c
omme sécurisé si l’intrus ne p
arvient
pas à trouver cette clé
, ou s’il épuise tou
tes 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.

Rapport de projet

:

Nasser Fangayoumani Debras







9
/
37

2.

L
a 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’es
t pas
sécurisé
, ils fournissent un contre
-
exemple pour montrer comment le protocole viole les
niveaux de sécurité souhaités. Fournir un contre
-
exemple es
t un moyen facile de
montrer
comment une attaque peut être me
née

contre un protocole.


Dans la suite nous nous intéresserons à divers outils de vérification formelle
de pr
otocoles de sécurité, afin

de mener une étude comparative entre

certains de ces outil
s.


3.2.

Etat de l
’art des outils de vérification

formelle

En matière de
véri
fication

formelle de protocoles, il existe
principalement

de
ux

classes d
e techniques

: les techniques

algorithmique
s appelées aussi de "
presse
-
bouton
"
, et
les techniques dites de preu
ve.

3.2.1.

Techniques dites



de preuve




La méthode "du raisonnement logique"

[PBP+]

: C’est la première des mét
hodes
utilisées en matière de vé
rification automatique de protocoles. On peut citer 3
techniques essentielles

:



La
BAN
: dont les auteurs sont Mike

B
URROWS, Martin
A
BADI
, Roger
N
EEDHAM

.C’est la
plus importante des techniques de raisonnement. Elle décrit les pri
ncipes de
communication et les é
value grâce à des règles d’inférence. Ces raisonnements logiques
aboutissent à assertion finale qui permet d
e juger si un protocole est correct ou pas.



La
GNY

(extension la BAN
)

: dont les auteurs sont
G
ong,
N
eedham et
Y
ahalom. 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 significatio
n. 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
B
ackin, c’est une extension du
GNY
. Elle permet de
spécifier les
propriétés

du protocole à des niveaux int
ermédiaires (insertion de
d’opérations de hachage, algorithmes d’échange de clés…)

Rapport de projet

:

Nasser Fangayoumani Debras







10
/
37



L’approche par preuve de théorèmes

: Elle est basée s
ur un raisonnement
mathématique

formel sur un système. Les outils développés pour c
ette méthode
utilisent la HOL (Hig
h Order M
ethod) et la FOL

(First Order M
ethod ).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 pert
e 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 certaine
s conditions. La vérification "non
-
bornée"

cons
idère une infinité d
e principes et une infinité de s
essions. L’espace des états
généré par l’analyse d’un protocole peut être infini, on parle a
lors d’explosion d’état. Dans
"La vérification bornée"
, le nombre de principes et de sessions est fixé. La métho
de 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érifi
cation 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 cryptogr
aphiques afin d’établir les
démonstrations et prouver les résultats. D’autre part, les outi
ls 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éri
fica
tion formelle est donnée dans le

table
au 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).

Rapport de projet

:

Nasser Fangayoumani Debras







11
/
37




Table
au 2

:
comparaison d’outils

de
vérification

formelle

[PBP+]

Outil

gratuit

Falsification

Borné

Non
borné

terminaison

FDR/CASPER

Oui

oui

oui

non

oui

AVISPA

oui

oui

oui

oui

oui

HERMES

oui

oui

non

oui

oui

INTERROGATOR

non

oui

oui

non

oui

Analyseur de
protocole NRL

non

non

non

oui

oui

BRUTUS

non

oui

oui

non

oui

MUR
φ

oui

oui

oui

non

oui

偒佖P剉F

併i

oui

non

oui

併椠*

䅔H䕎A

(bo牮é
)

non

oui

oui

non

oui

䅔H䕎A

(non
bo牮

non

併椠

non

oui

non

千奔H䕒

併椠

併椠

併椠

oui

oui




⩎攠条g慮t楴 p慳aune t敲浩m慩獯渠an c慳aT攠p牯toco汥

f慩汬ab汥l

䄠污l汥捴u牥 Tu t慢汥luH 楬 牥獳潲V 癩vib汥lent qu攠T敵x out楬猠Vont 汥猠p汵猠敦f楣慣敳aen
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, nou
s 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


Rapport de projet

:

Nasser Fangayoumani Debras







12
/
37


3.3.

Introduction à l’out
il 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 per
formant, 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é
I
nternet à
grande éc
helle.


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



















sortie


H
igh
-
Level Protocol Specification Language

(HLSPL)

[YBPHOK+]

Traduction HLPSL

IF

OFMC

[BMV05]

CL
-
ATSE

[Tur06]

SATMC

[AC05]

TA4SP

[BHK05]

Rapport de projet

:

Nasser Fangayoumani Debras







13
/
37

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éb
riques 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’in
tégrer facilement d’autres spécifications
de fonctions cryptographiques.



SATMC

utilise un état transitoire et recherche les éventuelles violation
s

d’un
protocole donné. Ceci lui permet de générer une formule représentant la
violation et la transforme en a
ttaque.



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 pe
uvent être vus comme
une trace "Alice & Bob"

d’une spécification HLPSL. Da
ns 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 p
eut déclencher d’un
double
-
clique
. S’il n’y a plus de tran
sitions, c’est qu’on est arrivé à la fin du protocole ou qu’il y a une
erreur dans la spécification HLPSL.

Il y a
deux modes de simulation

: le mode normal et le mode intrus.

En mode normal, les seules transition
s qu’on voit sont celles où

l'
émetteur

et le
récepteur du message sont d’accord sur le message. En mode intrus, tous les messages
peuvent être envoyés
à

l’intrus et chaque message qu’il reçoit enrichit ses connaissances.


SPAN a plu
sieurs utilités dont celle de vé
r
ifier

que la spécification HLPSL cor
respond
bien au protocole qu’on avait en tête avant même de chercher des attaques. On peut ainsi
trouver des erreurs de spécification que les outils de vérification ne détecteraient pas ou
n’expliciteraient pas correctement. SPAN peut même être d’un grand se
cours pendant la
phase de conception du protocole. Plutôt que de dessiner laborieusement des sc
hémas
incomplets ou mal expliqué
s au tableau, il peut

être très efficace d’animer avec SPAN les
premières idées que l’on a et de faire des tests d
è
s le début de la

conception. Cependant, la
plus grande utilité de SPAN est la possibilité de reconstruire les attaques fournies par les
outils de vé
r
i
fication, ou même de les construire
à partir

d’une intuition. SPAN permet à

l’utilisateur de choisir à chaque étape si les

messages sont reçus par l’intrus ou non
et affiche
dans un cadre les connaissances de l’intrus.

Rapport de projet

:

Nasser Fangayoumani Debras







14
/
37



3.3.4.


Syntaxes formelles HLPSL et CAS+

HLPSL est un langage extrêmement expressif et intuitif servant à modéliser un
protocole, pour l’outil AVISPA. Sa sémantique est basée sur les travaux réalisés

par Lamport
à propos de la logique temporelle des actions. C’est un langage de spécification modulaire
basé sur la notion de rôles (participants) et de rôles comp
osés (sessions, instances). Un r
ôle
simple sert à décrire les actions d’un agent lors de l’e
xécution du protocole. Un rôle
composé permet d’instancier plusieurs rôles simples afin de modéliser l’exécution du
protocole entier. En plus de la notion de rôle

fournie par HLPSL, ce langage possède

les
caractéristiques suivantes

:



support cryptographiqu
es variés (clés symétriques, clés publiques et privées,
fonctions de hachage,…)
;



information typée (ou non), avec des types simples ou composés
;



propriétés algébriques supportées (concaténation, OU exclusif,
exponentiation…)
;



canaux pour les échanges de m
essages
;



flux de contrôle assurant les transitions valides
;



propriétés de sécurité à vérifier

: confidentialité, authentification, intégrité
.

1

1


2

3

Rapport de projet

:

Nasser Fangayoumani Debras







15
/
37

Cependant, la définition de l’environnement d’implémentation du protoco
le et la
spécification du modèle

de l’int
rus peuvent accroitre la complexité du langage.



Pour remédier au problème de complexité dans la spécification du protocole,
le langage CAS+ a été crée. C’est un langage simple à lire et à écrire, mais dont le niveau de
précision dans la spécification é
gale celui de HLPSL. Nous allons plus loin comparer la
syntaxe de deux spécifications d’un même protocole en voir la syntaxe à l’aide d’un
exemple.

a.

Identifiants (
identifiers
)

: ils doivent être de l’un des types suivants

: user,
public_key, symetric_key, f
unction, number.

L’identifiant number est une abstraction utilisée pour n’importe quel type de donnée
(numérique, texte...) qui soit différente des autres types (public_key…)

Un identifiant F de type function est une fonction de hachage non réversible (se
ns
-
unique), i
-
e on ne peut obtenir X à partir de F(X).L’apostrophe ‘ placée devant une clé signifie
qu’il s’agit d’une clé privée.

Exemple:

User: A, B

Public_key: k

Symmetric_key: kab

Function: H

b.

messages (
message
)

Ils permettent de décrire les étapes de c
ommunication dans le protocole





i.

Si

Ri

: Mi

i représente le numéro de l’étape, Si et Ri des utilisateurs (émetteur et récepteur) et
Mi le message. La flèche représente le type de canal utilisé. Il peut être du type Dolev
-
Yao
(

), du type protégé e
n lecture et écriture (=>), ou du type protégé en écriture (~>).

Exemple:

1.A

B

:{A,M}

2.B

A

:{B,M’}

Rapport de projet

:

Nasser Fangayoumani Debras







16
/
37

c.

Connaissances (
knowledge
)


Au commencement du protocole, chaque utilisateur a besoin de certaines
connaissances pour composer ses messages (clés, fonction
s, ….).On considère que chaque
utilisateur connait implicitement son nom.

Exemple

:

Knowledge


B

:A,k,H

;

d.

Sessions (
sessions_instances
)


Elles permettent d’assigner certaines valeurs à des identifiants, et ainsi
décrire les différents systèmes qui utilise
nt le protocole. Il est aussi possible d’instancier
l’intrus en utilisant l’identifiant i. Les sessions s’exécutent en parallèle.

Exemple

:

Sessions_instances

[A

: serveur, B

: client1, K

: KAB1]


[A

: serveur, B

: client2, K

: KAB2]


[A

: serveur, B

: i,
K

: Ki]

;

e.

connaissances de l’intrus (
intruder_knowledge
)

C’est un ensemble de valeurs qu’on introduit dans une session.


Exemple

:

Intruder_knowledge

K,A,B

;

f.

Buts (
Goals
)

Ce sont les propiétés de sécurité que l’on souhaite tester dans notre protocole. On e
n
distingue 3 familles de buts

: la confidentialité (secrecy), l’authenticité (authentification),
l’intégrité (integrity).

Exemple

:

Goals

A authenticates B on Num
,

Rapport de projet

:

Nasser Fangayoumani Debras







17
/
37


B
est un identifiant déjà mentionné dans la rubrique
identifiers
.

Nous nous servirons d
e
s spécifications du protocole NSSP pour voir l
es portions de
code en cas+ et en HLPSL

correspondants
.

4.

Cas d’application

: présentation informelle du
protocole SNSSP

4.1.

Notions basiques en sécurité utilisées

La cryptographie est l’étude des méthodes permettan
t de transmettre des messages
de manière confidentielle. Afin de protéger un message on lui applique une transformation
qui le rend incompréhensible, c’est ce qu’on appelle le chiffrement, qui, à partir d’un texte
en clair, donne un texte chiffré ou crypto
gramme. Inversement le déchiffrement est l’action
qui permet de reconstruire le texte en clair à partir du texte chiffré.

Ainsi, la cryptographie met à la disposition des concepteurs de systèmes
d’informations des outils permettant d’assurer, ou de contr
ibuer à assurer, des fonctions de
sécurité telles que la confidentialité, l’intégrité, l’authenticité et la non
-
répudiation. Ces
outils sont souvent qualifiés d’algorithmes, de primitives ou encore de mécanismes
cryptographiques.


4.1.1.

Cryptographie symétrique

La

cryptographie symétrique
, également dite

à clé secrète ou à clé privée

est la plus
ancienne forme de chiffrement et consiste
à utiliser la même clé pour le chiffrement et le
déchiffrement.

Donc cette technique de chiffrement repose sur la notion fondame
ntale
de

clé

(information permettant de chiffrer/déchiffrer un message)

: en effet, dans ce type
de chiffrement, la sécurité de la communication de données dépend entièrement d’elle.


Exemple

:

Bob désire envoyer une donnée confidentielle à Alice; ils dis
posent tous
les deux d’une clé identique. Bob chiffre le message avec, et l’envoie à Alice qui le déchiffre
grâce à la même clé.

Rapport de projet

:

Nasser Fangayoumani Debras







18
/
37


Avantages & Inconvénients

:

Les principaux avantages sont

:



Compréhension du principe simple

;



Réalisation peu complexe

;



Con
sommation de ressources et de bande passante faible

: rapidité de transmission
.

Les inconvénients de cette cryptographie sont

:



Clé

privée connue de plus d'une personne

;



Sécurité incertaine lors du transfert de cette clé

;



Nécessité de générer autant de

clés que de couples de correspondants
.


4.1.2.


Cryptographie asymétrique

C'est une approche radicalement différente apparue en 1976 car, pour cette
cryptographie,
la clé qui sert à
chiffrer

est différente de celle qui peut déchiffrer
.

La première est

souvent p
ublique
,

di
vulguée sur tout le réseau afin que tout
participant puisse chiffrer mais la deuxi
è
me reste en général secrète pour qu’une seule
entité puisse déchiffrer.

La grande nouveauté introduite par cette famille de méthodes, c'est que

la clé
de
chiffre
ment

est publique,

d’où le nom cryptographie à clé publique. Cette notion de
cryptographie à clé publique résulte d'un défi mathématique lancé par Witfield Diffie et
Martin Hellman. Trois mathématiciens américains (Ronald Rivest, Adi Shamir et Leonard
Adle
man) ont réussi à l'époque à trouver une solution, aujourd'hui employée sous le nom de
RSA.

La méthode repose sur un constat très simple : il est facile d'effectuer la
multiplication de deux nombres premiers, mais il est très difficile de retrouver les fac
teurs
quand le résultat est grand.

La clé publique est donc constituée du produit n de deux nombres premiers p et q,
choisis très grands. La clé secrète dépend directement de p et q et ne peut donc être déduite
de la clé publique.

En résumé, chacun dispose

d'une clé privée qui est gardée secrète et d'une clé
publique qui est destinée à être divulguée (clé chiffrante). Ces clés sont liées entre elles.
Un document encrypté avec l'une ne peut être décodé qu'avec l'autre. Toutefois, la
possession de l'une des c
lés ne permet pas d'en déduire l'autre.

Rapport de projet

:

Nasser Fangayoumani Debras







19
/
37


Exemple:

Alice désire recevoir des messages chiffrés de n’importe qui

; ici, nous
parlerons plus précisément de Bob. Alice possède deux clés

: clé publique connu par les
entités du réseau dont Bob fait partie et un
e clé privée qu’elle garde secrète. Avec la clé
publique d’Alice, Bob chiffre son message puis lui envoie

: cette dernière déchiffre le
message grâce à sa clé privée.

Avantages & Inconvénients

:

Les principaux avantages sont

:



Impossibilité de substitutio
n du destinataire

:
clé

privée connue de lui seul

;



Aucun transfert de
clé

privée

: confidentialité assurée

;



Un seul couple de clés pour plusieurs expéditeurs
.

Les inconvénients de cette cryptographie sont

:



Sa complexité

;



Elle requiert beaucoup d'opérat
ions, donc peu recommandé pour transférer de
grandes quantités de données

;



Authentification incertaine de l'expéditeur
.

Néanmoins, un problème reste à régler comment s’assurer qu’une
clé

publique
appartient bien à
un utilisateur ?

Il faut
alors
passer par

un acteur intermédiaire qui va
certifier la
clé

publique, c’
est l’autorité de certification.

4.1.3.


Certificats et autorités de certification

U
ne autorité de certification (AC
) lie une
clé

publique à

un sujet durant une période
de
validité.

(Le sujet est un uti
lisateur, u
n processus ou un ordinateur).



L’assertion "
ce sujet dé
tient bien cette
clé

publique"

se traduit par la génération d’
un
certificat de
clé

publique.
Ainsi, une autorité de certification offre un niveau d’assurance sur
le certificat de
clé

publi
que que l’on utilise.

P
arce qu’il est indispensable de s’assurer du bon
propriétaire de la clé publique, cette dernière doit être certifiée par une autorité de
certification pour pouvoir lui faire confiance.

Rapport de projet

:

Nasser Fangayoumani Debras







20
/
37

L’autorité

de certification

(AC
) a pour mission,

après vérification de l'identité du
demandeur du certificat par une

autorité d'enregistrement
, de signer, émettre et maintenir
les

certificats

et les listes de révocation.

Elle définit et fait appliquer une politique de délivrance, révocation et
renouvellement de certificats numériques. Tous les certif
icats numériques émis par une CA
sont signés avec la clé privée de cette CA afin d'assurer l'authenticité du certificat.

4.1.4.

Fonctions de hachage

Une fonction de hachage est aussi appelée fonction de hachage à sens unique ou
"one
-
way hash function" en anglais.

Ce type de fonction est très utilisé en cryptographie,

principalement dans le but de réduire la taille des données à traiter par la fonction de
cryptage. En effet, la caractéristique principale d'une fonction de hachage est de produire un
condensé

des don
nées, c'est
-
à
-
dire un condensé de ces données. Ce condensé est de taille
fixe, dont la valeur diffère suivant la fonction utilisée.


Le but d'un condensé (résultat de la fonction de hachage) est simple : représenter
des données de façon certaine tout en ré
duisant la taille utile.

Exemple

:


On imagine qu’on souhaite envoyer un fichier par mail, mais que ce fichier est de
taille importante. On souhaite de plus rassurer le destinataire sur la provenance de ce fichier
et sur son contenu. Plutôt que de chiffre
r notre fichier directement avec votre clé privée, on
va hach
er notre fichier et chiffrer le c
ondensé obtenu avec notre clé privée. On enverra
ensuite notre fichier

original ainsi que le condensé c
hiffré (la signature) à notre destinataire.


Celui
-
ci va,
lors de la réception, hacher d'une part le fichier reçu et d'autre part déchiffrer le
condensé reçu (au

moyen de votre clé publique).


S
'il n'y a pas égalité entre les 2 résultats, cela signifiera :



soit que la signature n'est plus la notre, donc que quelq
u'un a intercepté le
fichier (pour le modifier ou le remplacer,
etc

.
..)



soit que le fichier n'est plus le même que l'original (mais la signature n'a pas
été remplacée); dans ce cas, le hachage ne peut plus donner le même
condensé ce qui conduit au rejet l
ors du test de comparaison.


Dans les 2 cas, ni l'intégrité ni l'authentification du fichier n'ont été vérifiées. Il ne faut donc
pas faire confiance au fichier.


Nous voyons comment dans ce cas simple, l'utilisation d'une fonction de hachage permet de
s'a
ssurer de l'intégrité des données et indirectement de les authentifier. Il existe bien sûr de
Rapport de projet

:

Nasser Fangayoumani Debras







21
/
37

nombreuses autres applications pour les fonctions de hachage, comme les MACs (message
authentification

code), certificats, etc...


4.2.


Etude
du protocole SNSSP


Dans notre projet, on se propose d’utiliser l’outil d’analyse
AVISPA
afin de valider
formellement le protocole intitulé
SNSS
P
. Ce dernier a été spécifié dans le cadre du projet
FAST mené au sein du laboratoire LEOPART de l’ENAC afin de définir une architec
ture de
sécurité adaptative pour les communications aéronautiques du futur.

Le rôle du protocole SNSSP est d’établir une base de données commune entre un
client à bord d’un avion et un serveur au sol. Cette base contient l’ensemble des
mécanismes de sécuri
té pouvant être utilisés pour sécuriser les échanges air
-
sol.


Prenons l’exemple d’un
Airline Operational Communications (AOC)

qui souhaite
établir une connexion Internet sécurisé (consultation d’email, virement bancaire,…). Tout
d’abord, il faut savoir qu
’au sein de l’avion il existe un proxy qui gère toutes les
communications entrantes et sortantes de l’avion. Nous nous sommes donc intéressés
directement au proxy et non à l’utilisateur.
Pour démarrer la connexion, le proxy contacte un
serveur sol.

Le pro
tocole détaille principalement les échanges entre proxy avion et serveur sol.
Les enjeux majeurs de cette connexion sont en effet l’identification du serveur sol pour
s’assurer qu’un intrus ne puisse pas se faire passer pour le serveur sol et le partage de

la
base de données permettant l’ouverture d’une connexion sécurisée. L’authentification du
serveur sol est donc l’objectif majeur de ce protocole. Nous allons tenter de vérifier cet
objectif à l’aide de deux versions du protocole que nous avons détaillé p
lus tard.

Voici un schéma sur lequel on voit bien les interactions entre les agents

:

Rapport de projet

:

Nasser Fangayoumani Debras







22
/
37



1
-
négociation initiale


Le SMP envoie une requête
request_ssp[nonce1]

contenant un nonce à
l’entité
au sol E2. La présence des nonces

permettra de garantir la fraiche
ur du message
envoyé et/ou reçu.

La
réponse de l’e
ntité E2 au sol est la suivante
Response_SSP

[Nonce1,

Nonce2,

certE2,

SSPE2,

LifeTime,

he2,

SigE2]. Le nonce1 renvoyé permet à SMP de savoir qu’il s’agit
d’une réponse à la requête qu’il a émise précédemmen
t. En prévision d’une éventuelle
Rapport de projet

:

Nasser Fangayoumani Debras







23
/
37

vérification de la fraîcheur de message, E2 envoie aussi le nonce2. Le certificat CertE2 est
celui fourni par une autorité de certification (que nous avons rajouté dans la spécification).Il
contient l’identifiant de l’enti
té demandeuse, avec sa clé publique, le tout signé avec la clé
privée de l’autorité. SigE2 est le message entier (nonce1, nonce2…he2) chiffré par l’entité
E2avec la clé publique de SMP ou la clé de cession qu’ils auront échangé au préalable. À la
réception

de ce message, SMP procède à la vérification du CertE2, du nonce1, de la
signature SigE2.En cas d’informations correctes, SMP calcule la SSPnégociée qui correspond
à l’intersection de la SSPsmp et de la SSPE2.

2
-
demande de connexion ultérieure

Si la SSP d
e l’entité au sol existe déjà dans la base de données SSPD, on en vérifie la
date d’expiration.

Deux alternatives s’offrent à ce niveau

:



Si la date est valide, la connexion sécurisée est établie.



Si la date a expiré, Le SMP émet une requête
request_
hash [nonce2, nonce3].

L
a
réponse de l’entité au sol E2 est la suivante

:
Response_hash [nonce3, nonce4, Cert2E, h’e2,
SigE2
]. h’e2 est le nouveau condensé de la SSPE2.

Si après réception le SMP valide le
certificat, vérifie le nonce3 et confirme l’égalité

entre h’e2 et he2 (stockée précédemment
dans la SSPD), alors la connexion sécurisée est établie. En cas de différence, une nouvelle
négociation est entamée avec l’entité au sol.

Nous avons donc pensé à simuler ce protocole à l’aide de deux versions l’une

se
basant sur la cryptographie symétrique (la

v
ersion à base de clé de session) l’autre se basant
que sur la cryptographie asymétrique (la version à base de certificat).

4.3.


Version à base de clé de session
2

Dans cette version, on a pensé assurer l’authent
ification de S par P grâce à une clé
symétrique générée par CA (entité de confiance).Le but est de garder la
clé Kps un secrète
entre P et S, c
eci en chiffrant le message généré par le CA par deux clés

:



la clé publique de l’un d’eux

: pour

qu’il soit le s
eul à pouvoir extraire le
contenu du message

;



la clé privée de CA pour que le destinataire soit sûr que c’est bien cette entité
de confiance qui a envoyé le message. CA
exécute

donc une signature du
message

;

Donc lors de l’envoi du message
6, P

est sûr q
ue c’est S qui a envoyé le message et S
est sûr qu’il n’ya que P qui peut déchiffrer le
contenu.





2

Pour le code Cas+ et HLPSL se référer à la partie 5.2.2

Rapport de projet

:

Nasser Fangayoumani Debras







24
/
37


4.4.


Version à base de certificat
3

Cette version se pose sur le fait que le CA est une entité de confiance qui va délivrer
un certificat IdS qui servira à l’authe
ntification de S.
(Le code CAS+ est disponible dans la
partie 5.2

.1)
Donc le premier message est une demande de certificat, le second correspond
à l’envoi de ce dernier par le CA à P qui s’en servira après pour l’identification de l’expéditeur
(serveur S)
.

PS

:
l’IdS comporte l’identifiant de S ainsi que sa clé publique, la clé avec laquelle P
est sensé déchiffrer le 4ème message. On a pas mentionné le contenu de IdS dans le code
sur CAS+ car ce dernier ne permet de réaliser l’identification de l’expéditeu
r que sur une
donnée (Number).

Donc lors de l’envoie du 4
ème

message, P va déchiffrer le message avec la clé publique
de S communiquée par le CA auparavant. Ce qui élimine la possibilité qu’un intrus modifie le
contenu du message chiffré car la modificatio
n d’un message nécessite le chiffrement par sa
propre clé et par conséquent P est sûr que S est bien celui qui a envoyé l’information car il
n’est sensé déchiffrer le contenu qu’avec la clé publique de S.

Pour renforcer la sécurité du protocole, on a pensé

à ajouter l’identifiant de S dans
l’IdS. Ainsi on est certain que la modification de la partie non chiffrée par un intrus sera
détectable par P qui fera la comparaison entre le IdS envoyé auparavant du CA et le IdS reçu
lors du 4
ème

message.





3

Pour les codes Cas+ et HLPSL se référer à la partie 5.2.1

Rapport de projet

:

Nasser Fangayoumani Debras







2
5
/
37

5.

Vérification

formelle du protocole SNSSP

5.1.

Hypothèses sur les capacités d’un intrus

5.1.1.

Introduction au modèle de l’intrus
Dolev
-
Yao

Le modèle de Dolev
-
Yao est un des premiers modèles formels pour la vérification de
protocoles cryptographiques. Cette formalisation des protocoles idéalise les protocoles en
considérant les points suivants.



Un réseau idéalisé

Le modèle de Dolev
-
Yao ne prend

pas en compte la notion de temps, ni les pertes de
messages. Nous supposons un réseau « idéal » c'est
-
à
-
dire qu’aucun message échangé n’est
perdu et tous les messages sont envoyés et reçus instantanément par les agents. Ainsi, avec
le modèle introduit par

Dolev et Yao, il n’est pas possible de prendre en compte le temps
dans les capacités de l’attaquant. De plus, dans ce modèle, tous les canaux de
communications sont supposés être publics, ainsi nous sommes dans un environnement le
plus hostile possible po
ur effectuer la vérification.



Abstraction des messages échangés

En réalité, les messages échangés par des agents lors d’une communication sont des
chaînes de bits. Dans ce modèle, comme dans de nombreuses approches symboliques en
vérification de protocoles, l
es messages échangés sont abstraits par des termes générés par
une algèbre de termes qui contient les symboles des fonctions de chiffrement, de
construction d’une paire et un ensemble de messages constants.



Chiffrement parfait

Dans ce modèle on fait l’hypot
hèse de cryptographie parfaite. Ainsi, Les messages
chiffrés sont donc analysés comme des « boites noires » contenant un message qu’il n’est
possible d’ouvrir
que

si la
clé

de déchiffrement est connue.



Capacités de l’intrus

Dans le modèle de Dolev
-
Yao, un in
trus peut utiliser n’importe quel terme qu’il a
observé sur le réseau précédemment et ce, autant de fois qu’il le désire. On dit
habituellement que « l’intrus est le réseau » ainsi, les messages, qui circulent sur le réseau,
sont connus par l’intrus et con
stituent l’ensemble de sa connaissance initiale.

Donc, dans ce système, on considère que l’intrus a le contrôle total du réseau. Il
connait toutes les données publiques des agents, dispose des privilèges et des clés des
agents malhonnêtes. Ainsi, l’intrus

peut appliquer une des règles données par le modèle

: Il
peut déchiffrer un message s’il connaît la
clé

de déchiffrement, il peut chiffrer un message
avec n’importe quelle
clé

en sa possession et il est capable de mémoriser, effacer, construire
et envoyer t
ous les messages s’il a la clé.

Rapport de projet

:

Nasser Fangayoumani Debras







26
/
37

De plus, le nombre d’opérations élémentaires de l’intrus est non borné

: l'attaquant
peut envoyer une infinité de messages
,

ceci engendre un espace d'états à explorer infini.
C’est pourquoi ce modèle est parfois appelé «

mod
èle formel

».

En bref, Dolev et Yao ont modélisé les capacités de l’intrus par un modèle de
déduction c’est à dire qui représente tous les messages qu'un intrus peut fabriquer par un
ensemble de règles.

Pour montrer qu'un protocole respecte une propriété
donnée, il faut fournir une
preuve formelle que quelles que soient les actions de l'attaquant, la propriété désirée est
maintenue pour le protocole.


5.2.

Spécification formelle du protocole SNSSP en langage CAS+
et codes HLPSL générés

5.2.1.


Version à base de certif
icat

Code CAS+ :

identifiers

P, S
, Ca






: user;

Kp, Ks
, Kca






: public_key;

SSPs
, Nonce1
, Lifetime, CertS
, IdS


: number;

F
, H







: function;


messages

1. P
-
> Ca


: CertS

2. Ca
-
> P : {IdS
} Kca’

3. P
-
> S : Nonce1

4. S
-
> P


: SSPs,H(
SSPs), IdS, Nonce1,Lifetime,{F(H(SSPs),IdS,
Nonce1,Lifetime)}Ks'



knowledge

P

: S,F,Ca;

S

: P,F,H,Ca;

Ca

: S,P;


session_instances

[P:proxy,Ca:certif,Ks:key1,Kca:key2,Kp:key3,S:serveur]


intruder_knowledge

proxy,certif,serveur;


goal

P authenticates S on

IdS;

Rapport de projet

:

Nasser Fangayoumani Debras







27
/
37

Code HLPSL généré

:

role role_P(P:agent,S:agent,F:function,Ca:agent,SND,RCV:channel(dy))

played_by P

def=


local



State:nat,CertS:text,Kca:public_key,Ks:public_key,Nonce1:text,SSPs:text,H:function,IdS:text,Lifeti
me:text


init



State := 0


transit
ion



1. State=0 /
\

RCV(start) =|> State':=1 /
\

CertS':=new() /
\

SND(CertS')



2. State=1 /
\

RCV({IdS'}_inv(Kca')) =|> State':=2



4. State=2 /
\

RCV(SSPs'.H(SSPs').IdS.Nonce1'.Lifetime'.{F(H(SSPs').IdS.Nonce1'.Lifetime')}_inv(Ks')) =|> State':=3

end role


role role_S(S:agent,P:agent,F:function,H:function,Ca:agent,SND,RCV:channel(dy))

played_by S

def=


local



State:nat,Ks:public_key,Nonce1:text,SSPs:text,IdS:text,Lifetime:text


init



State := 0


transition



3. State=0 /
\

RCV(Nonce1') =|> State':=1 /
\

Ks':
=new() /
\

Lifetime':=new() /
\

IdS':=new()
/
\

SSPs':=new() /
\

SND(SSPs'.H(SSPs').IdS'.Nonce1'.Lifetime'.{F(H(SSPs').IdS'.Nonce1'.Lifetime')}_inv(Ks'))

end role


role role_Ca(Ca:agent,S:agent,P:agent,SND,RCV:channel(dy))

played_by Ca

def=


local



State:nat,
CertS:text,Kca:public_key,IdS:text,Nonce1:text


init



State := 0


transition



1. State=0 /
\

RCV(CertS') =|> State':=1 /
\

Kca':=new() /
\

IdS':=new() /
\

SND({IdS'}_inv(Kca')) /
\

Nonce1':=new() /
\

SND(Nonce1')

end role


role session1(S:agent,P:agent,F:funct
ion,H:function,Ca:agent)

def=


local



SND3,RCV3,SND2,RCV2,SND1,RCV1:channel(dy)


composition



role_S(S,P,F,H,Ca,SND3,RCV3) /
\

role_Ca(Ca,S,P,SND2,RCV2) /
\

role_P(P,S,F,Ca,SND1,RCV1)

end role


role environment()

def=


const



hash_0:function,const_1:funct
ion,proxy:agent,serveur:agent,certif:agent,auth_1:protocol_id


intruder_knowledge = {proxy,certif,serveur}


composition



session1(serveur,proxy,const_1,const_1,certif)

end role


goal


authentication_on auth_1

end goal


environment()


5.2.2.


Version à base de cl
é de session

Rapport de projet

:

Nasser Fangayoumani Debras







28
/
37

Code Cas+ :

identifiers

P, S,

Ca






: user;

Kca,Ks,Kp






: public_key;

Kps







: symmetric_key;

SSPs,Nonce1, Lifetime, CS,CP,Idps,N

: number;

F,H







: function;


messages

1. P
-
> S

: Nonce1

2. S
-
> Ca : CS

3. Ca
-
> S : {{Kps,N}Ks}Kca'




4. P
-
>Ca : CP

5. Ca
-
> P : {{Kps,N}Kp}Kca'

6. S
-
> P

: SSPs,H(SSPs), Nonce1,Lifetime,Idps,{F(H(SSPs),
Nonce1,Lifetime,SSPs,Idps)}Kps



knowledge

P

: S,F,Ca;

S

: P,F,H,Ca;

Ca

: S,P;


session_inst
ances

[P:proxy,Ca:certif,S:serveur,Kps:key1,Kca:key2,Ks:key3,Kp:key4];


intruder_knowledge

proxy,certif,serveur;


goal

P authenticates S on Idps;

secrecy_of Kps [Ca,S];

secrecy_of Kps [Ca,P];


Code HLPSL généré

:

role role_P(P:agent,S:agent,F:function,Ca:
agent,SND,RCV:channel(dy))

played_by P

def=


local



State:nat,CP:text,Kca:public_key,N:text,Kp:public_key,Kps:symmetric_key,SSPs:text,Nonce1:text,
H:function,Lifetime:text,Idps:text


init



State := 0


transition



1. State=0 /
\

RCV(start) =|> State':=1 /
\

Nonce1':=new() /
\

SND(Nonce1') /
\

CP':=new() /
\

SND(CP')



5. State=1 /
\

RCV({{Kps'.N'}_Kp'}_inv(Kca')) =|> State':=2 /
\

secret(Kps',sec_2,{P,S})



6. State=2 /
\

RCV(SSPs'.H(SSPs').Nonce1.Lifetime'.Idps'.{F(H(SSPs').Nonce1.Lifetime'.SSPs'.Idps')}_Kps) =|>

State':=3 /
\

secret(Kps',sec_2,{P,S})

end role


role role_S(S:agent,P:agent,F:function,H:function,Ca:agent,SND,RCV:channel(dy))

played_by S

def=


local



State:nat,CS:text,Kca:public_key,N:text,Ks:public_key,Kps:symmetric_key,SSPs:text,Nonce1:text,Li
fetim
e:text,Idps:text


init

Rapport de projet

:

Nasser Fangayoumani Debras







29
/
37



State := 0


transition



1. State=0 /
\

RCV(Nonce1') =|> State':=1 /
\

CS':=new() /
\

SND(CS')



3. State=1 /
\

RCV({{Kps'.N'}_Ks'}_inv(Kca')) =|> State':=2 /
\

secret(Kps',sec_2,{P,S}) /
\

Idps':=new() /
\

SSPs':=new() /
\

Lifetime':=new(
) /
\

SND(SSPs'.H(SSPs').Nonce1.Lifetime'.Idps'.{F(H(SSPs').Nonce1.Lifetime'.SSPs'.Idps')}_Kps')

end role


role role_Ca(Ca:agent,S:agent,P:agent,SND,RCV:channel(dy))

played_by Ca

def=


local



State:nat,CS:text,Ks:public_key,CP:text,Kca:public_key,N:text,Kp
s:symmetric_key,Kp:public_key


init



State := 0


transition



2. State=0 /
\

RCV(CS') =|> State':=1 /
\

Kca':=new() /
\

Ks':=new() /
\

N':=new() /
\

Kps':=new() /
\

secret(Kps',sec_2,{P,S}) /
\

SND({{Kps'.N'}_Ks'}_inv(Kca'))



4. State=1 /
\

RCV(CP') =|> State':=
2 /
\

Kp':=new() /
\

secret(Kps',sec_2,{P,S}) /
\

SND({{Kps.N}_Kp'}_inv(Kca))

end role


role session1(S:agent,P:agent,F:function,H:function,Ca:agent)

def=


local



SND3,RCV3,SND2,RCV2,SND1,RCV1:channel(dy)


composition



role_S(S,P,F,H,Ca,SND3,RCV3) /
\

role_C
a(Ca,S,P,SND2,RCV2) /
\

role_P(P,S,F,Ca,SND1,RCV1)

end role


role environment()

def=


const



hash_0:function,const_1:function,proxy:agent,serveur:agent,certif:agent,auth_1:protocol_id,sec_2:
protocol_id


intruder_knowledge = {proxy,certif,serveur}


composit
ion



session1(serveur,proxy,const_1,const_1,certif)

end role


goal


authentication_on auth_1


secrecy_of sec_2

end goal


environment()

5.3.

Résultats et discussion

Avec ces deux versions du protocole, nous avons testé les différents back
-
ends
fournis par AVISP
A.
Voici les résultats obtenus :



Pour la version à base de certificats :

Rapport de projet

:

Nasser Fangayoumani Debras







30
/
37




Rapport de projet

:

Nasser Fangayoumani Debras







31
/
37



Pour la version à base de certificat

:





Rapport de projet

:

Nasser Fangayoumani Debras







32
/
37

Pour les back
-
ends proposé par AVISPA, le protocole est donc sécurisé.

5.4.

Scénarios d’attaques complémentaires

5.4.1.


Besoin

Dans ce

projet, nous nous intéressons à la protection des communications entre le
serveur S et le proxy P

et plus particulièrement, l'authentification de S par P
. Donc, pour
tester la sécurité du protocole, on peut se servir de l’outil AVISPA déjà programmé pour
simuler les principales attaques à l’aide des backends et trouver quelques failles dans le
protocole sauf que

le logiciel ne peut pas couvrir l'ensemble des scénarios d’attaque
possibles, c’est
-
à
-
dire la suite d’opérations susceptibles de provoquer la per
te des
objectifs(l’intégrité et l’authentification) pour lesquels le protocole a été conçu, ainsi la
validation de la sécurité du protocole doit passer par la création des scénarios
qui ne sont
pas nécessairement pris en compte

par l’outil AVISPA.

Pour r
ésumer le besoin d’imaginer des scénarios supplémentaires afin de vérifier le
respect du protocole SNSSP aux objectifs fixés vient du fait que l’outil de vérification
automatique ne permet pas la couverture des différentes attaques possibles et imaginables
.


Néanmoins, on peut utiliser l’
outil graphique SPAN pour connaî
tre les connaissances
supplémentaires acquis
es

par l’intrus lors de l’envoie d’un nouveau message, et ainsi
essayer de tester les

a
ttaques en fonction de ces données.



5.4.2.


Utilisation d
e l’env
ironnement de simulation
d’attaque dans AVISPA

A l'aide de l'environnement de simulation d'attaque dans AVISPA, on peut créer
notre propre attaque sur le protocole tout en connaissant les connaissances de l'intrus suite
à l'échange de messages. Voici comme
nt cela se présente :

Rapport de projet

:

Nasser Fangayoumani Debras







33
/
37








Permet
de construire
une attaque du
déb
ut à la fin

permet de choisir
le prochain
message envoyé

Indique les
connaissances
actuelles de
l'intrus

Représentation
graphique des
messages envoyés
un des agents

Rapport de projet

:

Nasser Fangayoumani Debras







34
/
37

Nous avons donc imaginé les deux scénarios d'attaques suivant.

1
er

scénario

:
I

se fait passer pour P


Les entités présentes sur le réseau sont donc

: un serveur, deux proxys dont l’un
d’entre eux est malhonnête et
l’autorité de certification.

Pour la version à base de certificat, ce scénario est obsolète car le but fixé dans le
code CAS+ est de faire l’authentification de S par P. Donc le fait que P soit un intrus n’influe
pas sur l’objectif fixé puisque ce dernier
reste toujours valable.

Pour la version à base de clé de session, la clé Kps ne peut pas être dévoilée par
l’autre proxy malhonnête car ne possède pas la clé pr
ivée de l’autre proxy. Par conséquent

l’in
trus ne peut en aucun cas altérer

la communication (mo
difier le contenu du message sans
que S se rende compte) entre le

serveur et le proxy légitime
.

2
ème

scénario

:
I se fait passer pour S

On utilise donc l'outil de travail décrit au dessus pour simuler ce scénario. On peut
noter qu'il est aussi possible de
rajoute
r

une deuxième session dans le code CAS+ dans
laquelle on précise que S se fait passer pour un intrus

:

[P

:proxy, CA

: certif, Kp

:Key3, Kca

:key2,
S

:I
,
Ks

:Ki
]

Les résultats obtenus sur l’outil AVISPA montrent que le protocole est bien sécurisé
et

que cette attaque ne constitue pas une menace sur les propriétés de SNSSP

notamment
sur
l’authentification et l’intégrité.

Ceci est prédictible
.

En effet, pour la version à base de certificat, si lors de l’échange
entre S et P (proxy SMP), l’entité malho
nnête intercepte le message envoyé par un serveur
(honnête), une tentative de modification du message par le serveur malhonnête sera
détectée par P. En fait, l’intrus devra utiliser sa propre clé privée pour chiffrer le message.
Vu que P a déjà reçu du Ca

le certificat de S incluant son identifiant et sa clé publique, une
tentative de lecture du message avec la clé publique de S échouera. Ainsi, la propriété
d’
intégrité

ne peut être violée.

Pour la version à base de clé de session, la logique reste la mêm
e. L’intrus est
totalement passif car il ne pourra qu’observer l’échange entre S et P. Ceci est dû à l’échange
préalable de clé symétrique secrète entre P et S (honnête) par l’intermédiaire du Ca. Vu que
Ca est une entité de confiance, la clé secrète parta
gée n’est connue que de P et de
S
.


Rapport de projet

:

Nasser Fangayoumani Debras







35
/
37

6.

Conclusion et perspectives

Conclusions et perspectives

De nos jours, l
a vérification des protocoles de sécurité
est vite devenue
incontournable
au
vu
d
es
actions malveillantes, de tentatives d’i
ntrusion et d’attaques
d
iverses que subissent

les réseaux informatiques
. C'est pourquoi des outils comme AVISPA
sont des moyens
efficaces et

performants pour vérifier la
robustesse

des protocoles
cryptographiques.

Le projet nous a servi dans un premier temps en tant qu'introduct
ion aux concepts
fondamentaux de la sécurité et de la cryptographie. Une fois les connaissances de bases
acquises, nous avons abordé une autre facette indispensable dans le cycle de vie d'un
protocole cryptographique qui est la vérification formelle.

Tout
d'abord,

nous avons introduit l’outil de vérification formelle AVISPA et spécifié
son architecture
logicielle
ainsi que les langages

CAS+ et HLPSL

utilisés au cours du projet.

Ensuite,

nous

a
vons

présenté une

brève

introduction au domaine de
s

protocoles
cr
yptographiques et de
la

vérification

formelle
.

Ceci nous a permis de comparer
l
es
outils de
vérifications existants

et de pouvoir
dégager

d’une part, leurs avantages et inconvénients et
d’autre part, les exigences qu’ils ne peuvent pas satisfaire.
Nous av
ons aussi introduit

le
protocole

de négociation des mécanismes de sécurité

S
NSSP
à vérifier en

deux versions

:
l'une à base de clé de session et l'autre à base de certificat
.

Finalement,

nous avons
présenté

les résultats de recherche qui
nous
ont permis
de

vérifier
automatique
ment

le

protocole
SNSSP.
L
e modèle formel de
l'intrus

utilisé dans les simulations
étant

celui de

Dolev
-
Yao,
nous avons

pu

traiter un nombre non
-
borné de sessions et des primitives cryptographiques
variées
.

L’utilisation d’AVISPA et de

l’outil SPAN dans la vérification de SNSSP montre que
le
protocole, tel que nous l'avons envisagé dans les deux versions,
est sécurisé.
La simulation
de scénarios d'attaques complémentaires avec l'outil SPAN nous a permis de s'assurer que le
protocole est bien immunisé contre les attaques les plus courantes.

Il est cependant
judicieux

de rappeler qu'AVISPA ne tient pas compte des
attaques

de
cryptanalyse
,

qui
permettent de casser un protocole par attaques brutes (dites de
dictionnaire),
mais propose uniquement d'analyser les erreurs logiques des protocoles. Avec
le développement de machines de plus en plus puissantes et rapide
s
, il est en e
ffet possible
de voir
certains protocoles
,

supposés sécurisés, cassés au bout de temps de traitement assez
raisonnable
s

comme ça été le cas
récemment
pour le protocole asymétrique RSA (Rivert
Shamir Aldman).


Rapport de projet

:

Nasser Fangayoumani Debras







36
/
37

Référence
s

[AC05] Alessandro Armando and Luca
Compagna.


An optimized intruder model for
sat
-
based model
-
checking of security protocols.
”,
Electr. Notes Theor. Comput. Sci.,
125(1) :

91

108, 2005.

[BHK05] Y. Boichut, P.
-
C. H´eam, and O. Kouchnarenko.

Automatic verification of
security protocols using approximations. Research
”,
Report RR 5727, INRIA, 2005. in
revision for Journal of Automated Reasoning.


[BMLPV]
M.S Ben Mamhoud, N. Larrieu, A. Pirovano, A. Varet,


an adaptative
security architecture
fo
r future aircraft communications ” in Procedinf of the 29
th

Digital Avionics Systems conference, October 2010, Salt Lake City, USA

[BMV05] David A. Basin, Sebastia
n M¨odersheim, and Luca Vigan`o, “
Ofmc : A
symbolic model checker for security protocols. Int
.
”,
J. Inf. Sec., 4(3) :181

208, 2005

[CAS] “Cas +”, Ronan Saillard and Thomas Genet, September 4, 2009

[CCC+] Y. Chevalier, L. Compagna, J. Cuellar, P. Hankes Drielsma, J. Mantovani, S.
M¨odersheim, and L. Vigneron.


A high level

protocol specification language for
industrial security
-
sensitive

protocols.


In Proceedings of Workshop on Specification
and Automated Processing of Security Requirements (SAPS), Linz, Austria, 2004.

[GGH] Y. Glouche, T.Genet, E. Houssay, "Span a Security P
rotocol Animator for
AVISPA" IRISA/Université de Rennes 1, Septembre 2008


[HS] M.Hussain, D. Seret “A comparative study of Security Protocols, Validation Tools:
Hermes vs. Avispa” UFR Math
-
info Université René Descartes Paris5

[NSPK]

http://en.wikipedia.org/wiki/Needham
-
Schroeder_protocol


[PBP+] R. Patel, B. Borisaniya, A. Patel, D. Patel, M. Rajarajan, A. Zisman
“Comparative Analysis of Formal Model Checking Tools for Security Protoc
ol
Verification”

[SG] S. Geller “Utilisation de SPAN et des outils AVISPA pour la verification d’un
protocole pair
-
à
-
pair

sécurisé“

[Tur06] Mathieu Turuani. The cl
-
atse protocol analy
ser. In Frank Pfenning, editor

RTA, volume 4098 of Lecture Notes in Comp
uter
”,
Science, pages 277

286. Springer,
2006.

[YBPHOK+] Y. Boichut, P.C.Héam, O. Kouchnarenko, "Vérifier automatiquement les
protocoles de Sécurtié" ENS Lyon, Octobre 2007


ET

aussi:


Rapport de projet

:

Nasser Fangayoumani Debras







37
/
37

[MB] MS. "Bouassida, Sécurité des communications de groupe dans les rés
eaux ad
hoc
"

, université Henri Poincaré


Nancy, 5 D
é
cembre 2006

[SaG] S. Gharout, "Sécurité des communications dans les groupes dynamiques",
Université de Technologie de Compiègne, 27 Novembre 2009

[YBPHOK] Y. Boichut, P.C.Héam, O. Kouchnarenko, "Vérific
ation des protocoles de
Sécurté" ENS Lyon.