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

Transcription

1 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

2 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 VoIP Problématique de sécurité du protocole RTP Service de confidentialité Service d authentification et d intégrité La gestion des clés Déni de service Attaques IP appliquées à la VoIP Attaques de reconnaissance Problématiques de confidentialité Problématique de l authentification Problématique du contrôle d intégrité Attaques par déni de service Les protocoles sécurisés Le protocole SRTP (RFC3711) Objectifs de srtp Caractéristiques de srtp Le contexte de cryptographie : Traitement d un paquet SRTP Les Algorithmes de cryptographie L authentification Gestion des clés Bilan des protocoles SRTCP et SRTP La gestion des clés avec MIKEY (RFC 3830) Généralités sur MIKEY Fonctionnement de MIKEY Interaction entre MIKEY et SRTP Méthodes de transports et d échange des clés Gestion des autorisations Conclusion sur MIKEY IPSEC VOIPsec Problèmes avec IPsec Conclusion cipsec Description cipsec Conclusion DTLS Rappel TLS Description DTLS Conclusion Cutlass Mini-projet La sécurisation du flux média pour la VoIP

3 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

4 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

5 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 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 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

6 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 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 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, 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,G 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

7 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 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 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) 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

8 Faiblesses, menaces et attaques sur le flux média pour la VoIP 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 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

9 Chapitre 3 Les protocoles sécurisés 3.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 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

10 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

11 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 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 = * 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

12 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 Traitement d un paquet SRTP Voici les étapes du traitement d un paquet srtp lors de la réception. 1. Recherche du contexte de cryptographie grâce au triplet. 2. Calcul de l index du paquet 3. Recherche de la clé maître et de la clé salt grâce à l index ou au MKI 4. 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. 5. Vérification que le paquet n a pas été rejoué en comparant l index et la fenêtre de rejeu. 6. Vérification de l étiquette d authentification 7. Décryptage de la partie cryptée 8. Mise à jour du Roll Over Counter 9. Suppression des étiquettes d authentification et du MKI afin de le transformer en paquet RTP standard 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 clés. Rappel sur les attaques par collision : Référence : The Need of Salt, 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

13 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

14 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

15 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 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é à HMAC du message M avec la clé d authentification Le HMAC choisi est HMAC-SHA1 défini dans le RFC 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

16 Le schéma qui suit décrit clairement son fonctionnement : Fig. 3.7 schéma du HMAC-SHA1 (référence : http :// 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 )/ 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

17 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é) 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 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 f 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é 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

18 Fig. 3.8 Fonctionnement de MICKEY 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 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

19 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 É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

20 É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 É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 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