PSECRES2017-Projet11-KHATOUN_RIDA-Secu_VoIP-RapFinal

Université Pierre et Marie Curie
Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
Sécurité de la VoIP
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
Encadrant : R. Khatoun,
Etudiants : B. Kaid, H. Mhira, S. Mansfeld,
B. Rigault
Table des matières
1 Introduction 1
2 Retranscrire une conversation chiffrée - Faille de confidentialité dans
VoIP 1
2.1 Idée de base et contexte de l’attaque . . . . . . . . . . . . . . . . . . . . . 1
2.2 Méthode détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.3 Résultats et déductions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
3 ZRTP : Echange D-H et protection MiTM pour SRTP 7
3.1 Définition et fonctionnement du protocole ZRTP . . . . . . . . . . . . . . . 7
3.1.1 Définition du ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2 Fonctionnement du ZRTP . . . . . . . . . . . . . . . . . . . . . . . 7
3.2 Attaques possibles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1 Attaque DoS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2 Attaques MiTM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.3 Vue d’ensemble pour le ZRTP . . . . . . . . . . . . . . . . . . . . . . . . . 11
4 L’attaque en pratique 12
5 Conclusion 13
Références 14
Annexe 1 15
Annexe 2 17
Glossaire 18
0/18 Rapport final

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
1 Introduction
e Ces dernières années, la voix sur IP (VoIP) est devenue de plus en plus populaire aussi
bien chez les entreprises pour sa facilité de mise en oeuvre que chez les particuliers pour
son coût extrêment faible (voire gratuit). VoIP est un ensemble de protocoles applicatifs
se basant sur IP et permettant de faire communiquer des individus en vocal ou en audio
visuel. C’est un système qui s’est montré comme une alternative à la téléphonie classique
(PSTN) et qui continue de se développer encore aujourd’hui. Cependant contrairement
au PSTN, l’ensemble des communications circulent sur un réseau libre d’accès, il convient
donc de mettre en place un certain nombre d’outils et de protocoles pour sécuriser et fia-
biliser les communications. On rappel que les enjeux principaux de toute communications
sécurisées sont la confidentialité, l’intégrité, l’authentification, la non-répudiation et la
disponibilité. Dans ce rapport, nous allons voir que les méthodes employées de nos jours
ne sont pas toujours suffisantes pour répondre à ces critères. Dans un premier temps nous
parlerons d’une faille de confidentialité dans le protocole SRTP, ensuite nous aborderons
le protocole ZRTP qui propose une alternative pour assurer l’authentification, l’intégrité
et la confidentialité lors de la mise en place d’une session VoIP. Enfin, nous montrerons
comment effectuer une attaque de type man in the middle sur la VoIP de manière pratique
dans la dernière partie.
2 Retranscrire une conversation chiffrée - Faille de confi-
dentialité dans VoIP
Cette section présentera brièvement une faille de confidentialité dans les conversations
VoIP. La présentation porte sur deux articles, d’abord celui de 2008 exposé au IEEE
Symposium on Security and Privacy [1] puis celui de 2011 également exposé pendant
cette même conférence [2]. On présentera notamment la méthodologie utilisée dans ce
second article celui-ci, bien que se basant sur des techniques similaires à l’article de 2008,
présentant une approche plus détaillée et généraliste.
2.1 Idée de base et contexte de l’attaque
Contrairement au PSTN, les informations d’une communication VoIP transitent sur un
réseau observable et accessible par tous. Pour assurer les services basiques de sécurité, une
communication VoIP a été cindée en deux connexions, une de contrôle et une d’échange
vocal. Les services de sécurité de la connexion de contrôle sont le plus souvent pris en
charge par le protocol SIP et ceux de la connexion vocale sont ordinairement gérés par
SRTP (RFC 3711 [3]). SRTP utilise un chiffrement symétrique pour échanger les paquets.
Une clé de session est donc échangée au début de la communication, l’échange de cette
clé étant lui-même chiffré soit à l’aide d’un secret partagé par les deux partis soit par un
Diffie-Hellman habituel. Il est important de noter que, puisque SRTP est conçu pour le
temps réel, l’algorithme de chiffrement utilisé doit à la fois optimiser le temps de calcul
1/18 Rapport final

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
et limiter l’usage de la bande passante tout en assurant un niveau de sécurité suffisant.
Pour cela, SRTP implémente diverses variantes de AES (128, 192 et 256 bit), AES ayant
l’avantage d’être un algorithme de chiffrement rapide et qui ne gonfle pas le payload des
paquets.
Cependant, la faille de confidentialité qui va être exposée ici ne va pas chercher à casser
ce chiffrement mais simplement utiliser les méta-données des paquets transmis. Quand un
interlocuteur parle dans son micro, sa voix est d’abord enregistrée sous la forme d’un
signal analogique puis numérisée par la carte son et enfin compressée par le codec avant
d’être chiffrée et encapsulée dans un paquet. Les codecs utilisés par la VoIP sont des
codecs optimisés pour la voix humaine, la plupart du temps QCELP ou Speex. L’objectif
de ces codecs est d’offrir un bon compromis entre taux de compression et qualité sonore.
Par défaut, les codecs pour la voix se basent sur un seul codebook. Un codebook est une
simple table de référence, chaque bloc de bits qui va être envoyé au codec sera retranscrit
comme une entrée dans cette table. Plus la table est grande, moins la compression est
efficace mais plus la qualité sonore est préservée et inversement. Néamoins, QCELP et
Speex implémentent également le VBR (variable bitrate) ce qui leur permet d’adapter la
taille de leur codebook selon le bloc de bits à compresser. En d’autre terme, le taux de
compression dépendra des évènements sonores enregistrés.
De plus, en phonologie, chaque langue peut être divisée en un certain nombre de son
élémentaire que l’on appelle phonème (par exemple les phonologues s’accordent à dire
que l’anglais en possède entre 40 et 60). Ces phonèmes forment les briques de base de
la langue et sont classés selon des critères sonores (consonne, voyelle, articulation, souffle
etc). Aussi, ces deux articles ont montré qu’il existe un lien étroit entre le bitrate utilisé
par le codec pour compresser un échantillon vocal et les phonèmes qui le constituent. Les
auteurs arrivent alors à établir une correlation entre un échantillon vocal émis par un
interlocuteur et la taille du paquet compressé et chiffré (le chiffrement n’ajoutant aucun
payload correspondant). A partir de là, il devient envisageable de deviner le contenu de
la conversation.
La méthode employée suppose que l’attaquant possède les informations suivantes :
— L’attaquant a pu identifier l’ordre et la taille de chaque paquet transmis lors de la
conversation.
— Il connait la langue utilisée par les interlocuteurs.
— Il possède un dictionnaire de phonème de la langue cible.
— Il possède une bibliothèque de texte enregistré avec leurs transcriptions mot par
mot et par phonème dans la langue cible.
La première hypothèse est facilement réalisable avec des outils comme wireshark, la se-
conde peut être devinée facilement avec les méta-données de la conversation. La troisième
et la quatrième peuvent être obtenues auprès de phonologues. Il s’agit de plus d’une at-
taque ne nécessitant pas de puissance de calcul particulièrement élevée et ne nécessitant
pas de moyens déraisonnables. La partie suivante reviendra en détail sur les idées présen-
tées ci-dessus et sur la méthodologie employée depuis la réception des paquets jusqu’à la
retranscription de la conversation.
2/18 Rapport final

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
2.2 Méthode détaillée
Dans cette partie, on explorera les idées directrices de la méthodologie pour mener
l’attaque telle qu’elle est présentée dans l’article de 2011, celui-ci étant plus récent et
présentant une méthode plus généraliste. Cependant on faira le parallèle avec les résultats
trouvés dans l’article de 2008 quand cela est possible. La ﬁgure 1 donne un aperçu sur les
étapes nécessaires à retranscrire une conversation VoIP à partir de l’approche présentée
précédemment.
Figure 1 – Architecture générale pour retranscrire une conversation VoIP
La première étape consiste à découper les paquets VoIP récupérés sur le réseau en petits
fragments correspondants aux phonèmes de la conversation audio encodée. Le premier
article de 2008 observa d’abord de manière empirique que certain phonèmes avaient une
plus forte probabilité d’être encodés avec un bitrate particulier que d’autre. Les auteurs ont
pu ainsi, grâce au corpus du TIMIT 1
, construire un modèle probabiliste pour trouver une
correspondance entre taille du paquet et phonèmes employés. En plus de ces observations,
les auteurs de l’article de 2011 étudient également les changements brutaux de taille de
paquet, ceux-ci pouvant indiquer la transition entre deux phonèmes. Ils arrivent ainsi,
également à l’aide d’une base de donnée riche, à construire un modèle probabiliste basé
sur le principe d’entropie maximale 2
. A partir de ce modèle il est possible d’évaluer la
probabilité qu’un paquet soit la frontière entre deux phonèmes.
1. Le corpus du TIMIT est une grande base de donnée phonétique acoustique de discours enregis-
trés par plus de 630 orateurs. Il est largement utilisé dans le domaine de la phonétique acoustique et
les systèmes de reconnaissance automatique de voix car ce corpus a l’avantage de fournir également le
découpage en phonème de chaque phrases enregistrées.
2. L’entropie maximale consiste à étudier un phénomène statistique dont on ne connaît pas tout les
3/18 Rapport ﬁnal

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
Une fois les paquets fragmentés en phonèmes, il faut évaluer et classer chacun de ces
fragments pour trouver à quel phonème ils correspondent. Pour cela, les deux articles
utilisent une approche similaire basée sur les modèles HMM (Hidden Markov Modeling).
Simplement, les HMMs sont des automates probabilistes à état finis. Ils permettent de
modéliser le comportement d’un système dont l’ensemble des paramètres est trop complexe
pour être entièrement déterminé, les paramètres inconnus sont alors représentés sous forme
de probabilités dans les transitions entre les états. Dans notre cas, le bruit, le timbre de
la voix et la diction par exemple sont des paramètres complexes inconnus. L’alphabet de
l’automate est alors les différentes tailles de compression possibles quand le codec encode
un élément vocal. Les transitions sont munis de probabilités qui vont être affinées au fur
et à mesure des essais. Cette technique évalue cependant les fragments indépendament les
uns des autres. L’article de 2011 utilise également une classification qui prend en compte
les prédécesseurs et succésseurs du fragment étudié, encore une fois basé sur un modèle
d’entropie maximale.
A ce stade, on possède désormais un flux de phonème classifié, il reste alors à les
séparer en mots. Pour cela, on procède en deux étapes, d’abord on identifie des triplets
de phonèmes qui n’ont pas ou ont peu de sens phonologiquement dans la langue cible.
Ces triplets sont donc constitués de deux paires qui peuvent potentiellement former un
séparateur entre deux mots. Cependant, encore une fois il faut prendre en compte les
phonèmes directement adjacents pour vérifier si ils peuvent correctement former la fin
ou le début d’un mot. Finalement, on utilise également un dictionnaire de prononciation
pour comparer et éventuellement corriger le résultat obtenu.
Pour finir, il suffit de convertir ces groupes de phomènes obtenus formant des mots
en véritable mot dans la langue cible. Pour chaque groupe de phonème il faut énumérer
l’ensemble des mots dont la prononciation est la plus proche. Les auteurs de l’article de
2011 évaluent sous la forme d’une distance le degré définissant si la prononciation d’un
mot est plus ou moins proche du groupe de phonèmes étudié. Cette distance est par
exemple évaluée selon les suites de voyelles et de consonnes tout en prenant en compte
un certain nombre d’exceptions pour les phonèmes dont les sonorités sont très proches.
Une fois cette liste établie, il faut traiter le cas des homophones. Pour cela, on utilise des
éléments d’étude du langage pour se servir du contexte et faire le bon choix parmis les
mots possibles.
2.3 Résultats et déductions
Grâce aux techniques évoquées on a pu obtenir une reconstitution textuelle d’une
conversation VoIP chiffrée. La dernière section de cette partie s’attardera sur quelques
éléments qui vont permettre d’évaluer le résultat obtenu. La méthode la plus directe pour
évaluer la retranscription serait de la comparer avec le texte original et simplement comp-
paramètres en étudiant les éléments de ce phénomène ayant la plus grande entropie et donc la distribution
aléatoire la moins arbitraire
4/18 Rapport final

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
ter le nombre d’erreurs. Cependant cette méthode est trop sévère, par exemple il suffit
qu’un verbe soit mal conjugué pour compter une erreur alors que pour une personne, le
sens reste entièrement compréhensible. En phonologie il existe de nombreuses techniques
plus ou moins avancés et complexes pour comparer un texte original et une retranscription.
Dans ce cas présent, les résultats ont été évalués avec la méthode de Lavie et Denkowski
dites METEOR (Automatic metric for machine translation). L’idée de cette méthode est
de comparer le texte original et la retranscription mot à mot selon trois niveaux. Une
fois avec une comparaison exacte, une fois avec une comparaison suffixe/préfixe et une
dernière fois en comparant les synonymes. La figure 2 donne un exemple de l’application
de la méthode d’évaluation METEOR. Le texte de référence se situe à gauche et la re-
transcription à droite. Les cercles pleins sont des comparaisons exactes et les cercles creux
des comparaisons suffixe/préfixe.
Figure 2 – Application de la méthode d’évaluation METEOR sur 3 textes différent
Avec cette méthode, un premier jeux de test est fait avec la base de donnée du TIMIT.
Pour ces tests, la base de donnée permet de supposer que la segmentation des phonèmes
est correcte (notamment pour ne pas que des segments correspondant à du bruit faussent
les résultats). Les premiers test se font en considérant ensemble tout les énoncés du corpus
pour deux phrases de référence (SA1 et SA2). Les meilleurs résultats obtenus montré dans
le tableau 1 de la figure 3 sont très prometteurs. En effet, il est considéré qu’un texte est
facilement compréhensible quand son score METEOR est d’au moins 0.50. Un second
jeu de tests élargit les hypothèses de départ en considérant cette fois-ci des phrases du
TIMIT prises indépendamment les uns des autres. Les résultats obtenus dans le tableau 2
restent satisfaisants si on garde en mémoire que la conversation est censée être entièrement
chiffrée. La quantité d’information récupérée est loin d’être acceptable pour considérer que
le système est sécurisé. Un dernier jeu de tests est réalisé cette fois sans considérer aucune
hypothèse mentionnée ci-dessus. Les meilleurs résultats sont alors moins bons, étant donné
que le meilleur score est de 0.27. Il faut tout de même noter que la retranscription obtenu
reste compréhensible et que la méthode peut encore être améliorée. On peut également
rappeler qu’il s’agit d’une façon d’évaluer les résultats, peut être qu’un autre modèle
d’évaluation aurait été plus approprié dans ce cas.
5/18 Rapport final

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
En conclusion, ces deux articles ont montré qu’il existe une faille dans la confidentialité
de la VoIP qui ne dépend pas du système de chiffrement. Les résultats obtenus et les
avancés dans le domaine de la reconnaissance de voix automatique donnent d’autant
plus de raisons pour se préoccuper du problème. Néanmoins des solutions existent déjà.
Le nouveau codec de Skype par exemple (SILK) peut faire varier le nombre de blocs
compressés par paquet selon l’état du réseau. De plus, il faut également souligner que
la méthode employée pour la retranscription suppose que les paquets IP n’ont pas été
fragmentés, c’est-à-dire que l’attaquant doit pouvoir observer les paquets comme s’il se
situait sur le réseau local de l’émetteur ou du récepteur (ou il devra utiliser des outils de
défragmentation IP). Les paquets doivent également être suffisament petits, en effet il est
d’autant plus difficile de segmenter un paquet en phonème si celui-ci est trop volumineux.
Enfin, cette attaque est impossible à réaliser si les codecs employés n’utilisent pas de
variable bit-rate ou si simplement le protocol ajoute du padding aux paquets.
Figure 3 – Résultats obtenus avec la méthodes METEOR sur les phrases SAT1 et SAT2
du corpus TIMIT
6/18 Rapport final

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
3 ZRTP : Echange D-H et protection MiTM pour SRTP
3.1 Définition et fonctionnement du protocole ZRTP
3.1.1 Définition du ZRTP
ZRTP est un protocole d’accord de clé développé par P.Zimmermann (créateur du
PGP) qui effectue un échange de clés Diffie-Hellman pendant l’établissement de l’appel.
ZRTP génère un secret partagé, qui est ensuite utilisé pour générer les clés et le salt pour
une session Secure RTP (SRTP).
ZRTP n’utilise pas de PKI ni de clé publiques persistantes. Pour la session média, ZRTP
fournit la confidentialité, la protection contre les attaques man-in-the-middle (MiTM) et
le Perfect Forward Secrecy (les clés sont détruites à la fin de l’appel)
ZRTP utilise le Diffie-Hellman (DH) éphémère avec un engagement de hachage et permet
la détection d’attaques man-in-the-middle (MiTM) en affichant une "Short Authentica-
tion String" (SAS) à lire par les utilisateurs et à comparer verbalement par téléphone.
Une implémentation de ZRTP est disponible sur Zfone.com.
3.1.2 Fonctionnement du ZRTP
Le protocole ZRTP commence après que deux terminaux ont utilisé un protocole de
signalisation et sont prêts à échanger des médias.
Il existe 3 modes d’accords de clé :
• le mode Diffie-Hellman (D-H)
• le mode Multistream
• le mode pré-partagé
Mode Diffie-Hellman :
Le mode Diffie-Hellman se base sur un échange Diffie-Hellman ainsi toutes les clés
SRTP sont calculées à partir de la valeur secrète calculée par chaque partie.
Modes Multistream :
Le mode Multistream est une méthode d’accord de clé utilisée lorsque deux extré-
mités ont un flux de média SRTP établi entre eux avec une clé de session ZRTP active.
ZRTP peut alors dériver plusieurs clés SRTP à partir d’un seul échange D-H.
7/18 Rapport final

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
Mode pré-partagé :
En mode pré-partagé, les extrémités peuvent ignorer le calcul DH s’ils ont un se-
cret partagé à partir d’une session ZRTP précédente. La principale différence entre le
mode Multistream et le mode pré-partagé est que le mode pré-partagé utilise un secret
partagé préalablement en cache, rs1, au lieu d’une clé de session ZRTP active.
On va s’intéresser ici au mode Diffie-Hellman, et faire un petit rappel en l’occurrence :
Figure 4 – Échange de clés Diffie-Hellman
Alice et Bob choisissent un nombre premier p et une base g. Ici, p = 23 et g = 3 :
1. Alice choisit un nombre aléatoire secret a = 6
2. Elle envoie à Bob la valeur A = ga
(mod p) = 36
(mod 23) = 16
3. Bob choisit à son tour un nombre aléatoire secret b = 15
4. Bob envoie à Alice la valeur B = gb
(mod p) = 315
(mod 23) = 12
5. Alice calcule maintenant la clé secrète : K = Ba
(mod p) = 126
(mod 23) = 9
6. Bob calcule et obtient la même clé qu’Alice : Ab
(mod p) = 1615
(mod 23) = 9
Etablissement d’une session SRTP via ZRTP :
Notations pour le D-H de ZRTP :
— B (Bob) = pvi = public value initiator (calculée)
— b = svi = secret value initiator
— A (Alice) = pvr = public value responder (calculée)
— a = svr = secret value responder
— K = DHResult = clé secrète commune (calculée)
8/18 Rapport final

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
Comme K = Ba
(mod p) = Ab
(mod p), on obtient alors :
DHResult = K = pvisvr
(mod p) = pvrsvi
(mod p)
La figure ci-dessous décrit l’établissement d’une session SRTP via ZRTP :
Figure 5 – Établissement d’une session SRTP via ZRTP
Le message Hello contient les options de configuration SRTP et le ZID (ZRTP ID).
Le ZID reçu est utilisé pour rechercher les secrets partagés conservés des sessions ZRTP
précédentes avec l’autre partie.
Notons que l’extrémité (Bob) qui envoie le message Commit est considérée initiateur
de la session ZRTP.
L’initiateur (Bob) doit générer sa paire de clés éphémères avant d’envoyer Le Commit, et
le répondeur (Alice) génère sa paire de clés avant d’envoyer DHPart1.
Les valeurs publiques (pvi et pvr) de Diffie-Hellman sont échangées dans les messages
DHPart1 et DHPart2.
Les clés SRTP et les "salt" sont alors calculées.
9/18 Rapport final

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
L’authentification ZRTP utilise une "Short Authentication String" (SAS), qui est af-
fichée afin que l’utilisateur la lise oralement.
Alternativement, la SAS peut être authentifié en échangeant une signature numérique
facultative sur la SAS dans les messages Confirm1 ou Confirm2.
Les messages Confirm1 et Confirm2 sont envoyés entre autres pour confirmer que tous les
calculs d’accord de clé sont bons et que le chiffrement fonctionnera.
3.2 Attaques possibles
3.2.1 Attaque DoS
ZRTP est potentiellement vulnérable aux attaques de déni de service simplement en
envoyant de faux messages HELLO aux deux parties. Pour chaque HELLO reçu, l’extré-
mité ZRTP crée alors une connexion demi-ouverte et conserve ses paramètres.
Finalement, il sera à court de stockage ou de mémoire, et les demandes ultérieures de
clients légitimes seront refusées.
3.2.2 Attaques MiTM
Cas ou les interlocuteurs ne connaissent pas la voix l’un de l’autre :
Dans ce cas d’attaque, le MiTM peut faire une attaque de type « Mafia Attack » qui
fonctionne comme suit :
Quand Alice appelle Bob, Eve redirige l’appel vers son téléphone. Elle répond à l’appel
d’Alice mais en même temps établit une session séparée avec Bob. Eve effectue un échange
de clés Diffie-Hellman avec Alice et Bob et établit deux clés différentes pour crypter le
flux multimédia.
Alice pense qu’elle parle à Bob et Bob pense qu’il parle à Alice, mais en fait tous les
deux parlent à Eve, qui peut modifier la conversation de la manière qu’elle veut. Lorsque
Alice ou Bob demandent une confirmation SAS, Eve relaie également la SAS et confirme
les deux SAS différents, qui sont associés aux deux clés différentes, séparément à Alice et
à Bob. Eve agit dans ce scénario comme MiTM.
Ce type d’attaque ne peut être lancé avec succès que si les valeurs publiques Diffie-
Hellman ne sont pas authentifiées. L’authenticité des valeurs publiques peut être assurée
par l’ajout d’un hachage de la valeur publique lors de la signalisation et en ayant cette
empreinte digitale signée par le service d’authentification.
Il faut souligner que ces attaques ne fonctionnent que lorsque le ZRTP handshake est
effectué entre Alice et Bob pour la première fois. Toutes les clés suivantes sont dérivées
de l’ensemble des clé initiales en utilisant la continuité des clés.
10/18 Rapport final

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
Cas ou le contrôle SAS n’est pas utilisé par les interlocuteurs :
L’authentification basée sur SAS nécessite qu’une sorte d’interface graphique ou d’af-
fichage soit disponible pour l’utilisateur. C’est un problème sérieux pour de nombreux
périphériques VoIP sécurisés, par exemple ceux qui implémentent la VoIP via un proxy
de réseau local et qui n’ont pas d’affichage. Par conséquent, nous nous concentrerons sur
la sécurité de ZRTP dans la situation où l’utilisateur ne peut pas explicitement vérifier la
SAS sur la connexion vocale. Parce que les secrets partagés sont recalculés après chaque
session, l’attaquant doit être présent à chaque session à partir de la première, dans laquelle
il n’y avait pas de secret partagé.
L’attaquant choisit des exposants aléatoires x’, y’ et calcule respectivement
x = gx
(mod p) et y = gy
(mod p). z est le hachage de x concaténé avec l’ensemble
des algorithmes choisis par Bob pour la session ZRTP.
L’attaquant remplace également tous les ID secrets partagés par des nombres aléa-
toires. Lorsque Alice reçoit le message DHPART2 de Bob, elle récupère l’ensemble des
secrets qu’elle partage avec Bob et calcule l’ensemble des ID attendus. Comme l’attaquant
a remplacé tous les ID par des nombres aléatoires, ils ne correspondent pas.
La spécification du protocole permet explicitement à l’ensemble des secrets parta-
gés d’être vide : "le secret partagé final, s0, est calculé en hachant la concaténation du
Diffie-Hellman Shared Secret (DHSS) suivi de l’ensemble (éventuellement vide) des secrets
partagés qui sont réellement partagés entre l’initiateur et le répondeur". La spécification
n’exige pas qu’Alice arrête le protocole et lui ordonne plutôt de calculer la valeur commune
de Diffie-Hellman comme ysvr
(mod p)(= gy .svr
(mod p)).
La clé de session est maintenant calculée comme le hash de la valeur conjointe de
Diffie-Hellman seul parce que Alice croit qu’elle n’a plus de secrets partagés avec Bob. De
même, Bob calcule la clé de session comme le hash de la valeur de Diffie-Hellman gx .svi
(mod p). L’attaquant connaît les deux valeurs, donc il peut calculer la master key et le
salt, et complètement briser le cryptage SRTP.
3.3 Vue d’ensemble pour le ZRTP
ZRTP est une relativement bonne solution pour sécuriser le premier échange de clé
Diffie-Hellman d’une communication SRTP sans avoir recours au SDES ou à la lourdeur
de mise en place d’une PKI. Cela est vrai à condition bien sûr, d’utiliser le mécanisme
de Short Authentication String (SAS) afin que les utilisateurs lisent oralement ou com-
parent la SAS en validant une signature numérique optionnelle échangée dans les messages
Confirm1 ou Confirm2.
ZRTP n’a pas de parade à l’attaque sur la taille des paquets SRTP chiffrés en AES
préalablement encodés avec un codec audio utilisant le VBR.

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
4 L’attaque en pratique
La cryptographie est nécessaire au niveau des paquets VoIP, et particulièrement au
niveau SIP, en effet, un appareil malveillant pourrait intercepter les paquets concernant
la session voip et usurper une identité, tenter un deni de service, ou simplement écouter
la communication. Les concepts cités dans les parties précédentes présentaient quelques
manières de sécurisation des paquets en question, ainsi que la vulnérabilité du VoIP.
D’autre part, nous avons, montré à travers des programmes en python la possibilité
de faire quelques attaques ainsi que de manipuler des paquets interceptés pour les utiliser
à des fins malveillantes. Pour ce faire et après installation et configuration des para-
mètres du serveur VoIP (Asterisk), nous nous sommes mis en situation de deux clients
(X-Lite/Zoiper) communiquant entre eux, avec la présence d’un script écris en python,
servant d’intercepteur de paquets relatifs au VoIP (Man in the middle).
Une application python rejoue le paquet ‘invite’ fournis par le premier script avec
l’option sniff de scapy, en mettant de fausses informations dans le but d’usurper l’identité
d’un client possible, et appelle un destinataire en boucle, à fin de rendre ce dernier injoi-
gnable, ou d’inonder son réseau d’appels répétitifs.
Une autre application en python est mise en place pour intercepter les paquets VoIP (sip
et rtp) dans le but de pouvoir espionner les utilisateurs, et de réécouter leurs communi-
cations après enregistrement de la trace de chaque session VoIP détectée.
Nous avons par la suite constaté qu’une simple ouverture de session SIP malveillante
pourrait faire croire à une machine victime la présence d’une communication VoIP et ainsi
offrir la possibilité de faire passer des paquets RTP dont le contenu est malveillant à un
pirate potentiel (Cf figure . 6 ) :
Figure 6 – Interception,écoute et fabrication de paquets VoIP

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
De plus, ces vulnérabilités ne se limitent pas à un serveur de type Asterisk mais bien
aussi aux applications VoIP que nous utilisons de nos jours. Les manières d’intrusion sont
plus ou moins différentes mais il est possible d’espionner voire de tenter une attaque sur
une communication VoIP dite sécurisée, et pour ce faire il existe quelques outils qui sont
majoritairement utilisés par des institutions gouvernementales :
— Skype capture Unit :Trojan développé par Digitask et utilisé par les autorités
bavaroises pour intercepter les communication voix et texte Skype.
— VoIPong : Utilitaire détectant tous les appels Voix sur IP sur un pipeline. Il prend
en charge SIP, H323, Cisco Skinny Client Protocol, RTP et RTCP.
— VOMIT (Voice Over Misconfigured Internet Telephones) : Utilitaire convertissant
une conversation téléphonique IP Cisco en un fichier wave qui peut être lu avec
des lecteurs audio ordinaires. Vomit nécessite un fichier de sortie tcpdump.
— SIPtrap : logiciel développé par Peter Cox, co-fondateur de la société de sécurité
BorderWare, et servant à pirater / écouter / enregistrer n’importe quelle conver-
sation IP. Ce logiciel, est une véritable preuve des vulnérabilités affectant cette
technologie, pourtant utilisée partout dans le monde.
5 Conclusion
De part sa nature, VoIP a hérité des principales failles de toute les applications né-
cessitant un niveau de sécurité élevé mais dont l’information circule sur un réseau public.
L’un des points d’attaque les plus courant est l’initiation d’une session VoIP avec le pro-
tocole SIP. Dans la partie précédente nous avons vue et mis en pratique une attaque basée
sur le rejeu grâce à un man in the middle. Avec cette attaque il est possible d’intercep-
ter et d’écouter une conversation ou plus directement de nuire à celle-ci par l’émission
de paquet intrusifs. La troisième partie nous a permit d’explorer un protocole alternatif
pour l’échange de clé. En effet, le protocole ZRTP propose notamment une solution aux
attaques de type man in the middle permettant ainsi de sécuriser le secret partagé né-
cessaire au protocole SRTP pour chiffrer la conversation. Cependant la première partie
nous a montré que le chiffrement de SRTP possède également des failles. Sous certaines
conditions, il reste possible de deviner une retranscription d’une conversation VoIP entiè-
rement chiffrée mais nous avons également vu qu’il existe des parades à cette attaque.
En conclusion, la voix sur IP propose une alternative intéressante à la téléphonie pour
les entreprises. Bien que ce système devient de plus en plus populaire et continue de se
développer allant jusqu’à transporter tout type de média sur IP, il doit encore faire ses
preuves en terme de sécurité.

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
Références
[1] Spot Me if You Can : Uncovering Spoken Phrases in Encrypted VoIP Conversations
http://ieeexplore.ieee.org.accesdistant.upmc.fr/stamp/stamp.jsp?arnumber=5958018
Security and Privacy, 2008. SP 2008 IEEE Symposium on
[2] Phonotactic Reconstruction of Encrypted VoIP Conversations : Hookt on Fon-iks
http://ieeexplore.ieee.org.accesdistant.upmc.fr/stamp/stamp.jsp?arnumber=5958018
Security and Privacy (SP), 2011 IEEE Symposium on
[3] The Secure Real-time Transport Protocol https://www.ietf.org/rfc/rfc3711.txt Re-
quest for Comments 3711, 2004
[4] Security Analysis of Voice-over-IP Protocols http://ieeexplore.ieee.org.accesdistant.upmc.fr/docume
Computer Security Foundations Symposium, 2007. CSF ’07. 20th IEEE
[5] Using SIP identity to prevent man-in-the-middle attacks on ZRTP
http://ieeexplore.ieee.org.accesdistant.upmc.fr/document/4812920/ Wireless Days,
2008. WD ’08. 1st IFIP
[6] A formal security proof for the ZRTP Protocol
http://ieeexplore.ieee.org.accesdistant.upmc.fr/document/5402595/ Internet Tech-
nology and Secured Transactions, 2009. ICITST 2009. International Conference
for
[7] RFC 6189 - ZRTP : Media Path Key Agreement for Unicast Secure RTP
https://tools.ietf.org/html/rfc6189 Request for Comments 6189, 2011
[8] Attention aux techniques de hack de la téléphonie sur IP !
http://www.journaldunet.com/solutions/expert/49727/attention-aux-techniques-
de-hack-de-la-telephonie-sur-ip.shtml David Huré 2011
[9] SIPtap :comment pirater les conversations téléphoniques VoIP
http://www.generation-nt.com/siptap-logiciel-espion-faille-pirater-voip-conversation-
telephonique-actualite-65790.html Bruno C. 2008
[10] Nessus Vulnerability Scanner Tenable Network Security, 2017
[11] VoIPong Underunix project http://www.enderunix.org/voipong/index.php?sect=downloadlang=en
EnderUNIX Software Development
[12] Allemagne espionnage malware https://www.nextinpact.com/archive/41480-
Allemagne-espionnage-malware.htm Nextinpact
[13] Skype and the Bavarian trojan in the middle
https://wikileaks.org/wiki/SkypeandtheBavariantrojaninthemiddle Daniel Schmitt
2008
[14] VOMIT - voice over misconﬁgured internet telephones http://vomit.xtdnet.nl/ 2004
[15] VoIP Hacking Techniques https://hakin9.org/voip-hacking-techniques/ Mirko Rai-
mondi

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
Annexe 1
L’application sniﬀ_voip.py permet d’écouter sur le port 5060 (sip) et de remonter
n’importe quel paquet correspondant à la VoIP en l’occurrence, Cf Figure 7 :
Figure 7 – Interception des numéros des adresses ip, dport et payload ’INVITE’
L’application fake_voip.py permet d’usurper une communication VoIP après intercep-
tion d’une communication antérieure, et ce en réutilisant le numéro de port destination,
et un payload invite en changeant l’information de l’appelant. Le programme donne une
information sur la réponse de l’utilisateur victime, ainsi cela donnera une idée sur la
possibilité de faire transiter de faux paquets RTP par la suite, Cf Figure 8 :
Figure 8 – Emission d’un faux appel avec une identité usurpée

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
L’appel reçu par l’interlocuteur victime comprendra le nom usurpé, Cf Figure 9 :
Figure 9 – Reception d’un appel dont l’identité est usurpée

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
Annexe 2
Une communication VoIP basée sur SIP pour établir une session, est simple à inter-
cepter, et à réécouter. L’application voip_listner.py écoute sur le port SIP, et récupère les
informations relatives à l’établissement et à la ﬁn de la communication, à ﬁn d’enregis-
trer la trace contenant les données voix essentiellement de l’appel entre deux utilisateurs
victimes. Cf Figure 10 :
Figure 10 – Indication de réponse et de terminaison d’un appel écouté dans le but
d’exploiter la trace récupérée
Une fois l’appel terminé, la trace est enregistrée dans le directory courant, et l’appel
peut être réécouté, Cf Figure 11 :
Figure 11 – Exemple de sessions VoIP enregitrées

Master Informatique
UE SECRES 2016-17
R. Khatoun
Projet 11
B. Kaid
H. Mhira
S. Mansfeld
B. Rigault
Glossaire
SIP : (Session Initiation Protocol) Protocole standard ouvert de gestion de session.
RTP : (Real-Time Transport Protocol) Protocole permettant le transport de données
soumises à des conditions de temps réel.
Rejeu : Forme d’attaque réseau dans laquelle une transmission est malicieusement répé-
tée par un attaquant qui a intercepté la transmission.
Trojan : (Cheval de Troie) Logiciel en apparence légitime, mais qui contient une fonc-
tionnalité malveillante.
WAVE : Format de ﬁchier audio développé par Microsoft et IBM.
VoIP : (Voice over IP) Technique permettant de communiquer par la voix sur des réseaux
compatibles IP.
Cryptographie : Disciplines de la cryptologie s’attachant à protéger des messages.
Usurpation : Fait de prendre délibérément l’identité d’une autre personne, généralement
dans le but de réaliser des actions frauduleuses ou malveillantes.
Deni de Service : Attaque informatique ayant pour but de rendre indisponible un ser-
vice.
MiTM : L’attaque "man − in − the − middle" (MiTM) a pour but d’intercepter les
communications entre deux parties, sans que ni l’une ni l’autre ne puisse s’en douter.
PKI : (Public Key Infrastructure) Ensemble de composants physiques, de procédures hu-
maines et de logiciels, en vue de gérer le cycle de vie des certiﬁcats numériques/électroniques.

PSECRES2017-Projet11-KHATOUN_RIDA-Secu_VoIP-RapFinal

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (15)

Similaire à PSECRES2017-Projet11-KHATOUN_RIDA-Secu_VoIP-RapFinal

Similaire à PSECRES2017-Projet11-KHATOUN_RIDA-Secu_VoIP-RapFinal (20)

Plus de Belkacem KAID

Plus de Belkacem KAID (7)

PSECRES2017-Projet11-KHATOUN_RIDA-Secu_VoIP-RapFinal