Diplôme d'etudes Approfondies Réseaux de télécommunications

UNIVERSITE LIBANAISE (Faculté de Génie) UNIVERSITE SAINT-JOSEPH (Faculté d'ingénierie) Sous l'égide de l'agence Universitaire de la Francophonie AUF Diplôme d'etudes Approfondies Réseaux de télécommunications Analyse, définition et conception d une solution de sécurité de la voix Par Nathalie Boulos Encadré par : M. Nicolas Rouhana Soutenance le 23 Décembre 2003 devant le jury composé de MM. Samir Tohmé Mohamad Zoaeter Wajdi Najem Imad Mougharbel Nicolas Rouhana Mahmoud Doughan Maroun Chamoun Président Membre Membre Membre Membre Membre Membre

Remerciements Je remercie chaleureusement M. Nicolas Rouhana et Mlle Carole Bassil pour l aide qu ils m ont apportée. C est grâce à leurs qualités professionnelles, à leur patience, à leur encouragement et à l efficacité de leur collaboration que le succès de ce mémoire est assuré. Nathalie Boulos - 2 -

Sommaire Sujet 5 Introduction 7 La voix sur IP 7 Critères de sécurité 7 Travail effectué 8 I. Bluetooth A. Bluetooth technologie 10 1. Historique 10 2. La technologie Bluetooth 10 3. Bluetooth architecture protocolaire 11 4. Transmission de voix et données 12 5. Format d un paquet Bluetooth 14 B. Bluetooth sécurité 15 1. Gestion des clés 15 2. Chiffrement dans Bluetooth Algorithme E0 19 3. Authentification dans Bluetooth Algorithme E1 21 4. Problèmes de sécurité 22 C. Performance de la voix sur ACL 23 1. Introduction 23 2. Simulation 24 3. Expérimentation 25 4. Conclusion 28 D. Synthèse 28 II. GSM A. GSM architecture 29 B. GSM sécurité 30 1. authentification GSM 31 2. Chiffrement GSM 32 C. Synthèse 33 III. Wireless LAN A. 802.11 architecture 34 B. 802.11 sécurité 36 1. Wired Equivalent Protocol 36 a. chiffrement WEP 36 b. authentification WEP 38 c. conclusion 39 2. L authentification 802.1X 39 Extensible Authentication Protocol (EAP) 40 3. Le standard 802.11i 43 a. WiFi Protected Access 44 b. Robust Security Network 44 c. Advanced Encryption Standard 44 C. Voix sur 802.11 47 1. 802.11 e 48-3 -

2. Simulation de la voix sur 802.11 WLAN 49 D. Synthèse 52 IV. IPsec A. Le protocole IPsec 55 1. Authentication Header (AH) 56 2. Encapsulating Security Payload (ESP) 57 3. Internet Key Exchange (IKE) 58 4. synthèse 60 B. La voix sur IP 1. voix sur IP et Bande Passante 61 2. voix sur IPsec 63 C. Synthèse 64 V. Real Time Protocol 68 A. Le protocole RTP 69 1. RTP 69 2. RTCP 71 3. Taille d un paquet RTP 72 B. Le protocole SRTP 72 VI. Synthèse globale 77 A. Tableau comparatif 77 B. Conception d une solution de sécurité de la voix 80 1. Le service d authentification 81 2. Le service de chiffrement 84 Références 86-4 -

Sujet : Analyse, définition et conception d une solution de sécurité de la voix. Depuis l invention du premier téléphone par Alexandre Graham Bell en 1869, la téléphonie n a cessé d évoluer : de la commutation de circuit à la commutation par paquet, pour passer ensuite à la voix sur IP, au GSM, à la voix sur IP sur réseau mobile. Plusieurs architectures ont été crées où la voix est combinée aux données et à l imagerie. Un seul réseau est utilisé pour le transport de la voix et des données. De nouvelles architectures émergent : l architecture H.323 qui regroupe une diversité de protocoles nécessaires à la voix, aux données et à l imagerie, à la signalisation et au contrôle. Le partage des ressources entre ces différentes composantes du réseau implique l application de plusieurs protocoles pour gérer la bande passante tout en assurant une qualité de service appropriée à chaque service offert. L application de ces protocoles implique un temps de traitement énorme dont l impact est néfaste à la qualité de la voix, puisque cette dernière est sensible aux délais. La nature de ces réseaux ouverts a un impact sur la voix en terme de sécurité. D où le besoin imminent de sécuriser la voix tout en assurant une bonne qualité de service à la voix et aux donnés aussi bien dans un réseau fixe que dans un réseau mobile. Des solutions de sécurisation sont proposées pour les données. Mais des solutions partielles voir incomplètes sont proposées pour la voix. Nous proposons ce qui suit : 0- Etudier les solutions proposés pour les données 1- Analyse des différentes architectures utilisées pour la voix que ce soit pour un réseau fixe ou un réseau mobile 2- Problématique de la sécurité de la voix : a. Au niveau du réseau fixe b. Au niveau du réseau mobile Faut-il sécuriser la voix de bout en bout (niveau applicatif) ou il suffit de sécuriser au niveau des couches basses du réseau entre deux nœuds du réseau. 3- Analyse des protocoles utilisés pour la sécurité de la voix sur les différentes paltformes. Etudier l impact des protocoles associés (protocole de signalisation), leur temps de traitement sur la voix. - 5 -

Est-ce que les protocoles existants répondent aux exigences de la voix et sa sécurité? 4- Trouver une solution pour la sécurité de la voix, voir définir un nouveau protocole. - 6 -

Introduction La voix sur IP L Internet est le réseau le plus déployé à travers le monde actuellement. Beaucoup d équipements de communication supportent déjà le protocole TCP/IP pour se connecter à l Internet, comme les téléphones portables et les nouveaux PDA. La mobilité de l utilisateur devient de plus en plus indispensable, et la convergence de différents services comme les données et le multimédia, font augmenter la complexité des technologies actuelles. Tout le monde veut faire de la téléphonie, de la vidéoconférence, et du transfert de fichiers à partir du même poste, en utilisant le même réseau. C est ce qui devient la tendance de l Internet actuel, la convergence des services. Mais chaque type de service a des contraintes différentes. Par exemple le trafic de données par paquets est de type «Bursty». Les paquets peuvent avoir des longueurs variables engendrant des délais élastiques pendant leur transfert. Alors que le trafic de voix a des contraintes en termes de délai. S il est mélangé avec le trafic de données sans avoir une priorité sur celui-ci, les contraintes ne seront pas respectées et la qualité de réception sera médiocre. Ceci impose l implémentation des techniques de Qualité de Service sur le réseau pour assurer un compromis de performances. Le sujet des performances et de la qualité de service est un sujet à part, et ne fait pas l objet de cette étude. Et puisque l Internet est un réseau ouvert au grand public, ceci incite les attaques et l écoute de ce qui transite sur le réseau. D où s impose l utilisation de mécanismes de sécurité pour protéger les flux contre les attaques malintentionnées. Critères de la sécurité La sécurité devient de plus en plus importante dans le domaine des réseaux quelle que soit leur nature, mais surtout dans les réseaux sans fils dits Wireless. La sécurité dépendra du niveau demandé par l utilisateur, et la sensibilité des données en question. Des applications requièrent parfois un niveau élevé de sécurité, et d autres aucun niveau de sécurité. Ces niveaux de sécurité requis par des applications sensibles sont classifiés selon les critères listés ci-dessous : 1. Confidentialité des données: pour protéger les données transmises entre différents nœuds du réseau. La confidentialité existe uniquement en combinaison avec une authentification et un chiffrement appropriés. - 7 -

2. Authentification : vérification de l identité des entités communicantes, pour la prévention de l intervention d autres entités. 3. Intégrité : comme dans la confidentialité, les données circulant sur le réseau doivent être altérées uniquement par la source ou par des entités autorisées. Un processus de vérification de l intégrité du message transmis doit être mis en place. Ce processus est réalisé par une fonction de hachage. 4. Contrôle d accès : les services présents sur le réseau doivent être accessibles par des nœuds autorisés du réseau. 5. Non-répudiation : garantie que l origine d un message ne peut pas nier d avoir envoyé ce message. 6. Non-rejeu : le récepteur doit recevoir les données une seule fois afin d éviter l intervention d un troisième parti ayant pour rôle de dupliquer puis renvoyer les données modifiées. Travail effectué Tout d abord, les technologies suivantes ont été développées, avec leurs apports en termes de sécurité, et une idée brève de l impacte de la sécurité sur les performances de la voix. La Technologie Bluetooth est une technologie wireless. Elle est par nature conçue pour transporter un trafic de voix et multimédia, et a ses propres algorithmes de sécurité et assure les services d authentification et de chiffrement sans ajouter des entêtes aux paquets à envoyer. Elle est détaillée dans la première partie de ce document. Les réseaux GSM sont utilisés principalement pour la téléphonie. L accès au lien radio étant accessible au grand public engendre la nécessité d implémenter de la sécurité. Aussi, le besoin d authentification de l utilisateur auprès de l opérateur s impose. L aspect sécurité du réseau GSM est développé dans la deuxième partie de ce document. L utilisation des réseaux Wireless LAN devient de plus en plus demandée. Et le fait de pouvoir y intégrer plusieurs services, y compris celui de la téléphonie sur IP, le rend de plus en plus convoité. Pourtant les réseaux 802.11 sont initialement conçus pour le transfert des données, l aspect sécurité de ces réseaux est développé dans la troisième partie de ce document. La quatrième partie présente l impact du protocole IP sur le transport du trafic de voix à contraintes temps réel, ainsi que les services de sécurité d IPsec et leur impact sur la voix. Le protocole RTP spécialement conçu pour le trafic de voix est présenté avec son profil sécurisé SRTP dans la cinquième partie. - 8 -

Enfin, la synthèse de toute cette étude a résulté en un tableau comparatif des différents mécanismes de sécurité de chacune de ces technologies, et une conception de sécurité de la voix sur IP indépendante des technologies utilisées. - 9 -

I. Bluetooth A. Bluetooth Technologie 1. Historique Durant les années précédentes, les données furent transférées sur des mediums différents assurant l interconnexion d applications et d équipements. Il est évident qu un des problèmes de connexion de base est la connexion physique entre les équipements. La technologie Bluetooth introduit la possibilité de communication sans fils entre plusieurs équipements. Bluetooth est développée par Bluetooth Special Interest Group (SIG) en 1998. En 1994, Ericsson a investi dans la recherche pour découvrir une technologie à prix et consommation en ressources électriques assez bas, entre les téléphones portables et leurs accessoires. Plusieurs compagnies furent alors intéressées par Bluetooth, elles formèrent avec Ericsson le group SIG. 2. la technologie Bluetooth La technologie Bluetooth est conçue pour être à bas prix et basse consommation en courant, et permettre la communication entre équipements sans se soucier du câblage, c.à.d. le médium est l interface Air (Radio). C est une technologie robuste et efficace. Trois classes d équipements existent actuellement (classement par consommation électrique) : 1. classe 1 : équipements ayant une puissance de transmission allant jusqu à 100mW et ayant une portée de 100 mètres 2. classe 2 : équipement ayant 1-2.5mW de puissance de transmission et une portée de 10m 3. class 3 : 1mW de puissance et une portée de 1-10m respectivement Le standard Bluetooth spécifie l opération sur la bande de fréquences de 2.45GHz. et supporte des débits allant jusqu à 720kbps Bluetooth a deux types d architectures de réseaux fonctionnant selon l architecture maître/esclave (master/slave) : piconet étant le réseau le plus simple constitué d un seul maître et de un ou plusieurs esclaves (voir figure 1 suivante). Donc il support 2 à 8 équipements actifs dont un seul est le maître. scatternet tant l ensemble de plusieurs piconets interconnectés (voir figure 2 suivante) Chaque équipement peut participer à un ou plusieurs piconets (3 au maximum) soit comme esclave ou comme maître dans un piconet et esclave dans l autre. - 10 -

Figure 1 : Exemple d un Piconet Figure 2 : Exemple d un scatternet (composé de 3 piconets) 3. Bluetooth architecture protocolaire L architecture protocolaire générale de Bluetooth est représentée à la figure suivante. Un profil définit quelle partie des couches protocolaires est chargée dans un équipement pour effectuer une communication avec un autre, selon le type de service qu il utilisera. Figure 3 : architecture protocolaire Bluetooth - 11 -

Les significations des différentes couches sont regroupées dans le tableau suivant : Link Manager Pour authentification et gestion du piconet : configuration et établissement du lien de communication HCI Host Controller Interface L2CAP Link Layer Control and Adaptation Protocol: segmentation et réassemblage + qualité de service RFCOMM Protocole de transport pour émulation de port série (pour connexions d imprimantes et d ordinateurs portables) TCS Telephony Control protocol Specification : pour le contrôle d appels et la signalisation SDP Service Discovery Protocol : pour que l application voit les services proposés par Bluetooth OBEX Object Exchange protocol 4. Transmission de voix et données Pour éviter les interférences dues à d autres signaux, Bluetooth utilise la technique de saut de fréquences avec étalement de spectre (Frequency Hpooing Spread Spectrum) décrite à la figure 4 suivante. Nous n allons pas rentrer dans les détails de cette technologie, mais juste citer que l information, quelle que soit sa nature (temps réel ou données), est transmise sur des intervalles de temps (time slots) sautant en fréquence pour minimiser l influence des interférences. - 12 -

Figure 4 : technique de saut de fréquences L accès au médium est contrôlé par la station maître. C est le rôle principale de cette dernière : synchroniser et distribuer l accès au medium entre les nœuds d un même piconet. Chaque intervalle de temps a une durée de 625µs et peut contenir un paquet Bluetooth. La taille des paquets peut varier. Chaque paquet peut occuper soit 1, 3 ou 5 intervalles de temps. Deux types de liens utilisés dans Bluetooth sont représentés dans le tableau suivant : Synchrones SCO Asynchrones ACL Synchronous Connection Oriented Asynchronous Connection Less 64kbps chacune Asymétrique (57.6kbps 723kbps) Symétrique (432.6kbps) Les liens SCO forment une émulation de circuit pour le transport d information à contraintes temps réel, typiquement pour le transport de la voix. Le maître peut effectuer jusqu à 3 connexions avec le même esclave. Chaque esclave peut supporter 3 liens SCO en provenance du même maître, mais 2 SCO simultanés provenant de maîtres différents. Les liens ACL ferment une commutation de paquets entre les entités Bluetooth. Dans un piconet, un seul lien ACL peut exister entre un maître et un esclave. Chaque paquet circulant sur un lien ACL peut être mis sur 1, 3 ou 5 intervalles de temps. Types de poayload : DV (Données + voix ) DMx Data Medium de type ACL avec correction d erreurs, avec x le nombre de slots occupés DHx Data High de type ACL mais sans correction d erreurs. Ceci permet un débit effectif plus grand - 13 -

HVy High quality Voice de type SCO avec y déterminant le type de contrôle d erreurs: Y=1 FEC 1/3 Y=2 FEC 2/3 Y=3 pas de FEC 5. Format d un paquet Bluetooth Toute information transitant dans un piconet entre un maître et un esclave est sous la forme de paquets. Le format d un paquet Bluetooth est le suivant : Figure 5 : Format du paquet Bluetooth Figure 6 : champs de l entête Bluetooth Les différents champs du paquet Bluetooth sont illustrés dans le tableau suivant : Access Code Header Payload 68/72 bits 54 bits 0 2745 bits Dérivé de l adresse bluetooth du maître (BD_ADDR) pour identifier un canal physique AM_ADDR active member Address TYPE type de paquet et le nombre de slots qu il occupe FLOW Contrôle de flux des paquets sur le lien asynchrone ARQN Numéro d acquittement SEQN Numéro de séquence HEC Header Error Check: correction d erreur de l entête. Données utiles - 14 -

B. Bluetooth Sécurité Trois niveaux de sécurité sont définis dans Bluetooth : sans sécurité authentification et confidentialité au choix authentification et confidentialité obligatoires La spécification Bluetooth définit trois modes de sécurité : 1. mode non sécurisé 2. sécurité niveau service : mise en place après l établissement de la communication 3. sécurité niveau lien : établie avant l établissement du canal Remarque : Dans Bluetooth, les équipements sont authentifiés et non les utilisateurs donc on ne peut pas appliquer la non répudiation. Dans chaque équipement Bluetooth, quatre entités existent pour maintenir la sécurité au niveau lien : - l adresse Bluetooth (BD_ADDR) codée sur 48 bits, et unique pour chaque équipement Bluetooth et définie par l IEEE (Institute of Electrical and Electronics Engineers) - la clé d authentification qui est un nombre aléatoire de 128 bits, utilisée pour l authentification. - la clé de chiffrement privée de 8 à 128 bits utilisée dans le chiffrement - un nombre aléatoire RAND généré par l équipement Bluetooth lui-même. Sa longueur est de 128 bits et sa valeur change fréquemment Dans un profil générique d accès Bluetooth, la sécurité est divisée en trois modes : 1. mode non-sécurisé 2. mode de sécurité renforcé niveau service 3. mode de sécurité renforcé niveau lien La différence entre les modes 2 et 3 est que dans le mode 3, l équipement Bluetooth commence les procédures de sécurité avant l établissement du canal. Sécurité niveau liaison Comme toute forme de réseau sans fil, les signaux Bluetooth peuvent être interceptés. Les données interceptées peuvent être alors falsifiées. La spécification Bluetooth définit deux modes de sécurité niveau liaison : a- Saut de fréquence sur la bande de 2.4GHz. Tous les participants d un même piconet sautent ensemble sur les mêmes fréquences b- authentification avec lancement d un défi et réception d une réponse 1. Gestion des clés Toutes les transactions sécurisées entre deux ou plusieurs partis sont prises en charge par la clé de lien (ou link key). Cette dernière est un nombre aléatoire de 128 bits. Elle - 15 -

est utilisée dans la procédure d authentification et pour la dérivation de la clé de chiffrement. La durée de vie de la clé de lien dépend de son type temporaire ou semi permanente : - une clé semi permanente peut être utilisée après la terminaison de la session courante pour l authentification des équipements communicants - la clé temporaire dure seulement jusqu à ce que la session courante soit terminée, et ne peut pas être réutilisée. Un usage commun de cette clé est dans les sessions point à multipoint où la même information est transmise à plusieurs récipients. Différents types de clés sont définis dans Bluetooth. Les «link keys» peuvent être : - combination keys - unit keys - master keys - initialisation keys et ce, selon le type d application. En plus des clés «link keys», vient s ajouter la clé de chiffrement. Génération des clés : 1. unit key est générée dans un équipement lors de son installation 2. combination key générée à partir d information collectée de deux équipements Bluetooth. Elle est générée entre deux équipements désirant communiquer. 3. master key est une clé temporaire destinée à remplacer la clé «link key» courante. Elle peut être utilisée lorsque l équipement maître veut transmettre à plusieurs esclaves. - 16 -

4. initialisatio key est utilisée comme clé de lien durant la procédure d initialisation quand il n y a pas encore de clé unit ou combination. Elle est utilisée uniquement durant l installation Note : La longueur du code PIN (Personal Identification Number) utilisé dans les équipements Bluetooth peut varier de 1 à 16 octets. Le code de 4 digits peu être suffisant pour quelques types d applications, mais d autres applications ayant besoin d une sécurité plus renforcée peuvent utiliser des PIN plus longs. Figure 8 : Algorithme E22 générant les clés master et d initialisation a. initialization key elle est utilisée quand deux équipements ont besoin d initier une communication. Durant la procédure d initialisation, le code PIN est entré par l utilisateur dans les deux équipements. La clé d initialisation elle est générée par l algorithme E22 qui lui utilise le code PIN, d adresse Bluetooth de l équipement désirant communiquer, et un nombre aléatoire de 128 bits généré par l équipement comme données d entrée pour l algorithme E22. La clé d initialisation résultante est utilisée pour l échange de clés durant la génération de la clé de lien. Après l échange de clés, la clé d initialisation est rejetée. - 17 -

b. unit key Figure 9 : Algorithme E21 pour la generation des clés unit et combination La clé unit est générée par l algorithme E21 lorsqu un équipement Bluetooth rentre en opération pour la première fois. Après sa création, elle est enregistrée dans une mémoire non volatile dans l équipement et n est modifiée que rarement. Un autre équipement peut utiliser la clé unit d un autre comme clé de lien. c. combination key La clé combination est générée durant le processus d initialisation si les équipements ont décidé de l utiliser. Elle est générée par les deux partis en même temps. En premier temps, les deux unités génèrent un nombre aléatoire. Avec l algorithme de génération de clés E21, les deux équipements génèrent une clé, et combinent le nombre aléatoire avec leur BD_ADDR. Suite à cela, les équipements échangent de façon sécurisée leurs nombres aléatoires et calculent la clé de combinaison qui sera utilisée entre eux. d. Master key La clé master est la seule clé temporaire entre les clés de lien décrites ci-dessus. Elle est générée par l équipement maître en utilisant l algorithme E22 avec deux nombres aléatoires de 128 bits. Toutes les clés de lien ont une longueur de 128 bits, la sortie de l algorithme E22 est aussi de 128 bits. Un troisième nombre aléatoire est transmis à l esclave et avec l algorithme et la clé de lien courante, un résultat est calculé par le maître et l esclave. Le maître effectue alors l opération OU-exclusif sur la clé master et le résultat retourné précédemment et l envoie à l esclave qui lui calcule la master key. Cette procédure doit être répétée entre chaque deux équipements maître/esclave désirant communiquer en utilisant la master key. - 18 -

e. clé de chiffrement ou encryption key Figure 10 : Algorithme E3 pour génération de la clé de chiffrement La clé de chiffrement est générée à partir de la clé de lien courante, et un nombre de 96-bits, le COF (Cyphering Offset Number), qui lui est généré par la procédure d authentification. Quand le Link Manager active le chiffrement, la clé de chiffrement est générée. Elle est changée automatiquement à chaque fois que l équipement Bluetooth rentre dans le mode chiffrement. 2. Chiffrement dans Bluetooth Algorithme E0 Le système de chiffrement dans Bluetooth chiffre les données utiles (payload seulement) et non n ensemble des paquets. Ceci est fait par l algorithme de chiffrement E0 qui est re-synchronisé avec chaque bloc de données utiles. Le schéma logique de l algorithme E0 est décrit dans la figure suivante. - 19 -

Figure 11 : La procédure de chiffrement Plusieurs modes de chiffrement sont envisageables, dépendamment de l utilisation de clés semi permanentes ou de la master key. Si la clé unit ou combination est utilisée, le trafic de type broadcast ou diffusion n est pas chiffré. Le trafic adressé à une ou plusieurs stations pourrait éventuellement être chiffré. Si la clé master est utilisée, 3 modes possibles existent : - Mode de chiffrement 1 : rien n est chiffré - Mode de chiffrement 2 : le trafic de diffusion n est pas chiffré mais le trafic adressé est chiffré avec la clé master - Mode de chiffrement 3 : tout le trafic est chiffré avec la clé master Comme la taille de la clé de chiffrement varie de 8 à 128 bits, cette taille doit être négociée entre deux équipements désirant communiquer. Dans chacun d eux, il y a un paramètre définissant la taille maximale permise pour une clé. Durant la négociation de la taille des clés, le maître envoie à l esclave la taille qu il suggère pour la clé de chiffrement. L esclave à son tour peut accepter la taille suggérée et envoyer un acquittement positif, ou bien suggérer une autre taille au maître. Ceci se répète jusqu à ce que les deux partis consentent, ou bien l un deux arrête la négociation. L arrêt de la négociation est décidé au niveau applicatif, et dans ce cas, le chiffrement ne peut pas être appliqué. Ceci est nécessaire pour éviter des situations où un équipement mal intentionné force l utilisation d une clé de chiffrement faible, facilement craquable pour des fins néfastes. - 20 -

3. Authentification Algorithme E1 L authentification sous bluetooth utilise la stratégie défi/réponse. Le protocole d authentification utilise une clé symétrique. Alors une authentification réussie est basée sur la même clé possédée par les deux partis. L ACO (Authenticated cyphering Offset) utilisé par l algorithme E3 ci-dessus, est calculé et enregistré dans les deux équipements et est utilisé pour la génération de la clé de chiffrement. Figure 12 : La procédure d authentification Les deux participants utilisent la fonction d authentification E1 avec un nombre aléatoire, l adresse Bluetooth et la clé de lien courante pour calculer la réponse au défi lancé. La réponse est envoyée l autre parti qui à son tour vérifie l identité. L application utilisée indique qui doit être authentifié. Alors l équipement effectuant la vérification n est pas nécessairement le maître. Certaines applications requièrent une authentification dans un seul sens, ainsi un des partis est authentifié uniquement. Ceci n est pas toujours le cas, où parfois les deux partis doivent être authentifiés tour à tour. Si l authentification échoue, un intervalle de temps doit s écouler avant qu un nouvel essai d authentification ne soit fait. Cet intervalle de temps est doublé à chaque fois qu une tentative échoue, à partir d une même adresse, jusqu à ce que le temps d attente maximal soit atteint. Ce temps d attente diminue exponentiellement jusqu à atteindre un minimum lorsque aucune tentative d authentification n échoue durant une période de temps. - 21 -

4. Problèmes de sécurité de Bluetooth a. Chiffrement et KeyStream La procédure de chiffrement dans Bluetooth présente plusieurs vulnérabilités. L algorithme de chiffrement E0 avec une clé de 128 bits peut être cassé dans certaines circonstances. Nous n allons pas nous attarder sur la preuve mathématique dans ce document. Toutefois, cette attaque est prise en compte dans la spécification Bluetooth. Pour l exécuter on a besoin d accéder au KeyStream chiffrant chaque paquet. Or le KeyStream a une fréquence de re-synchronisation assez grande de sorte à ce qu un bout de keystream différent est utilisé pour chiffrer chaque trame. Alors la possibilité d attaque devient médiocre. b. Entrer le code PIN Le problème d utilisation d équipements Bluetooth se pose aussi. L utilisation du code PIN dans la procédure d initialisation d un équipement Bluetooth est assez embêtante. Le faite de faire rentrer le code PIN au niveau des deux équipements désirant communiquer est assez ennuyante même si on utilise des codes courts. Or la spécification Bluetooth suggère l utilisation d une clé au niveau applicatif avec des PIN longs (de l ordre de 16 octets). De cette façon le code PIN n a pas besoin d être rentré à chaque connexion, mais sera échangé entre les équipements avec un algorithme de gestion de clés comme Deffie-Hellman. c. la clé d initialisation La génération de la clé d initialisation doit aussi être prise en compte. La force de la clé d initialisation est proportionnelle à la longueur du code PIN. Le générateur E22 de la clé d initialisation dérive la clé du code PIN, la longueur du PIN et un nombre aléatoire qui est transmis sur l interface radio. La sortie de cet algorithme est suspecte, tant que le seul secret est le code PIN. En utilisant un code PIN de 4 digits, 10.000 possibilités existent seulement, en rajoutant que dans 50% des cas le code PIN est composé de quatre 0000. La fiabilité de la clé d initialisation s avère être assez faible. d. la clé unit L authentification et le chiffrement Bluetooth sont basés sur le secret partagé qui est la clé de lien. Toute autre information utilisée dans ces procédures est publique. On suppose que deux équipements A et B utilisent la clé unit de A comme leur link key partagée. En même temps ou un peu plus tard, l équipement C désire communiquer avec A en utilisant la clé unit de A comme link key. Ceci implique que B qui a déjà obtenu la clé unit de A peut l utiliser avec une fausse BD_ADDR - 22 -

pour calculer la clé de chiffrement, et ainsi écouter le trafic transitant sur le lien radio. Il peut aussi s authentifier auprès de A comme étant C, et auprès de C comme étant A. d. l adresse Bluetooth L adresse Bluetooth, qui elle est unique à chaque équipement Bluetooth, introduit un nouveau problème. Une adresse Bluetooth identifiant un équipement identifie aussi son utilisateur. Les transactions effectuées sur le réseau par cette personne peuvent être enregistrées et ceci viole la confidentialité et la privatisation. C. Performances de la voix sur ACL 1. Introduction Deux types de connexions peuvent être établies dans un piconet. - Synchronous Connection Oriented (SCO) ou bien connexions synchrones orientées connexion - Asynchronous connection less (ACL) ou bien asynchrones et non orientées connexion Les liens SCO offrent un service orienté circuit avec bande passante constante et une allocation périodique constante de slots. En contrepartie, les connexions ACL offrent un service paquet. Dans les deux cas, l équipement maître utilise un mécanisme de polling pour diviser la bande passante du piconet entre les liens ACL et SCO. Les liens SCO par leur nature laissent peu de bande passante pour les ACL qui à un certain moment peuvent être à court de bande. Pour cette raison, une tendance à utiliser des liens ACL pour la voix a été développée et des simulations et des expériences ont été faites pour montrer que la qualité de la voix sur ACL n est pas moins bonne que sur SCO. (Référence article «Bluetooth : carrying voice over ACL links» par Rohit Kapoor, Ling-Jyh Chen, Yeng-Zong Lee et Mario Gerla). Les experiences faites dans cet article montrent que la voix est peu affectée par son transit sur des liens ACL au lieu de SCO. La performance de TCP est meilleure sur les liens ACL. Le maître divise la bande passante équitablement entre les esclaves. Et selon les mécanismes de polling d accès au médium contrôlés par le maître, les liens ACL suffisent pour la circulation d une bonne qualité de voix sur IP. Ceci permet l utilisation de façon plus efficace de la bande passante. La voix risque - 23 -

toutefois de se dégrader sur ACL, comparé à SCO, lorsque le trafic augmente. Les expériences suivantes le montrent. 2. Simulation Environnement Soit un piconet avec 7 esclaves. Les esclaves communiquent entre eux deux à deux. Les points source et destination sont choisis aléatoirement. Les sources de voix sont basées sur le modèle ON-OFF. Le codage de la voix est basé sur un échantillonnage de 8kbps et la période de paquétisation est de 20ms. Ce qui résulte en un payload de 20 bytes. La compression d entête existant dans Bluetooth, ceci implique une chaque paquet aura une taille de 30 bytes. La transmission de la voix utilise RTP sur UDP. Résultat et commentaires La figure suivante montre la distribution de délai lorsque le nombre de connexions varie de 5 à 15 dans le piconet. Figure 1 : Distribution du délai de la voix lors de son transport sur ACL On remarque une augmentation de délai de 80 ms environ selon tout le graphe en abscisse. Mais toutefois, le délai restera toujours inférieur à 100ms, ce qui est toujours acceptable pour la voix. - 24 -

3. Expérimentation But on veut comparer les délais de ACL par rapport aux différents niveaux de SCO (HV1, HV2 et HV3). Environnement Des paquets de voix de 100 bytes sont codés sur 100ms. Dans ce cas les délais seront supérieurs à ceux de la recommandation Bluetooth. Soit un piconet avec deux esclaves et un maître. Chaque esclave établissant une connexion avec le maître selon des conditions ci-dessus. Résultats Le tableau suivant donne la valeur moyenne du délai pour les différents types de connexions, dans le cas ou on ouvre une seule connexion de voix entre un esclave et le maître : Délai moyen par paquet de voix (ms) SCO (HV1) SCO (HV2) SCO (HV3) ACL 7.094 15.061 20.061 15.385 On remarque que le délai pour ACL se trouve entre HV2 et HV3. Donc, ACL peut être plus efficace en termes de délai par rapport à SCO et pour la voix. Les figures suivantes montrent la distribution du délai de ACL par rapport aux types de SCO et en fonction de l augmentation du nombre de connexions. 1 er cas : Les deux esclaves effectuent une connexion de voix avec le maître, mail l un d eux sur ACL et l autre sur SCO. Ceci a donné les deux graphes ci-dessous selon le type du lien SCO : HV2 (fig 2 ci-dessous) et HV3 (Fig 3 ci-dessous) - 25 -

Figure 2 : Distribution du délai de la voix pour ACL et SCO HV2 Figure 3 : Distribution du délai de la voix pour ACL et SCO HV3 2 ème cas : Deux esclaves communiquent avec la station maître. Un des esclave effectue une connexion TCP et l autre fait de la voix. L expérience est répétée deux fois : - Une fois avec la voix sur ACL - Une deuxième fois avec la voix sur SCO HV2 (fig 4 suivante) et HV3 (fig 5 suivante). - 26 -

Figure 4 : Distribution du délai de la voix pour ACL et SCO HV2 Figure 5 : Distribution du délai de la voix pour ACL et SCO HV3 Les figures ci-dessus renforcent les résultats du tableau et montrent que les performances en terme de délai de ACL sont meilleures que HV3 mais pire que HV2. - 27 -

4. Conclusion On peut dire que la voix sur ACL ou bien la voix paquetisée peut bien être utilisé, sauf si le besoin d une qualité impeccable s impose. Donc ACL est un bon choix pour l acheminement de la voix. L utilisation de ACL rend les algorithmes d ordonnancement plus simples. Ceci est aussi un avantage d ACL pour le transport de la voix, mais ce ne sera pas couvert dans ce compte rendu. D. Synthèse Les réseaux Bluetooth sont initialement conçus pour supporter le trafic à contraintes temps réel. Ceci est démontré par la présence de canaux SCO pour le transport de la voix. Nous avons déjà vu que le nombre de connexions entre maître et esclave est limité, selon le type de lien établi. Ainsi, les performances des algorithmes d authentification et de chiffrement (respectivement E1 et E0) ne seront pas affectées et n affecteront pas la qualité de la voix transmise. La voix sur Bluetooth n est pas transportée sur IP. Elle est mise dans des paquets juste au dessus du niveau bande de base. (Voir la figure 1 de l architecture protocolaire au début du document). La signalisation sera transportée par la couche TCS (Telephony Control protocol Specification) sur L2CAP. Les services de sécurité couverts par Bluetooth sont : l authentification des équipements et non des utilisateurs. Ainsi, la non répudiation ne peut pas être implémentée L authentification est assurée par l algorithme E1 décrit dans la partie précédente la confidentialité assurée par l algorithme E0 L algorithme de chiffrement E0 de Bluetooth est câblé. Pour cela, il n y a aucun souci d affectation des performances de la voix. Le chiffrement dans Bluetooth est effectué au dessus de la couche BaseBand. Ainsi, tous les paquets, que ce soit ACL ou SCO, sont chiffrés. Des failles des sécurité existent dans Bluetooth, et sont dues à l algorithme E0 qui peut dans certains cas être craqué. Pour renforcer cela, il suffit de choisir un code PIN plus grand et assez aléatoire. - 28 -

II. GSM Global System for Mobile Communication (GSM) est le système de téléphonie mobile le plus populaire dans le monde. Un de ses grands avantages est le roaming international permettant à l utilisateur la mobilité dans 168 pays à travers le monde. A. GSM Architecture L architecture d un réseau GSM est représentée à la figure 1 suivante. L objectif de notre étude n est pas d exposer l architecture GSM, mais la sécurité de la voix qui y est implémentée. Figure 1 : architecture d un réseau GSM Quelques composants d un réseau GSM sont listés dans le tableau suivant : MS BSS MSC OMC VLR/HLR Station mobile Base station subsystem composée de la station de base contenant l antenne d une cellule, et la BSC qui est le contrôleur central à plusieurs BTS Le commutateur central du réseau GSM Station de gestion du réseau Bases de données contenant des informations sur les utilisateurs, dont les triplets qu on verra dans la partie sécurité suivante Entre le téléphone mobile et la BTS, la communication passe sur l interface radio, en utilisant des canaux logiques qui ne sont pas l objet de notre étude. - 29 -

Vu la présence de l interface Air (radio), l écoute sur le réseau s avère possible dans le cas qu aucune mesure de sécurité n est prise. L accès au medium dans le réseau GSM est contrôlé par le réseau de l opérateur. Tout comme Bluetooth, une technique de saut de fréquences est adoptée pour protéger le lien radio des interférences dues aux canaux adjacents ou bien à un troisième parti malintentionné. Les accès se font à des instants bien déterminés. Les échantillons de voix codés sur 8 bits sont entrelacés avec d autres et mis dans des slots ou intervalles de temps. Les slots sont acheminés à la MSC qui effectue la commutation vers la destination. Ainsi nous allons nous arrêter sur la sécurité implémentée sur l interface radio du réseau GSM. B. GSM sécurité La sécurité de GSM doit assurer ce qui suit : Confidentialité et anonymat sur le lien radio Authentification forte du client pour protéger l opérateur contre les fraudes (surtout dans le domaine de la tarification) Empêcher la surveillance inter opérateurs pour alléger la pression due à la compétition Les mécanismes de sécurité ne doivent pas ajouter de la lourdeur à l établissement de l appel, ni augmenter l utilisation de la bande passante, ni augmenter le taux d erreurs, ni ajouter de la complexité au système. Chaque équipement mobile GSM a une carte SIM (Subscriber Identity Module). La carte SIM donne à la station mobile une identité unique IMSI (International Mobile Subscriber Identity). La carte SIM est comme une clé sans laquelle la station mobile ne pourra pas fonctionner. Cette carte est capable d enregistrer des numéros de téléphone et des messages courts (SMS) La carte SIM contient aussi de l information relative à la sécurité comme : l algorithme A3 utilisé pour l authentification l algorithme A8 générant la clé de chiffrement la clé d authentification Ki et l identité IMSI La station mobile abrite l algorithme A5 de chiffrement. Le modèle de sécurité de GSM est basé sur un secret partagé entre la base de donnée HLR (Home location Register) de l opérateur de l abonné. Le secret partagé est la clé - 30 -

Ki de 128 bits, utilisée pour générer une réponse SRES au défi RAND envoyé par le MSC. 1. l authentification GSM La MSC lance un défi à la station mobile à authentifier. Ce défi est un nombre aléatoire RAND que la MSC envoie sur l interface radio à la station mobile. Cette dernière, après réception de RAND, le passe à l algorithme A3 (figure 2) avec la clé partagée Ki et génère en sortie une réponse SRES Figure 2 : Algorithme A3 d authentification SRES sera signé et renvoyé à la MSC sur le lien radio. La MSC possède pour chaque utilisateur, dans les bases de données VLR/HLR, un triplet composé de RAND, SRES et la clé Kc de chiffrement (voir figure 4). Suite à cela, la MSC vérifie que SRES reçu par le mobile est bien celui enregistré dans le triplet (voir figure 3 suivante). Figure 3 : procédures d authentification et de chiffrement dans GSM - 31 -

2. le chiffrement GSM A la réception du défi RAND, la carte SIM va le passer à l algorithme A8 qui va générer la clé de chiffrement Kc qui sera utilisée comme clé symétrique pour chiffrer l information transitant dans les deux sens sur le lien radio entre le mobile et le MSC. Figure 5 : Algorithme A8 de génération de la clé de chiffrement Kc La clé Kc va alors alimenter l algorithme A5 pour chiffrer le flux de voix à envoyer sur l interface Air (ou radio). Le déchiffrement se fera aussi avec A5 à l autre bout. Figure 6 : Algorithme de chiffrement/déchiffrement A5 La spécification de l algorithme de chiffrement A5 de GSM 2 ème génération n a jamais été publiée. Ce qui fait qu il existe une version faible de cet algorithme susceptible aux attaques. Les algorithmes A3 et A8 sont dépendants de l opérateur. Chaque opérateur peut acheter une version au group GSM, ou bien de la modifier pour avoir son propre algorithme. Certains utilisent la fonction COMP128 pour remplacer les deux algorithmes A3 et A8 de la carte SIM. - 32 -

Figure 7 : Fonction COMP128 remplaçant A3 et A8 chez certains opérateurs La fonction COMP128 comme la figure 7 ci-dessus le montre, a comme entrées les mêmes données que A3 et A8, et la sortie unique est la combinaison de SRES et de la clé Kc de chiffrement. C. Synthèse GSM est un réseau conçu à la base pour la commutation de circuits de voix. Donc les performances sont étudiées pour ne pas affecter la qualité de la voix, surtout que le service GSM est essentiellement un service de voix. Le réseau GSM 2 ème génération n est pas conçu pour faire de la voix sur IP comme le réseau UMTS tout IP qui ne fait pas partie de notre étude. Les algorithmes d authentification et de chiffrement sont câblés dans la carte SIM (A3 et A8) et dans le téléphone mobile lui-même (A5). Ainsi les performances ne seront pas affectées. Les services de sécurité couverts par GSM sont : L authentification de la carte SIM, qui peut être considérée comme authentification de l utilisateur car l opérateur considère que la personne qui a acheté la carte l utilise. Cette authentification est faite vis-à-vis de l opérateur pour la tarification en premier lieu, et de bout en bout afin que l appelé sache qui l appelle s il a l option CLIP (Caller Line ID) Le chiffrement sur le lien radio uniquement, entre l opérateur et la station mobile, car la partie câblée de l opérateur est considérée comme fiable. L authentification vis-à-vis du réseau GSM requiert la présence d un tiers, qui est la base de données contenant le triplet relatif chaque station mobile (ou carte SIM). La carte SIM identifie l utilisateur auprès de l opérateur. Donc dans ce cas on va audelà de l authentification de l équipement qui fut le cas de Bluetooth. Ainsi, la présence d une base de données peut être envisageable pour une nouvelle idée de conception de sécurité de la voix sur IP. - 33 -

III. Wireless LAN Actuellement, dans tous les environnements de travail on trouve un réseau Ethernet câblé. Dans ce cas, chaque PC doit être raccordé au réseau avec un câble. Les réseaux dits Wireless ou sans fils offrent les mêmes services mais sans fils. Le raccordement d un PC au réseau se fait à travers un lien radio. Les réseaux WLAN ou Wireless Local Area Network sont standardisés par le groupe IEEE comme ont été standardisés Ethernet ou Token Ring. Le standard WLAN est connu sous le terme IEEE 802.11. A. 802.11 Architecture Le but de notre étude n est pas l architecture des WLAN, mais le côté sécurité de ceux-ci et surtout l impact de la voix sur 802.11. Pour cela, un passage rapide sera fait sur le côté architecture de ces réseaux-là. Chaque PC avec sa carte réseau wireless va se connecter au réseau WLAN via un point d accès. Le point d accès est l interface entre l environnement Wireless et le monde câblé. Figure 1 : Accès au Réseau Wireless Les fréquences utilisées sur le lien radio par un réseau WLAN sont : 900MHz, 2.4GHz et 5GHz. L interface radio peut aussi fonctionner sur Infra Rouge, mais l inconvénient devient la couverture qui devient assez étroite (l espace d une chambre puisque les murs sont isolants). Les systèmes WLAN à large bande fonctionnent par étalement de spectre pour éviter les interférences environnantes. Deux formes d étalement de spectre s imposent : - 34 -

FHSS : Frequency Hopping Spread Spectrum DSSS : Direct Sequence Spread Spectrum Le coût d implémentation de FHSS est inférieur mais DSSS peut offrir des débits supérieurs, une largeur de bande supérieure et une capacité intégrée de correction d erreurs. FHSS : La porteuse saute en fréquences en fonction du temps. Chaque équipement est programmé avec un code de saut qui détermine l ordre des fréquences. Pour communiquer correctement, les équipements doivent avoir le même code de saut pour synchronisation. On peut assigner plusieurs codes de sauts à un même WLAN afin d éviter les interférences entre deux sous WLAN. Ainsi, la bande de 2.4GHz est divisée en 75 canaux. Le signal saute sur les canaux selon one séquence gérée par un code pseudo aléatoire détenu par l émetteur et par le récepteur. Il existe 22 séquences prédéfinies. Le récepteur détecte la séquence suivie par l émetteur. Le fait que le signal soit étalé sur plusieurs fréquences minimise le risque d interférences. DSSS : L émetteur ajoute une chip aux paquets à émettre. Le récepteur doit posséder le même chip pour décoder les paquets. Ainsi le signal résultant émis n est pas susceptible aux interférences. Comme la taille du signal étalé augmente après l ajout du chip, DSSS requiert alors plus de bande passante pour fonctionner. La capacité de correction d erreurs élimine les besoins de retransmission. Ainsi, en plus de détails, chaque bit à émettre est multiplié par un chip de 11 bits. Chaque chip est transformé en une sinusoïde et envoyé sur une large bande de fréquences. Le récepteur peut ainsi décoder le chip reçu pour avoir le signal émis. Dans le standard 802.11, il existe 64 codes de 8 bits pour étaler le signal. Le standard 802.11b Le standard 802.11 fonctionne sur la bande 2.4 2.48GHz 802.11b utilise uniquement la technique de transmission DSSS. Le débit dans ces réseaux-là peut atteindre 5.5 et 11Mbps. Malgré les avantages des réseaux sans fils, WLAN est vulnérable aux failles de sécurité. Les failles communes dans WLAN sans sécurité sont : l écoute de l information transitante (sniffing) l accès non autorisé au réseau les interférences et le brouillage les pannes physiques - 35 -

Ces failles peuvent être évitées selon la configuration du WLAN : Les systèmes utilisant la technologie d étalement de spectre résistent aux interférences et à l écoute passive des canaux La mise en place d algorithmes de sécurité ou le remaniement du standard 802.11 peut cependant introduire l authentification et le chiffrement. Ceci sera le sujet de notre étude dans le paragraphe suivant Une bonne formation des utilisateurs est aussi très importante afin de réduire les risques B. 802.11 sécurité Comme les réseaux Wireless dont nous avons étudié l aspect sécurité (Bluetooth et GSM), les réseaux 802.11 ont une interface radio à sécuriser. 1. Wired Equivalent Protocol (WEP) Comme son nom l indique, il permet de sécuriser le transfert sur l interface radio de façon à avoir l équivalent d un réseau câblé. Son but est d assurer un certain niveau de confidentialité en cryptant le signal à émettre sur le lien radio et de ne pas permettre à des utilisateurs non autorisés d accéder au WLAN. Donc WEP assure confidentialité, intégrité et authentification. a- Chiffrement WEP WEP utilise dans son chiffrement une clé partagée de 40 à 128 bits de taille, entre la station mobile et le point d accès. Le standard 802.11 permet d allouer à chaque station sa propre clé partagée selon un tableau enregistré dans le point d accès. Par défaut, une seule clé est partagée entre toutes les stations reliées au même point d accès. Le chiffrement WEP est décrit à la figure 2 suivante. Un vecteur d initialisation (IV) est ajouté à la clé secrète partagée, et en clair dans le payload à envoyer sur le lien. La clé secrète et le IV alimentent un générateur pseudo aléatoire qui donnera en sortie la clé de chiffrement. Les données à transmettre dites Plaintext sont passées à un algorithme de calcul d intégrité qui dans le cas de WEP est le RC4. C est une fonction de hachage qui calcule un condensât du Plaintext. Ensuite, le Plaintext et le condensât subissent l opération OU-Exclusif avec la clé de chiffrement formant ainsi en sortie le message chiffré prêt à l envoi, dit Ciphertext. - 36 -

Figure 2 : Chiffrement WEP L opération de déchiffrement à la réception est décrite à la figure 3 suivante. Le récepteur reçoit le Ciphertext et en extrait le vecteur d initialisation IV, et passe ce dernier avec la clé secrète partagée avec l émetteur à un générateur de nombre pseudo aléatoire (le même que celui de la source) pour avoir la même clé de chiffrement. L opération OU-Exclusif sera exécutée sur le Ciphertext et la clé de chiffrement pour en retirer le Plaintext initial. Le contrôle d intégrité sera alors effectué en appliquant le même hachage RC4 sur le Plaintext résultant et le comparant avec la valeur du condensât reçu de l émetteur (le ICV sur le schéma Integrity Check Value). Figure 3 : Déchiffrement WEP et contrôle d intégrité Le vecteur d initialisation est changé à chaque message envoyé. Remarque : La distribution de la clé partagée s avère être un problème de sécurité. Certains administrateurs préfèrent la configurer eux-mêmes sur chaque station à connecter sur le WLAN. Mais la vulnérabilité persiste vu que la clé est enregistrée sur le disque dur et peut être accédée. - 37 -

b- Authentification dans WEP Deux types d accès sont présents dans les réseaux 802.11 : Open system : tous les utilisateurs peuvent accéder au point d accès donc au réseau Shared Key Authentication : authentification basée sur la clé partagée utilisée aussi dans le chiffrement déjà vu ci-dessus La deuxième méthode est bien sûr la plus sécurisée. Lorsqu une station essaie de communiquer avec un point d accès, ce dernier lui lance un défi qui est un texte aléatoire. La station doit alors utiliser la copie de sa clé secrète pour chiffrer ce défi avec la fonction XOR (OU-Exclusif) et l envoyer au point d accès afin de s authentifier. Le point d accès à son tour décrypte le texte reçu avec XOR et le compare à celui qu il a envoyé. S ils sont identiques, le point d accès envoie un message de confirmation à la source. Sinon le point d accès n autorise pas l accès à la station source. Figure 4 : procédure d authentification WEP Notes : Il faut remarquer que l authentification avec clé partagée ne peut être effectuée que si la chiffrement est mis en œuvre. S il ne l est pas, le point d accès sera dans le mode Open System. Dans le cas où la clé est partagée entre toutes les stations, l authentification individuelle est impossible. Cette vulnérabilité peut aboutir à un accès non autorisé surtout si le système supporte un grand nombre d utilisateurs. Dans plusieurs systèmes WLAN, la même clé partagée utilisée dans le chiffrement est utilisée dans l authentification. Donc si un attaquant possède la clé, il peut non seulement accéder au réseau mais aussi décrypter les données qui y transitent. - 38 -

Le protocole WEP est devenu trop connu et publique, ce qui le rend plus susceptible aux attaques. Une autre méthode d authentification peut être utilisée dans WEP par utilisation du ESSID (Extended Service Set ID) par point d accès. Le ESSID identifie le subnet auquel appartient chaque point d accès. Ainsi, si une station ne connaît pas le ESSID, elle n est pas autorisée à communiquer avec le point d accès concerné. De plus, plusieurs constructeurs mettent des listes d accès (Access lists ACL) dans les points d accès pour permettre à des adresses MAC qui y sont définies d avoir accès au point d accès, donc au réseau. c- conclusion WEP a introduit les trois fonctions de sécurité suivantes : L authentification Le chiffrement L intégrité assurée par la fonction de hachage RC4. Le protocole WEP n est pas assez sécurisé. Il est basé sur la fonction XOR connue. Il suffit de détenir la clé secrète pour générer la clé de chiffrement et décrypter les paquets qui transitent. La gestion des clés est assez faible : La gestion des clés doit être faite par l administrateur du réseau WLAN. C est lui qui place configure chaque station avec une clé secrète partagée avec le point d accès. La clé secrète partagée entre le point d accès et la station est enregistrée sur le disque dur côté station. Donc elle peut être facilement accessible. La clé partagée est utilisée pour l authentification ainsi que dans le chiffrement. Ceci présente un autre point faible car celui qui prend possession de la clé n est pas uniquement authentifié, mais accède au réseau et peut écouter ce qui transite si le réseau est mal configuré Le protocole WEP est vulnérable à des attaques déjà bien connues. Pour cela le groupe IEEE a essayé de concevoir d autres méthodes pour sécuriser les réseaux 802.11, ce qu on verra par la suite. 2. L authentification 802.1X Vu l inefficacité de WEP, IEEE a commencé par introduire un standard d authentification pour les réseaux 802.11 qui est le 802.1X. - 39 -

L authentification initiale dans les réseaux 802.11 est plus focalisée sur la connectivité sur le réseau LAN plutôt que sur la vérification de l identité de l utilisateur ou de la station souhaitant communiquer. Pour les grandes entreprises, il faudrait authentifier un très grand nombre d utilisateurs, donc la façon la plus facile est l implémentation d une authentification centralisée. 802.1X est le standard qui permet aux WLANs de fonctionner à grande échelle avec une authentification d utilisateurs et/ou de stations centralisée. Le standard est flexible et permet l utilisation de plusieurs algorithmes d authentification. 802.1X supporte un protocole d authentification existant : EAP (Extensible Authentication Protocol [RFC 2284]). 802.1X prend EAP qui lui est implémenté au niveau PPP, et le lie au médium physique pouvant être Ethernet, Token Ring ou WLAN. Les messages EAP sont encapsulés dans les messages 802.1X et sont dits EAPOL ou EAP over LAN. a- Extensible Authentication Protocol (EAP) C est un protocole très flexible. Plusieurs autres protocoles d authentification peuvent être utilisés en dessus et de nouveaux peuvent être rajoutés. EAP est initialement développé pour être utilisé avec PPP (Point to Point Protocol). EAP est une extension du protocole PPP-CHAP. C est un protocole d authentification niveau liaison. Le but de EAP est : chercher toute l information sur l utilisateur avant de choisir le protocole d authentification utiliser une multitude de protocoles pour authentifier les deux partis permettre au point d accès ou Network Access Server (NAS) de communiquer avec un serveur d authentification EAP est un protocole requête/réponse. Quatre types de messages y sont définis dans le tableau suivant : EAP request EAP response EAP success EAP failure Requête EAP envoyée par l équipement désirant ouvrir une session de communication, contenant le protocole d authentification de couche supérieur que l entité source désire utiliser Réponse EAP contenant le même type de protocole ou un acquittement négatif Envoyé par la source pour confirmer l utilisation du protocole échangé dans les messages ci-dessus Envoyé par la source pour arrêter les tentatives de négociation du protocole d authentification à utiliser Le format d un message EAP est représenté à la figure 5 suivante. - 40 -

Figure 5 : Format d un paquet EAP Exemple d échange de messages EAP à la figure 6 suivante : Figure 6 : échange de messages EAP Remarque : EAP doit être utilisé sur un lien sécurisé, sinon le protocole d authentification négocié par les deux partis sera connu, ce qui facilitera les tentatives d attaque ou d écoute. b- EAP sur 802.1X L authentification EAP pour WLAN a trois composants principaux : - Le «supplicant» étant le poste client - L «autentificateur» étant généralement le point d accès - Le serveur d authentification - 41 -

Etapes d authentification : a. Le client essaie d accéder au point d accès. Ce dernier le détecte et lui alloue un port, et met ce port dans un état «Non-autorisé» de sorte à ce que seul le trafic 802.1X est permis. Les autres types de trafic, comme DHCP, http, FTP, POP3, SMTP etc sont bloqués. Le client envoie alors un message EAP-start. b. Le point d accès lui répondra avec un message EAP-request identity pour obtenir l identificateur du client. Le client répond par un message EAP-response contenant son identité qui sera alors acheminée au serveur d authentification. c. Le serveur d authentification est configuré pour authentifier des clients avec un algorithme d authentification spécifique. Le résultat sera un message d acceptation ou de rejet du client qui sera transmis par le serveur d authentification au point d accès. d. Après la réception du paquet d acceptation, le point d accès va mettre le port qu il a alloué au client à l état «autorisé», et tout trafic sera acheminé. Note : Le standard 802.1X ne définit pas un algorithme de distribution de clés. Cette implémentation est ouverte au constructeur. e. Lorsque le client désire se déconnecter du réseau, il envoie un message EAP-logoff qui forcera le passage du port du client au niveau du point d accès à l état «Nonautorisé». Figure 7 : Fonctionnement de 802.1X L implémentation de 802.1X sur les réseaux 802.11 simplifie la gestion de la sécurité dans de larges réseaux sans fils. Mais ceci n est pas suffisant pour mettre de la sécurité sur les réseaux 802.11. En implémentant un algorithme d authentification avec du chiffrement au niveau liaison de données, on pourrait donner un service mobile géré et à échelle variable. - 42 -

Il est important de noter que 802.1X ne définit pas des mécanismes d authentification. Lorsqu on utilise 802.1X, on doit choisir un type EAP. Le protocole EAP offre une architecture variée de mécanismes d authentification : - EAP-MD5 : authentification pat mot d utilisateur et mot de passe (pas suffisament sécurisée) - EAP-TLS : Basée sur les certificats PKI (authentification forte) - EAP-TTLS : authentification bsée sur mot d utilsateur et mot de passe, suffisamment sécurisée - MS-CHAPv2 : propriétaire à Microsoft, basée sur mot d utilisateur et mot de passe, pas assez sécurisée - PEAP : tunnel propriétaire Microsoft et Cisco pour le transport sécurisé de MS-CHAPv2 Figure 8 : Aperçu sur les couches protocolaires 3. Le standard 802.11i A cause des vulnérabilités dans le système de cryptage WEP utilisé dans le standard 802.11b, le groupe de travail I de l IEEE essaie de lui trouver un remplaçant dans 802.11i, tout en essayant de ne pas altérer la compatibilité avec le système existant. WLAN expose un réseau, et côté sécurité, il doit être considéré comme réseau d accès et non le réseau «cœur» de l entreprise. 802.11i construit le standard 802.11 autour de l authentification 802.1X permettant l authentification des utilisateurs et des équipements. Le standard 802.11i inclut deux principaux développements : 1. Wi-Fi protected access (WPA) 2. Robust Security Network (RSN) - 43 -

a- Wi-Fi Protected Access (WPA) WPA utilise TKIP (Temporal Key Integrity Protocol) comme protocole et algorithme pour améliorer la sécurité des clés utilisées dans WEP. TKIP change la méthode de dérivation des clés et les change plus fréquemment pour plus de sécurité. Il ajoute aussi une fonction de Contrôle d intégrité des messages échangés pour éviter le changement des données en route. Pas tous les utilisateurs pourront bénéficier de WPA car il n est pas compatible avec ce qui est préexistant comme équipement et systèmes d exploitation. Ainsi, les utilisateurs ne pourront pas tous partager la même infrastructure de sécurité. De plus, TKIP/WPA dégrade les performances si les WLAN n a pas des équipements puissants permettant d accélérer le protocole WPA. Dans la plupart des WLAN existe un compromis entre sécurité et performance sans présence d accélérateur câblé dans les points d accès. b- Robust Security Network (RSN) RSN utilise la négociation dynamique des algorithmes d authentification et de chiffrement entre les points d accès et des équipements mobiles. L authentification décrite dans le draft repose sur 802.1X et EAP (Extensible Authentication Protocol) vu dans le paragraphe précédent. L algorithme de chiffrement est l AES (Advanced Encryption Standard). La négociation dynamique de l authentification et du chiffrement permet RSN d évoluer avec la sécurité, en ajoutant de nouveaux algorithmes les plus à jour. Avec la négociation dynamique, RSN est nettement plus fort que WEP et WPA. Toutefois, la performance est médiocre sur les anciens équipements. Le nouveau Hardware au niveau des clients et des points d accès permet une meilleure performance. En conclusion, RSN améliore la conception Wi-Fi Protected Access (WPA) en remplaçant la rotation du Temporal Key Integrity Protocol (TKIP) avec l algorithme plus sécurisé Advanced Encryption standard (AES). RSN est le futur de la sécurité dans les réseaux 802.11. c- Advanced Encryption Standard (AES) C est un algorithme de chiffrement symétrique destiné à remplacer le DES (Data Encryption Standard) devenu trop vulnérable. AES est un standard libre d utilisation sans restrictions ni brevet. C est un algorithme de chiffrement par blocs comme le DES. Il possède plusieurs combinaisons [longueur de clé] [longueur de bloc] comme par exemple : 128 128 ; 192 128 et 256 128-44 -

Caractéristiques et points forts de l AES a. sécurisé b. facilité de calcul et par conséquence rapidité de traitement c. besoins en ressources et en mémoire très faibles d. flexibilité d implémentation sur une variété de plateformes et d applications ainsi que différentes tailles de clés et de blocs e. implémentable en hardware (câblé) ou en software f. sa conception est relativement simple - 45 -

Figure 9: Chiffrement / Déchiffrement AES - 46 -

AES opère sur des blocs de 128 bits dits Plaintext qu il transforme en blocs cryptés de 128 bits dits Ciphertext par une séquence Nr d opérations ou rounds avec une clé de 128, 196 ou 256 bits. Note : Nr peut prendre les valeurs 10, 12 ou 14 rounds L AES est plus sûr que le 3DES car il présente entre autre une plus grande résistance aux attaques par dictionnaire de clés. Les performances de AES sont de loin meilleures que celles de 3DES. Elles sont proches de celle du DES simple. C. Voix sur 802.11 Les réseaux 802.11 sont essentiellement conçus pour être des réseaux de données. Ils forment le réseau d accès à des réseaux Ethernet à commutation de paquets. Les réseaux 802.11 sont plats, sans aucune classification de trafic pour différencier les services. Ainsi, les contraintes du trafic temps réel ne seront plus respectées dans certains cas : par exemple un délai dû à l augmentation du trafic total affectera sûrement la qualité du trafic de voix. La voix sur 802.11 est naturellement sur IP utilisant le protocole temps réel qui est spécialement conçu pour cela (voir partie V de ce compte rendu). Un problème de performances s impose si les couches MAC et Physiques de 802.11 sont utilisées. Typiquement, VoIP utilise UDP même sur des réseaux de type Best Effort et la correction d erreurs et la retransmission doivent être faites aux niveaux supérieurs car pour le trafic temps réel, les couches basses doivent réduire le temps de latence et la gigue autant que possible. L introduction de tels mécanismes au niveau bas augmente les délais. Figure 9b : couches protocolaire de VoWLAN Mais vu que les pertes et les erreurs sont beaucoup plus fréquentes sur le lien radio que dans un réseau câblé, la couche MAC de 802.11 introduit un mécanisme d acquittement qui introduit de la fiabilité au niveau du lien radio. Mais dans le cas - 47 -

des applications de voix, ce protocole rajoute de la gigue et de la latence au trafic de voix. La couche MAC possède aussi la procédure RTS/CTS (Reuqest To Send / Clear to Send) avant d envoyer quoi que ce soit. Ce mécanisme permet de réduire le risque de collisions sur le canal. RTS/CTS ajoutent de la robustesse au système mais rajoutent aussi de la latence supplémentaire au trafic de voix. D où l idée d améliorer la couche MAC pour mieux faire passer la voix dans IEEE 802.11 e décrite dans le paragraphe suivant. Eviter le problème de QoS Le fait d utiliser des codecs de voix à débits faibles au niveau applicatif permet de réduire la latence et la gigue. Aussi on peut envisager l utilisation de DSP (Digital Signal Processors) qui améliorent la qualité de la voix dans une implémentation wireless VoIP. 1. 802.11e Tous les paquets transitant sur un réseau 802.11b on la même priorité. Le groupe E de travail de l IEEE voudrait changer cela en mettant en place ce qui est couramment connu sous le nom de «Qualité de service» ou QoS, pour garantir que certains paquets aient une priorité supérieure à d autres. La QoS est requise pour des appels de voix de bonne qualité utilisant VoIP (la voix sur IP), et pour les flux multimédias. 802.11e peut être utilisé avec plusieurs standards 802.11, comme le b, le g et le a. Le standard HomeRF, fonctionnant aussi sur la bande de fréquences 2.4GHz, a toujours été le concurrent de 802.11b, surtout qu il implémente un mécanisme d ordonnancement permettant au trafic de voix d avoir une priorité supérieure aux paquets de données. Dans le standard initial 802.11, le protocole d accès au medium est conçu avec deux modes de communications pour les stations mobiles : 1. Distributed Coordination Function (DCF) : basé sur CSMA/CA qui impose l écoute du canal avant d émettre. La station voulant émettre attend une période de silence sur le réseau puis commence à transmettre ses données tout en détectant les collisions. La fonction DCF ne supporte aucun type de priorité d accès au medium radio. 2. Point Coordination Function (PCF) - (optionnel) : supporte le trafic sensible aux délais. Les points d accès radio propagent des trames dites «beacon» périodiquement, pour communiquer l identificateur du réseau et les paramètres de gestion spécifiques au réseau sans fils. Entre l émission de deux «Beacon», PCF divise le temps en deux périodes : période de contention, et période sans contention. La station a le droit d émettre durant la période de non-contention. La fonction PCF n est pas beaucoup implémentée à cause des temps de transmission imprévisibles. - 48 -

Comme DCF et PCF ne différencient pas les types de trafic ou de sources, IEEE propose des améliorations dans 802.11e pour les deux modes de coordination d accès afin de faciliter la QoS. Ces changements permettent aussi d avoir une compatibilité avec le standard 802.11 initial. Enhanced Distribution Coordination Function (EDCF) Elle introduit le concept de catégories de trafic. Chaque station mobile a 8 catégories de trafic, ou niveaux de priorité. Dans EDCF, la station tente d émettre après avoir détecté un silence sur le medium et après avoir attendu une certaine période de temps déterminée définie selon la catégorie de trafic en question. Cette période probabiliste est appelée Arbitration InterFrame Space (AIFS). Un trafic de haute priorité aura un AIFS inférieur au trafic de priorité moindre. Ainsi, le temps d attente d accès au medium sera supérieur pour les stations ayant un trafic de basse priorité, par rapport à celui des stations ayant un trafic de priorité supérieure. Afin d éviter les collision pour une même catégorie de trafic, la station décompte un nombre aléatoire supplémentaire d intervalles de temps, nommé «fenêtre de contention», avant d essayer de transmettre des données. Au cas où une autre station transmet avant la fin du compteur, la station en question attend la période de silence suivante après laquelle elle reprend le décomptage là où elle s est arrêtée. Aucune garantie du service n est assurée, mais EDCF établit un mécanisme de priorités probabiliste pour allocation de la bande passante en fonction de la catégorie de trafic. Hybrid Coordination Function Introduit un mécanisme de polling à la fonction PCF. Une station de contrôle interpelle une station durant la période de non-contention et lui donne un temps spécifique d accès et une durée maximale de transmission. EDCF est plus répandu que HCF. 2. Simulation la voix sur 802.11 WLANs La voix sur IP sur des réseaux paquets sans fils devient de plus en plus demandée. En particulier, le déploiement de la technologie WLAN étant de plus en plus répandu engendre que cette technologie soit la base de la téléphonie mobile sur IP. Les applications de conversation duplexes sont toutefois très sensibles au délai de bout en bout. La limite supérieure tolérée pour la voix étant de 150ms selon la recommandation G.114 de l ITU-T. De plus, le taux de perte de paquets doit être inférieur à 1% pour éviter la dégradation qui devient alors perceptible. - 49 -

L environnement WLAN n est cependant pas l idéal pour avoir ces conditions. Un lien radio présente des pertes assez considérables dû au phénomène de fading et d interférences. L accès au medium à travers la couche MAC avec un système de contention de canal, a un système de correction d erreurs et de retransmission qui pourrait réduire les longs délais. La téléphonie sur WLAN devient efficace lorsqu une conception avancée de transmission de la parole est mise en place. Conditions de la simulation La simulation a été faite sur une application simulateur de réseau (Network Simulator) modifié pour simuler un canal introduisant des erreurs (modélisant un wireless channel). Au niveau applicatif deux codecs sont assignés pour les deux états possibles du canal wireless : 1. Dans un bon état, une source à 12.2kbps est utilisée 2. Dans un mauvais état, le codec produit une sortie à 4.74kbps La détection de l état du cana déclenche automatiquement le choix du codec approprié. Le payload est encapsulé dans un paquet RTP (Real Time Protocol développé dans la partie V de cette étude). UDP est utilisé pour multiplexer les différents flux venant des couches supérieures, et IP s occupe du routage et de l adressage. La compression d entête RTP/UDP/IP initialement de 40 octets est utilisée durant la simulation. Donc le paquet de voix aura 4 octets d entête au niveau 3. Les entêtes de la couche MAC et de la couche Physique sont alors rajoutées à l ensemble selon le standard 802.11. Les simulations sont faites à 11Mbps. 1 ère partie : - 50 -

Figure 10 : paquets perdus et retardés en fonction de la probabilité d erreur du MacPDU Adaptative veut dire que le codage de la voix varie en fonction de la condition du canal. Vu que le point d accès est le premier hop sur le réseau, le délai maximum tolérable avant l adaptation du codec est de 20ms. A 20ms, la source adapte la taille du payload à 224 ou 95 bits selon l état du canal. Observation du graphe de la figure 10 Le graphe de la figure 10 montre que si le codec au niveau applicatif est adaptif en fonction de la qualité du canal, les performances en termes de pertes de paquets et de délai sont meilleures que dans le cas non adaptif. Aussi, le graphe nous montre que la retransmission au niveau MAC aide aussi à améliorer les performances. 2 ème partie Figure 11 : paquets perdus et retardés en fonction de la probabilité d erreur du MacPDU avec et sans présence d un trafic FTP - 51 -

La présence d un trafic FTP qui est un service sur TCP, dégrade les performances de VoIP sur WLAN comme on le voit clairement sur le graphe de la figure 11. Comme la 1 ère simulation, le fait d avoir un codec adaptatif permet de meilleures performances dans chaque cas de figure. Mais on remarque qu avec un codec adaptatif, un trafic VoIP seul a presque les mêmes performances qu un codec non adaptatif et un trafic VoIP + FTP (les deux courbes du milieu). Figure 12 : Paquets détruits par le récepteur dû à leur retard (arrivée >20ms) Conclusion La présence d une technique d adaptation du codage de la voix en fonction de la qualité du canal radio présente une amélioration des performances. Donc la réduction de la taille du payload d un paquet de voix sur IP affecte la qualité de réception de la voix sur un réseau 802.11 WLAN. D. Synthèse Les réseaux WLAN sont initialement conçus pour transporter des données. Mais vu l exigence actuelle de mise en place de la mobilité et des applications de voix et de multimédias à contraintes temps réel, le standard 802.11 a subi plusieurs modifications pour assurer la sécurité des transferts sur les liens radio, et la qualité de service des applications sensibles. Le réseau GSM étudié dans la partie II de ce document représente un modèle de référence pour la sécurité de la voix sur un lien radio. - 52 -

Sur ce, des études ont été faites pour intégrer des «smart cards» dans un réseau 802.11. Comme la carte SIM GSM, l idée des smart cards dans WLAN sera implémentée pour la sécurité. Actuellement les «smart cards» n ont pas d équivalent côté résistance aux attaques, et la facilité de gestion des clés qu elles introduisent. Rappel : Deux types de cryptographie sont connus actuellement : - Concept basé sur la clé partagée pour faire un chiffrement symétrique, qui fut le cas de GSM et de WEP par exemple - Concept basé sur les clés publiques pour un chiffrement asymétrique, basé sur des certificats (principe de SSL et TLS qui sont des protocoles de sécurité implémentés sur TCP) Si on envisage d utiliser les «smart cards» avec WLAN, l infrastructure de clé publiques devient convenable et facile à manipuler. Si les certificats sont enregistrés dans la «smart card» et l authentification utilisée sera EAP TLS. Dans le cas EAP TLS, la station et le serveur d authentification RADIUS vont échanger les certificats à travers un point d accès pour s authentifier mutuellement. Ensuite ils font établir un canal sécurisé (chiffré) en dérivant une clé de session. Sur ce canal, le serveur RADIUS enverra la clé partagée WEP ou autre à la station. Figure 13: échanges EAP TLS entre station et serveur RADIUS L insersion du système «smart card» sur un PC est actuellement possible sur le port USB. Certains constructeurs de cartes réseau y intègrent un lecteur de carte à puce ou «smart card». - 53 -

Avec l insertion des cartes à puces dans les réseaux 802.11, on peut envisager de mettre plus de services sur la carte elle-même. Pourquoi ne pas câbler AES pour le chiffrement rapide entre le point d accès et le PC. Dans ce dernier cas, l authentification qui se fait au début avec la gestion des clés sur EAP, et surtout le chiffrement câblé aura moins d impact sur la performance de la voix. Les simulations de VoIP sur WLAN décrites dans le paragraphe précédent montrent que le codage adaptatif de la voix sur WLAN peut améliorer la qualité de service et les performances en termes de délai et de perte de paquets du trafic de voix. Et dans le cas de VoIP la carte peut jouer le rôle de SIM pour authentifier l utilisateur et non seulement l équipement, et on peut même introduire de la tarification comme dans GSM. - 54 -

IV. IPsec Dans les trois grandes parties précédentes de ce document ont été exposés trois différents réseaux d accès sans fils (wireless) Bluetooth, GSM et 802.11 actuellement implémentés et largement utilisés. Les piles protocolaires de chacune de ces architectures sont différentes. Donc, afin de concevoir un service de téléphonie commun à tous les terminaux quelle que soit l architecture utilisée, il faut s arrêter sur ce qui est commun à ces différentes architectures et s y lancer. Le protocole Internet (IP) est commun aux réseaux Bluetooth et 802.11 ainsi que toute la pile qui vient au dessus (TCP/UDP/RTP..). Donc, dans cette partie de notre étude, on s arrêtera sur le protocole IP, son aspect sécurisé IPsec actuellement implémentable et largement utilisé et son impact sur le transport du trafic à contraintes temps réel. A. Le protocole IPsec IPsec est une norme IETF [RFC 2401] qui définit une extension de sécurité pour le protocole IP. Les services fournis de bout en bout sont la confidentialité, l authentification de la source des données, l intégrité des données, la protection contre le rejeu et le contrôle d accès. IPsec est basé sur la cryptographie. IPsec est composé de trois protocoles : deux protocoles d encapsulation distincts et un protocole (ou mécanisme) d échange de clés. - AH : Authentication Header : fournit l authentification, le contrôle d accès, l intégrité et l anti-rejeu. - ESP : Encapsulating Security Payload, fournit le contrôle d accès, l antirejeu et la confidentialite - IKE : Internet Key Exchange, permet de mettre d accord les deux protagonistes de l échange sur les mécanismes et algorithmes à utiliser pour la sécurisation. Les protocoles AH et ESP se trouvent au niveau IP. IPsec peut être juste au-dessus ou au-dessous de IP. IKE en revanche se situe au-dessus de UDP et IP. - 55 -

IKE (UDP port 500) Applications Application (FTP, Telnet, SMTP, ) IPSec Implémentations IPv4 existantes IPSec Transport (TCP / UDP) Nouvelles implémentations IPv4 (intégrant IPSec) Physique (Ethernet, ATM, ) IPv6 (intégrant IPSec) Figure 1: Positionnement du protocole IPSec dans la pile IP 1. Authentication Header (AH) AH offre les services de sécurité suivants: Intégrité en mode non-connecté Authentification des données Anti-rejeu (optionnel) L entête AH est composée de six champs Figure 3 : Entête AH Chacun des champs de l entête AH est décrit dans le tableau suivant : NEXT LEN Réservé SPI Numéro de séquence Authentification Type de l entête suivante. Peut être UDP, TCP, ESP Longueur du champ de données Pour usage ultérieur Security Parameter Index est un numéro permettant d identifier les services fournis et les algorithmes utilisés Protection contre le rejeu Résultat d un algorithme de hachage appliqué sur les données utiles pour effectuer un contrôle d intégrité - 56 -

Les algorithmes d authentification utilisés par AH sont : HMAC-MD5 (obligatoire)., HMAC-SHA1 (obligatoire), KPDK-MD5, DES-MAC, HMAC-RIPE-MD. Tous ces algorithmes sont symétriques. 2. Encapsulating Security Payload (ESP) ESP assure les services suivants: Confidentialité Protection contre de l'analyse de trafic Intégrité en mode non connecté (comme AH) Authentification des données (comme AH) Anti-rejeu (comme AH) L entête ESP est composée de sept champs : Figure 4 : Entête ESP Chacun des champs de l entête ESP est décrit dans le tableau suivant : SPI Numéro de séquence Pad LEN NEXT Authentification Security Parameter Index est un numéro permettant d identifier les services fournis et les algorithmes utilisés Protection contre le rejeu Longueur du bourrage dans le champ de données Type de l entête suivante. Peut être UDP, TCP, ESP Comme dans AH, l authentification est réalisée au moyen d un ICV (Integrity Check Value) et en pratique, il s agit toujours d un MAC. Contrairement a AH ou on se contentait d ajouter un ou deux champs, on a ici une vraie encapsulation, les données chiffrées sont littéralement mises au milieu entre plusieurs blocs de données ESP. Les algorithmes : - 57 -

- de confidentialité : DES, Tripple DES, RC5, CAST, IDEA, Triple IDEA, blowfish, RC4, et Null. Tous ces algorithmes sont symétriques. - D authentification : HMAC-MD5, HMAC-SHA1, KPDK-MD5, DES- MAC, HMAC-RIPE-MD et NULL. 3. Internet Key Exchange (IKE) Les clés dans la sécurité ont une durée de vie. Les clés qui durent longtemps sont généralement les clés utilisées pour authentifier les partis. Alors que les clés utilisées pour la confidentialité sont généralement de courte durée et sont dites clés de session. Leur durée de vie est à peine celle d une session. Parfois plus courtes. IKE est un protocole d authentification mutuelle avec échange de clés. Il est dit hors bande car les informations relatives a cette négociation ne sont transportées directement avec les données mais dans une phase dédiée a la négociation et utilisant un autre protocole (ISAKMP). Public Key Infrastructures (PKI) IKE peut utiliser des clés publiques pour authentification des partis. Les PKIs qui peuvent être utilisés avec IPsec : - PKIX (Public Key Infrastructure X.509) - SPKI (Simple Public Key Infrastructure) - DNSSEC - PGP signed keys L échange des clés doit être authentifié pour éviter les attaques. Les clés de session permettent d étendre l authentification initiale à toute la communication. Diffie-Hellman Le protocole Diffie-Hellman (DH) est un protocole de cryptographie permettant à deux partis de générer un secret partagé sans aucune information sur l un et l autre. Nous n allons pas rentrer dans les détails de l algorithme DH, mais son principe est de dériver le même secret partagé en partant d une clé privée et d une clé publique. Mais l algorithme DH est susceptible pour les attaques de l homme au milieu. Exemple : Si l attaquant Eve se place entre Alice et Bob, et leur envoie la clé publique. Ainsi chaque parti construit le secret partagé se basant sur la clé publique d Eve, tout en croyant que c est la clé de l autre. La solution à cela est l authentification des clés publiques. IKE est plus qu un échange de clé. C est une association de sécurité (SA) : Il ne s agit pas uniquement de la gestion des clés mais de tous les paramètres de sécurité d une communication Gère uniquement les paramètres à courte durée de vie, et non les certificats Dans IKE, la gestion des clés est séparée des mécanismes de sécurité ; les deux sont reliés par les SA. Les SAs sont utilisés par IPsec pour définir les opérations effectuées - 58 -

sur un paquet IP. IKE gère les SAs (configuration dynamique, écourtement de la durée de vie ) IKE est un protocole orienté connexion et utilise le port UDP 500 La figure suivante montre l interaction entre les mécanismes IKE et IPsec. Figure 5 : Interaction des mécanismes IKE et IPsec On peut considérer qu IPsec traite les PDU (Protocol Data Unit) arrivant des couches supérieures avant de les envoyer sur le réseau, et lorsqu elle reçoit des paquets IPsec du réseau elle les déchiffre avant de les envoyer aux couches supérieures. L administrateur configure IPsec et IKE à travers la SPD (Security Policy Database). La SPD contient : - des règles organisées indiquant quel trafic doit être protégé et comment - les paramètre IKE utilisera pour sa négociation Ensuite la SPD indique que le trafic sortant doit être protégé, IPsec consulte alors la SAD (Security Association Database) pour voir si une SA appropriée est déjà montée. Sinon, IPsec formule une demande de SA auprès de IKE. IKE consultera la SPD pour y puiser tous les paramètres dont il a besoin et démarre la négociation. Si la négociation est réussie, la SA correspondante est enregistrée dans la base SAD afin qu elle soit utilisée par IPsec. L échange IKE est constitué de deux phases : - La phase 1 de l échange est basée sur les identités qui peuvent être des noms et des secrets comme des paires de clés publiques ou des secrets partagés entre deux identités. Cette phase se déroule une seule fois et par suite permet l exécution de plusieurs phase 2 entre deux entités. Deux modes possibles pour cette phase 1 : o Mode commun (6 messages échangés, assurant protection de l identité* o Mode agressif (plus rapide, avec 3 messages) - La phase 2 de l échange utilise la clé de session établie après la phase 1 afin d effectuer l authentification mutuelle des deux partis, et générer une deuxième clé de session qui sera utilisée pour protéger tous les échanges de la phase 2. Cette Phase est utilisée pour négocier les SAs (AH, ESP ) - 59 -

Donc en résumé, la phase 1 négocie : les algorithmes de chiffrement (3DES, CAST, Blowfish, DES, ) Les foncions de hachage (MD5, SHA, Tiger) La méthode d authentification : o Secrets pré-partagés o PKI o signatures Diffie-Hellman pour générer les clés de session Plusieurs connexions de phase 2 sont conseillées pour les raisons suivantes : 1. échange périodique de nouvelles clés ou de nouveaux secrets partagés 2. établir plusieurs connexions avec des profils de sécurité différents, par exemple une connexion avec un clé de chiffrement simple et insécurisée, et une autre avec une clé plus longue. 3. Si plusieurs applications veulent communiquer entre deux nœuds, et dans le cas où chaque application utilise sa propre clé. 4. Synthèse Des débats se déroulent autour de l inutilité de AH vu que ESP présente le service d intégrité. En revanche, le service d intégrité de ESP est différent de celui d AH. Les deux protocoles effectuent le hachage de tout le payload IP, mais AH assure l intégrité de quelques champs de l entête IP elle-même. Mais est-il nécessaire de protéger l entête IP? Si cela l est, ce sera fait par ESP en mode tunnel (une autre entête IP avec ESP est superposée au paquet IP à envoyer, ainsi ce dernier sera chiffré par ESP). Un des avantages présentés par AH est que les routeurs intermédiaires et les murs pare-feu savent que le contenu des paquets IPsec AH n est pas chiffré car AH n offre pas le service de confidentialité. Ainsi des décisions de routage peuvent être prises selon les données de l entête du niveau 4, comme les ports par exemple. Donc le routage sera fait selon le type de l application. L option que possèdent quelques routeurs et qui est de regarder dans les entêtes TCP et UDP pour la décision de routage, ne peut être utilisée si la confidentialité ESP est appliquée. Mais parfois il s avère préférable de chiffrer les entêtes TCP et UDP car les ports divulguent de l information importante. L approche de chiffrement au niveau trois du modèle OSI s avère être bonne comparée à celle envisagée aux niveaux supérieurs, et ceci car des problèmes peuvent avoir lieu si on opère au dessus de TCP par exemple. Si on considère SSL qui introduit de la sécurité au dessus de TCP, un problème peut se poser au niveau des numéros de séquences. Exemple : TCP ne peut pas savoir si le contenu du segment qu il reçoit est erroné, que le chiffrement soit au niveau SSL ou au niveau IP. Dans le cas où la sécurité se trouve - 60 -

au niveau SSL, et un attaquant, interceptant une communication entre Alice et Bob, envoie à Bob des paquets erronés portant le même numéro de séquence TCP que ceux envoyés par Alice. La couche TCP de Bob reçoit les segments de l attaquant avec des numéros de séquence corrects. Elle va les décapsuler et les envoyer à la couche SSL. SSL à son tour va détecter que les paquets de l attaquant ne sont pas ceux d Alice et va les détruire. Aucun mécanisme ne permet à SSL de notifier TCP que les paquets reçus sont mauvais afin qu une retransmission soit faite. Alors TCP va recevoir les bons segments d Alice avec les mêmes numéros de séquences de ceux déjà reçus par l attaquant, va penser que ce sont des paquets dupliqués, et par suite les purger sans les passer à SSL. Ainsi le transfert entre Alice et Bob n atteindra plus le niveau applicatif. Suivant le même exemple, si la sécurité aurait été implémentée au niveau IPsec, ce dernier détectera les paquets de l attaquant par son authentification et contrôle d intégrité et les purgera, et ainsi ne passeront à TCP que les bons segments d Alice. B. La Voix sur IP 1. Voix sur IP et Bande Passante Un des aspects le plus critique dans la conception d un réseau de voix sur IP (VoIP : Voice over IP) est la bande passante. Une certaine partie de la bande passante totale est utilisée pour chaque appel VoIP. a. Paquetisation La voix codée avec un codec est assemblée dans des paquets pour être envoyée sur le réseau. Sur la couche TCP/IP, le protocole RTP (Real Time Protocol) est conçu pour le transport du trafic à contraintes temps réel sur UDP. RTP sera détaillé avec son profil sécurisé SRTP (Secure Real Time Protocol) dans le chapitre V. suivant de ce document. Un paquet typique de voix sur IP est composé du payload, encapsulé dans l entête RTP, qui elle est encapsulée dans l entête UDP. Le segment UDP sera mis dans un paquet IP. La somme de la taille des entêtes du paquet IP/UDP/RTP restant est 40 octets. Ces entêtes contiennent l information relative à chaque protocole, et elles sont toutes indispensables pour transporter proprement les données. Dans ces entêtes on trouve les adresses source et destination et les ports source et destination, le numéro de séquence du paquet, etc En utilisant le codage G.723.1 pour la voix par exemple, 24 octets d échantillons de voix sont produits chaque 30 millisecondes et encapsulé dans un paquet IP/UDP/RTP. Donc, chaque paquet IP aura 40 octets d entêtes pour 24 octets de données utiles. L entête forme ainsi 67% de la totalité du paquet IP. - 61 -

Figure 6 : Paquet VoIP Un moyen commun pour augmenter l efficacité de l entête IP est d inclure deux payloads de voix codées dans le même paquet IP. Mais ceci introduit un temps de latence supplémentaire par trame. C est un compromis qui peut être opté. b. Voice Activity Detection (VAD) Les conversations téléphoniques contiennent 35 à 50 pourcent de silences. En général, dans les réseaux standard de voix, un appel de voix occupe une bande passante de 64kbps, sans traitement spécial est suppression des silences. Le système VAD effectue la suppression des paquets de silence. Ceci permettra l utilisation plus efficace de la bande passante du réseau. Des études ont été faites pour prouver que VAD réduit l utilisation de la bande passante de 35 %. VAD a une fonction intégrée : Comfort-Noise-Generator (CNG). Le CNG génère du bruit blanc pour remplacer les silences à la réception pour bien reconstituer la conversation. Le tableau suivant illustre l utilisation de la bande passante sur un réseau Ethernet par connexion de voix sur IP/UDP/RTP, avec et sans VAD. Une combinaison de codecs et de taille de données utiles y est envisagée. G.723.1 G.723.1 G.723.1 G.729 G.729 G.729 G.711 Durée Trame 30 30 30 10 10 10 1 (ms) Débit codec 6.3 6.3 6.3 8 8 8 64 (kbps) Trames de 1 2 3 1 2 3 20 voix par paquet Paquets par 33.3 16.7 11.2 100 50 33.3 50 seconde Taille du 24 48 72 10 20 30 160 payload (octets) Taille du 78 102 126 64 74 84 214 paquet + entête MAC de 14 octets Pourcentage 70% 53% 43% 85% 73% 65% 26% - 62 -

d entête Bande passante fullrate (kbps) Avec VAD (65% de la Bande passante) (kbps) 20.8 13.7 11.3 51.2 29.6 22.4 85.6 13.5 8.9 7.3 33.3 19.2 14.5 55.6 Les formules suivantes ont été utilisées pour calculer les données dans la table : Taille du paquet Débit paquets par seconde Bande passante Entête RTP/UDP/IP (40 octets) + Entête MAC (14 octets) + taille des données utiles (payload) Débit du codec / taille des données utiles Débit paquets par seconde * taille du paquet en octets * 8 On remarque d après le tableau que le type de codec influe sur la bande passante d une communication de voix sur IP. Et Plus on augmente le nombre de trames de voix dans le même paquet, le pourcentage d entête par paquet diminue, ainsi que la bande passante occupée par la communication. 2. Voix sur IPsec Dans les applications à contraintes temps réel, nous avons aussi besoin d introduire des couches introduisant la confidentialité du contenu d un paquet, l intégrité de l information reçue et l authentification. Mais ces mécanismes peuvent ralentir la transmission d un paquet ce qui ne peut pas être acceptable par l application elle-même. Dans le cas de la voix, les délais tolérés sont de 150ms de bout en bout extensibles à 200ms dans le cas de communication chiffrées. Comme nous l avons vu un peu plus haut, dans les applications standard VoIP, après que le signal soit digitalisé, le signal est codé avec des codecs standards (G.729, G.723, etc ), puis divisé en paquets qui eux seront routés à travers l internet. Le flux de voix originant sera reconstitué à la destination avec l utilisation de mémoires tampons pour minimiser l effet des délais différentiels entre un paquet et un autre. A cause de ces contraintes de temps, les paquets de voix sont petits (10-50 octets de payload). - 63 -

Lors de l utilisation d IPsec, la taille du paquet IP totale augmente vu l ajout des entêtes AH et ESP, et éventuellement une deuxième entête IP si on utilise IPsec en mode tunnel. Ceci par suite augmente le ratio entête/payload et par suite, réduit la bande passante effective. De plus, le temps nécessaire pour la construction de toutes ces entêtes et l application des fonctions cryptographiques correspondantes ajoute un délai supplémentaire à la transmission d un paquet. Des simulations et expérimentations montrent que par rapport à VoIP, VoIPsec diminue la bande passante effective de 63%. Donc VoIPsec ne peut pas être utilisé sur des liens à faible bande (connexions modem par exemple). L engin de cryptographie peut être un sérieux bouchon au trafic de voix. A part le débit de traitement (dit throughput), le temps d accès à l engin de cryptographie ne peut être prévu, ainsi l ordonnancement donnant la priorité au trafic de voix par rapport à d autres s avère être impossible. Alors, si les paquets de voix arrivent à l Ordonnanceur mélangés avec un autre type de trafic (ftp ou http par exemple), un délai supplémentaire dit de latence est introduit par le traitement des paquets de taille variable. Ainsi, les paquets de voix seront retardés au point qu ils seront souvent purgés par l application destination. Figure 7 : Format des paquets de VoIPsec Figure 8 : VoIPsec et bande passante effective - 64 -

Le tableau de la figure 8 ci-dessus représente les longueurs d entêtes et les longueurs totales des paquets utilisant IP ou IPsec avec différents algorithmes de chiffrement (DES et 3DES) et d intégrité SHA. La dernière colonne montre le nombre d appels de voix simultanés sur un lien de 128kbps, sans dégradation de qualité. Les différents algorithmes de chiffrement ont un impact sur la longueur de l entête du paquet de voix. Le tableau de la figure 8 a montré le pourcentage de l augmentation de la taille de l entête (colonne Size incr.) Les algorithmes de chiffrement ont aussi un impact sur le délai. La figure 9 suivante montre le throughput de chaque engin de crypto en fonction du débit entrant. Tous les algorithmes atteignent un point maximal au-delà duquel les performances se dégradent. Parmi les engins de chiffrement le DES présente les meilleures performances. Figure 9 : Throughput des engins cryptographiques en fonction du débit augmentant C. Synthèse Tout réseau VoIP est essentiellement un réseau IP. Le réseau VoIP et les terminaux font face aux mêmes problèmes de sécurité que les réseaux IP simples. Pour cela, les appels VoIP ont besoin d être sécurisés au moins comme l est le réseau téléphonique commutation de circuits, avec respect de l anonymat et de la confidentialité. Le réseau IP étant de nature ouvert au grand public, il présente beaucoup de failles de sécurité. Ce que requièrent les services de VoIP alors est : a. Protection de la confidentialité d une communication de voix b. Authentification des deux partis communicant c. Protection contre le mauvais usage des ressources du réseau, ou bien en d autres termes, le contrôle d accès sur le réseau. d. Tarification éventuelle par l opérateur VoIP, et protection des données de tarification par les accès non autorisés - 65 -

e. protection des serveurs et terminaux contre les attaques DoS (Denial of Service) pouvant causer l interruption du service, et les attaques «man in the middle». Vu la lourdeur de l entête IPsec introduits à des petits paquets de voix, la bande passante effective sur le lien devient très faible. Donc l utilisation de VoIPsec sur des liens à faible bande s avère être une très mauvaise idée. Dans le cas où VoIPsec est utilisé, certains mécanismes de QoS sur IP comme la classification de paquets, traffic shaping, congestion avoidance de TCP, et les protocoles de réservation de ressources ne peuvent pas être implémentés car ils utilisent des champs de l entête IP qu IPsec chiffre. La qualité de service doit être envisagée à des niveaux inférieurs, comme MPLS par exemple. De plus, non seulement le débit du lien pour avoir une bonne qualité de service, mais aussi les contraintes imposées par les performances des engins de cryptographie. Afin d alléger la bande passante, il faut éviter d augmenter la taille des entêtes des paquets IP. Pour cela, on pourrait arrêter d envisager le mode tunnel qui rajoute une entête IP supplémentaire. Et afin de router les paquets sur un réseau IP, il faut que l entête IP soit en clair. Donc le chiffrement à un niveau plus bas qu IP s avère être impossible, et bloquera le routage. Mais le chiffrement niveau ESP n introduira pas de bloquage. Enfin, le graphe de la figure 10 suivante introduit le délai en fonction du nombre d appels, pour des communications de voix sur IP (courbes de bas en haut sur la figure) : - sans sécurité - IPsec avec service d authentification uniquement - IPsec avec service de chiffrement - IPsec avec authentification et chiffrement Figure 10 : Délai en fonction du nombre de connexions pour la voix sur IP et IPsec - 66 -

On en déduit que le fait d avoir uniquement un service d authentification sur IPsec n influe pas tellement sur les performances en termes de délai que le service de chiffrement. Le chiffrement consomme beaucoup plus de ressources que l authentification. - 67 -

V. Real Time Protocol Le protocole IP offre un service Best Effort sans aucune garantie de qualité de service. Pour avoir une communication de voix sur IP avec un certain niveau de qualité, des garanties sont nécessaires vu que le perte de plusieurs paquets, ainsi que les délais, vont affecter sérieusement la qualité de la conversation. Quand une application veut transmettre des données, elle utilise un protocole de transport pour le faire. TCP et UDP sont les deux protocoles de transport de l architecture TCP/IP. TCP et UDP ne sont pas suffisants pour le transport de trafic de type temps réel, d où la conception du protocole RTP (Real Time Protocole). Pour les applications VoIP qui fournissent un service de téléphonie, TCP semble être bon. Ce protocole offre un service dans lequel la connexion forme un flux fiable. TCP es un protocole orienté connexion, et les données sont échangées. Enfin la connexion est fermée. Cette procédure nous rappelle celle d un appel téléphonique. En termes de synchronisation, le flux fiable arrive dans le même ordre dans lequel il a été envoyé. Ceci est assuré par le numéro de séquence de TCP. Aussi, ce dernier garanti l arrivée correcte de l information par son mécanisme de contrôle d erreurs intégré. Le mécanisme de contrôle de flux et de congestion protège contre le débordement du réseau. Cependant, l utilisation de TCP présente plusieurs inconvénients pour la voix. TCP repose dans ses mécanismes sur la retransmission de paquets corrompus ou perdus. L attente de cette retransmission cause des délais supplémentaires à la communication. Or, pour la voix, il est préférable d avoir des paquets perdus ou corrompus qu une grande quantité de délai. Le problème est que TCP empêche l application de recevoir le reste des paquets si la retransmission de l un d eux est attendue, car TCP préserve l ordre des paquets. Le contrôle de flux effectué par TCP introduit aussi parfois un délai supplémentaire au transfert de paquets. Ainsi, TCP qui a pourtant beaucoup d avantages, n est pas utile pour le service de voix sur IP. Ainsi, le protocole restant à utiliser est UDP. UDP ne présente aucune complexité. C est une simple extension du protocole IP qui offre donc un service Best Effort, sans aucune garantie. UDP présente l avantage de ne pas attendre les retransmissions de paquets perdus. Mais UDP présente aussi des désavantages pour le transport du trafic de voix. Il ne présente aucun mécanisme de synchronisation ou de contrôle de flux et de congestion pourtant assez utiles pour la voix. Une solution à ces problèmes est de concevoir une extension d UDP pour introduire ces fonctions. C est ainsi que fonctionne RTP au dessus de l architecture TCP/IP. - 68 -

A. Le protocole RTP Le Real Time Protocol est défini comme un protocole assurant le transport de bout en bout de données à contraintes temps réel, comme le trafic de voix ou de vidéo multimédia. Alors ce protocole peut être utilisé pour les applications de voix sur IP. Figure 1 : RTP dans le modèle OSI TCP/IP La spécification RTP définit en fait deux protocoles séparés. Le premier étant Real Time Protocol (RTP), et le second Real Time Control Protocol (RTCP). Le rôle de RTP est de transporter les données temps réel. Le protocole de contrôle qui lui est associé apporte des informations sur les participants d une session. Les duex protocoles sont définis de sorte qu ils peuvent être implémentés sur différentes architectures et non seulement sur les réseaux TCP/IP. Toutefois, RTP dans un réseau TCP/IP fonctionne au dessus de UDP. (Voir figure 1 ci-dessus). RTP/RTCP n offrent pas de garantie de QoS. Ceci doit être assuré par d autres mécanismes. Toutefois, ces protocoles assurent l ordre de réception des paquets à l aide d un numéro de séquence. RTCP donne des informations sur la qualité de réception que l application doit attendre, afin qu elle fasse les ajustements nécessaires pour assurer une bonne livraison à l utilisateur. Par exemple, dans le cas où une congestion se forme, l application pourrait décider de diminuer son débit. 1. RTP Un paquet RTP consiste en une entête RTP, suivie par les données à envoyer. Dans la spécification RTP, ces données utiles sont dites payload. La figure 2 présente le format d une entête RTP. - 69 -

Figure 2: Entête RTP Les deux premiers bits de l entête contiennent la version courante du protocole RTP. Le deuxième champ «padding», indique que du bourrage existe dans les données courantes. Le dernier octet de padding contient le nombre d octets de bourrage. Le bit extension spécifie si l entête contient une extension d entête. Dans ce cas, le champ CC (CSRC count) spécifie combien de sources sont impliquées dans l entête RTP. Le bit marker peut être utilisé par une application. Il n est pas interprété dans la spécification RTP. Il est laissé pour usage applicatif. Ensuite, le champ payload type définit le type de données contenu dans le paquet, alors il définit comment chaque application interprète le paquet qu elle reçoit. Le numéro de séquence peut être utilisé par une application pour placer les paquets reçu dans l ordre transmis. La numérotation commence par un nombre aléatoire pour des raisons de sécurité. Le champ tampon de temps ou Timestamp contient une donnée de synchronisation pour un flux de paquets. Sa valeur indique le temps d échantillonnage du premier octet de payload à la source. Ainsi, l application peut jouer l échantillon au même temps par rapport au précédent. Et comme pour le numéro de séquence, la valeur initiale du timestamp est aléatoire. Il faut noter que plusieurs paquets peuvent avoir la même valeur de Timestamp, par exemple pour une image numérique transmise en plusieurs paquets : chaque paquet a un numéro de séquence différent mais tous ont le même Timestamp. L identifiant de synchronisation de la source (SSRC) est comme son nom l indique, le numéro d identifiant de la source. Cet identifiant est choisi aléatoirement. Tous les flux partant d une même source ont le même SSRC. La probabilité que deux sources aient le même identifiant est très faible. Dans certains cas, plusieurs flux audio provenant de sources différentes doivent être mixés. Les SSRC originants sont mis dans le champ CSRC comme étant les sources contribuant au flux transporté. Finalement, l entête RTP peut contenir une extension. La spécification RTP ne définit pas les extensions possibles, mais juste la possibilité d extension de l entête. - 70 -

Note : On remarque que l entête RTP ne contient aucun champ indiquant la longueur du payload. Ceci est inclus dans les protocoles de couches inférieures. Dans l architecture TCP/IP, le protocole UDP contient un champ indiquant la longueur du payload. 2. RTCP Le protocole RTP est accompagné du protocole RTCP. Chaque participant d une session RTP doit envoyer périodiquement un paquet RTCP à tous les autres participants de la même session. Selon la spécification, RTCP a quatre fonctions : 1. Donner de l information sur la qualité de la distribution des données. Cette information peut être utilisée par l application pour effectuer du contrôle de flux et de congestion. 2. RTCP distribue un identifiant qui pourrait regrouper plusieurs flux, audio et vidéo par exemple. Ce mécanisme est toutefois nécessaire, puisque RTP seul ne le présente pas. 3. En envoyant périodiquement des paquets RTP, chaque session peut marquer le nombre de participants. Le protocole RTP ne peut être utilisé pour cela, car une source pourrait ne pas envoyer des données à un moment donné, mais reçoit des données d une source. 4. Une fonction optionnelle est la distribution d information sur un participant. Cette information peut être utilisée par l application pour affichage sur l interface utilisateur. Plusieurs types de paquets RTCP sont utilisés pour assurer ces fonctions. Les sender Reports (SR) sont utilisés par la source pour la transmission et la réception de statistiques. Si un participant n est pas une source active, il distribue des statistiques de réception Receiver Reports (RR). Ces paquets de statistiques du récepteurs donnent des informations sur la qualité de service reçue, sur le nombre de paquets perdus, le besoin du changement du codage de la voix utilisé par la source. L information décrivant le participant est transmise dans un paquet Source Description (SDES). Le paquet APP permet le transport de données spécifiques à l application. Finalement, lorsqu un participant désire quitter la session, il envoie un paquet RTCP BYE. Le trafic RTCP ne doit pas dépasser 5% de la bande passante Note : RTP/RTCP fonctionnent sur des ports différents (une paire de port est allouée par connexion). Si RTP prend le port X, RTCP prend X+1. Audio et vidéo sont - 71 -

séparés. Par exemple dans le cas d une vidéo conférence, deux paires de ports sont allouées : une paire pour l audio, la deuxième pour la vidéo. Les ports sont aléatoires. Réservation de ressources Les messages RTCP peuvent être utilisés pour la réservation de ressources, donc indiquer aux routeurs quels chemins doivent être réservés. 3. Taille d un paquet RTP Comme nous avons déjà vu, il est préférable d envoyer des paquets ayant un petit payload de voix pour deux raisons : - Si un paquet est perdu, cela ne va pas causer de distorsion sévère à la communication - Pour réduire le délai de transmission de bout en bout, l intervalle d échantillonnage doit être le plus petit possible, et chaque bout de voix numérisée doit être transmise le plus tôt possible. Mais il faut toujours prendre en compte que lorsque des données sont transmises, une partie de la bande passant disponible va être occupée par les entêtes des couches inférieures. Alors, plus la taille du payload diminue, plus le pourcentage d entête dans chaque paquet augmente. Exemple : Si on considère un échantillon minimal à transmettre and un paquet IP, l entête totale RTP/UDP/IP a une longueur de 40 octets. Supposons qu une source génère un paquet de 40 octets chaque 1ms, le flux total d entête occupera 320kbps de la bande passante du canal! Mais si on augmente la taille du payload, le pourcentage de bande passante occupée par les entête diminuera par rapport à la bande passante totale du flux. Mais ceci va engendrer des délais supplémentaires. Et l augmentation de la taille du payload va résulter en ce que l application sera plus vulnérable à la perte de paquets. Nous voilà alors devant un compromis. B. Le protocole SRTP Secure Real Time Protocol est défini comme un profil du protocole RTP, introduisant confidentialité, authentification de messages et protection contre le rejeu au trafic RTP/RTCP. SRTP rajoute ce qui suit au protocole RTP : - le chiffrement et l authentification de messages aux flux RTP et RTCP - définit un groupe d algorithmes de cryptographie. - 72 -

- est ouvert à l insertion de nouveaux algorithmes - avec une gestion de clés propre, SRTP est sécurisé pour le trafic unicast et multicast RTP - le débit à travers la couche SRTP est acceptable (Throughput) Ainsi, SRTP introduit la confidentialité des payloads RTP et RTCP, et l authentification de tout les paquets RTP et RTCP, ainsi que leur protection contre le rejeu. SRTP est indépendant des protocoles des couches inférieures, tout comme RTP. SRTP réside entre la couche UDP et la couche RTP comme l indique la figure suivante. Figure 3: Positionnement de SRTP SRTP intercepte les paquets RTP pour y ajouter les services de sécurité qu il offre. L authentification des messages SRTCP est obligatoire et protège ainsi les paquets RTCP pour protéger l identité des membres d une session, donner les bonnes informations aux sources, et maintenir les numéros de séquence. Le chiffrement d un paquet RTP consiste en le cryptage des données utiles uniquement (avec le bourrage s il existe) du paquet RTP correspondant. Le format d un paquet SRTP est présenté à la figure 4 suivante : - 73 -

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ V=2 P X CC M PT sequence number +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ timestamp +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ synchronization source (SSRC) identifier +=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ contributing source (CSRC) identifiers... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ RTP extension (OPTIONAL) +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ payload... +-------------------------------+ RTP padding RTP pad count +>+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+<+ ~ SRTP MKI (OPTIONAL) ~ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : authentication tag (RECOMMENDED) : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +- Portion cryptée Portion Authentifiée ---+ Figure 4 : Format d un paquet SRTP Un paquet SRTP a le même format qu un paquet RTP avec les mêmes champs. Le profil SRTP rajoute uniquement les deux derniers champs résumés dans le tableau suivant : MKI (Master Key Identifier) Authentication tag Peut être utilisé par la gestion des clés, identifiant une «Mater Key» particulière dans le contexte cryptographique Utilisé pour les données d authentification de messages. Si les deux services d authentification et de chiffrement sont implémentés, le chiffrement est effectué avant l authentification du côté de la source, et inversement du côté de la destination. Le champ «authentication tag» assure l authentification de l entête RTP et des données utiles. Il introduit indirectement la protection contre le rejeu en authentifiant les numéros de séquence dans l entête RTP. Une seule clé «Mater Key» est l origine de toutes les autres clés utilisées pour le chiffrement et l intégrité, et ceci pour les flux SRTP et SRTCP. Les clés sont dérivées à partir de la «Master Key» à l aide d une fonction de dérivation de clés. Des clés de session sont générées à partir de la «Mater Key». La dérivation des clés peut être configurée pour faire une mise à jour périodique à partir de la clé «Master Key», limitant ainsi la quantité de données chiffrées produites avec la même clé. - 74 -

Des clés dites «Salting Keys» sont utilisées pour protéger contre certaines attaques. Crypto contexte Une session SRTP a un contexte cryptographique composé des éléments suivants : - Un compteur de 32 bits dit Roll Over Counter ou ROC, enregistre le nombre de fois le numéro de séquence des paquets retourne à zéro après avoir atteint 65,535 - Un identifiant de l algorithme de chiffrement (algorithme + le nœud sur lequel il tourne) - Un identifiant de l algorithme d authentification - Replay list, contenant la liste des derniers paquets RTP reçus et authentifiés, pour éviter le rejeu - L indicateur MKI (Master key Identifier) sur 1 bit Si l indicateur =1, le context contiendra la longueur du MKI et sa valeur courante, et ceci dans le contexte de la source - La clé Master, aléatoire et secrète - Pour chaque Master Key, un compteur de paquets permettant de savoir le nombre de paquets SRTP traités par cette «Master Key» - deux entiers positifs n_e et n_a déterminant la longueur des clés de session, pour le cryptage et l authentification de messages Pour chaque «Mater Key» existe : - un «Master salt» aléatoire et peut être public, utilisé pour la dérivation des clés de session. - Une fréquence de dérivation des clés - Un MKI - Une durée de vie Le protocole SRTCP partage le même crypto contexte décrit ci-dessus avec SRTP à l exception de ce qui suit : pas de ROC une liste de rejeu (replay list) séparée de celle de SRTP un compteur séparé pour la «Master Key» Note : La clé «Master Key» peut être partagée entre SRTP et SRTCP mais pas les clés de session. Ainsi le contexte cryptographique définit donc l état cryptographique d une session. Il est maintenu du côté source comme du côté destination. SRTP utilise deux types de clés : - 75 -

1. «Master Keys» : une suite de bits aléatoires générés par le protocole de gestion des clés, et partir de laquelle les clés de session sont dérivées par une méthode cryptographique sécurisée. 2. les clés de session ou «session keys» : utilisées directement par les algorithmes cryptographiques pour effectuer le chiffrement et l authentification de messages. Remarque : Les mécanismes de gestion des clés «Master keys» est externe à la spécification SRTP. Chaque session RTP pour chaque participant est composée de la paire suivante : (adresse du réseau destination, Paire de ports RTP/RTCP) Ainsi, une session multimédia est composée de plusieurs sessions RTP. Et chaque contexte cryptographique est identifié par : context id = <SSRC, adresse du réseau destination, ports SRTP destination> Protection contre le rejeu Une protection sécurisée contre le rejeu est mise en place lorsque la protection de l intégrité est présente. Un paquet est «rejoué» lorsqu il est intercepté par un attaquant qui le réinjecte sur le réseau. Chaque récepteur SRTP maintient une liste contenant les indices des paquets qu il a reçus et authentifiés. Cette liste est maintenue selon le principe de la fenêtre glissante. Les indices de paquets où le nombre dépasse la taille de la fenêtre sont considérés comme reçus. Chaque récepteur observe les indices des paquets arrivants ainsi que la liste de rejeu et sa fenêtre et choisit en fonction de sa liste de les accepter ou de les rejeter. Après l authentification, la liste de rejeu sera mise à jour avec les indexes des paquets nouvellement reçus. En résumé : - le chiffrement utilisé dans SRTP peut être : AES_CM (avec une clé de chiffrement de 128 bits NULL (clé «salting» de 112 bits) - l authentification de messages et l intégrité seront faites par la fonction de hachage HMAC-SHA-1 - la dérivation des clé engendre les trois clés de session suivantes à partir de la «Master Key» et du «Mater Salt» : session encryption key session authentication key session salt key - 76 -

VI. Synthèse globale A. Tableau comparatif Dans ce document le côté sécurité des différentes technologies suivantes a été étudié, ainsi que son impact sur le transport de trafic présentant des contraintes temps réel, en particulier la voix : 1. Bluetooth 2. GSM 3. WLAN 802.11 4. IP (IPSec) 5. RTP/RTCP (SRTP/SRTCP) Les différents services de sécurité bien connus sont les suivants : Authentification Confidentialité protection de l intégrité Protection contre le rejeu Protection contre la répudiation Chacune des technologies étudiées dans ce document présente certains de ces services de sécurité selon son besoin. Suite à l étude a été conduite précédemment, le tableau comparatif suivant regroupant les différents algorithmes de sécurité de chaque technologie a été dressé. - 77 -

Mécanismes de sécurité GSM Bluetooth IPsec WLAN 802.11 WEP 802.11i SRTP Gestion des clés Clé individuelle Ki utilisée par l algorithme A3, et implémentée dans la carte SIM. Une copie de cette clé réside dans la base de données de l opérateur ; Une clé de session générée par l algorithme A8 puis utilisée par A5 pour générer la clé de chiffrement Protocole IKE / ISAKMP Clé secrète partagée mise en place par l administrateur. La clé de chiffrement est générée par un générateur PRNG (Pseudo Random Number Generator) ayant comme entrée la clé secrète partagée, et le vecteur d initialisation (IV) TKIP Authentification Basée sur l algorithme A3 : entrée (nombre aléatoire de 128 bits + Ki de 128 bit enregistrée dans SIM) = sortie (Signature de 32 bits) Défi/réponse avec la base de donnée de l opérateur. Si la signature est correcte, l utilisateur est authentifié. La clé de session est basée sur l algorithme A8 : entrée (nombre aléatoire de 128 bits reçu de l opérateur + Ki 128 bits) = sortie (clé de session de 64 bits) La procédure de Pairing utilisée pour générer la clé master (128 bits) par l algorithme E22. L entrée de cet algorithme est (un nombre aléatoire de 128 bits + PIN de 8 à 128 bits + longueur du PIN) = sortie (les clés Master ou d Initialisation de 128 bits chacune) Et l algorithme E21 générant les clés unit et de combinaison de 128 bits chacune. L entrée de E22 est (un nombre aléatoire de 128 bits + BD_ADDR) = sortie ( unit ou combination keys de 128 bits) La clé de chiffrement est générée par l algorithme E3 : entrée (nombre aléatoire de 128 bits + COF de 96 bits + clé de lien de 128 bits) = sortie (clé de chiffrement de 128 bits) Authentification d équipements basée sur l algorithme E1 qui est une variante d un algorithme de chiffrement de blocs ; entrée ( défi de 128 bits lancé par l autre bout + BD_ADDR 48 bits + clé de lien) = sortie (valeur de 128 bits) ; les 32 bits de plus fort poids sont envoyés à la réception ; la même opération est effectuée côté destination pour vérifier les 32 bits reçus ; si réussi, l authentification est faite dans un seul sens. L opération doit être répétée dans l autre Pour les communications en point à point, l authentification de message HMAC est implémentée. Elle peut utiliser des algorithmes de chiffrement symétriques comme DES ou des fonctions de hachage dans un seul sens comme MD5 et SHA-1. Pour les communications multicast, un algorithme de hachage dans un seul sens est utilisé, combiné avec une signature symétrique. L authentification de la machine source est ainsi faite (et pas celle de l utilisateur) Procédure de défi/réponse avec le point d accès permettant à ce dernier de s assurer que l entité communicante a la bonne clé de chiffrement pour transmettre 802.1X Echange de messages EAP (Extensible Authentication Protocol) entre la source, le point d accès et un serveur d authentification pour effectuer l authentification de l entité désirant faire accès sur le réseau wireless Mécanismes d échange de clés sont externes à la spécification SRTP. Peut être MIKEY, KEYMGT, SDMS etc Algorithme d authentification pré défini dans la spécification SRTP est HMAC-SHA-1 avec une sortie de 80 bits et un clé de 160 bits. Le processus de calcul du condensât d authentification est le suivant : la source calcule le condensat et le rajoute aux données à envoyer. Le récepteur calcule un autre condensat avec les données reçues et le vérifie avec celui reçu avec le paquet. D autres algorithmes d authentification pourraient - 78 -

Confidentialité Basée sur l algorithme A5 : entrée (clé de session Kc de 64 bits + numéro de la trame à traiter sur 64 bits) = sortie (clé de chiffrement de 114 bits ; La clé de chiffrement XOR les blocs de données de 114 bits = texte chiffré sens pour avoir l authentification mutuelle des deux partis. Basé sur l algorithme E0 de chiffrement par paquet. Entrée (BD_ADDR 48 bits + clock + clé de chiffrement de 128 bits) = sortie (clé de 128 bits) ; Cette dernière valeur XOR Données = texte chiffré Basé sur le chiffrement symétrique de blocs par exemple DES, 3DES et récemment AES Intégrité - - L algorithme utilisé pour le calcul de l ICV est basé sur l algorithme de clé symétrique DES ou sur une fonction de hachage dans un seul sens MD5 ou SHA-1 Non répudiation - - La non répudiation est présente grâce à un algorithme d authentification asymétrique (RSA) où les clés de la source et de la destination sont utilisées pour calculer les données d authentification (dans le cas de l emploi du protocole AH) Basée sur XOR La fonction de hachage RC4 est utilisée dans WEP pour calculer un condensât ICV par la source, et le rajouter au paquet à envoyer. La réception calcule un autre ICV et le compare au reçu. Si les deux sont pareils le paquet reçu est intègre. Advanced Encryption Satndard AES être définis et utilisés Les algorithmes de chiffrement mettent l index de chaque paquet SRTP et la clé secrète dans un segment pseudo aléatoire. Chaque segment chiffre un seul paquet SRTP. Le processus de chiffrement générant le segment relatif au paquet à chiffrer effecture l opération XOR bit par bit de ce segment avec les données chiffrer. L algorithme de chiffrement pré défini dans SRTP est l AES en mode Compteur ou mode AES-f8 - Le calcul d intégrité est basé sur une fonction de hachage unidirectionnelle (comme SHA-1) - - - Non rejeu - - - - Basé sur la liste de rejeu enregistrée dans les récepteurs et qui contiennent les indices des paquets reçus selon le processus de fenêtre glissante - 79 -

B. Conception d une solution de sécurité de la voix Le but de toute cette étude est de concevoir un opérateur offrant le service de voix sur IP, indépendamment de la nature du terminal utilisé par l utilisateur. Pour effectuer un appel l utilisateur peur utiliser : - son PC relié à un réseau Ethernet par une carte réseau ordinaire (Wired) - son portable doté d une carte réseau WLAN 802.11 - son PDA Bluetooth Le point commun à toutes ces technologies étant la pile TCP/IP, le service VoIP est bien implémentable sans effectuer de changement aux différentes architectures. Le service doit couvrir au moins les services de sécurité présents dans un opérateur téléphonique ordinaire et qui sont : 1. Protection de la confidentialité d une communication de voix 2. Authentification des deux partis communicant 3. Protection contre le mauvais usage des ressources du réseau, ou bien en d autres termes, le contrôle d accès sur le réseau 4. Tarification éventuelle par l opérateur VoIP, et protection des données de tarification par les accès non autorisés 5. protection des serveurs et terminaux contre les attaques DoS (Denial of Service) pouvant causer l interruption du service, et les attaques «man in the middle». Note : Il faut prendre en considération la nature ouverte du réseau IP Internet actuel auquel tout le monde a accès. Il faut donc envisager la confidentialité de bout en bout entre les entités communicantes, et pas comme les réseau téléphoniques actuels dans lesquels le réseau de l opérateur n est pas sécurisé. Par exemple, dans le réseau GSM, la confidentialité est seulement au niveau du réseau d accès. Dans le réseau PSTN câblé, aucune confidentialité n est envisagée. Il faudrait cependant placer les services de sécurité dans l architecture actuelle de façon transparente à l utilisateur et au terminal qu il utilise. Il faut aussi spécifier si chaque service a besoin d être implémenté de bout en bout ou pas. L architecture protocolaire globale est représentée à la figure 1 suivante : - 80 -

Figure 1 : Architecture protocolaire globale Les technologies Wireless vues dans les trois premières parties de cette étude constituent des réseaux d accès. Donc, il s agissait d imposer la sécurité sur le lien radio. Dans le cas d un opérateur VoIP : - l authentification doit se faire vis-à-vis de l opérateur, qui lui à ce moment certifiera l identité des deux partis communicant. - l ouverture d une connexion chiffrée entre l appelant et l appelé indépendamment de l opérateur. Donc le chiffrement se fera de bout en bout. - le service de la protection d intégrité paquet par paquet n est pas nécessaire dans le cas de la téléphonie sur IP, vu que les échantillons de voix encapsulés dans un seul paquet IP sont très petits. La réception d un paquet dont le payload est corrompu est acceptable. Il n altèrera pas la qualité du signal reconstitué global. - le service de protection contre le rejeu peut être assuré par la confidentialité choisie et les numéros de séquence et le tampon de temps de la couche RTP. 1. Service d authentification Tout d abord, si on envisage le service d authentification, plusieurs niveaux existent, comme l authentification des équipements ou des utilisateurs. En ce qui concerne un opérateur de Voix sur IP, l authentification d utilisateur s impose. Dans ce cas, l opérateur peut être considéré comme un troisième parti, certifiant l identité des deux entités communicantes. Afin de pouvoir mieux authentifier les utilisateurs, l opérateur GSM leur fournit une carte SIM. Ainsi, l appel originant d une carte SIM identifie l utilisateur propriétaire de la carte afin de pouvoir lancer la tarification, et envoyer son identité à l appelé. - 81 -

On pourrait s inspirer de GSM pour notre opérateur VoIP qui lui aussi distribuera des cartes à puces à ses abonnés. Actuellement les cartes à puces peuvent être intégrées dans n importe quel PC par son port USB ou avec un lecteur de «smart card» qui lui sera raccordé. Le système «smart card» a commencé à être déployé dans les réseaux 802.11. Ainsi, la carte à puce fournie par l opérateur sera placée dans l équipement que l abonné utilisera pour effectuer ses appels VoIP. Cette carte doit être indépendante de la technologie de l équipement. Elle sera interfacée avec ce qu il y a de commun entre tous les abonnés de cet opérateur : la couche IP. Avec chaque carte à puce, l abonné aura un identifiant VoIP équivalent à un numéro de téléphone dans les réseaux traditionnels. La carte sera placée au niveau 3 puisque les échanges entre l opérateur et l abonné se feront aussi sur IP. Là, le développement d une API s avère nécessaire. La carte à puce contient : une clé publique propre à l opérateur (Kop) une clé privée propre à l abonné (Kab) un secret partagé entre l abonné et l opérateur (Ki) identifiant l abonné un algorithme de chiffrement L opérateur de son côté est doté d une base de données où chaque abonné a l information suivante : - le numéro identifiant de l abonné - l adresse IP courante de l abonné - la clé publique de l abonné (Kpub) - le secret partagé de l abonné (Ki) Lorsque l abonné branche son appareil sur le réseau Internet, un échange sécurisé est automatiquement déclenché entre lui et l opérateur. Ouverture d un canal sécurisé entre l opérateur et l abonné, basé sur les certificats : Tout ce que l abonné envoie sur le canal est chiffré avec la clé publique de l opérateur qui se trouve dans sa carte à puce. Les données retournées par l opérateur seront chiffrées avec la clé publique de l abonné que l opérateur détient dans sa base de données. Les deux bouts déchiffrent ce qu ils reçoivent avec leur clé privée. Cet échange servira uniquement pour des paquets, donc pas de voix pour le moment. Il peut être alors effectué sur SSL, en utilisant les couches TCP et IP. L échange suivant se fera alors une seule fois, lorsque l utilisateur branche son appareil de communication sur le réseau : 1. L abonné envoie une demande de mise à jour de son adresse IP à l opérateur. 2. L opérateur lui lance alors un défi qui est un nombre aléatoire - 82 -

3. L abonné déchiffre le défi avec sa clé privée, lui rajoute son adresse IP courante, et chiffre le tout avec sa clé Ki et renvoie à l opérateur. 4. l opérateur déchiffre la réponse avec la même clé Ki ; si le résultat est bon, l utilisateur est authentifié. L opérateur enregistre alors l adresse IP de l abonné dans sa base de données et lui renvoie un acquittement positif sur SSL aussi. Ainsi, pour chaque utilisateur on a une correspondance (adresse IP, identifiant). L échange ci-dessus illustre alors la procédure d authentification de l utilisateur auprès de l opérateur qui s effectue sur SSL. Maintenant supposons qu Alice veut appeler Bob en utilisant le service VoIP. La procédure d authentification et d établissement d appel peut avoir une durée de quelques secondes. Pas de contraintes de délais y sont imposées puisque c est un échange de paquets de données. De même l établissement de l appel dans les opérateurs de téléphonie classique prend quelques secondes! Donc, les étapes d établissement de VoIP entre Alice et Bob se résument comme suit : 1. Alice envoie à l opérateur une demande d ouverture de connexion sur le canal SSL chiffré de la même façon décrite un peu plus haut. 2. l opérateur lui lance alors un défi, qui est un nombre aléatoire, comme dans l étape 2 ci-dessus. 3. Alice déchiffre le défi avec sa clé privée, lui rajoute le numéro identifiant de l appelé Bob, et chiffre le tout avec son secret partagé Kia. Une fonction de contrôle d intégrité peut être ajoutée à ce point, et rajoutera un condensât au payload à envoyer pour que la destination s assure de l intégrité du paquet reçu. Le résultat est renvoyé sur SSL à l opérateur. 4. L opérateur déchiffre le résultat avec Kia, en tire le défi initial, et le numéro identifiant de l appelé, calcule le condensât du résultat déchiffré et le compare au condensât reçu pour s assurer de l intégrité. 5. L opérateur tire l adresse IP de Bob de sa base de données de correspondance, selon l identifiant reçu par Alice, et envoie à Bob un paquet d appel sur un canal SSL chiffré avec la clé publique de BOB contenant un défi pour l authentifier de la même manière qui a été faite précédemment avec Alice. 6. Bob envoie la réponse au défi, chiffrée avec son propre secret partagé Kib. 7. L opérateur déchiffre alors la réponse avec Kib et authentifiera donc Bob. Note : Jusqu ici, les deux partis Alice et Bob sont authentifiés auprès de l opérateur. 8. L opérateur enverra alors simultanément deux paquets d acquittement positif sur les canaux SSL, l un à Alice et l autre à Bob : a. le paquet d Alice contiendra l adresse IP de Bob et une clé de session (Ks) b. le paquet de Bob contiendra l adresse IP et l identifiant d Alice et la même clé de session (Ks) - 83 -

Figure 2 : Echange des messages d authentification Note : Le fait que l opérateur envoie l identifiant d Alice à Bob, Alice est authentifiée auprès de Bob. Maintenant, les deux partis ont toutes les informations l un sur l autre pour commencer leur conversation. 2. Service de confidentialité et de protection d intégrité Suite à la procédure d authentification décrite dans le paragraphe précédent, Alice et Bob possèdent la même clé de session Ks fournie par l opérateur sur les canaux sécurisés par SSL. Les deux partis pourront alors ouvrir un tuyau IP dont le payload est chiffré avec une clé dérivée de la clé de session, périodiquement mise à jour. - 84 -

Figure 3 : Positionnement du chiffrement par rapport aux couches protocolaires Remarque : L entête IP passe en clair afin que le routage soit fait. Le payload IP, étant formé de l entête UDP + l entête RTP + l échantillon de voix, est entièrement chiffré avec l algorithme de chiffrement câblé dans la carte à puce fournie par l opérateur. Un service de protection d intégrité par paquet effectué par une fonction de hachage unidirectionnelle peut être mis en place pour assurer la réception du payload intact. L algorithme de chiffrement câblé dans la carte à puce va nous éviter d utiliser IPsec qui impose avec ses service une extension d entête supplémentaire, et un délai de traitement dans ses algorithmes cryptographiques. Les performances d un algorithme câblé sont nettement meilleures. Comme alternative au chiffrement de la carte à puce, le protocole ESP d IPsec pourrait être envisagé pour ajouter la confidentialité et l intégrité aux paquets envoyés. - 85 -

Références - http://www.bluetooth.org - «Bluetooth : Carrying voice over ACL links», Rohit Kapoor, Ling-Jyh Chen, Yeng-Zhong Lee, Mario Gerla - Bluetooth security whitepaper, Bluetooth SIG Security Expert Group - Security Comparison: BluetoothTM Communications vs. 802.11, Thomas G. Xydis Ph.D., Simon Blake-Wilson, Bluetooth security expert group - http:// www.gsm.org - «GSM security», Max Stepanov - ADAPTIVE INTERACTIVE SPEECH TRANSMISSION OVER 802.11 WIRELESS LANS ; Antonio Servetti, Juan Carlos De Martin - http://www.securityinfo.com - http://www.networkworld.com - Overcoming QoS, security issues in VoWLAN designs, by Ravi Kodavarti, Texas Instruments, CommsDesign.com, April 3, 2003 - Smart cards for WLANs A white paper ; Jerome Ajdenbaum Iteon Version 2; February 10th,2003 - Voice over IP per call bandwidth consumption, BOScom - Voice over IPsec: Analysis and solutions, Roberto Barbieri, Danilo Bruschi, Emilia Rosti, Dipartimento di Scienze dell Informazione, Università degli Studi di Milano - Dynamic Management of the IPsec parameters: The IKE protocol, Ghislaine Labouret, http://www.hsc.fr - Investigations into Impact of Key exchange mechanisms for security protocols in VoIP Networks, Mohan Krishna Ranganathan and Liam Kilmartin - Draft RTP/RTCP - Draft SRTP/SRTCP - 86 -