La sécurisation du flux média pour la VoIP

La sécurisation du flux média pour la VoIP
Duc-Anh NGUYEN
Florian MERCERON
Cedric L’OLLIVIER
Institut National des Télécommunications
Evry
18 mai 2005
Sécurité des Systèmes et des Réseaux
Table des matières
1 Introduction
1
2 Faiblesses, menaces et attaques sur le flux média pour la
2.1 Problématique de sécurité du protocole RTP . . . . . . . .
2.1.1 Service de confidentialité . . . . . . . . . . . . . . .
2.1.2 Service d’authentification et d’intégrité . . . . . . . .
2.1.3 La gestion des clés . . . . . . . . . . . . . . . . . . .
2.1.4 Déni de service . . . . . . . . . . . . . . . . . . . . .
2.2 Attaques IP appliquées à la VoIP . . . . . . . . . . . . . . .
2.2.1 Attaques de reconnaissance . . . . . . . . . . . . . .
2.2.2 Problématiques de confidentialité . . . . . . . . . . .
2.2.3 Problématique de l’authentification . . . . . . . . . .
2.2.4 Problématique du contrôle d’intégrité . . . . . . . .
2.2.5 Attaques par déni de service . . . . . . . . . . . . .
VoIP
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
. . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
2
2
2
3
3
4
4
4
4
5
5
3 Les protocoles sécurisés
3.1 Le protocole SRTP (RFC3711) . . . . . . . . . . . .
3.1.1 Objectifs de srtp . . . . . . . . . . . . . . . .
3.1.2 Caractéristiques de srtp . . . . . . . . . . . .
3.1.3 Le contexte de cryptographie : . . . . . . . .
3.1.4 Traitement d’un paquet SRTP . . . . . . . .
3.1.5 Les Algorithmes de cryptographie . . . . . .
3.1.6 L’authentification . . . . . . . . . . . . . . . .
3.1.7 Gestion des clés . . . . . . . . . . . . . . . . .
3.1.8 Bilan des protocoles SRTCP et SRTP . . . .
3.2 La gestion des clés avec MIKEY (RFC 3830) . . . .
3.2.1 Généralités sur MIKEY . . . . . . . . . . . .
3.2.2 Fonctionnement de MIKEY . . . . . . . . . .
3.2.3 Interaction entre MIKEY et SRTP . . . . . .
3.2.4 Méthodes de transports et d’échange des clés
3.2.5 Gestion des autorisations . . . . . . . . . . .
3.2.6 Conclusion sur MIKEY . . . . . . . . . . . .
3.3 IPSEC . . . . . . . . . . . . . . . . . . . . . . . . . .
3.3.1 VOIPsec . . . . . . . . . . . . . . . . . . . . .
3.3.2 Problèmes avec IPsec . . . . . . . . . . . . .
3.3.3 Conclusion . . . . . . . . . . . . . . . . . . .
3.4 cIPsec . . . . . . . . . . . . . . . . . . . . . . . . . .
3.4.1 Description cIPsec . . . . . . . . . . . . . . .
3.4.2 Conclusion . . . . . . . . . . . . . . . . . . .
3.5 DTLS . . . . . . . . . . . . . . . . . . . . . . . . . .
3.5.1 Rappel TLS . . . . . . . . . . . . . . . . . . .
3.5.2 Description DTLS . . . . . . . . . . . . . . .
3.5.3 Conclusion . . . . . . . . . . . . . . . . . . .
3.6 Cutlass . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
6
6
6
6
8
9
9
12
14
14
14
14
14
15
15
17
18
18
18
19
20
20
21
21
21
22
22
24
24
Mini-projet
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
La sécurisation du flux média pour la VoIP
Sécurité des Systèmes et des Réseaux
4 Conclusion
25
Bibliographie
26
Mini-projet
La sécurisation du flux média pour la VoIP
Introduction
Chapitre 1
Introduction
La voix sur IP remporte actuellement un vif succès notamment grâce à son coût très avantageux. Cependant l’interconnexion de la téléphonie avec le monde IP apporte les risques du monde IP vers un monde
qui était « protégé » car fermé à l’informatique. Les menaces sont larges et nous aborderons uniquement la
sécurité des flux médias de la voix IP. Cela signifie que nous n’aborderons pas la sécurité des signalisations
SIP et H323.
De nombreuses attaques IP sont valables sur la voix sur ip. Nous aborderons quelques uns de ces scénarios
d’attaques impactant la confidentialité, l’authenticité et l’intégrité. Il est donc important de pouvoir
appliquer des services de sécurité.
Nous allons donc décrire une évolution du protocole RTP le protocole SRTP, le protocole DTLS qui
correspond à une adaptation de TLS à UDP et les solutions de tunnels IPSEC et SSL. Cependant
cette étude sur la sécurisation des flux média VOIP est théorique et donc ne se repose pas sur les
implémentations des constructeurs.
Mini-projet
La sécurisation du flux média pour la VoIP
1
Faiblesses, menaces et attaques sur le flux média pour la VoIP
Chapitre 2
Faiblesses, menaces et attaques sur
le flux média pour la VoIP
Cette partie sera consacrée aux faiblesses et menaces sur les flux média VoIP. Nous verrons que celles-ci
sont pour une grande partie liées aux attaques qui touchent de manière générale les réseaux IP. Certaines
restent cependant spécifiques à un environnement VoIP avec notamment des vulnérabilités sur le protocole
RTP que nous détaillerons. Dans le cadre de cette étude, seuls les flux média pour la VoIP seront pris en
compte. Mais il est important de noter que le flux de signalisation, et notamment SIP, présente également
de nombreuse failles et vulnérabilités exploitables par un attaquant : attaques déni de service par injection
de messages SIP Cancel, Bye ou attaque par détournement d’appel (Call Hijacking) avec l’utilisation des
messages SIP 30x.
2.1
Problématique de sécurité du protocole RTP
RTP (Real-time Transport Protocol) est un protocole de niveau applicatif conçu notamment pour les flux
sensibles aux délais comme la vidéo ou la VoIP. Il est aujourd’hui largement utilisé pour des communications VoIP à travers Internet, réseau non sécurisé. Dans cette partie nous ne rappellerons pas les principes
de base des protocoles RTP et RTCP décrits dans la RFC1889, nous nous focaliserons davantage sur les
mécanismes et problématiques de sécurité liés à RTP.
2.1.1
Service de confidentialité
Le chiffrement est possible avec l’algorithme DES-CBC. Le mode CBC permet de garantir que le paquet
perdu empêche uniquement le déchiffrement de ce paquet et du suivant : c’est une caractéristique vitale
pour des flux sensibles aux délais comme la VoIP, peu tolérants aux retransmissions. Si un autre algorithme
de chiffrement devait être utilisé, l’implémentation sera indépendente du protocole RTP qui ne supporte
que DES en mode CBC.
L’algorithme DES-CBC n’est aujourd’hui plus adapté dans la mesure où il est facilement cassable avec
les puissances de calcul disponibles. De plus, il peut présenter un conflit avec la compression d’en têtes
et donc dégrader de manière significative les performances, surtout pour les connexions bas débits. Un
autre point négatif a lieu dans un environnement conférence où chaque participant possède la clé de
chiffrement partagée. La compromission de la clé par l’un des hôtes entraı̂ne évidemment la supression
de la confidentialité de l’ensemble de la conférence. La sécurité pour des sessions à plusieurs participants
est donc difficile à garantir avec ce mode de fonctionnement.
2.1.2
Service d’authentification et d’intégrité
L’authentification dans le protocole RTP est implicite et se base sur la connaissance de la clé de chiffrement
partagée. Le contrôle d’intégrité est effectué à partir de la vérification de champs connus comme le numéro
de version du protocole, la longueur du paquet et le type de payload.
Mini-projet
La sécurisation du flux média pour la VoIP
2
Faiblesses, menaces et attaques sur le flux média pour la VoIP
Ce faible niveau d’authentification introduit par le protocole RTP et qui repose sur une authentification
purement implicite des participants est aujourd’hui inadapté et peu fiable. De plus les participants d’une
communication étant identifiés par leur SSRC, il est possible de forger un paquet avec une SSRC différente
afin de perturber une session RTP.
2.1.3
La gestion des clés
Le seul système de gestion de clé spécifié par la RFC1890 pour RTP est l’utilisation de MD5 pour dériver
la clé de chiffrement à partir du mot de passe. Pour une gestion plus complexe des clés, la mise en œuvre
doit être effectuée par d’autres protocoles voire par les applications elles-mêmes.
2.1.4
Déni de service
– Une attaque possible entrainant un déni de service consiste à utiliser les collisions SSRC (Synchronize
Source) dans le protocole RTP. Un participant peut envoyer une commande et revendiquer le SSRC
d’un autre participant. Ce dernier, selon les spécifications du protocole RTP dans la RFC, cesse toute
communication et doit sélectionner un nouveau SSRC.
– A partir d’un paquet RTP forgé avec un numéro de SSRC utilisé par un participant, il est possible
de modifier les champs numéro de séquence et timestamps avec des valeurs supérieures aux valeurs
réelles : les paquets forgés envoyés sont donc d’abord traités par l’utilisateur et peuvent aboutir à une
forme de déni de service.
– Une autre attaque spécifique à la VoIP vise à modifier les codecs audio dans une session RTP établie, à
partir de l’injection de paquets RTP par un pirate : choix d’un codec plus gourmand en bande passante
et entrainant davantage de pertes de paquets. Les conséquences peuvent être multiples allant de la
dégradation de la qualité du son au déni de service.
Fig. 2.1 – Format de l’en tête RTP
(source : Pierre Vincent, http://www-lor.int-evry.fr/~vincent/expArad/arad2001/voIP/www.html#
3.4)
Détail des champs de l’en tête RTP :
V : Version sur 2 bits, la version approuvée par l’IETF est la version 2.
P : Bourrage sur 1 bit.
X : Extension sur 1 bit. Si l’extension de l’en-tête ; 0 : pas d’extension pour la téléphonie
CC : nombre de CSRC sur 4 bits ; en téléphonie cc=1.
M : Marqueur sur 1 bit.
PT : Type de contenu (Payload Type) sur 7 bits. Ce champ identifie le type de données audio ou
vidéo transporté par ce paquet et leur format de codage. Il détermine la manière dont elles devront être
interprétées. Les différents types sont JPEG, GSM, PCM, G711,G721...
Numéro de séquence : Numéro d’ordre de sortie des paquets sur 16 bits. Il sera utilisé par le destinataire
pour remettre les paquets dans l’ordre ou constater une perte éventuelle
Horodatage : Sur 32 bits. Le paquet de données est horodaté à l’instant même de l’échantillonnage du
premier octet le constituant. L’horloge doit être monotone, linéaire dans le temps et avoir une précision
suffisante pour assurer celle de la resynchronisation
SSRC : Sur 32 bits. Le champ SSRC identifie la source de synchronisation c’est à dire l’émetteur sur
lequel il faudra caler la base de temps du flux. Il est choisit aléatoirement pour être unique au sein d’une
même session RTP.
CSRC : De 0 à 15 éléments de 32 bits chacun. La liste CSRC nomme toutes les sources ayant contribué
aux données contenues dans le paquet. Dans le cas de la téléphonie, il n’y aura qu’un seul CSRC.
Mini-projet
La sécurisation du flux média pour la VoIP
3
Faiblesses, menaces et attaques sur le flux média pour la VoIP
2.2
Attaques IP appliquées à la VoIP
Les nombreuses menaces du réseau IP sont valables pour un environnement de VoIP. Dans cette partie,
nous avons choisi de mettre en évidence quelques attaques IP appliquées à la VoIP plutôt que de dresser
une liste exhaustive (qui serait trop longue !) des attaque sur le réseau IP.
2.2.1
Attaques de reconnaissance
Il s’agit en général de la première phase d’une attaque. L’objectif pour un pirate est de récupérer un
maximum d’informations sur le réseau VoIP, comme obtenir les ports ouverts ou encore les adresses IP
qui sont les identifiants des téléphones IP. Des logiciels en téléchargement libre (ex : Angry IP Scanner)
sont disponibles sur Internet pour réaliser ces attaques.
2.2.2
Problématiques de confidentialité
Sniffing (ou EavesDropping) :
Cette attaque consiste à écouter passivement le trafic sur le réseau VoIP. Il est ainsi possible de reconstituer entièrement une communication entre deux téléphones IP. Si un hub est utilisé pour interconnecter
des téléphones IP, il suffit pour un pirate de se brancher sur un des ports du hub pour écouter les
conversations : en effet, un hub duplique le trafic sur l’ensemble de ses ports.
Fig. 2.2 – Exemple d’une attaque par ”sniffing”
Dans le cas d’un switch, le pirate a la possibilité de lancer au préalable une attaque de type CAM Overflow
afin de remplir sa table d’association adresse MAC/port : le commutateur se comporte alors comme un
hub. Il s’agit là d’une attaque générale valable pour tous les réseaux commutés (de niveau 2) et donc
pour une architecture VoIP.
Attaque Man In The Middle :
Il s’agit pour un pirate de s’insérer dans une communication téléphonique de manière transparente pour
les utilisateurs. Les possibilités d’actes malveillants pour le pirate sont variées : simple écoute, redirection
de la conversation téléphonique...
Un exemple concret de ce type d’attaque a été démontré en environnement réel et a été effectué en
environnement réseaux commutés. L’attaque de l’ARP Spoofing consiste dans la génération de GARP
(Gartuitous ARP ou ARP non sollicités) afin de modifier les tables ARP des équipements (switch et
téléphones IP). Il en résulte une attaque « Man In The Middle » qui est totalement transparente pour
les utilisateurs (aucun moyen de déceler l’attaque, on ne dénote aucune baisse de qualité du son pendant
et après l’attaque).
2.2.3
Problématique de l’authentification
L’attaque consistant à usurper l’identité par spoofing d’adresse IP reste valable en environnement VoIP,
ce qui donne la possibilité à un pirate de se faire passer pour un rogue phone.
Mini-projet
La sécurisation du flux média pour la VoIP
4
Faiblesses, menaces et attaques sur le flux média pour la VoIP
2.2.4
Problématique du contrôle d’intégrité
Le service de sécurité d’intégrité assure que des informations n’ont pas été altérées par une tierce personne. Les menaces liées au service d’intégrité incluent des données ou des fonctionnalités qui auraient
été corrompues volontairement ou même involontairement. Un exemple de problème d’intégrité est la corruption de la fonctionnalité DHCP (qui attribue les adresses IP aux téléphones IP), essentielle dans une
architecture ToIP. Un serveur DHCP pirate qui attribuerait une fausse adresse IP au téléphone pourrait
avoir des conséquences importantes : attaque Man In The Middle ou déni de service.
2.2.5
Attaques par déni de service
Une architecture VoIP repose largement sur une partie software (téléphone IP, passerelle, serveur) et qui
sont donc susceptibles à des failles et vulérabilités : buffer overflow, bug, virus ou même worms (dans le
cas de softphones)... Nous ne détaillerons pas cette partie qui est spécifique à chaque système et logiciel.
Un autre type d’attaque par déni de service pourrait consister à inonder de paquets forgés à destination
d’équipements critiques tels que les serveurs ou les passerelles utilisés dans l’architecture VoIP. Le but
étant de produire un déni de service par une incapacité de l’équipement à assurer sa fonction ou même
un crash.
Mini-projet
La sécurisation du flux média pour la VoIP
5
Les protocoles sécurisés
Chapitre 3
Les protocoles sécurisés
3.1
3.1.1
Le protocole SRTP (RFC3711)
Objectifs de srtp
L’objectif principal de cette boı̂te à outil est de fournir les services de sécurité suivants :
– confidentialité du contenu utile de RTP et RTCP
– intégrité de l’ensemble du paquet RTP et RTCP
– protection contre le rejeu
L’ensemble de ces services est optionnel et indépendant excepté l’intégrité des flux srtcp.
D’autre part, la conception de ce protocole respecte les contraintes suivantes :
– une évolution possible des algorithmes de cryptographie
– une faible consommation de bande passante avec préservation de l’efficacité de compression des en-têtes
RTP
– une faible consommation en ressource de calcul
– une taille de code et occupation mémoire minimale
– l’indépendance vis à vis des autres couches avec forte tolérance à la perte de paquet et à leurs remises
en ordre.
3.1.2
Caractéristiques de srtp
SRTP et SRTCP représentent un profil de RTP et doivent être implémentés sans aucune modification
de RTP. C’est pour cette raison que l’on parle de RTP en tant que boite à outil. Afin de visualiser les
changements voici les formats des paquets SRTP et SRTCP.
Mini-projet
La sécurisation du flux média pour la VoIP
6
Les protocoles sécurisés
Format d’un paquet SRTP
Fig. 3.1 – Format d’un paquet SRTP
Seul le champ MKI et l’étiquette d’authentification apparaissent :
SRTP MKI (Master Key identifier) : cet identifiant permet de repérer la clé maı̂tre à partir de laquelle
la clé de session a été produite.
L’étiquette d’authentification :
– La validation de l’intégrité dont le numéro de séquence permet d’éviter les rejeux.
– Le cryptage est toujours effectué avant la création du tag authentification
– Le MKI n’est pas protégé car cela n’apporte pas de protection en plus
Mini-projet
La sécurisation du flux média pour la VoIP
7
Les protocoles sécurisés
Format d’un paquet SRTCP
Fig. 3.2 – Format d’un paquet SRTCP
Les nouveaux champs apparaissent à partir du drapeau E :
– champ E : il indique si ce paquet est crypté ou non
– SRTCP index : contrairement au SRTP où il doit être calculé, il est ici directement indiqué
– étiquette d’authentification : données d’authentification
– MKI (Master Key Indicator) : idem au SRTP
3.1.3
Le contexte de cryptographie :
Le contexte de cryptographie permet le partage d’information sur la sécurité entre les deux extrémités
de la communication. Il est identifié par le triplet : SSRC, adresse de destination et port de destination.
Le contexte comporte un ensemble de paramètres appelés « paramètres indépendants de transformation
». Ces données sont stockées sur les deux extrémités d’une communication. Voici quelques-uns de ces
paramètres :
– un ROC (Roll Over Counter) : il compte le nombre de fois que le numéro de séquence à été réinitialisé
à 0. Ce paramètre permet de calculer l’index.
– un index tel que i = 21 6 * ROC + SEQ : Cet index est en fait la localisation du paquet dans l’ensemble
des séquences reçues. Dans le cas du SRTCP, il l’est pas nécessaire de le calculer car il est fournit
directement dans chaque paquet.
– un identifiant de l’algorithme de cryptage et de son mode
– un identifiant de l’algorithme d’authentification
– une liste de rejeu au niveau du récepteur contenant les derniers paquets SRTP authentifiés reçus.
– etc...
Ces paramètres permettent donc d’identifier les algorithmes de cryptographie pour chaque paquet et de
se protéger des attaques par rejeu.
La liste de rejeu et l’index apportent une protection supplémentaire contre les attaques par rejeu. Dans
la pratique, la liste de rejeu ne peut pas contenir l’ensemble des paquets reçus et authentifiés à cause
de la taille de stockage (cf voir objectifs). D’où l’utilisation d’une fenêtre glissante, pour chaque paquet,
Mini-projet
La sécurisation du flux média pour la VoIP
8
Les protocoles sécurisés
un index est calculé. Puis on valide que cet index se trouve au dessus de la fenêtre ou à l’intérieur (à
condition qu’il ne soit pas déja présent).
Pour terminer, les flux SRTCP utilisent le même contexte de cryptographie que le SRTP sauf séparation
du ROC, de la liste de rejeu et du compteur paquet SRTCP par clé maı̂tre.
3.1.4
Voici
1.
2.
3.
4.
5.
6.
7.
8.
9.
Traitement d’un paquet SRTP
les étapes du traitement d’un paquet srtp lors de la réception.
Recherche du contexte de cryptographie grâce au triplet.
Calcul de l’index du paquet
Recherche de la clé maı̂tre et de la clé salt grâce à l’index ou au MKI
Recherche de la clé de sessions de cryptage et clé session salt grâce à la fonction de dérivation des
clés à partir de la clé maı̂tre et de la clé salt ainsi que du taux de dérivation.
Vérification que le paquet n’a pas été rejoué en comparant l’index et la fenêtre de rejeu.
Vérification de l’étiquette d’authentification
Décryptage de la partie cryptée
Mise à jour du Roll Over Counter
Suppression des étiquettes d’authentification et du MKI afin de le transformer en paquet RTP
standard
3.1.5
Les Algorithmes de cryptographie
Dans cette partie nous allons décrire les algorithmes de dérivation de clés et les algorithmes de cryptages
et d’authentification.
Dérivation et formation des clés
Une seule clé maı̂tre peut être utilisée à la fois pour le srtp et srtcp grâce à une fonction de dérivation de
clé de session. La nécessité de la dérivation des clés est facile à comprendre :
– seulement deux clés sont transmises à l’initialisation : la clé maitre et la clé ”salt” maı̂tre
– si une clé de session est découverte, il sera impossible de retrouver les autres clés de sessions
– différentes clés de sessions permettent de se prémunir contre les attaques par collisions (voir ci dessous).
Cependant l’utilisation de clés de sessions ne rallongent pas la durée de vie de la clé maı̂tre.
Voici la procédure de dérivation simplifiée des clés :
Fig. 3.3 – Procédure de dérivation des clés
La clé salt est l’une des forces de protocole. Elle sert à se prémunir des attaques par collision. En effet,
l’une des solutions la plus simple et la plus fiable pour ce prémunir de ce type d’attaque est de rallonger
la clé principale par une séquence pseudo-aléatoire. La clé salt permet ainsi d’allonger artificiellement les
clés. Par défaut la taille de la clé salt est de 112 bit, ce qui impose au cryptanalyste d’essayer 2112 clés.
Rappel sur les attaques par collision :
Référence : ”The Need of Salt” , http://www.3gpp.org/ftp/tsg_sa/WG3_Security/TSGS3_35_Malta/Docs/PDF/S3040796.pdf
Les attaques par collision sont basées sur la connaissance préalable de données en clair par l’attaquant.
A partir de ces données, l’attaquant est apte à savoir lorsque la clé est bonne ou pas. Les étapes de
l’attaquant sont les suivantes :
Mini-projet
La sécurisation du flux média pour la VoIP
9
Les protocoles sécurisés
1. L’attaquant connait déjà les parties contenant les données connus, ou il fait en sorte que des données
connues rentrent dans des flux qu’il a à décrypter
2. Il crypte ces données connues par un ensemble de clé
3. Il enregistre le trafic crypté qu’il souhaite casser et recherche une collision (similarité entre sa base
de données connue crypté et une donnée dans le fichier crypté)
4. Il valide la collision en testant la clé sur l’ensemble des données cryptées.
Procédure de cryptage
Chaque paquet est crypté par un segment keystream pseudo aléatoire. Ce segment est créé à partir de
l’index du paquet et de la clé secrète. Donc chaque segment correspond à un seul paquet. Enfin le système
de génération du keystream dépend du cryptage ainsi que son mode.
Fig. 3.4 – Procédure de cryptage
Les algorithmes de cryptage
Deux algorithmes sont disponibles :
– Null Cipher : pas de cryptage.
– AES : deux modes sont proposés le ”Segmented Integer Counter (AES-CTR)” et le f8-mod
AES mode Segmented Integer Counter :
Ce mode consiste en un cryptage par incrémentations successives.
Mini-projet
La sécurisation du flux média pour la VoIP
10
Les protocoles sécurisés
Fig. 3.5 – AES mode Segmented Integer Counter
Le rfc indique bien que le SSRC et l’index doivent être indépendants de la clé salt, sinon cela casserait
complètement ce système. (Cela pourrait être un axe d’étude dans le cassage des sessions SRTP)
AES mode f8 :
Ce mode a été développé pour l’UMTS. Voici son fonctionnement :
Mini-projet
La sécurisation du flux média pour la VoIP
11
Les protocoles sécurisés
Fig. 3.6 – AES mode f8
On peut remarquer la présence d’une authentification implicite de l’en-tête via la création du vecteur
d’initialisation. D’autre part, la clé salt sert ici uniquement à rallonger la clé via un masque.
3.1.6
L’authentification
1. Création d’un message M tel que :
En SRTP : M = Partie à authentifier || ROC (Roll Over Counter)
En SRTCP : M = Partie à authentifier
Rappel : le ROC indique le nombre de fois que le numéro de séquence à été réinitialisé à 0.
2. HMAC du message M avec la clé d’authentification
Le HMAC choisi est HMAC-SHA1 défini dans le RFC 2104. Nous pouvons décrire grossièrement cette
fonction telle que : HMAC-SHA1 = SHA1(k a XOR opad, SHA1(k a XOR ipad, M)).
Voici les différents paramètres utilisés :
M : le message à authentifier
k a : clé d’authentification
SHA1 : algorithme de hachage
ipad : un octet 0x36 répété avec XOR B fois
opad : un octet 0x5C répété avec XOR B fois
Mini-projet
La sécurisation du flux média pour la VoIP
12
Les protocoles sécurisés
Le schéma qui suit décrit clairement son fonctionnement :
Fig. 3.7 – schéma du HMAC-SHA1 (référence : http ://www.research.avayalabs.com/techreport/ALR2004-001-paper.pdf)
Selon Avaya, ce choix souffre d’une vulnérabilité en terme de « Denial Of Service ». En effet, le Hash
est calculé à chaque fois qu’un paquet est reçu. En fait un calcul de 6 SHA1 est effectué pour un paquet
SRTP de 172 octets (codec G711 à 8kz) car le nombre de SHA1 = (172 * 8 )/ 512 + 3. Selon le document
(voir référence schéma), cela revient à 76 µs sur un processeur 60 Mhz. Donc si l’on envoie une rafale de
100 paquets vides mais avec un tag d’authentification, on occupe 7,6 secondes de temps processeur.
Pour contrer cela la société AVAYA a conçu une amélioration « propriétaire » de SRTP (pas de draft RFC
décrit à ce jour). appelée SRTP+. Cette implémentation se base sur génération du numéro de séquence
par une séquence pseudo-aléatoire seulement connue des deux extrémités. C’est en quelque sorte une
authentification implicite. Ainsi la validation de ce numéro étant faite avant l’authentification et étant
plus rapide, cela permet de se prémunir de ce type d’attaque.
Mini-projet
La sécurisation du flux média pour la VoIP
13
Les protocoles sécurisés
Mais rien n’est indiqué sur l’échange de cette séquence aléatoire, seul un détail précis de cet échange
validerait la non-faillibilité de leurs solutions. D’autre part, Avaya ne prend pas en compte la protection
contre les rejeux et la recherche du contexte de cryptographie qui apparaissent AVANT la validation de
l’authentification. Donc ce type d’attaque paraı̂t donc difficile à mettre en oeuvre en pratique.
Pour revenir à la fonction initiale, cette fonction HMAC permet donc à la fois de garder des performances
acceptables et de garantir le changement de fonction de hachage au cas ou le SHA1 serait devenu obsolète
(au niveau sécurité).
3.1.7
Gestion des clés
La gestion de clés permet d’établir le contexte de cryptographie. Trois standards émergent actuellement :
MIKEY (RFC 3830) , KEYMGT et SDMS. Nous décrirons MIKEY dans le prochain chapitre.
3.1.8
Bilan des protocoles SRTCP et SRTP
Cette étude légèrement détaillée permet de comprendre que SRTP n’est pas un simple protocole où l’on
ajouté du cryptage et de l’intégrité. En effet de nombreux mécanismes comme la protection contre le rejeu
et la dérivation des clés sont à l’avantage de cette boı̂te à outil. En outre, la force de cette conception est
la prise en compte des performances via l’adoption d’algorithmes optimisés tels que HMAC (RFC 2104)
ou AES mode f8.
3.2
3.2.1
La gestion des clés avec MIKEY (RFC 3830)
Généralités sur MIKEY
Le rôle de MIKEY est d’établir une session de sécurité (SA) pour un protocole de sécurité par la fourniture
d’une clé de cryptage de trafic (traffic-encrypting key (TEK)). Nous reviendrons par la suite sur le rôle
de cette clé.
Le design de MIKEY prend en compte la légèreté (consommation légère de bande passante, de calcul,
etc), la simplicité et une indépendance complète vis-à-vis des autres couches.
Enfin, il permet le tunneling et l’intégration dans les protocoles d’établissement de session tel SDP et
RTSP.
De plus le concept de ”Crypto Session Bundle (CSB)” permet à plusieurs instances d’avoir le même
générateur de clé ainsi que les mêmes paramètres de sécurité mais avec une clé de session différente.
Sa conception intègre les quatre scénarios suivants :
– peer-to-peer (unicast) : Ce scénario concerne un appel SIP de base. La sécurité est ici fournie soit par
un accord mutuel soit par une mise en place indépendante des deux parties dans les flux de sorties.
– Point à multipoint (multicast) : Seul l’émetteur met en place la sécurité.
– Multipoint à multipoint (décentralisé) : Chacun gère la sécurité de ses flux de sorties.
– Multipoint à multipoint (centralisé) : Les groupes les plus larges sont chargés de la sécurité.
3.2.2
Fonctionnement de MIKEY
MIKEY repose sur deux clés :
– La clé TGK : La clé TGK (TEK Generation Key (TGK)) correspond à une chaı̂ne de caractère partagée
entre les extrémités de la communication.
– La clé TEK : Cette clé correspond à la clé maı̂tre dans SRTP. Elle est soit utilisée directement ou
dérivée en plusieurs clés par le protocole de sécurité (SRTP). Elle est crée à partir de la clé TGK .
Ce schéma du fonctionnement de MIKEY présente le rôle de ces clés :
Mini-projet
La sécurisation du flux média pour la VoIP
14
Les protocoles sécurisés
Fig. 3.8 – Fonctionnement de MICKEY
3.2.3
Interaction entre MIKEY et SRTP
1. Lors de la réception d’un paquet SRTP, le triplet <SSRC, destination address, destination port>
est extrait et utilisé pour rechercher le contexte de cryptographie et donc l’association de sécurité.
2. Si un MKI est présent, il pointe alors directement vers les clés de la SA, sinon il faudra utiliser
l’index.
3. Si le type de clé envoyé à MIKEY est une TEK, alors elle est utilisée directement comme clé maı̂tre.
Sinon si c’est une TGK, alors MIKEY devra calculer la clé maı̂tre
3.2.4
Méthodes de transports et d’échange des clés
MIKEY définit trois méthodes pour transporter ou établir une clé TGK (voir ci dessus) : l’utilisation
d’une pre-shared key, d’un cryptage par clé publique ou d’un échange Diffie-Hellman (DH). Le TGK et
une valeur aléatoire RAND serviront à dériver la clé maı̂tre (TEK).
Avec le secret partagé le volume de données échangées sera léger. Cependant ce type d’échange n’est
réalisable qu’avec les scénarios en point à point. En effet il paraı̂t difficile de partager un même secret
avec plusieurs hôtes.
Pour les autres scénarios, la cryptographie à clé publique sera préférée. Mais la cryptographie a clé
publique consomme plus de ressource de calcul et repose sur une infrastructure PKI pour la distribution
de ces clés.
Enfin, DH consomme plus de ressources réseaux et de calcul que la clé publique et le secret à clé partagé.
Mais il a l’avantage de la flexibilité grâce à la possibilité d’implémenter différents groupes finis et de la
sécurité grâce à la perfect forward secrecy. C’est-à-dire qu’il est impossible de retrouver une autre clé de
TGK si une autre clé TGK est compromise.
Nous allons aborder le contenu des messages d’échanges sur ces trois méthodes. A savoir, elles ont toutes
deux types de messages :
– un message provenant de l’initiateur de la communication. Son rôle est le transport de un à plusieurs
TGK dans un KEMAC avec les paramètres de sécurités SP.
– un message de réponse à l’initiateur provenant du récepteur. Ce message valide l’authentification mutuelle en renvoyant des données transmises par l’initiateur dans un MAC.
Les champs suivants sont présents dans les échanges MIKEY quelque soit la méthode utilisée :
– HDR : en-tête général de MIKEY
– T : timestamp utilisé contre les attaques à rejeu
– RAND : chaı̂ne de caractère aléatoire utilisé dans la dérivation des clés. Par rapport à SRTP, ce champ
pourrait correspondre à la clé salt.
– Idi : identité de l’initiateur
Mini-projet
La sécurisation du flux média pour la VoIP
15
Les protocoles sécurisés
– Idr : identité du répondeur
– SP : politique de sécurité. Elle définit les différents paramètres tels que les algorithmes de cryptage,
d’authentification. Enfin elle indique les services de sécurité à prendre en compte
– V : MAC du message du récepteur
Méthodes de transport et d’échange des clés
La clé partagée sert à dériver les clés de cryptage encr key et la clé d’authentification auth key du message
MIKEY.
Fig. 3.9 – Échange à clé partagée
Le champ KEMAC (Key data transport payload) sert à transporter une ou plusieurs clés TGK. Dans ce
cas KEMAC = E(encr key, TGK) || MAC.
Échanges par clés publiques
La clé publique du récepteur sert à crypter une clé dite de clé d’enveloppe (env key). Cette clé enveloppe
(env key) permet de dériver la clé de cryptage utilisée dans le KEMAC et la clé d’authentification utilisée
dans le MAC. La clé d’enveloppe est donc comparable au secret partagé.
La signature du message par la clé privé de l’initiateur permet une authentification mutuelle des deux
parties.
Enfin le champs CRASH permet d’indiquer au récepteur la clé publique à utiliser.
Fig. 3.10 – Échange par clés publiques
– PKE : ce champ contient la clé enveloppe (env key) cryptée par la clé publique du destinataire tel
que : PKE = E(PKr, env key)
– KEMAC : ce champ transporte une ou plusieurs clés comme les clés TGK en les cryptant avec la clé
encr key dérivée de la clé env key (clé d’envellope).
Il est généré de la façon suivante : KEMAC = E(encr key, IDi || TGK) || MAC
– SIGNi : C’est la signature couvrant l’ensemble du message de l’initiateur
– CHASH (Cert Hash Payload) : Ce champ contient le hash de la clé publique du répondeur. Cette
partie est utilisée lorsque le destinataire possède plusieurs clés publiques.
Mini-projet
La sécurisation du flux média pour la VoIP
16
Les protocoles sécurisés
Échange Diffie-Hellman
L’objectif de cet échange est de créer une clé Dh qui sera utilisée comme clé TGK. L’avantage de cet
échange est que l’initiateur n’ a pas besoin du certificat du récepteur avant l’échange.
Cependant comme TLS ou SSL, l’authentification requiert une validation des certificats par la racine. Si ce
n’est pas fait, toute l’authentification peut être compromise. Une approche d’attaque de ce type d’échange
serait la compromission des racines de certifications ou l’envoi de fausses informations concernant ces
racines pour que l’attaquant s’autoproclame racine.
Voici les étapes de cet échange :
1. Les paramètres de groupes G (groupe) et g (générateur) sont choisis par l’initiateur. Le groupe
utilisé est de type OAKLEY 5 d’une taille de 1536 bits
2. Chaque partie génère un secret aléatoire xi et xr.
3. Les parties s’échangent les valeurs Dh telles que : Dhi = g xi et Dhr = g xr
4. La clé TGK est calculée sur les deux extrémités : TGK = g xi∗xr
Fig. 3.11 – Échange Diffie-Hellman
– CERTi : certificat de l’initiateur permettant au récepteur de valider la signature de message de l’émetteur.
– CERTr : certificat du récepteur permettant à l’initiateur de valider la signature du récepteur.
– Dhi : valeur DH tel que Dhi = g xi
– Dhr : valeur DH tel que Dhr = g xi
– SIGNi :signature du message de l’initiateur
– SIGNr :signature du message du récepteur
On peut remarquer l’absence du champ KEMAC grâce à la génération de TGK différent à chaque échange.
Cependant l’envoi des données Dh et des certificats alourdit l’échange.
Conclusion sur les échanges de clés
MIKEY offre ainsi trois méthodes correspondant à chaque fois à des besoins spécifiques. On remarque
bien que le nombre de données échangées en clé partagée est plus léger que par les clés publiques ou
Diffie-Hellman.
3.2.5
Gestion des autorisations
Deux modèles permettent d’effectuer des décisions d’autorisation selon le scénario :
– Configuration point à point spécifique : L’utilisateur configure son application pour un utilisateur
spécifique. Dans le cas de la clé partagée, c’est la meilleur solution car cette fonction implique une
autorisation implicite. Pour les clés publiques, cela impose un échange des clés publiques via un autre
canal de communication.
– Configuration par racine de confiance : L’utilisateur accepte tous les autres utilisateurs ayant un certificat signé d’une autorité de confiance spécifique. Pour cela chaque participant doit mettre en place
une ou plusieurs autorités de certification et être capable de valider des certificats.
Dans la pratique ces solutions sont utilisées simultanément. Mais on remarque bien la complexité de la
gestion des autorisations.
Mini-projet
La sécurisation du flux média pour la VoIP
17
Les protocoles sécurisés
3.2.6
Conclusion sur MIKEY
Cependant les clés publiques et Diffie Hellman imposent la mise en place d’une PKI. Sachant que la PKI
devra être sûre afin ne pas compromettre le service d’authentification et donc toute la sécurité.
Pour terminer sur l’autorisation, il paraı̂t difficile en terme de coût humain voire matériel que toutes
les entités deviennent chacune autorité de certification. Ainsi à titre personnelle, il sera nécessaire les
hash des clés publiques autorisées soient stockées sur chaque terminal SIP. Ceci impose bien entendu des
procédures de mises à jour et donc une complexité supplémentaire.
3.3
IPSEC
Un moyen de sécuriser la VOIP est de protéger les données elles-mêmes. Une solution est donc de chiffrer
les paquets en utilisant IPsec. Ainsi toute personne, autorisée ou non, qui intercepte le trafic de VOIP ne
pourra lire le contenu chiffré de ces paquets.
3.3.1
VOIPsec
IPsec est un des protocoles les plus utilisés pour faire du Tunneling VPN à travers Internet. Il y a deux
protocoles de base définis pour IPsec : ESP (Encapsulating Security Payload) et AH (Authentication Header). Ces deux modèles fournissent les services de sécurité d’intégrité, d’authentification et d’anti-rejeu.
Concernant la VOIP, ESP se différencie de AH par un temps de latence de chiffrement et déchiffrement
des données et une authentification plus étroite, qui normalement ne protège pas l’en-tête IP au dessus
de l’en-tête ESP, bien que IKE peut être utilisé pour négocier l’association de sécurité (SA) incluant des
clés secrètes symétriques. Dans ce cas, les adresses dans l’en-tête (en mode transport) ou dans la nouvelle
en-tête (en mode tunnel) sont indirectement protégées puisque seulement les entités ayant négocié la
SA peut chiffrer/déchiffrer ou authentifier les paquets. IPsec peut fonctionner en deux modes : le mode
transport et le mode tunnel. Le mode transport permet de chiffrer les données et l’en-tête associé dans
le paquet IP. Ainsi l’en-tête IP et le nouvel en-tête IPsec peuvent être lus, ce qui permet à un pirate
interceptant le trafic, non pas de déterminer le contenu mais de connaı̂tre la source et la destination finale
du paquet. Le mode tunnel permet de chiffrer le datagramme IP entier et de le placer dans un nouveau
paquet IP. Ainsi le payload et l’en-tête IP original sont chiffrés, de sorte que si un pirate intercepte le
trafic, il est incapable de lire le contenu et également de connaı̂tre la source et le destinataire final.
Fig. 3.12 – IPsec en modes transport et tunnel
La facilité d’intercepter des données en capturant les paquets d’un réseau IP font du chiffrage de données
Mini-projet
La sécurisation du flux média pour la VoIP
18
Les protocoles sécurisés
une nécessité pour la voix sur IP. De plus il est aussi important de protéger ce qu’une personne dit que
de protéger à qui cela est adressé. C’est pourquoi IPsec peut être utilisé pour atteindre ces objectifs
de confidentialité dans la mesure où le protocole ESP en mode tunnel est utilisé comme le décrit le
paragraphe précédent, puisque l’identité des différentes entités communiquant entre elles et les données
transitant sont protégées. En outre, l’intégration de IPsec dans IPv6 facilitera la possibilité de chiffrement
(même s’il existe d’autres moyens de sécuriser les données à la couche applicative). Ainsi IPsec permet de
réduire les différents risques d’attaques du type man-in-the-middle, ou capture de paquets sur un réseau
par exemple.
3.3.2
Problèmes avec IPsec
Toutefois si IPsec semble un moyen fiable et robuste pour protéger les données et d’authentifier l’émetteur,
l’utilisation d’un tel protocole peut être remis en question. Contrairement à un trafic de données normal,
le trafic VOIP nécessite une certaine qualité de service (QoS) pour ne pas dégrader le qualité de la voix,
notamment au niveau du temps de latence, du jitter (variation dans le délai de livraison des paquets), ou
de la perte des paquets.
Le délai maximum acceptable pour la transmission d’un paquet pour une qualité de voix optimale est
de 150ms, qui peut être étendu à 200 ms dans le cas de communications chiffrées. Cela signifie qu’après
la numérisation du signal, le temps pour coder le signal (utilisant certains standards comme G.729 ou
G.723 par exemple), pour le fragmenter en paquets et l’encapsuler dans des paquets IP, ainsi que le temps
de routage et la reconstruction du paquet original par le destinataire doit être au maximum de 150 ms.
Pour répondre à ces contraintes les paquets voix sont de petites tailles (entre 10 et 50 octets de payload).
Ainsi selon le codec utilisé, la numérisation peut durer de 0.75 à 30ms, le délai dans les processus de
files d’attentes (temps passé par un paquet dans les buffers des routeurs lors du routage) peut ajouter un
retard de 30 ms et le temps de variation lors du buffering du destinataire un retard de 40 à 70 ms, et cela
sans compter les délais induits par IPsec, car de nombreuses contraintes doivent être prises en compte.
Un des principaux problèmes induits par IPsec est le temps de chiffrement et déchiffrement. Selon les
algorithmes utilisés, les temps de calculs peuvent être défavorables à la VOIP. Une étude réalisée par
l’université de Milan montre que, comme on peut s’en douter, que plus l’algorithme est « léger », moins les
délais de chiffrement/déchiffrement sont importants, comme le décrit le schéma suivant. Il est important
de noter que les disparités entre les différents algorithmes peuvent être significatives : environ 500 paquets
par seconde entre le DES et le 3DES+SHA-1 pour d’un trafic important. Un autre problème de sécurité
apparait alors : plus l’algorithme est « léger », plus il sera facilement « crackable ». Il faut alors faire face
à un dilemme entre la sécurité et la qualité de la voix.
Mini-projet
La sécurisation du flux média pour la VoIP
19
Les protocoles sécurisés
Fig. 3.13 – Comparaison des nombres de paquets par seconde (pps) en sortie d’un composant cryptographique en fonction du trafic pour les différents algorithmes de chiffrement et/ou authentification
Un autre point, un peu plus problématique concernant la VOIP, est la gestion des files d’attente pour ces
processus de chiffrement et déchiffrement. Si les routeurs, firewalls ou autres gateways permettent de faire
de la QoS pour déterminer la priorité des paquets, les composants cryptographiques (crypto-engine) quant
à eux ne permettent pas une telle gestion, utilisant le simple standard FIFO. Le nombre de petits paquets
étant assez important, les performances sont alors réduites considérablement puisque la saturation de la
file d’attente peut être atteinte. A cela s’ajoute le fait que plus les paquets sont gros, plus les délais sont
importants.
Enfin, l’utilisation de IPsec augmente la taille du paquet, notamment à cause l’en-tête ESP et les nouveaux en-têtes du mode tunnel ajoutés à chaque paquet transmis. Par conséquent, cela augmente le
ratio des tailles de l’en-tête par rapport au payload, réduisant alors considérablement l’efficacité de la
bande passante. De plus un délai supplémentaire est introduit pour la construction des différents en-têtes
ajoutés.
3.3.3
Conclusion
Si IPsec apporte un certain degré de sécurité recherché, cela induit également des réductions de performances au niveau de la qualité de la voix. Néanmoins, on peut espérer que d’ici quelques temps, les
performances seront améliorées. En effet on peut s’attendre à une diminution des temps de traitement de
chiffrement et déchiffrement avec le développement croissant des technologies. Une solution supplémentaire au problème de files d’attentes des processus cryptographiques serait l’utilisation de routeurs gérant
la QoS avant la phase de chiffrement. Une autre approche aux problèmes de QoS serait la compression
de la taille des paquets, notamment aux niveaux des en-têtes, solution détaillée plus bas.
3.4
cIPsec
Nous avons vu précédemment que IPsec introduisait une augmentation de la taille des paquets à cause des
rajouts des différents en-têtes. L’idée de cIPsec, basée sur cRTP est de compresser les en-têtes des paquets
IP, UDP et RTP, dont les valeurs de certains champs restent constantes. De plus, certaines informations
présentes dans d’autres champs sont également présentes dans les en-têtes externes. Cette compression
permet alors de réduire de 4 octets pour la plupart des paquets IP, UDP et RTP.
Deux modules sont alors ajoutés : un module de compression, permettant la compression du paquet
Mini-projet
La sécurisation du flux média pour la VoIP
20
Les protocoles sécurisés
lors de son émission par l’émetteur et un module de décompression, permettant de reconstruire l’en-tête
original lors de sa réception par le destinataire.
3.4.1
Description cIPsec
Différentes informations partagées et le contexte de la session doivent être maintenus entre les deux entités
communicantes pour le fonctionnement de cIPsec. Ces informations sont utilisées par le destinataire pour
reconstruire les en-têtes originaux qui ont été compressés. Le contexte de la session est défini à la fois par
les adresses IP source et destinataire, par les ports UDP source et destinataire et le champ SSRC de RTP.
Les informations partagées pour chaque contexte de session et stockées par l’émetteur et le destinataire
sont les suivantes :
– les en-têtes complets des paquets IP, UDP et RTP des derniers paquets envoyés par le module de
compression ou reçus par le module de décompression.
– la dernière valeur du numéro de séquence de 4 bits, utilisé pour détecter la perte des paquets.
Le Session Context ID (CID) permet d’identifier la communication peer-to-peer. Ce champ de 16 bits
permet de maintenir jusqu’à 65536 appels entre les deux entités.
Le Link Sequence contient les 8 bits de poids faible du numéro de séquence de l’en-tête RTP et permet
de garder la trace de 256 paquets perdus consécutivement.
Le bit de Séquence (S) notifie la présence des bits de séquences RTP.
Le bit de Checksum (C) notifie la présence des bits de checksum UDP.
L’option UDP Checksum contient la valeur du checksum, parfois nécessaire pour garantir l’intégrité des
données de bout en bout. Si le protocole ESP utilise un algorithme d’authentification, cette option peut
être désactivée.
L’option RTP Sequence représente le bit de séquence RTP utilisé pour la synchronisation du contexte.
Le bit de Retransmission (R) indique s’il est nécessaire de retransmettre un paquet.
3.4.2
Conclusion
Le problème principal avec ce type de compression est lié à l’occurrence d’erreurs de transmission, dues
aux pertes de paquets ou au vérification du CRC ou du checksum dans les en-têtes IP et UDP. Or
pour la VOIP, la correction d’erreur induit un délai trop important, il est donc nécessaire de faire une
retransmission, ce qui est défavorable à la VOIP.
L’étude de cIPsec reste expérimentale mais les performances mesurées par une étude de l’université de
Milan montre quand même que les délais de transmission sont diminués (de 10 ms pour deux liens d’accès
64 Kbps), que les délais de chiffrement et déchiffrement sont réduits (de 1,8 à 6,5
3.5
DTLS
TLS est le protocole le plus répandu pour sécuriser le trafic réseau (HTTP, POP, IMAP).
Toutefois les applications sont limitées au protocole TCP, ce qui est problématique pour les protocoles
comme SIP, RTP ou MGCP, basé sur le protocole UDP. Ainsi le protocole DTLS (« Datagram TLS
»), version modifiée de TLS, a pour but de palier à cette limitation. Les avantages sont clairs : tout
d’abord, DTLS reste proche de TLS, ce qui permet de réutiliser les implémentations et infrastructures
des protocoles préexistants. Ensuite DTLS se base, comme TLS, sur une couche de sécurité générique, ce
qui facilite l’adaptation des protocoles pour l’utiliser.
Mini-projet
La sécurisation du flux média pour la VoIP
21
Les protocoles sécurisés
3.5.1
Rappel TLS
TLS assure les services de sécurité suivant : authentification du serveur, confidentialité et intégrité de la
communication. Sa structure est décrite par le schéma suivant :
Fig. 3.14 – Structure de TLS
Le « record layer » est la couche qui assure le transport des données basé directement sur TCP et peut
transporter 4 types de payload :
– Les messages Handshake utilisés pour la négociation et l’établissement des clés.
– Les messages ChangeCipherSpec, qui font partie des messages Handshake mais qui sont techniquement
séparés.
– Les messages d’alertes utilisés en cas d’erreur.
– Les données de la couche applicative.
DTLS est donc basé sur cette structure avec quelques modifications décrites dans la partie suivante.
3.5.2
Description DTLS
DTLS réemploie la plupart des éléments constituant le protocole TLS avec quelques changements pour
le fonctionnement avec le mode UDP.
Record Layer :
Comme le TLS, toutes les données DTLS sont transportées par la couche « record ». Pour éviter la
fragmentation, le DTLS « record » sera formé de telle sorte qu’il soit inclus dans un seul datagramme.
En effet cela permet d’éviter de mettre en buffer des « records » partiels, ainsi un gain de mémoire
sera apporté, permettant de diminuer aussi les risques d’attaques par déni de services. De plus si des
datagrammes se perdent contenant des « records » partiels, les autres fragments deviennent inutilisables.
Ainsi la longueur maximale du payload sera plus petite que celle du TLS. Comparé au TLS, un champ
epoch et un champ sequence number sont ajoutés à la structure du record layer, comme le décrit le
schéma ci-dessous (les nouveaux champs sont encadrés). Le premier sert à résoudre l’ambiguı̈té qu’il peut
y avoir quand des données se perdent pendant une session de renégociation (pour différencier les messages
ChangeCipherSpec et les données par exemple), tandis que le second sert au reséquencement.
Fig. 3.15 – Structure du DTLS record
Mini-projet
La sécurisation du flux média pour la VoIP
22
Les protocoles sécurisés
Modes de Chiffrement :
DTLS est compatible avec le mode de Chiffrement par Bloc (CBC) permettant d’utiliser du 3DES ou
AES. En effet contrairement aux modes de chiffrement de TLS (1.0), il n’est pas nécessaire de traiter les
différents « records » dans l’ordre et sans perte à l’opposé de RC4 par exemple. Chaque record peut être
déchiffré séparément avec un vecteur d’initialisation explicite.
Protocole Handshake :
DTLS fonctionnant en mode UDP est alors susceptible à des attaques de type DoS. En effet un pirate peut
se faire passer pour le client envoyant une requête ClientHello à laquelle le serveur renvoie un message de
Certificat beaucoup plus large à la victime. Pour éviter cela, un système d’échange de cookie est ajouté.
Un champ cookie est donc ajouté à la structure de la requête ClientHello envoyé au serveur qui répond
par une requête HelloVerifyRequest afin de s’assurer de la demande coté client. Le client doit ensuite
rejouer ce cookie pour montrer qu’il est capable de recevoir des paquets. La phase réelle de négociation
peut alors commencer. La figure ci-dessous représente les différentes phases décrites précédemment (les
requêtes encadrées sont les requêtes modifiées ou ajoutées par rapport à TLS).
Fig. 3.16 – Le protocole DTLS
Cet échange de cookie est utilisé pour certains protocoles comme Photuris et est décrit dans la RFC 2522.
Fig. 3.17 – Structure des messages ClientHello et HelloVerifyRequest
Timer et retransmission :
Pour que la phase de négociation précédente se déroule sans problème, il faut que tous les messages
Handshake soient transmis. Toutefois, certains messages peuvent se perdre, mal séquencé, ou encore trop
large pour être inclus dans un seul « record », nécessitant une fragmentation en plusieurs « records ».
C’est pourquoi un système de retransmission est nécessaire, utilisant un seul timer pour le client et le
serveur. Tant qu’aucune réponse n’a été donnée, le message est retransmis. La structure des messages
Handshake est alors modifié comme indiquée ci-dessous afin de permettre cette fragmentation et réordonner correctement les messages, en définissant un séquencement des messages, un offset et une longueur
de fragment.
Mini-projet
La sécurisation du flux média pour la VoIP
23
Les protocoles sécurisés
Fig. 3.18 – Structure des messages Handshake
3.5.3
Conclusion
Si la modification des différentes structures augmente la taille des paquets DTLS, elle n’engendre pas
une augmentation significative par rapport à TLS et les temps de latence restent que très légèrement
supérieurs, n’affectant pas la qualité de la voix.
Cependant DTLS reste à l’état expérimental et n’est pas encore standardisé mais pourrait devenir un
substitut potentiel de SRTP. L’avantage de DTLS est qu’il peut être utilisé pour sécuriser d’autres
protocoles que RTP (contrairement à SRTP) et qu’il peut établir ses propres canaux de communication
(ne dépendant pas de SIP par ex.).
3.6
Cutlass
Référence : http://www.synacklabs.net/projects/cutlass/
L’objectif de Cutlass est d’être un protocole sécurisé s’adaptant à différents types de trafics tel que :
Voix sur ip, le transfert de fichier et de textes. Ce projet est une initiative individuelle et il est donc peu
probable que cela devienne un standard.
Voici ses caractéristiques :
– basé sur UDP
– échange de clé Diffie hellman uniquement
– cryptage AES 256 bit mode compteur
– HMAC : HMAC-SHA1
– signature RSA
– pas de protection de rejeu implémenté à ce jour
– Un seul codec voix : Speex à 8khz
Ce protocole est donc moins flexible que SRTP-MIKEY en terme de choix de mode de cryptage et
d’échange de clés. Mais à priori, il semble qu’il est un avenir car une société inconnu finance ce projet.
Mini-projet
La sécurisation du flux média pour la VoIP
24
Conclusion
Chapitre 4
Conclusion
Le choix des protocoles est donc large et devra être effectuer en fonction des critères suivants :
– coût : cela dépend du constructeur et de l’existant.
– impact sur les communications en terme de performance
– bande passante nécessaire
– robustesse du protocole
– support de la confidentialité, authentification et protection contre le rejeu
– flexibilité du protocole sur le choix des algorithmes de cryptographie
– adoption par le publique : la multitude de choix sera synonyme d’hétérogénéité ce qui s’avère handicapant. Le choix devra donc sur les solutions les plus déployées.
Actuellement, quelques constructeurs proposent du SRTP comme Cisco. Mais aucune étude n’indique la
possibilité d’interconnexion de constructeurs différents et le support minutieux de la RFC 3711. Malgré
une réduction de la qualité de la voix, on peut donc penser que la solution d’IPSEC serait la plus
appropriée actuellement. Cependant, il est nécessaire de faire une veille permanente car l’adaptation de
SRTP par les constructeurs et la standardisation du DTLS pourrait bouleverser ce choix.
Mini-projet
La sécurisation du flux média pour la VoIP
25
Sécurité des Systèmes et des Réseaux
Bibliographie
[RFC-RTP] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP, RFC 1889, Janvier 1996
[RFC-RTP] H. Schulzrinne, RTP Profile for Audio and Video Conferences with Minimal Control, RFC
1890, Janvier 1996
[Internet RTP links] http ://www.topology.org/comms/rtp.html
[RTP Security] http ://www.tml.hut.fi/Opinnot/Tik-110.501/2000/papers/hallivuori.pdf
[Sécurité VOIP] http ://www.iaik.tugraz.at/teaching/11 diplomarbeiten/archive/thalhammer.pdf
[SRTP] http ://www.tml.hut.fi/Opinnot/Tik-110.501/2000/papers/hallivuori.pdf
[RFC-SRTP] M. Baugher, D. McGrew, M. Naslund, E. Carrara, K. Norrman, SRTP, RFC 3711, Mars
2004
[RFC-MIKEY] J. Arkko, E. Carrara, F. Lindholm, M. Naslund, K. Norrman, MIKEY, RFC 3830, Août
2004
[SRTP+] http ://www.research.avayalabs.com/techreport/ALR-2004-001-paper.pdf
[Cutlass] http ://cutlass.info/
[cIPsec] http ://www.acsac.org/2002/papers/92.pdf
[Cisco VOIPsec] http ://www.cisco.com/networkers/nw00/pres/2403.pdf
[DTLS] http ://crypto.stanford.edu/ nagendra/papers/dtls.pdf
[RFC cRTP] http ://www.faqs.org/rfcs/rfc3545.html
Mini-projet
La sécurisation du flux média pour la VoIP