Travail Personnel Encadré

Rapport finale

Vérification de la sécurisé

du protocole service web email

Encadrement : Michael Rusinowitch

Suivi : Nguyen Hong Quang

Réalisé par : Hoang Minh Tien

Tableau de matière
I. Etat de l’a t ........................................................................................................................ 1
1. Principe de service web.................................................................................................. 1
2. Service web sécurisé ...................................................................................................... 3
2.1 Protocole sécurité du SOAP ........................................................................................ 3
2.2 Protocole Single Sign-on SAML ................................................................................... 4
3. I t odu tio d’u s st e WSE ail .............................................................................. 5
4. Architecture du système WSEmail ................................................................................. 5
5. Attaque sur le service web ........................................................................................... 10
6. Outil AVISPA ................................................................................................................. 13
II. Modélisation du protocole WSEmail .............................................................................. 15
1. Protocole WSEmail ....................................................................................................... 15
2. Modélisation en langage HLPSL ................................................................................... 18
III. Expérimentation et évaluation ....................................................................................... 20
1. Scénario 1 ..................................................................................................................... 20
1.1 Pré-conditions ........................................................................................................... 20
1.2 Analyser du résultat .................................................................................................. 20
2. Scénario 2 ..................................................................................................................... 21
2.1 Pré-conditions ........................................................................................................... 21
2.2 Analyser du résultat .............................................................................................. 21
3. Scénario 3 ..................................................................................................................... 22
3.1 Pré-conditions ........................................................................................................... 22
3.2 Analyse du résultat.................................................................................................... 23
4. Scénario 4 ..................................................................................................................... 23
4.1 Pré-conditions ........................................................................................................... 23
4.2 Analyse du résultat.................................................................................................... 23
5. Scénario 5 ..................................................................................................................... 24
5.1 Pré-conditions ........................................................................................................... 24
5.2 Analyse du résultat.................................................................................................... 24
IV. Conclusion .................................................................................................................... 27
V. Appendice ....................................................................................................................... 28
VI. Références .................................................................................................................... 29
 Vérification de la sécurisé du protocole service web email
(WSEmail)

Abstraire
Courriel est une des applications la plus a ie e, la plus utilis e depuis l’appa e e
d’I te et. Malgré ette appli atio ’est pas diffi ile à l’atta ue, le spa ... Depuis quelques
années, la o atoi e de s u is d’u i e sit d’Illi oise alise u e spécification d’u ou eau
système de courriel basant sur le service web, ce système est implémenté en .NET
technologie. La ré-conception de système de courriel basant sur service web cause le
ou eau s st e ait des a a tages de se i e e o e la fle i ilit , l’e te si ilit et
sp iale e t l’e ploitatio des sta da ds de s u is s dispo i les da s le ad e se i e e .
L’ uipe de d eloppement a vérifié le sécurisé du protocole en utilisant l’outil TulaFale et
ProVerif (vient de projet Samoi du Microsoft). Dans mon travail, je vous présente une
modélisation en langage HLPSL et une vérification du protocole WSE ail e utilisa t l’outil
AVISPA.

I. Etat de l’art
Dans cette partie, j’a o de ais quelques caractéristiques principales de service web et les
rôles de service web dans un système WSEmail. Ensuite, on continuera avec des attaques
populaires comme « réécriture » (rewriting) ou « l’ho e au ilieu » (man in the middle)
et u e petite i t odu tio d’outil AVISPA utilis pou ifi le s u is d’u p oto ole.

1. Principe de service web

Le service web est un ensemble des standards fournissant la communication entre des
systèmes différents avec des langages différences. Il base sur le standard XML et consiste de
trois standards principaux :
SOAP (Simple Object Access Protocol) permet la transmission de message entre
objets distants, il autorise un objet à invoquer des méthodes d'objets physiquement
situés sur un autre serveur.
WSDL (Web Services Description Language) décrit une interface publique d'accès à
un service web.
UDDI (Universal Description, Discovery Integration) permet de localiser sur le réseau
le service web recherché.

|1
O t ou e ue le p o essus d’ ha ge de do es da s u as si ple da s la figu e i-
dessous. Le client et le serveur échange des données (des requêtes et des réponses) par le
message SOAP. Ce type de message est envoyé et reçu via une connexion de HTTP/HTTPS.

Port de connexion (URL)

Pare-feu Pare-feu
Messages
Procuration Appel Translateur
SOAP
d'interface SOAP
Application HTTP/
Cliente HTTPS

RPC

Réponse local

Parser Parser
Serveur
XML XML
d'application

CLIENT SERVEUR

Fig1.1 - Echange de messages entres des

participants
On a les caractéristiques principales de service web

Le service web utilise le format XML pour rep se te le do , ’est u fo at t s

populaire et bien supporté par des plateformes différentes qui provoque une
interopérabilité pour l’appli atio se i e e .
Un client est indépendant du serveur, cela veut dire que quand l’i te fa e de se i e
web change, le client ne doit pas change pour pouvoir fonctionner normalement.
Cette a a t isti ue ause l’appli atio de service web plus facile à gérer et plus
si ple da s l’i t g atio e t e des s st es diff e ts
Le se i e e fou it les t pe d’i o atio s h o is et as h o e. Dans le
ode s h o is , le lie t lo ue et atte de jus u’à la fi d’e utio de service
avance les exécutions des autres fonctions. Dans le mode asynchrone, le client peut
invoquer le service et exécuter autres fonctions et recevoir le résultat au plus tard.
Le service web permet au lie t d’i o ue des p o du es, des fo tio s et des
thodes à dista e L’i o atio à dista e, RPC e utilisa t un pile des protocoles
base sur XML. Le développement ui suit l’a hite tu e composants orientés qui
utilise la technologie Enterprise JavaBeans (EJB) et .NET est le plus populaire dans le
déploiement de service web.

|2
 Le se i e e pe et d’ ha ge des do u e ts. Un des principaux avantages de
XML est sa façon générique de représenter non seulement des données, mais aussi
des documents complexes. Ces documents peuvent être simples, ex : représentation
d’une adresse actuelle, ou ils peuvent être complexes, la représentation d’un livre
entier. Les services web permettent un échange de documents transparent qui
destine à faciliter l'intégration des affaires.

2. Service web sécurisé

WS-Security est une spécification supplémentaire de sécurité pour le service web. Elle a été
développée originellement par IBM, Microsoft, VeriSign, le protocole est maintenant
offi ielle e t appel WSS et est d elopp pa l’o ga isatio OASIS. Le f ie , e
consortium a lancé la version 1.1 de cette spécification

2.1 Protocole sécurité du SOAP

WSS définir un ensemble d’e te sio s du SOAP pour implémenter la sécurité sur des
messages échangés. Dans ce modèle, les messages XML contiennent les informations
d’ide tifi atio , les sig atu es u i ues ui peu e t t e hiff es pou ut d’assu e
l’i t g it et o fide tialit de do e. O l’appelle jeto de s u it .

Fig1.2 - Sécurité au niveau du message

Pour former le jeton de sécurité on peut utiliser certificats X.509, tickets Kerberos, jetons
XML comme SAML, XrML.
La signature numérique des messages pour assurer leur intégrité en vérifiant par
ptog aphie ue le essage SOAP ’a pas t alt depuis u’il a t sig e se fo da t
sur le standard XML Sig atu e, d fi i pa le W C. Pou sig e le essage SOAP, l’ etteu a
besoin de sa clé privée et pour que le récepteur puisse vérifier la signature du message
SOAP, il a esoi de la l pu li ue de l’ etteu Figu e 1.3). On peut aussi chiffrer
le message en utilisant la clé publique du destinataire, et déchiffrer en utilisant sa clé privée
pour garantir la confidentialité des échanges [7] (Figure 1.4).

|3
 Fig1.3 - Sig atu e d’u essage SOAP Fig1.4 - Chiff e e t d’u essage SOAP

2.2 Protocole Single Sign-on SAML

U e des aiso s ue l’o utilise le p oto ole « Single Sign On » (SSO) est pour limiter le
o e d’appli atio utilisa t le se i e e . U e appli atio dois t e ifi e
l’authe ti it a a e l’utilise. SAML est u sta da d supporté par un grand nombre de
solutions de SSO pour les problèmes de gestion d'identité. SAML 2.0 est la version la plus
e te ui est d elopp pa l’o ga isatio OASIS. Le figu e 1.5 décrit le en détails le
processus au début quand le client veut utiliser le service web au moment il est servit ou
rejeté par le fournisseur.
Enhanced Client Service Provider Identity Provider
or Proxy (ECP) (SP) (IP)

J’ai un contexte de
1. ECP essaie d'accès de certaines sécurité pour ce ECP?
ressources au fournisseur de service Non? Etablit un !!!

2. créer un message <AuthnRequest>

en utilisant PAOS binding
3. Chercher le IP
4. créer un message <AuthnRequest>
en utilisant SOAP binding

5. IP vérifie le ECP

6. IP crée un message <Response>

pour ECP en utilisant SAML SOAP
binding

7. ECP envoie message <Response>

au SP en utilisant PAOS binding

8. soit SP retourne la ressource ou

d'une erreur (HTTP), dans une
réponse HTTP

Figure 1.5. Séquence des messages échangés

|4
3. Introduction d’un système WSEmail
Service web email (WSEmail) est dressé basant sur la fondation de service web pour
e ploite ses a a tages o e l’i te op a ilit , la fle i ilit e t e des s st es dist i u s
su l’i te et, la fle i ilit , les sta da ds, les a is es de s u is ui so t d elopp s
en avance. Les messages échangés dans WSEmail sont les messages de SOAP sécurisés qui
soutient l'intégrité, l'authentification et le contrôle d'accès de bout en bout.
La plate-forme WSEmail soutient la mise à jour dynamique des protocoles de messagerie
pour le client MUA (Mail User Agent) et le serveur MTA (Mail Transfer Agent). Cette
flexibilité aussi soutient des nouveaux protocoles de sécurisé, plus riches en routage de
message (telles que le routage basé sur la sémantique d'un message), et intégration étroite
avec les formes différents dans la communication comme la messagerie instantanée. La
conception de WSEmail est une compromise entre la flexibilité du système avec le
problème de sécurisé et le problème de performance.
Les avantages du système WSEmail sont

La compatibilité avec autres système de courriel

Le sécurisé est assuré par le développement de standard de sécurisé de service web
La fle i ilit d’u a hite tu e d a i ue, la fa ilit de is à jou le s st e
La du tio da s les tapes d’ ha ge des essages a e pi e joi te a e l’aide de
protocole « on-demand attachement »
On peut voir les avantages du système WSEmail plus claire dans les parties suivantes.

4. Architecture du système WSEmail

Fig 1.6 - L’a hite tu e glo al d’u s st e WSE ail

|5
En générale, les opérations dans un système WSEmail sont similaire en comparaison avec
un système de courriel traditionnel (utilisé les protocoles POP, SMTP, IMAP). Un MUA (Mail
Use Age t d’e p diteu de a de au le MTA Mail T a sfe Age t de serveur
d’e p diteu d’e o e le essage M1. La demande de SC1 est o pos da s le o ps d’u
essage de SOAP, l’e -tête de ce message contient autres informations comme les
paramètres de sécurisé. M1 est aussi structuré sous forme XML qui contient un en-tête de
sujet, d’e p diteu , de epteu s, des contenus de essage …
Après recevoir la demande de SC1, SS continue à envoyer au serveur de récepteur RS le
ou iel de do ai e d’e p diteu SD e s le domaine de récepteur RD.
Quand Le récepteur RC veut examiner la boîte de réception, il demande au RS pour requérir
des nouveaux messages ou pour télécharger le contenu de lesquels. Dans ce cas, RC
de a de au RS pou o te i l’e t te de M1 et après, il va requérir le contenu de M1 s’il est
nécessaire.
La o eptio de WSE ail est as su l’a hite tu e ou hes en combinaison avec un
s st e d’e te sio . La première couche fournit un a is e d’authe tifi atio as e
sur le mot de passe, la clé publique ou le t a e d’ide tit f d ale pou les utilisateurs
(MUAs). La deuxième couche fournit un mécanisme d’authentification basée sur la clé
publique, le certificat numérique pour les serveurs (MTAs). La troisième couche utilise le
certificat racine (root certificat). En générale, le message de SC1 à RC va être chiffré par une
signature XMLDSIG à SS ce qui est vérifié par RS et RC.
Une des avantages de WSEmail est l’i t g atio et la fle i ilit du mécanisme
d’authe tifi atio de MUA et la capacité d’ajoute d a i ue e t des ou elles fo tio s
sécurisées pour MTA et MUA. Dans la figure 4.1, on peut observer une extension du
protocole quand SC2 ’est pas da s le do ai e SD, ais il eut e oie un message
instantané à RC. Dans ce cas, premièrement, il demande à SS pour obtenir une trame de
sécurisé T ui est o ue pa RS. Qua d il l’a eçu, SC e oie le message M2 authentifié en
utilisant cette trame à RS et a ue da s l’e t te de essage SOAP pou ue RS et RC le
traitent comme message instantané. Ce message est envoyé directement de RS à RC. RS et
RC peuvent authentifier ce message baser sur le trame de sécurisé de SC à cause d'un
arrangement préalable entre SS et RS.
MUA et MTA da s u s st e WSE ail ase su l’a hite tu e de plugi des extensions
dynamiques [11]. La sécurisé est assuré par les mécanismes fournis par la politique du
service web. Le plugin est une libraire de codage qui corresponde aux certains interfaces qui

|6
est o u pa le se eu i pl e te l’i te fa e IServerPlugin). Au ou s d’i itialisatio , le
serveur traverse une liste de plugin dans le fichier de configuration et les charge. Le serveur
essaie de t ou e le plugi est l’i itialise . Si le ha ge e t est ussit, le se eu
demandera un complément de données de configuration du plugin et utiliser cette
information pour placer le plugin dans la file d'attente d'exécution. Le processus de
chargement ou de déchargement des plugins est totalement dynamique et peut survenir à
tout moment. En outre, la priorité des exécutions dans la file d'attente peut être changé ou
désactivé quand le serveur est en cours d'exécution.

.
Fig 1.7 – Architecture de type plugin

|7
Architecture de client
La figure 4.3 montre les modules implémentés sur le client :
T ois odules du œu de lie ts so t des modules pour recevoir, lire et composer
des messages.
Le module WSEmail Proxy s’o upe de pa kager des données locales sous forme des
requêtes de SOAP.
Le odule d’authe tifie le se eu lo al e utilisa t le e tifi at u i ue, le
certificat fédéral ou le mot de passe pré-partagé.
Le module pour découvrir et télécharger des plugins et mettre à jour le système à
côté de client.

Fig 1.8 – Architecture de client

|8
Architecture de serveur
Les serveurs ont des fonctions de recevoir et transférer des messages aux clients ou aux
autres serveurs. Ils sont capables de découvrir autres serveurs en utilisant la base de
données de serveur DNS. Dans un système WSEmail, il y a un serveur de base de données
qui stocker tous les messages et les pièces jointes.
Les modules implémentés sur le serveur WSEmail sont

Le module pour interconnecter avec le serveur de base de données et le serveur

DNS.
Le odule pou ui s’adapte au aut es p oto oles a ie s de ou iels o e POP
ou IMAP.
Les modules pour gérer des messages.
Les plugins qui sont activés pendant le démarrage du système.

Fig 1.9 – Architecture de serveur

|9
5. Attaque sur le service web

Attaque de réécriture
Da s e t pe d’atta ue, o suppose ue l'i t us peut i te pose toutes les lig es de
communication, et peut donc intercepter, décomposer, modifier le message, et le renvoyer.
Et puis, le protocole de cryptographie est solide et ne peut pas être cassé.
A envoie à B un essage, M l’i te epte et le odifie sa s ass le p oto ole de s u it .

Fig1.10 - Réécriture du message

Dans le cas de service web, A envoie à B un message SOAP sécurité, M ne cassé pas le
protocole mais seulement ajouter des informations dans le message SOAP pour tromper le
SOAP translateur de service web [6]. O peut oi plus lai e da s l’e e plai e suivant
Au dessous, ’est u essage SOAP MWSE Mi osoft We Se i es E ha e e ts en
réalité
<Envelope>
<Header>
<Security>
<UsernameToken Id=1>
<Username>"Alice"
<Nonce>"mTbzQM84RkFqza+lIes/xw=="
<Created>"2004-09-01T13:31:50Z"
<Signature>
<SignedInfo>
<SignatureMethod Algorithm=hmac-sha1>
<Reference URI=#2>
<DigestValue>"U9sBHidIkVvKA4vZo0gGKxMhA1g=“
<SignatureValue>"8/ohMBZ5JwzYyu+POU/v879R01s="
<KeyInfo>
<SecurityTokenReference>
<Reference URI=#1 ValueType=UsernameToken>
<Body Id=2>
<StockQuoteRequest>
<symbols>

| 10
 <Symbol>"FABRIKAM"
<Symbol>"CONTOSO"

L’e t te <Security> définit par OASIS WS-Security 2004 o tie t u jeto d’ide tit , d’u e
signature, et un partie de message chiffré
UsernameToken pour indiquer les deux partie connais le mot de passe p de Alice.
DigestValue est un hash d’u URI
SignatureValue est al ul pa l’e p essio hmacsha1(key, SignedInfo) avec
key psha1(p+nonce+created).

Le message suivant indique: « Transférer $1000 à Bob, signé par Alice »

<Envelope>
<Header>
<Security>
<UsernameToken Id=2>
<Username>Alice</>
<Nonce>cGxr8w2AnBUzuhLzDYDoVw==</>
<Created>2003-02-04T16:49:45Z</>
<Signature>
<SignedInfo>
<Reference URI= #1><DigestValue>Ego0...</>
<SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</>
<KeyInfo>
<SecurityTokenReference><Reference URI=#2/>
<Body Id=1>
<TransferFunds>
<beneficiary>Bob</>
<amount>1000</>

La banque peut vérifier la signature en utilisant la clé générée par le mot de passe de Alice.
L’i t us i te epte le message et ajoute plus des informations marqués en rouge dans le
dessin suivant. Le o te u est a he da s le BogusHeade ais l’i fo atio est peut être
encore valide. Il existe une possibilité que le parseur de XML examine la validation de
signature en utilisa t et i fo atio la ais utilise l’i fo atio da s le Bod ajout pou
réaliser le transaction. Alo s le ot de passe ’est pas ass mais le contenu du message est
changé complètement « Transférer $5000 à Eve, signé par Alice »

| 11
<Envelope>
<Header>
<Security>
<UsernameToken Id=2>
<Username>Alice</>
<Nonce>cGxr8w2AnBUzuhLzDYDoVw==</>
<Created>2003-02-04T16:49:45Z</>
<Signature>
<SignedInfo>
<Reference URI= #1><DigestValue>Ego0...</>
<SignatureValue>vSB9JU/Wr8ykpAlaxCx2KdvjZcc=</>
<KeyInfo>
<SecurityTokenReference><Reference URI=#2/>
<BogusHeader>
<Body Id=1>
<TransferFunds>
<beneficiary>Bob</>
<amount>1000</>
<Body>
<TransferFunds>
<beneficiary>Eve</>
<amount>5000</>

Attaque l’homme au milieu

Dans ce type d’atta ue, o suppose ue l'i t us peut i te pose toutes les lig es de
communication, et peut donc intercepter, décomposer, modifier le message, et le renvoyer.
Et puis, l’i t us sait toutes les l s pu li ues, il a des o aissa es de thodes de
chiffrage et de déchiffrage du message.
L’id e p i ipale de e t pe d’atta ue est ue l’i t us i te epte tous les essages de A et B
comme suivant :
1. A : « C’est oi Ali e, j’ai hoisit u No e NA, C peut d hiff e e
message seulement »

2. I : L’i t us i te epte le message et parle à B « C’est oi A, j’ai hoisit u No e NA,

B peut déchiffrer ce message seulement »

3. B : « Voila ta valeur Nonce NA, je peux le lit alo s ’est toi A ui eut pa le a e
oi, j’ai hoisit aussi u No e NB, A peut d hiff e e essage seulement »

4. I : L’i t us t a sf e si ple e t le essage à A

| 12
 5. A : « Tu ’as e o u No e, Je te le e oie pou p ou e ue je peu le lit,
alors je dois être A, C peut déchiffre ce message seulement »

6. I : L’i t us i te epte le essage et pa le à B « Tu ’as e o u No e, Je te le

renvoie pour prouver que je peux le lit, alors je dois être A, B peut déchiffre ce
message seulement »

Fi ale e t, B oit u’il est e t ai de pa le à A

Fig1.11 - Needham-Sh oede authe ti it est ass e pa l’atta ue « l’ho e au ilieu »

6. Outil AVISPA
AVISPA (Automated Validation of Internet Security Protocols and Applications) est un outil
servant à analyser des protocoles de sécurité. AVISPA fournit un langage formel expressif
basé sur les rôles pour la spécification de protocole et il intègre quatre différents back-end,
qui effectuent l'analyse du protocole. Ils sont
On-the-fly Model-Checker (OFMC): pou ut d’a al se la s u is du protocole
basant sur deux méthode [14] : types de donnée paresseux (lazy data-types) dans
l’espa e d’ tat infinité. Aut e thode est l’i t g atio de te h i ues s oli ues
pou od lise u l’i t us su le haî e Dole -Yao dont les actions sont générés sur
demande
CL-based Attack Searcher (CL-AtSe): verifier le sécurisé du protocole face à un
l’i t us Dole –Yao da s u e ou le a e le o e d’ tape li it d id pa
l’utilisateu . Ce « back-end » optimise le processus de vérification en simplifiant la
spécification du protocole, et rejet des infor atio s edo da tes da s l’e utio .
SAT-based Model-Checker (SATMC) [15]: éffectuer une analyse délimitée du
problème en envisageant des scénarios avec un nombre finit de session où les
essages ha g s su u e haî e o t ôl e pa l’i t us Dole -Yao.

| 13
 Tree-Automata-based Protocol Analyzer (TA4SP): pour estimer la connaissance de
l’i t us e utilisa t u a e de la gage. Cette méthode permet de savoir si un
e tai tat est a essi le ou o et ue l’i t us peut sa oi e tai o aissa e ou
non.

Le protocole doit être traduit en le la gage HLPSL a a e d’utilise es outils pour vérifier la
sécurité face aux attaques.

Figure 1-12. L’a hite tu e de l’outil AVISPA

| 14
II. Modélisation du protocole WSEmail
Dans cette partie, je vous vais détailler le protocole utilisé dans WSEmail et la modélisation
en langage HLPSL pour vérifier la sécurisé de ce protocole sur le chaîne Dolev-Yao où
l’i t us a oi le puissa t d’i te epte de d o pose et odifie tous les essages.

1. Protocole WSEmail
Pour que les expressions soient plus cours possible, on a des abréviations comme suivant
Da s le as o utilise l’authe tifi atio a e la clé publique et le Nonce :

[1] On écrit A B: M (pkey , r, t) pour indiquer que A envoie à B un message sous forme:
A | M | r | t | S (pubkey( ), H (A | M | r | t)). Dans cette expression t est le temps mesuré
sur A et r est un nombre aléatoire choisi par A. B traite ce message en vérifiant les
conditions suivantes en ordre:
Le temps t ’est pas plus que d'un certain seuil
La validation du certificat jusqu'à le moment traité en utilisant la clé public de
Le nonce r n'est pas repris dans le cache de B.
Dans les quelles, est le certificat numérique de A, S est une fonction de signer le message
en utilisant le PKI, H est une fonction de hash. Si toutes les conditions sont réussites, r est
ajouté à la reprise cache avec une date d'expiration déterminée par un certain seuil. Dans
ce cas, on dit le message est valable. Si l'un de ces vérifications échoue, les étapes restantes
sont abolies et le message est jeté.
Dans le cas on utilise la clé pré-partagée :
[1] On écrit A B: M (pswd P, r, t) si A envoie à B un message qui suit le forme
A| M | r | t | MAC(P, A | M | r | t). Dans cette expression t est le temps mesuré sur A et r
est un nombre aléatoire choisi par A. B traite ce message en vérifiant les conditions
suivantes en ordre:

le temps t ’est pas plus que d'un certain seuil

le nonce r ’est pas repris dans le cache de B
la valeur MAC est correcte pour le mot de passe associé avec A.
Si l'un de ces échoue ensuite les étapes restantes sont abolis et le message est jeté. Si
toutes les conditions sont réussites, r est ajouté à la reprise cache avec une expiration
temps déterminé par un certain seuil. Dans ce cas, le message est valable.

| 15
Le p o essus d’ ha ge d’u message est décrit dans la figure ci-dessous [1].

Fig 2.1 Le protocole WSEmail

Un système WSEmail fonctionne comme un système de courriel. Il y a au moins 4 parties

pa ti ipe t da s le p o essus d’ ha ge des messages:

SC (Sender’s Clie t est le lie t ui e oie le essage l’e p diteu

SS (Sender’s Server) est le serveur qui reçoit le message de SC, comme un serveur
courriel relais
RC (Receiver’s Client) est le destinataire, le client qui reçoit le courriel
RS (Receiver’s Server) est le serveur de RC (le récepteur)

L’authe tifi atio e t e SS, SC ou RS, RC est réalisée simplement par le mot de passe (PSC et
PRC)
L’authe tifi atio e t e SS, RS ou SS, RC est alis e pa le e tifi at digital ( SS , RS , RC )

| 16
O peut su e la fo tio alit d’u s st e WSE ail o e sui a t:

SC veut envoie un message avec la pièce jointe à RC

Etape 1 : SC envoie le message avec la pièce jointe à SS. SS authentifie SC par le mot
de passe pré partagé.
Etape 2 : SS crée un référence de pièce jointe, et envoie le message avec le
référence ver le RS. RS authentifie SS par un certificat digital
Etape 3 : RS crée une f e e du essage u’il a eçu, envoie une notification qui
contient la référence à RC. RC authentifie RS par le certificat digital
Etape 4 : Si RC veut retriever le message, il envoie un requête vers le RS
Etape 5 : RS réponse avec la f e e u’il a reçue de SS
Etape 6 : Optio elle a e tape , Si le RC ’est pas u e tifi at, il e oie u
message vers le RS pour obtenir un certificat fédéral
Etape 7 : Optionnelle avec étape 6, Si le RS reçoit une trame qui contient la clé
pu li ue de RC, il g e u e tifi at et l’e oie à RC. RC a etie t e e tifi at
pou u’il puisse utiliser plus tard
Etape 8 : RC envoie un message contient le référence de pièce jointe vers SS. SS va
vérifier RC par le certificat.
Etape 9 : SS envoie à RC la pièce jointe.

A chaque étape, s’il e iste u essage ui ’est pas ala le, toutes les autres étapes sont
abolies.

On a le la modélisation sous forme A-B

1. SC -> SS : SS | (RC|RS) | M | N (pswd Psc, r1, t1)

2. SS -> RS : RS | (RC|RS) | M | (SS|U*) (pkey ss, r2, t2)
3. RS -> RC : RC | (RC|RS) | V* (pkey rs, r3, t3)
4. RC -> RS : RS | V* (pswd Prc, r4, t4)
5. RS -> RC : RC | V*| (SS|U*) (pkey rs, r5, t5)
6. RC -> RS : RS | token(K) (pswd Prc, r6, t6)
7. RS -> RC : RC | rc
8. RC -> SS : SS | U* (pkey rc, r7, t7)
9. SS -> RC : RC | U* | N (pkey ss, r8, t8)

| 17
Dans les quelles
SS, SC, RS, RC sont des participants
M est le message
N est la pièce jointe
U* est le référence de pièce jointe créé par SS
V* est le référence de message et de la pièce jointe envoyés par SS

2. Modélisation en langage HLPSL

Comme spécifié dans la description du protocole, on va implémenter 4 rôles ce sont le rôle
d’e p diteu SC , le ôle de se eu d’e p diteu SS , le ôle de se eu de epteu RS
et le rôle de récepteur (RC).
Dans ce modélisation, on suppose que

RC a obtenu le certificat fédéral a a e, alo s il ’au a pas l’ tape et .

On utilise une fonction hash (ou un chiffrement utilisant le clé symétrique) pour
générer la référence de pièce jointe à SS et RS.
Il a deu t pe d’i t us : l’i t us e te e la o aissa e de e t pe d’i t us se
o pose des pa ti ipa ts, des l s pu li s des pa ti ipa t et l’i t us i te e u
utilisateu de s st e a e u e ase de o aissa e o e l’i t us e te e et les
autres informations comme son certificat numérique, un mot de passe, la fonction
MAC et la fonction H pour générer le hash qui sont utilisés dans le processus
d’authe tifi atio )

| 18
Les messages échangés entre des participants sont en ordre comme suivant
1. SC->SS :
SC.SS.RC.RS.Msg.Attc.N1.T1.MAC(PwdSC.SC.SS.RC.RS.Msg.Attc.N1.T1)
2. SS->RS :
SS.RS.RC.RS.Msg.RefSS.N2.T2.{PkSS.Hash(SS.RS.RC.RS.Msg.RefSS.N2.T2)}_inv(P
kSS)
3. RS->RC :
RS.RC.RC.RS.RefRS.N3.T3.{PkRS.Hash(RS.RC.RC.RS.RefRS.N3.T3)}_inv(PkRS)
4. RC->RS :
RC.RS.RefRS.N4.T4.MAC(PwdRC.RC.RS.RefRS.N4.T4)
5. RS->RC :
RS.RC.RefRS.RefSS.N5.T5.{PkRS.Hash(RS.RC.RefRS.RefSS.N5.T5)}_inv(PkRS)
6. RC->SS :
RC.SS.RefSS.N7.T7.{PkRC.Hash(RS.SS.RefSS.N7.T7)}_inv(PkRC)
7. SS->RC :
SS.RC.RefSS.Attc.N8.T8.{PkSS.Hash(SS.RC.RefSS.Attc.N8.T8)}_inv(PkSS)

Fig2.2 – L’e utio de WSE ail

Tous les authentifications réalisés sont unilatérales, cela veut dire, seulement le récepteur
authe tifie l’e p diteu .

| 19
III. Expérimentation et évaluation
Da s ette pa tie, je ais o t e uel ues sultat des testes ue j’ai alise su le
protocole WSEmail dans quelques scénarios

1. Scénario 1

1.1 Pré-conditions
Il existe un intrus externe
On vérifier le secret de contenu de message, de pièce jointe, ces informations là est
disponible seulement entre SC, SS, RC.
La fonction pour générer la référence de pièce jointe sur les serveurs est une fonction de
hash.

1.2 Analyser du résultat

La t a e d’atta ue est o t e o e sui a t
% OFMC
% Version of 2006/02/13
SUMMARY
UNSAFE
DETAILS
ATTACK_FOUND
PROTOCOL
/home/avispa/web-interface-computation/./tempdir/workfiler22851.if
GOAL
secrecy_of_sec_attc
BACKEND
OFMC
COMMENTS
STATISTICS
parseTime: 0.00s
searchTime: 0.05s
visitedNodes: 0 nodes
depth: 0 plies
ATTACK TRACE
i -> (sc,3): start
(sc,3) -> i:
sc.ss.rc.rs.Msg(1).Attc(1).N1(1).T1(1).mac(pwsc.sc.ss.rc.rs.Msg(1).Attc(1).N1
(1).T1(1))
i -> (i,17): Attc(1)

| 20
Le résultat est facile à prévoir, a e la puissa e d’i t us su la haî e Dole -Yao, le point
faible trouvé tout de suite après la première exécutio . L’i t us i te epte le essage et le
décompose pour avoir le contenu de courriel et la pièce jointe.

Fig3.1 – T a e d’atta ue d’u i t us e te e su le se et de o te u de essage

2. Scénario 2

2.1 Pré-conditions
Il existe un intrus interne
On vérifier le secret de contenu de message, de pièce jointe, ces informations là est
disponible seulement entre SC, SS, RC.
La fonction pour générer la référence de pièce jointe sur les serveurs est une fonction de
hash.

2.2 Analyser du résultat

Le résultat obtenu est le même du as l’i t us e te e
% OFMC
% Version of 2006/02/13
SUMMARY
UNSAFE
DETAILS
ATTACK_FOUND
PROTOCOL
/home/avispa/web-interface-computation/./tempdir/workfilesu3082.if
GOAL
secrecy_of_sec_attc
BACKEND

| 21
 OFMC
COMMENTS
STATISTICS
parseTime: 0.00s
searchTime: 0.04s
visitedNodes: 0 nodes
depth: 0 plies
ATTACK TRACE
i -> (sc,3): start
(sc,3) -> i:
sc.ss.rc.rs.Msg(1).Attc(1).N1(1).T1(1).mac(pwsc.sc.ss.rc.rs.Msg(1).Attc(1).N1
(1).T1(1))
i -> (i,17): Attc(1)
i -> (i,17): Attc(1)

Fig3.2 – T a e d’atta ue d’u i t us i te e su le se et de o te u de essage

3. Scénario 3

3.1 Pré-conditions
Il existe un intrus externe (un utilisateur légal du système)
On ignore le secret de contenu et la pièce jointe pour examiner l’authe tifi atio e t e des
participants.
La fonction pour générer la référence de pièce jointe sur les serveurs est une fonction de
hash.
Le teste est réalisé avec trois sessions parallèles

| 22
3.2 Analyse du résultat
Le teste est réalisé Avec les trois sessio s pou u i t us e te e, l’authe tifi atio ’est pas
cassée.
SUMMARY
SAFE
DETAILS
BOUNDED_NUMBER_OF_SESSIONS
UNTYPED_MODEL
PROTOCOL
D:\Programs\SPAN\testsuite\results\WSEmailv2_1_0.if
GOAL
As Specified
BACKEND
CL-AtSe
STATISTICS
Analysed : 16725 states
Reachable : 2683 states
Translation: 0.23 seconds
Computation: 1.70 seconds

4. Scénario 4

4.1 Pré-conditions
Il existe un intrus externe (un utilisateur légal du système)
On ignore le secret de contenu et la pièce jointe pour e a i e l’authe tifi atio e t e des
participants.
La fonction pour générer la référence de pièce jointe sur les serveurs est une fonction de
hash.
Le teste est réalisé avec quatre sessions parallèles

4.2 Analyse du résultat

Le teste est alis A e les t ois sessio s pou u i t us e te e, l’authe tifi atio ’est pas
cassée.

| 23
5. Scénario 5

5.1 Pré-conditions
Il existe un intrus interne (un utilisateur légal du système)
On ignore le secret de contenu et la pièce jointe pour exa i e l’authe tifi atio e t e des
participants.
La fonction pour générer la référence de pièce jointe sur les serveurs est une fonction de
hash.

5.2 Analyse du résultat

Co e o t e da s la t a e d’atta ue, le p oto ole est ul a ilit da s la deu i e
authentification.
SUMMARY
UNSAFE
DETAILS
ATTACK_FOUND
UNTYPED_MODEL
PROTOCOL
D:\Programs\SPAN\testsuite\results\WSEmailv2_2_0.if
GOAL
Authentication attack on (rs,ss,ss_rs_n2,N2(21))
BACKEND
CL-AtSe
STATISTICS
Analysed : 7842 states
Reachable : 1290 states
Translation: 0.16 seconds
Computation: 1.25 seconds
ATTACK TRACE
i -> (sc,3): start
(sc,3) -> i: sc.ss.rc.rs.n1(Msg).n1(Attc).n1(N1).n1(T1).
{pwsc.sc.ss.rc.rs.n1(Msg).n1(Attc).n1(N1).n1(T1)}_mac
& Witness(sc,ss,sc_ss_n1,n1(N1));
& Witness(sc,ss,sc_ss_t1,n1(T1));
i -> (ss,9): i.ss.rc.rs.Msg(21).RefSS(21).N2(21).Attc(17).N1(17).T1(17).
{pwin.i.ss.rc.rs.Msg(21).RefSS(21).N2(21).Attc(17).N1(17).T1(17)}_mac
& Test T1(17) not in dummy_set;
(ss,9) -> i:
ss.rs.rc.rs.Msg(21).RefSS(21).N2(21).{Attc(17)}_mkrefss.n17(N2).
n17(T2).{pkss.{ss.rs.rc.rs.Msg(21).RefSS(21).N2(21).{Attc(17)}_mkrefss.n17(N2
).n17(T2)}_hash_}_(inv(pkss))
& Witness(ss,rs,ss_rs_n2,n17(N2));

| 24
 & Witness(ss,rs,ss_rs_t2,n17(T2)); Add T1(17) to dummy_set;
i -> (rs,10):
ss.rs.rc.rs.Msg(21).RefSS(21).N2(21).{Attc(17)}_mkrefss.n17(N2).n17(T2).
{pkss.{ss.rs.rc.rs.Msg(21).RefSS(21).N2(21).{Attc(17)}_mkrefss.n17(N2).n17(T2
)}_hash_}_(inv(pkss))
& Test {Attc(17)}_mkrefss.n17(N2).n17(T2) not in dummy_set;
(rs,10) -> i:
rs.rc.rc.rs.{Msg(21).RefSS(21)}_mkrefrs.n21(N3).n21(T3).{pkrs.{rs.rc.rc.rs.{M
sg(21).RefSS(21)}_mkrefrs.n21(N3).n21(T3)}_hash_}_(inv(pkrs))
& Witness(rs,rc,rs_rc_n3,n21(N3));
& Witness(rs,rc,rs_rc_t3,n21(T3));
& Request(rs,ss,ss_rs_n2,N2(21));
&
WRequest(rs,ss,ss_rs_t2,{Attc(17)}_mkrefss.n17(N2).n17(T2));
& Add {Attc(17)}_mkrefss.n17(N2).n17(T2) to dummy_set;

Da s le de ie essage da s le t a e d’atta ue au dessous, RS e oie à RC le f e e de

pi e joi te o pl te e t diff e e de essage o igi ai e alRefSS, da s l’ tape de la
modélisation sous forme HLPSL). RC reçoit ces informations là sans doute, alors il y a un
dangereux potentielle à côté de RC. De plus, quand RC envoie le message pour retenir la
pièce jointe de SS (étape 6), la valeur malReffSS va être traité sous SS, Il y a plusieurs
conséquences : soit SS va envoyer une pi e joi t ui ’appa tie t pas à le essage
o igi ai e, soit SS est ul a ilit pa l’i o datio de ta po ua d il t aite u e al
aleu de f e e …

Fig3.1 – T a e d’atta ue d’u i t us i te e su l’authe tifi atio

| 25
Analyse de t a e d’attaque
i -> (sc,3): start
sc,3) -> i: sc.ss.rc.rs.n1(Msg).n1(Attc).n1(N1).n1(T1).
{pwsc.sc.ss.rc.rs.n1(Msg).n1(Attc).n1(N1).n1(T1)}_mac
& Witness(sc,ss,sc_ss_n1,n1(N1));
& Witness(sc,ss,sc_ss_t1,n1(T1));
SC->I(SS) : SC.SS.RC.RS.Msg.Attc.N1.T1.{SC.SS.RC.RS.Msg.Attc.N1.T1}_Mac

Le message se compose des identifiés des participants, un message et une pièce jointe et
deux valeur de Nonce. Et le hash des informations

i -> (ss,9):
i.ss.rc.rs.Msg(21).RefSS(21).N2(21).Attc(17).N1(17).T1(17).{pwin.i.ss.rc.rs.M
sg(21).RefSS(21).N2(21).Attc(17).N1(17).T1(17)}_mac
& Test T1(17) not in dummy_set;

I(SC)->SS:
I.SS.RC.RS.malMsg.malRef.malNonce.Attc.N1.T1.{I.SS.RC.RS.malMsg.malRef.malNon
ce.Attc.N1.T1}_mac

L’ide tifi de l’e p diteu est e pla pa l’ide tifi de l’i t us. Le essage o igi ai e Msg
est remplacé par malMsg.malRef.malNonce. Dans le pa tie d’a hite tu e, o a sait ue
que WSEmail basé sur service web, tous les messages est considéré comme message SOAP,
quand il y a plus de champs dans message SOAP, le parseur peut mal-traiter des champs
(I.5). Alo s, da s e as, l’i t us ajoute plus d’i fo atio pour tromper parseur de XML à SS
(ss,9) -> i:
ss.rs.rc.rs.Msg(21).RefSS(21).N2(21).{Attc(17)}_mkrefss.n17(N2).
n17(T2).{pkss.{ss.rs.rc.rs.Msg(21).RefSS(21).N2(21).{Attc(17)}_mkrefss.n17(N2
).n17(T2)}_hash_}_(inv(pkss))
& Witness(ss,rs,ss_rs_n2,n17(N2));
& Witness(ss,rs,ss_rs_t2,n17(T2)); Add T1(17) to dummy_set;

SS-> I(RS):
SS.RS.RC.RS.malMsg.malRef.malNonce.refAttc.N2.T2.{SS.RS.RC.RS.malMsg.malRef.m
alNonce.refAttc.N2.T2}

| 26
i -> (rs,10):
ss.rs.rc.rs.Msg(21).RefSS(21).N2(21).{Attc(17)}_mkrefss.n17(N2). n17(T2).
{pkss.{ss.rs.rc.rs.Msg(21).RefSS(21).N2(21).{Attc(17)}_mkrefss.n17(N2).n17(T2
)}_hash_}_(inv(pkss))
& Test {Attc(17)}_mkrefss.n17(N2).n17(T2) not in dummy_set;

I(SS) ->RS : SS.RS.RC.RS.malMsg.malRef.malNonce.refAttc.N2.T2.{

SS.RS.RC.RS.malMsg.malRef.malNonce.refAttc.N2.T2}

L’i t us e ha ge pas le essage, il transfert ce message à RS. Quand RS reçoit le message,

ce serveur traité le mal message, le mal référence de pièce jointe et considère le mal
message comme le message originaire, le mal référence comme le référence originaire,
malNonce comme la valeur de nonce généré par SS et le dernière partie de message
refAttc.N2.T2 comme T2.

Alo s l’authe tifi atio e t e SS et RS est ass o e o t e da s le essage sui a t, RS

envoi à RC des informations fraudes de message et de référence de pièce jointe.
(rs,10) -> i: rs.rc.rc.rs.{Msg(21).RefSS(21)}_mkrefrs.n21(N3).n21(T3).
{pkrs.{rs.rc.rc.rs.{Msg(21).RefSS(21)}_mkrefrs.n21(N3).n21(T3)}_hash_}_(inv(p
krs))
& Witness(rs,rc,rs_rc_n3,n21(N3));
& Witness(rs,rc,rs_rc_t3,n21(T3));
& Request(rs,ss,ss_rs_n2,N2(21));
& WRequest(rs,ss,ss_rs_t2,{Attc(17)}_mkrefss.n17(N2).n17(T2));
& Add {Attc(17)}_mkrefss.n17(N2).n17(T2) to dummy_set

IV. Conclusion
La pile de protocoles WSEmail est compliquée avec beaucoup de composants dans le
message échangé, alors le temps de vérification est long. Le processus de vérification que
l’ uipe de d eloppe e t est alis a he pe da t jou s a e l’aide de o sieu
Bruno Blanchet. Il a créé une version de Provérif qui s’adapte à la sp ifi atio , il ’ a eu
pas d’atta ue t ou . E od lisa t e p otocole en langage HLPSL, alg u’il existe
uel ues h poth ses ui ause t la od lisatio du p oto ole ’est pas o pl te, il e iste
des p o l es u’o doit fai e atte tio s pe da t le d eloppe e t d’appli atio
WSEmail. Il faudra investir plus sur la p ote tio du p oto ole fa e à t pe d’atta ue XML
réécriture.

| 27
Mo t a ail est li it su le p oto ole de ase de WSE ail, e ’est pas u e sp ifi atio
complète de la pile de protocoles. Il y a des scenarios que je ’ai pas sp ifi o e le
protocole AMPol pour sécuriser des messages avec le mécanisme dynamique. Dans
l’a hite tu e de WSE ail, il existe encore un aut e o posa t, ’est le se eu DNS. Da s
cette modélisation, le rôle de serveur DNS est transparent, mais dans le travail futur, on
peut spécifier plus détaillé su les ha ges d’i fo atio s e t e des MTAs et le se eu
DNS.

V. Appendice
Le fichier de code en HLPSL pour chaque scénario
1 Sénario 1 WSEmailv2_0_0.hlpsl Vérifier le secret de message
et la pièce jointe
2 Sénario 2 WSEmailv2_0_1.hlpsl
3 Sénario 3 WSEmailv2_1_0.hlpsl Vérifier la sécurisé de
mécanisme
4 Sénario 4 WSEmailv2_1_1.hlpsl
d’authe tifi atio
5 Sénario 5 WSEmailv2_2_0.hlpsl

| 28
VI. Références
[1] Kevin D. Lux, Michael J. May, Nayan L. Bhattad, and Carl A. Gunter - WSEmail: Secure
Internet Messaging Based on Web Services - University of Pennsylvania
[2] Raja Afandi, Jianqing Zhang, Munawar Hafiz and Carl A. Gunter - AMPol: Adaptive
Messaging Policy - University of Illinois
[3] David Basin - Model Checking Security Protocols using OFMC/AVISPA - ETH Zurich

[4] Laura Takkinen - Analysing Security Protocols with AVISPA - Helsinki University of
Technology

[5] Carl A. Gunter - Secure Web Services (SWS) - University of Illinois, Fall 2007
[6] Cédric Fournet - Vérification de Protocoles Cryptographique set de leurs
Implémentations - Centre de recherche commun INRIA, Microsoft

[7] V. Monfort et S.Goudeau – web service et interopérabilité des SI – Dunod, Paris,

2004

[8] AVISPA team - HLPSL Turorial v1.1 – June 2006

[9] Aberdeen group - The Ins and Outs of Email Vulnerability – July 2007
[10] E. Kleiner and A.W. Roscoe - On the relationship of traditional and Web Services
Security protocols

[11] Kevin Lux - WSEmail Applications - University of Pennsylvania, August 2005

[12] Yannick Chevalier, Denis Lugiez, Michael Rusinowitch - Towards an Automatic
Analysis of Web Service Security
[13] Karthik Bhargavan - Computer Security 463.6.2 Formal Methods - UIUC CS463,
Computer Security
[14] David Basin, Sebastian Modersheim, and Luca Vigano - An On-The-Fly Model-Checker
for Security Protocol Analysis - Department of Computer Science, ETH Zurich
[15] Alexandro Armando, Luca Compagna – SATMC a SAT-based Model Checker for
Security Protocol – AI lab, University of Genova, Italy.

| 29