\documentclass[10pt,a4paper]{report} \RequirePackage{fancyhdr,vmargin} \usepackage{graphicx} \usepackage[utf8]{inputenc} \usepackage[francais]{babel} \usepackage{style} \usepackage{here} \usepackage{indentfirst} \usepackage{amsmath} \usepackage{amsfonts} \usepackage{amssymb} \fancypagestyle{plain}{ \fancyhf{} \fancyfoot{} \fancyfoot[R]{\thepage} \fancyfoot[L]{Guillaume Kania, Mickaël Magniez, Bruno Sabos} \fancyhead[L]{SR04 - La sécurité dans les réseaux Wi-Fi} \fancyhead[R]{\includegraphics[height=0.5cm]{images/utc.eps}} } \fancyhf{} \fancyfoot{} \fancyfoot[R]{\thepage} \fancyfoot[L]{Guillaume Kania, Mickaël Magniez, Bruno Sabos} \fancyhead[L]{SR04 - La sécurité dans les réseaux Wi-Fi} \fancyhead[R]{\includegraphics[height=0.5cm]{images/utc.eps}} \pagestyle{fancy} \newcommand{\p}{\par \vspace{0.5cm}} \newcommand{\si}{\hspace*{1cm}} \begin{document} \begin{titlepage} \title{SR04 - La sécurité dans les réseaux Wi-Fi} \author{Guillaume Kania\\Mickaël Magniez\\Bruno Sabos} \date{4 janvier 2007} \maketitle \end{titlepage} \setcounter{tocdepth}{3} %\setcounter{secnumdepth}{1} \tableofcontents \listoffigures %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Introduction % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Introduction} Depuis quelques années, les réseaux Wi-Fi sont de plus en plus utilisés dans le but de faciliter les connections entre les ordinateurs. Afin de pouvoir mettre en place concrètement cette nouvelle technologie, différentes normes ont dû être établies. L'utilisation du Wi-Fi pose cependant un problème qui n'existait pas sous cette forme avec les réseaux filaires, celui de la diffusion de l'information et donc de la confidentialité de celle-ci. Pour une connexion physique, le flux d'information est canalisé, maîtrisé, ce qui n'est plus le cas avec une connexion Wi-Fi. Une onde radio-éléctrique est, en effet, beaucoup plus difficile à maîtriser qu’un signal se propageant dans un câble. \p Ce rapport a pour but d'apporter la connaissance nécessaire sur le fonctionnement des réseaux Wi-Fi et leur sécurisation et ainsi de permettre à l'administrateur réseau de faire le bon choix en terme de technologies à utiliser. La première partie de ce rapport détaillera le fonctionnement du Wi-Fi, les normes sur lesquelles cette technologie repose. Dans la deuxième partie, nous verrons quelles sont les différentes méthodes utilisées pour répondre à ce besoin de sécurité. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Généralités % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Présentation du standard 802.11} L’ensemble des standards préfixés 802 ont été établis par l’IEEE, l’Institute of Electrical and Electronics Engineers. Ils incluent des standards particuliers aux réseaux sans fils (wireless) dans la branche 802.11 développée en 1997. Ce fut le premier standard WLAN accepté par de nombreux constructeurs. Il décrit le fonctionnement des couches MAC (Media Access Control) et physique. \p Ces standards souffrent cependant de certaines lacunes et manques de précision qui peuvent amener à de fortes divergences d’interprétation selon les constructeurs qui souhaitent suivre les normes de l’IEEE. C'est ainsi que l’association internationale \textit{Wi-Fi alliance} a vu le jour en 1999. Son but est de lever les ambiguïtés des standards et de proposer une certification aux périphériques de communications sans fil afin d’apporter une certaine interopérabilité entre les matériels de différents constructeurs. \section{Modes} Les réseaux sans fils peuvent être configurés selon deux architectures principales: \subsection{Le mode infrastructure} C’est le mode le plus courant d’utilisation des réseaux sans fil. Dans cette configuration, chaque machine cliente se connecte au réseau par le biais d’un point d’accès qui contrôle tout le trafic. L’ensemble formé d’un point d’accès et d’au moins un client forme un BSS (Basic Service Set). Chaque BSS est identifié par un SSID (Service Set Identifier) encore nommé BSSID qui est attaché à chaque paquet émit dans le réseau. Il est possible de grouper plusieurs BSS en un seul réseau alors appelé ESS (Extended Service Set) mais qui apparaît toujours comme un seul BSS au niveau LLC. Le SSID devient alors un ESSID. \p Lorsqu'un client passe d'un BSS à un autre lors de son déplacement au sein de l'ESS, son périphérique de communication sans fil est capable de changer de point d'accès selon la qualité de réception des signaux provenant des différents points d'accès. Les points d'accès communiquent entre eux grâce au système de distribution (filaire ou directement aérien) afin d'échanger des informations sur les stations et permettre le cas échéant de transmettre les données des stations mobiles. Cette caractéristique permettant aux stations de "passer de façon transparente" d'un point d'accès à un autre est appelé itinérance (en anglais roaming). \subsection{Le mode Ad-Hoc} Le mode “Ad-Hoc” ou IBSS (Independent Basic Service Set), est une configuration de type peer-to-peer (pair à pair) utilisée majoritairement pour de petits réseaux. Selon ce mode, aucun point d’accès ne gère les communications du réseau et ceux sont les entités communicantes qui doivent jouer le rôle de client et de point d’accès et hérite des fonctions qui incombe dans le mode infrastructure au point d’accès comme la diffusion de SSID et la synchronisation des horloges. L’IBSS est identifié par un SSID, comme l'est un ESS en mode infrastructure. \p Dans un réseau ad hoc, la portée de l’IBSS est déterminée par la portée de chaque station. Cela signifie que si deux des stations du réseau sont hors de portée l'une de l'autre, elles ne pourront pas communiquer, même si elles "voient" d'autres stations. En effet, contrairement au mode infrastructure, le mode ad hoc ne propose pas de système de distribution capable de transmettre les trames d'une station à une autre. Ainsi un IBSS est par définition un réseau sans fil restreint. \p \section{Normes} 802.11 est donc la norme initiale proposée par l’IEEE. De nombreuses révisions sont ensuite apparues afin d’augmenter les capacités de débits (802.11a, 802.11b, 802.11g) ou d’apporter une meilleure sécurité et interopérabilités des matériels. \subsection{802.11} La couche MAC a été standardisée de façon à compenser les interférences et le taux excessif de perte de trames (compare à Ethernet). Cependant, 802.11 a une limite de débit de 2 MB. C’est un très faible débit compare aux possibilités des réseaux actuels. \subsubsection{La couche physique} La couche repose sur deux principes : Le DSSS (Direct Sequence Spread Spectrum) et le FHSS (Frequency Hopping Spread Spectrum). Chacun utilise une méthode différente de transmettre les signaux. DSSS utilise un unique large canal statique prédéfinie dans le point d’accès. Avec FHSS, le point d’accès et le client négocient ensemble pour fixer le signal dans une étroite bande de fréquence entre 2 et 4 GHz utilisable par 802.11. \subsubsection{La couche MAC} \paragraph{Format de trame} : \p Chaque trame est constituée d'un en-tête (appelé MAC header), d'un corps et d'un FCS (Frame Sequence Check) permettant la correction d'erreur. \p \begin{center} \begin{tabular}{c|c} \textbf{Champ} & \textbf{Nombre d'octets}\\ \hline Frame Control & 2\\ \hline Duration & 2\\ \hline Address 1 & 6\\ \hline Address 2 & 6\\ \hline Address 3 & 6\\ \hline Sequence Control & 2\\ \hline Address 4 & 6\\ \hline Frame Body & 0-2312\\ \hline Frame Check Sequence & 4 \\ \hline \end{tabular} \end{center} \begin{itemize} \item Durée / ID.\\ Ce champ indique la durée d'utilisation du canal de transmission.\\ \item Champs adresses.\\ Une trame peut contenir jusqu'à 3 adresses en plus de l'adresse de 48 bits.\\ \item Contrôle de séquence.\\ Ce champ permet de distinguer les divers fragments d'une même trame. Il est composé de deux sous-champs permettant de réordonner les fragments.\\ o Le numéro de fragment\\ o Le numéro de séquence\\ \item CRC.\\ Une somme de contrôle servant à vérifier l'intégrité de la trame. \end{itemize} \p Détail du champ Frame Control: \p \begin{center} \begin{tabular}{c|c} \textbf{Champ} & \textbf{Nombre de bits}\\ \hline Frame Control & 2\\ \hline Frame Control & 2\\ \hline Subtype & 4\\ \hline To DS & 1\\ \hline From DS & 1\\ \hline More Fragments & 1\\ \hline Retry & 1\\ \hline Power Management & 1\\ \hline More Data & 1\\ \hline Wep & 1\\ \hline Order & 1\\ \hline \end{tabular} \end{center} \begin{itemize} \item Protocol Version.\\ Ce champ identifie la trame comme trame wireless. Il n’y a actuellement qu’une possibilité pour ce champ mais elle permettra de prendre en compte les évolutions de version du standard 802.11.\\ \item Type.\\ Identifie la trame comme trame de contrôle (demande d'autorisation pour émettre sur le média), trame de gestion (demandes d'association et message d'annonce au point d'accès) ou trame de données.\\ \item Subtype.\\ Définie plus précisément le champ précédent en sous catégories de trame de contrôle, gestion ou données.\\ \item To DS.\\ Ce champ indique que la trame est destiné au système de distribution (Distribution System, DS) comme Ethernet filaire par exemple, ou wireless jusqu’à un autre point d’accès. Pour toutes les trames envoyées à destination d'un point d'accès, il est positionné à 1.\\ \item From DS.\\ Au contraire, ce champ (lorsqu'il est positionné à 1) indique que la trame provient du système de distribution. Si From et To DS sont à 0, il s'agit d'une communication entre deux clients.\\ \item More Fragments.\\ Indique que d’avantage de trames arrivent.\\ \item Retry.\\ Informe le récepteur que le fragment est une retransmission d'un fragment précédemment envoyé et sûrement perdu.\\ \item Power Management.\\ Ce champ renseigne si le matériel émetteur est en mode gestion d’énergie. Inutilisé par les points d’accès qui ne vont jamais dans ce mode, il est utile pour les clients.\\ \item More Data.\\ Ce bit, utilisé pour le mode gestion d'énergie, est utilisé par le point d'accès pour spécifier à un client que des trames supplémentaires sont stockés en attente.\\ \item WEP.\\ Ce champ indique qu’un chiffrement WEP est utilisé.\\ \item Order.\\ Ce dernier champ est utilisé dans la gestion de qualité de service (Quality of Service , QoS). Dans ce mode, les trames doivent être strictement ordonnées.\\ \end{itemize} \paragraph{Types de trame}: \p Pour entamer les négociations de connexion, un client diffuse sur chaque canal une requête de sondage (probe request) contenant l'ESSID pour lequel il est configuré ainsi que les débits que son adaptateur sans fil supporte. Si aucun ESSID n'est configuré, la station écoute le réseau à la recherche d'SSID qui sont propagé régulièrement par les points d’accès dans une trame balise (beacon). L'ESSID est automatiquement diffusé par défaut, mais il est possible pour une sécurité de bas niveau de désactiver cette option.\\ \p A chaque requête de sondage reçue, le point d'accès vérifie l'ESSID et la demande de débit présents dans la trame balise. Si l'ESSID correspond à celui du point d'accès, ce dernier envoie une réponse contenant des informations sur sa charge et des données de synchronisation. La station recevant la réponse peut ainsi constater la qualité du signal émis par le point d'accès afin de juger de la distance à laquelle il se situe. En effet d'une manière générale, plus un point d'accès est proche, meilleur est le débit. Une station se trouvant à la portée de plusieurs points d'accès (au sein d’un même ESS) pourra ainsi choisir le point d'accès offrant le meilleur compromis de débit et de charge. \subparagraph{Beacon}: \p Les points d’accès émettent régulièrement des trames d’identification contenant leur configuration (débit, canal, chiffrement WEP, …). Les clients ne peuvent envoyer ce type de trame que lorsqu’ils sont en mode ad-hoc. \subparagraph{Probe Request}: \p Ce type de requête est similaire au beacon au titre qu’ils sont tout les deux utilisés pour un échange d’informations d’identification et de configuration. Contrairement aux beacon qui sont utilisés par les points d’accès pour diffuser leurs informations à tous les clients dans leur rayon de portée, les probe resquest sont émis par les clients afin de localiser un point d’accès qui possède la même configuration que lui. Si la probe a un SSID reconnu, les deux périphériques (client, point d’accès) déterminent s’ils peuvent entamer un processus d’authentification. \subparagraph{Probe Response}: \p Un point d’accès recevant une probe request répond si le SSID de la probe correspond avec le sien et si les configurations renseignées sont compatibles. La probe response est donc similaire aux beacons à cela qu’elle n’est envoyée que si un client la demande. \subparagraph{Authentication}: \p L’authentification dépend du niveau de sécurité et doit intervenir avant d’essayer de s’associer à un réseau sans fil. Une trame d’authentification possède 3 parties principales: \p 1.L’algorithme d’authentification utilisé.\\ 2.Le numéro de transaction d’authentification qui permet d’identifier quelle trames correspondent à quelle authentification quand le point d’accès gère plusieurs tentative de connexion simultanées.\\ 3.Le code de statut qui identifie le type d’erreur ou de succès. \subparagraph{Association Request}: \p Une fois que le périphérique wireless s’est authentifié, il peut passer à l’étape suivante qui est l’association. Pour s’associer, le client doit à nouveau envoyer sa configuration au point d’accès. Ce dernier décide alors si le client peut rejoindre le réseau ou non. Pour cela il vérifie que les deux parties sont d’accord sur la configuration du réseau. Celle-ci concerne le SSID, le canal et la puissance. \subparagraph{Association Response}: \p Cette trame est la réponse du point d’accès qui indique au client qu’il est bien connecté au réseau. Elle est très proche de la trame de requête d’authentification. La seule différence est l’identification de la trame. \subparagraph{Disassociation and De-Authentication}: \p Ces deux trames sont les mêmes à la différence du code d’identification. Ce dernier permet de savoir pourquoi le client a été déconnecté du réseau. Ce code permettant d’invoquer jusqu’à 50,000 raisons n’est définie pour l’instant que sur 10 valeurs. La trame de dé-association est utilisée par le point d’accès pour supprimer du réseau les clients qui ne parlent plus depuis un moment. Cela lui permet de se "nettoyer" et notamment les clients qui sont partis sans le signaler. La dé-authentification est envoyée par un administrateur pour déconnecter un périhpérique particulier du réseau. \paragraph{Le mode CSMA/CA utilisant la Distributed Coordination Function (DCF)}: \p Le CSMA/CA (Carrier Sense Multiple Access with Collision Avoidance) est un protocole basé sur l’esquive de collision par un échange de demandes de transmission et d’accusés de réception entre l’émetteur et le récepteur. En effet, contrairement aux réseaux filaires où chaque machine peut détecter les collisions en écoutant le média commun, dans un environnement dans fil, les entités communiquantes ne s’entendent pas forcément mutuellement en raison de leur rayon de portée. \p La station voulant émettre écoute le réseau. Si le réseau est encombré, la transmission est différée. Dans le cas contraire, si le média est libre pendant un temps donné (appelé DIFS pour Distributed Inter Frame Space), alors la station peut émettre. La station transmet un message appelé Ready To Send (noté RTS signifiant prêt à émettre) contenant des informations sur le volume des données qu'elle souhaite émettre et sa vitesse de transmission. Le récepteur (généralement un point d'accès) répond un Clear To Send (CTS, signifiant Le champ est libre pour émettre), puis la station commence l'émission des données. \p A réception de toutes les données émises par la station, le récepteur envoie un accusé de réception (ACK). Toutes les stations avoisinantes patientent alors pendant un temps qu'elle considère être celui nécessaire à la transmission du volume d'information à émettre à la vitesse annoncée. \subparagraph{RTS}: \p Tout d’abord l’initialisation de l’échange avec la requête RTS (Request to Send). Le client l’émet lorsqu’il a besoin d’envoyer des donées. Le client determine dans ce message le temps qu’il souhaite réserver, correspondant à une estimation personnelle de son temps d’emission des données en question. C’est ce que précise le bit NAV. Le point d’accès utilisera également cette information pour determiner combien de temps le client devra attendre avant de pouvoir redemander à émettre. \begin{center} \begin{tabular}{c|c} \textbf{Champ} & \textbf{Nombre de bits}\\ \hline Frame Control & 2\\ \hline Duration & 2\\ \hline Receiver Address & 6\\ \hline Transmitter Address & 6\\ \hline Frame Check Sequence & 4\\ \hline \end{tabular} \end{center} \begin{itemize} \item Frame control section.\\ C’est le champ identifiant la trame comme requête RTS.\\ \item Duration.\\ C’est le temps que le client souhaite obtenir afin d’envoyer ses données.\\ \item Receiver address.\\ C’est l’adresse MAC du client de destination.\\ \item Transmitter address.\\ C’est l’adresse MAC du client source.\\ \item Frame check sequence.\\ En raison du taux d’erreurs élevé sur un réseau sans fil, la couche MAC intègre directement un contrôle d’erreur. \end{itemize} \subparagraph{CTS}: \p La CTS est retournée par le point d’accès lorsque la RTS d’un client est acceptée. Elle indique combien de temps le client est autorisé à émettre avant de devoir recommencer le processus complet de demande d’émission. La trame CTS est équivelente à la trame RTS mis à part le champ Tramsitter Address, l’ancienne adresse contenu dans celui-ci étant transférer dans le champ Receiver Address. \p \begin{center} \begin{tabular}{c|c} \textbf{Champ} & \textbf{Nombre de bits}\\ \hline Frame Control & 2\\ \hline Duration & 2\\ \hline Receiver Address & 6\\ \hline Frame Check Sequence & 4\\ \hline \end{tabular} \end{center} \p \subparagraph{DATA}: \p Ces trames ne rentre pas dans le processus de CSMA/CA à proprement parlé, mais interviennent en troisième acteurs dans le déroulement d’un envoi de données. \p \begin{center} \begin{tabular}{c|c} \textbf{Champ} & \textbf{Nombre de bits}\\ \hline Frame Control & 2\\ \hline Duration & 2\\ \hline Destination Address & 6\\ \hline BSSID & 6\\ \hline Source Address & 6\\ \hline Sequence Control & 2\\ \hline Payload & 0-2312\\ \hline Frame Check Sequence & 4\\ \hline \end{tabular} \end{center} \p \textbf{Fragmentation} En raison du nombre d’erreur fréquent dans les communications sans fil, proportionnel à la taille des trames, 802.11 offre un mécanisme de fragmentation des trames. Cela permet de ne renvoyer, en cas d’erreurs des morceaux plus petits que la trame complète. Cependant, la fragmentation entraîne un problem d’overhead et implique un réordonnancement à l’arrivée des fragments. \subparagraph{ACK}: \p La trame d’Acknowledgment indique à l’émetteur que les données ont été reçues sans erreurs. L’ACK est similaire à la CTS vu précédemment. Le champ Frame control section identifie la trame comme acknowledgment. \p \begin{center} \begin{tabular}{c|c} \textbf{Champ} & \textbf{Nombre de bits}\\ \hline Frame Control & 2\\ \hline Duration & 2\\ \hline Receiver Address & 6\\ \hline Frame Check Sequence & 4\\ \hline \end{tabular} \end{center} \p \textbf{Distributed Coordination Function} La DCF permet d’interroger le media (ici, l’environnement) afin de déterminer si quelqu’un est en cours d’envoi d’informations. Comme vu précédemment, avant de pouvoir émettre, un client doit s’assurer que personne n’utilise le réseau. Pour cela, DCF examine l’entête MAC entière des trames émises pour déterminer combien de temps va prendre l’envoi en cours. \p \textbf{La Point Coordination Function (PCF)} Le PCF ou mode d’accès contrôlé est base sur l’interrogation à tour de rôle des stations (polling), contrôlée par le point d’accès. Le client indique au point d’accès qu’il est prêt à répondre au poll. PCF ne peut donc fonctionner qu’en mode infrastructure. Une fois prévenu, le point d’accès va interroger les clients afin de savoir s’ils ont des données à envoyer. Cette méthode est conçue pour les applications temps réel (vidéo, voix) nécessitant une gestion du délai lors des transmissions de données. \subsection{802.11b} 802.11b est un des standards les plus largement utilisé dans le domaine des réseaux sans fils. \p Il a été mis au point pour proposer un plus gros débit que ne le proposait le standard 802.11 tout en gardant une rétro-compatibilité avec les matériels suivant les spécifications du 802.11. En effet, le débit du 802.11b atteint un maximum de 11 MB comparé aux 2 MB du 802.11. \p Au niveau de la couche physique, contrairement au 802.11 qui propose un choix entre le DSSS et le FHSS, 802.11b se concentre sur le DSSS et utilise donc un unique spectre de fréquences de 20 MHz dans une bande de 2.4 ISM. Ce choix est du au fait qu’il est difficile d’étendre le FHSS au-delà des 2 MB de débit. \p Au niveau 2, 802.11b utilise le CSMA/CA. \subsection{802.11a} Bien que les standards 802.11a et 802.11b furent développés en même temps (en 1999), le standard 802.11a fut finalisé bien après le 802.11b. \p Le 802.11a permet des débits de 54 MB en utilisant au niveau physique l’OFDM (Orthogonal Frequency Division Multiplexing) qui consiste à diffuser le signal à transmettre sur plusieurs porteuses afin de pourvoir à l’arrivée reconstituer le message malgré le brouillage de certaines fréquences. Comme le 802.11b, ce standard se base sur CSMA/CA. \subsection{802.11e} Ce standard est encore en étude. Il vise à instaurer une gestion de la qualité de service (QoS) dans les communications sans fil au niveau de la couche liaison de données afin d’accepter de nouvelles utilisations du réseau comme la voix ou la vidéo, critiques en temps de réponse. Dès sa finalisation, les mécanismes du 802.11e devraient être rapidement intégrés par les constructeurs. \subsection{802.11f} 802.11 n’a jamais réellement défini les algorithmes d’itinérance à utiliser. Chaque constructeur a du déterminer indépendamment sa méthode. \p Le but de 802.11f est de proposer une solution unique afin de rendre les différents matériels réellement interopérables. Cisco systems proposa un standard qui fut accepté en 2003. Il spécifie un protocole appelé IAAP pour Inter Access Point Protocol. \p IAAP est basé sur du multi-cast qui partage les informations sur les connexions client entre les points d’accès d’un même sous-réseau. Ainsi, IAAP permet à un utilisateur itinérant de changer de point d'accès de façon transparente lors d'un déplacement, quelles que soient les marques des points d'accès présentes dans l'infrastructure réseau. \subsection{802.11g} La norme 802.11g reprend le principe de transmission physique OFDM utilisé par 802.11a. Elle permet donc sur un seul canal subdivisé de fournir un meilleur débit que 802.11 et 802.11b (54 MB théorique). La particularité de 802.11g est de se situer dans la même plage de fréquence que le 802.11b. Cela lui assure une compatibilité avec les périphériques de type 802.11b. \subsection{802.11d et 802.11h} Ces deux normes visent a "internationaliser" 802.11. La première doit permettre aux matériels de s’échanger des informations sur les plages de fréquences et les puissances autorisées dans les différents pays, alors que la deuxième veut se rapprocher des réglementations européenne en matière de fréquence et d’économie d’énergie. \subsection{802.11i} 802.11i est un standard de sécurité élaboré en 2004 qui peut s’appliquer aux autres normes de la famille 802.11 (a/b/g). Entrainant beaucoup de changements, cette norme inclue notamment le chiffrement AES (Advanced Encryption Standard). \subsection{802.11n} Cette norme est un projet prévu pour fin 2007. Elle devrait permettre un débit théorique impressionnant de 540 MB, équivalent à 50 fois 802.11b et 10 fois 802.11a ou g. La technique proposée (MIMO) est d’utiliser plusieurs transmetteurs et plusieurs récepteurs simultanément. \p 802.11n devrait de plus pouvoir supporter à la fois les normes 802.11a et 802.11g. \subsection{L'authentification dans les réseaux 802.11} Nous avons vu précédemment que la connexion d’un client à un point d’accès se déroulait en deux étapes. Le client doit d’abord s’authentifier. Si sa configuration est compatible avec celle du point d’accès, il peut alors s’associer au réseau. \p Les normes acceptant la sécurisation de leurs communications par clé WEP peuvent utiliser deux modes d’authentification. \subsubsection{L’authentification partagée} Dans cette configuration, le point d’accès diffuse en clair une chaîne de caractères générée aléatoirement. Les clients qui souhaitent se connecter au réseau chiffrent cette chaîne à l’aide de leur clé WEP et la retourne au point d’accès. Ce dernier la déchiffre afin de valider la clé du client.\\ Le gros problème de ce mode est que des mêmes données circulent en clair et en chiffrées, ce qui facilite le décryptage. \subsubsection{L’authentification ouverte} Avec ce mode, le client est automatiquement authentifié et également associé. Il peut tenter de communiquer directement avec le point d’accès et les autres clients. Il faut cependant que sa clé WEP soit valide pour que les paquets soient déchiffrable convenablement.\\ Bien que tous les clients puissent se connecter directement au réseau, les communications irrégulières n’étant pas prises en compte, ce système est considéré comme moins sensible aux attaques que l’authentification partagée. \subsection{Synthèse} \begin{tabular}{l|l|l|l|l|l|l} Norme & Date & Fréquence $\backsimeq$ & Débit réel & Débit théorique & intérieur & extérieur \\ \hline 802.11 & 1997 & 2GHz & 1 Mbit/s & 2 Mbit/s & ? & ? \\ 802.11a & 1999 & 5GHz & 25 Mbit/s & 54 Mbit/s & 50m & ? \\ 802.11b & 1999 & 2 GHz & 6.5 Mbit/s & 11 Mbit/s & 100m & 200m \\ 802.11g & 2003 & 2GHz & 25 Mbit/s & 54 Mbit/s & 100m & 75m \\ 802.11n & (2007) & 2GHz ou 5GHz & 200 Mbit/s & 540 Mbit/s & 50m & ? \\ \end{tabular} %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Les protocoles de sécurisation % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Les protocoles de sécurisation} \section{WEP} \subsection{Présentation} Le WEP (Wired Equivalent Privacy) est le protocole de chiffrement par défaut introduit dans la première norme 802.11 en 1999. WEP a pour objectif d'offrir aux réseaux sans-fil 802.11 une sécurité comparable à celle qui existe dans un réseau 802.1. Il doit donc fournir au niveau 2 des mécanismes d'authentification, de préservation de la confidentialité et de contrôle d'intégrité. Pour les offrir, WEP utilise l'algorithme de chiffrement par flot RC4 pour assurer la confidentialité et la somme de contrôle CRC-32 pour en assurer l'intégrité. \p Le WEP 64 bits utilise une clef de chiffrement de 40 bits à laquelle est concaténé un vecteur d'initialisation (initialization vector ou IV en anglais) de 24 bits. La clef et le vecteur d'initialisation forment ainsi une clef RC4 de 64 bits permettant de chiffrer les données échangées. Au moment où la norme WEP a été rédigée, les restrictions imposées par le gouvernement des États-Unis d'Amérique sur l'export des moyens cryptographiques limitaient la taille des clefs. Une fois ces restrictions retirées, les principaux fabricants étendirent le WEP à 128 bits en utilisant une clef de 104 bits. \p Une clef WEP de 128 bits est quasiment toujours saisie par les utilisateurs comme une suite de 26 symboles hexadécimaux. Chaque symbole représente 4 bits de la clef WEP. 4 * 26 = 104 bits. En ajoutant le vecteur d'initialisation (IV) de 24 bits, on obtient ce que l'on appelle « une clef WEP de 128 bits ». \p \begin{figure}[H] \centering \includegraphics[width=8cm]{images/802.11header.eps} \caption{Trame 802.11} \end{figure} \subsubsection{L'algorithme de chiffrement RC4} RC4 (Rivest Cipher 4) est un algorithme de chiffrement par flot conçu en 1987 par Ronald Rivest, l'un des inventeurs du RSA, pour les Laboratoires RSA. Il est supporté par différentes normes, par exemple dans SSL ou encore WEP qui nous intéresse ici. \p L'algorithme utilise une clef de longueur variable (de 1 à 256 octets, cependant à cause des lois d'exportation, la clef a souvent une longueur de 40 bits) qui est utilisée pour initialiser une "table d'états" de 256 octets. La table d'état est employée pour la génération d'octets pseudo-aléatoires et ensuite pour produire le flux pseudo-aléatoire avec lequel le texte clair sera transformé grâce à l'opération OU-Exclusif. \p Deux étapes sont donc nécessaires pour le chiffrement : l'initialisation de la table d'états à l'aide de la clef et le chiffrement du texte clair. \p \begin{enumerate} \item La première étape génère un tableau de 256 octets en fonction de la clef (appelé table d'états, laquelle sera le flux appliqué sur le texte clair) initialisé avec les nombres de 0 à 255 permutés pseudo-aléatoirement (dépendant de la clef) : \begin{verbatim} for i from 0 to 255 S[i] := i j := 0 for i from 0 to 255 j := (j + S[i] + key[i mod keylength]) mod 256 swap(S[i],S[j]) \end{verbatim} \p \item La deuxième étape consiste aussi en des permutations pour effectuer le chiffrement. À noter que les additions sont toutes exécutées modulo 256. Le chiffrement est relativement simple, le flux des octets ne dépendant pas du texte en clair, il ne dépend que de la clef. \begin{verbatim} i := 0 j := 0 foreach byte b of plain text: i := (i + 1) mod 256 j := (j + S[i]) mod 256 swap(S[i],S[j]) output S[(S[i] + S[j]) mod 256] \end{verbatim} \p Cette fonction produit donc un flux d'octets de taille égale au texte clair, il ne reste donc qu'à appliquer le XOR entre ces deux flux. \p Pour un octet à chiffrer, on a donc : \begin{figure}[H] \centering \includegraphics[width=10cm]{images/RC4.eps} \caption{Fonctionnement de RC4} \end{figure} \p L'octet chiffré est déterminé à partir des valeurs de S[i] et S[j], en les ajoutant (modulo 256), et regardant la valeur correspondante dans la table d'états S. L'octet chiffré est alors le résultat du OU-exclusif entre cette valeur est l'octet du texte clair. \end{enumerate} \subsection{Fonctionnement} Dans WEP, le chiffrement est assuré par RC4. Cet algorithme reprend le principe du masque jetable et est constitué d'un générateur de données pseudo-aléatoire dont la sortie dépend d'une clef avec lequel on l'initialise. On génère donc un flux de données de taille identique au flux de données à chiffrer et on fait un XOR entre les deux, le déchiffrement se faisant alors par XOR entre le chiffré et le même flux pseudo-aléatoire. Or, dans le cas présent, nous ne voulons pas protéger un flux de données, mais des trames distinctes. Il conviendra donc de réinitialiser RC4 à chaque envoi de trame. Comme l'algorithme repose sur XOR, on veut éviter la réutilisation des clefs. C'est pourquoi on découpe notre clef RC4 en deux. Un premier jeu de 24 bits aléatoires (et transmis en clair en entête de trame) appelé vecteur d'initialisation (IV) qui précédera une clef fixe de 40 ou 104 bits, dite clef WEP (K), selon qu'on désire un chiffrement à 64 ou 128 bits. Ainsi, on espère faire tourner les clefs de chiffrement. Pour un message M clair (ICV représentant le calcul du CRC32), son chiffré sera donc : \p $P = RC4(IV \centerdot K) \oplus (M \centerdot ICV(M))$ \p Le chiffrement d'une trame se fait donc de la façon suivante : \begin{figure}[H] \centering \includegraphics[width=10cm]{images/wep.eps} \caption{Chiffrement d'une trame en WEP} \end{figure} \p On peut alors remarquer que seul le message et le contrôle d'intégrité sont chiffrés, alors que l'IV est transmis en clair. \p En ce qui concerne l'authentification, la norme 802.11 initiale spécifie deux modes différents : ouvert ou partagé (open ou shared). L'authentification ouverte signifie l'absence d'authentification et l'authentification partagée signifie l'utilisation d'un secret partagé, en l'occurrence une clef WEP dans un mécanisme challenge/réponse. Le point d'accès envoie un challenge aléatoire de 128 octets à partir duquel la station devra construire une trame de réponse correctement chiffrée à renvoyer. Il suffira alors au point d'accès de vérifier le bon déchiffrement de cette trame. \p On peut donc conclure que WEP utilise un algorithme de chiffrement faible dont le vecteur d'initialisation en est la clef de voûte. Pour maintenir un niveau décent de sécurité et éviter la fuite d'information l'IV doit être incrémenté pour chaque paquet afin que le paquet suivant soit chiffré avec une clef différente. Malheureusement pour la sécurité du protocole, l'IV est transmis en clair et le standard 802.11 ne rend pas obligatoire l'incrémentation de l'IV. \subsection{Les failles du WEP} \subsubsection{Cassage de la clef} On peut voir plusieurs problèmes dans ce protocole. Tout d'abord, ce protocole n'inclut aucun mécanisme permettant d'empêcher le rejeu ou l'injection arbitraire de données, ce qui constitue un moyen très efficace pour aider au cassage de WEP. \p Ensuite, un CRC32 est généralement utilisé pour détecter des erreurs de transmissions, or ce type de somme n'a pas les propriétés nécessaires pour assurer un bon contrôle d'intégrité, en particularité à cause de sa linéarité (il est simple de compenser un CRC32 quand on modifie le message sur lequel il est calculé, même en ayant peu de connaissances sur le contenu de ce message). \p Enfin, on voit tout de suite que l'authentification partagée est unilatérale. Si le point d'accès authentifie la station, cette dernière n'a aucun moyen d'authentifier le point d'accès auquel elle s'associe. Un point d'accès malicieux peut alors soustirer des informations à un client en lui fournissant des messages à chiffrer sous forme de challenge. Mais faille la plus importante vient du mécanisme d'authentification lui-même qui entraîne l'envoie du challenge d'abord en clair, puis chiffré. L'authentification n'est donc pas efficace. Pire, elle introduit une faille qui permet d'extraire des données précieuses (le même message, en clair et en chiffré) qui pourront contribuer à casser la clef. \p En ce qui concerne le chiffrement proprement dit, il y a trois règles de bases dans l'utilisation de RC4 : \begin{enumerate} \item ne jamais utiliser deux fois la même clef dans le même contexte \item jeter les 512 premiers octets de la sortie RC4 pour éviter les problèmes liés à l'utilisation de clefs faibles \item ne pas chiffrer plus de $2^{36}$ octets de données avec la même clef \end{enumerate} \p On pourrait croire que l'espace des clefs utilisées sur un réseau protégé par WEP est de 64 ou 128 bits, mais ce n'est pas le cas. En effet, la clef RC4 est construite par concaténation de l'IV et de la clef WEP K qui est fixe. La seule partie changeante est donc l'IV, ce qui nous donne un espace de clefs de 24 bits seulement. Si on applique le fameux théorème des anniversaires, on s'aperçoit qu'un collision de clef a 99\%de chances de se produire après l'envoi de seulement 12000 trames. La première règle n'est donc pas respectée, ce qui entraîne des fuites d'information utilisable pour la découverte de la clef. \\ La seconde règle n'est pas respectée non plus, ce qui rend le système vulnérable à l'utilisation de clefs faibles. Or il se trouve qu'on reconnaît les clefs faibles à leur premiers bits, qui font partie de l'IV, qui est transmis en clair dans l'entête de la trame. La simple observation du trafic permet donc de repérer les trames chiffrées avec des clefs faibles. Enfin, WEP n'a aucune condition d'arrêt, ce qui enfreint la troisième règle, facilitant là encore l'attaque du système. \p Il apparaît donc que WEP présentent plusieurs vulnérabilités, dont certaines sont structurelles. S'il est par exemple simple de modifier le générateur d'IV pour supprimer les clefs faibles, les problèmes du mécanisme d'authentification, de l'utilisation du CRC32 ou encore les possibilités de rejeu/injection ne peuvent pas être corrigés sans modifier le protocole lui-même. \subsection{Les attaques possibles} Nous avons donc présenté une faille dans le mécanisme d'authentification permettant à un attaquant de récupérer la sortie de RC4 pour un IV donné, laquelle pourra lui servir ensuite à calculer une réponse à un challenge arbitraire de manière à s'authentifier sans pour autant être en possession de la clef WEP. Cependant, cette faille ne s'arrête pas là. La sortie $RC4(IV \centerdot K)$ qu'il récupère est en effet longue de 140 octets, ce qui est largement suffisant pour chiffrer quelques requêtes courtes, ARP ou HTTP par exemple. L'attaquant est donc en mesure, à partir de l'observation d'une authentification, d'injecter des paquets cohérents dans le réseau. Il sera également en mesure de déchiffrer les 144 premiers octets de tout paquet chiffré avec l'IV en question. \p Afin d'obtenir des trames de taille supèrieure, l'attaquant peut utiliser la fragmentation 802.11 qui permet d'éclater un payload quelconque sur plusieurs trames distinctes. Comme chaque trame est chiffrée indépendamment des autres, il est possible de chiffrer plusieurs fragments avec la même sortie RC4 pour injecter des paquets IP de taille supérieure. Mais l'intérêt de l'attaque ne s'arrête pas là. Lorsqu'un point d'accès doit réémettre une trame fragmentée, il va la défragmenter, et comme nous connaissons le contenu de cette trame défragmentée, nous pouvons récupérer la sortie RC4 correspondant à l'IV utilisé par le point d'accès sur la longueur complète de notre trame. 802.11 nous accorde 64 fragments, ce qui est largement suffisant pour atteindre la MTU, et les 8 premiers octets de toute trame 802.11 chiffrée sont connus. Il s'agit de l'entête LLC/SNAP, dont la valeur est souvent connue : \begin{itemize} \item 0xAAAA030000000800 pour IP \item 0xAAAA030000000806 pour ARP \end{itemize} \p Comme l'immense majorité des réseaux parlent IP, et que les trames ARP sont faciles à repérer, nous pouvons aisément déduire 8 octet de sortie RC4, ce qui permet de chiffrer 4 octets de données (les 4 derniers étant le CRC), fois 64 fragments, moins les 28 octets de header (LLC/SNAP + IP), ce qui permet d'envoyer 36 octets de données, sans rien avoir fait de plus que d'écouter du trafic arbitraire. En ajoutant de la fragmentation IP par dessus le tout, nous sommes très rapidement capable d'injecter sur un réseau WEP n'importe quel paquet IP. \p Le but maintenant est de passer de la capacité d'injecter des paquets arbitraires au cassage de WEP. L'idée en elle même est assez simple. Nous savons que si nous possédons une sortie RC4 pour un IV donné de longueur N, alors nous pouvons déchiffrer tout payload chiffré de longueur N chiffré avec cet IV. L'idée est de construire une table associant à chaque IV la sortie RC4 correspondante sur la longueur maximale. \p L'injection de trafic sert alors à stimuler le réseau de toutes les manière possibles pour récupérer ces données : faire défragmenter au point d'accès, envoyer des requêtes à des stations de réseau, émettre des requêtes à destination de machines contrôlées à l'extérieur, tout est bon pour générer des trames dont nous sommes capables de prédire le contenu les plus longues possibles. Un telle table, une fois constituée, avoisine les 25 Go de données. C'est lourd, et les attaques les plus rapides étant annoncées à plusieurs heures, c'est trop long pour attaquer un réseau dans la plupart des cas. Il faut trouver plus rapide. \p Avant de passer à la récupération pure et simple de la clef, on peut exploiter la linéarité du CRC32. Dans la mesure où XOR est également linéaire, nous pouvons manipuler l'équation produisant le payload chiffré lorsqu'on introduit une modification. Si nous considérons un message M' obtenu par modification d'un message M de la manière suivante : $M'= M \oplus Mod$ Nous pouvons alors tenter de calculer P' le chiffré de M' : $P' = RC4(IV \centerdot K) \oplus (M' \centerdot ICV(M'))$\\ $ = RC4(IV \centerdot K) \oplus (M XOR Mod \centerdot ICV(M \oplus Mod))$\\ $ = RC4(IV \centerdot K) \oplus (M \centerdot ICV(M)) \oplus (Mod \centerdot ICV(Mod))$\\ $ = P \oplus (Mod \centerdot ICV(Mod))$\\ \p Nous voyons que si nous disposons d'une trame chiffrée, le calcul d'une nouvelle trame modifiée, mais cohérente vis-à-vis de WEP, ne dépend que de la modification qu'on veut apporter. C'est évidemment le cas plus simple, à longueur constante, mais on sait obtenir le même genre de résultat en enlevant ou en rajoutant des données. L'utilisation la plus connue de cette faiblesse est l'attaque dite chopchop. Elle consiste à capturer une trame et à la rejouer en enlevant le dernier octet. Pour que la modification apporté soit cohérente, nous avons besoin de connaître la valeur de cette octet. On construit donc 256 trames modifiées, une pour chaque valeur possible de l'octet, et on les soumet à l'AP pour voir s'il les relaie ou non. Si c'est le cas, on a la bonne valeur. On transforme donc notre AP en oracle. Ainsi, par itération, nous pouvons déchiffrer une trame complète. Évidemment, il est impensable de déchiffrer un flux à la volée en utilisant cette attaque. Mais elle permet de déchiffrer des paquets arbitraires lorsque le besoin se fait sentir. \p Mais notre but est toujours de récupérer la clef K. Pour se faire, revenons au problème des clefs faibles : Dès 1996, il a été montré que RC4 présentait des faiblesses. En particulier, pour des clefs spécifiques dites faibles. Un flux de données dont on connaîtrait les premiers octets chiffré à l'aide d'une telle clef nous permettrait d'obtenir des informations sur l'état interne de RC4. Nous avons vu que nous sommes capable de savoir si une trame est chiffrée avec une clef faible ; il suffit de regarder la valeur de l'IV. Mais nous avons vu aussi que les 8 premiers octets du payload sont également connus (l'entête LLC/SNAP). Il n'en faut pas plus pour implémenter une attaque qui permet de casser purement et simplement la clef, c'est à dire récupérer K, à partir d'une capture de 1 à 2 millions de paquets chiffrés avec des clefs faibles différentes, ce qui se traduit par l'utilisation d'IV qu'on appellera IV faibles. Cette attaque, qui date de 2001, porte le nom de ses inventeurs, à savoir Fluhrer, Mantin et Shamir (attaque FMS). Un aspect intéressant de cette attaque est que sa complexité est presque linéaire avec le nombre de bits de clef, alors qu'elle est exponentielle pour une attaque en force brute. Ainsi, l'effort nécessaire pour casser une clef de 128 bits sera à peine plus du double de celui nécessaire à la récupération d'une clef de 64 bits. On peut d'ors et déjà constater que WEP est mourant. La réaction évidente des constructeurs fut de supprimer les IV faibles, ce qui, combiné au temps nécessaire pour récupérer une capture utilisable, a longtemps confiné cette attaque aux laboratoires et aux démonstrations. \p Plus tard, cette attaque fut optimisée, d'abord en l'étendant à de nouvelles classes d'IV puis finalement à tous les IV possibles, tout reposant sur le fait que les octets qu'on peut deviner avec une forte probabilité sont assez nombreux dans les entêtes. L'implémentation la plus connue de ces attaques est aircrack, qui permet, à partir d'une capture réseau contenant suffisamment de paquets chiffrés avec des IV différents, de casser une clef en une dizaine de secondes.\\ Le facteur limitant de l'attaque devient alors le temps nécessaire à réaliser la capture. Pour cela, on va tout simplement stimuler de réseau, soit par injection de trames arbitraires avec les techniques précédemment évoquées, soit par rejeu de trafic. C'est cette dernière technique qui est implémentée dans aireplay: le logiciel repère des requêtes ARP et les rejoue en espérant déclencher des réponses qui vont alors alimenter notre capture en nouveaux IV. D'une part, le trafic ARP étant très particulier, il est facile à repérer. D'autre part, la faible tailles des paquets (28 octets) rend l'injection et la génération de trafic particulièrement rapide. En laboratoire, on parvient à casser des clefs de 128 bits en 10 minutes. Dans des conditions "réelles", on tourne autour de 30 minutes, voire une heure, ce qui reste très faible. \p À partir du moment où un attaquant possède la clef du réseau, il y entre comme un utilisateur normal et peut donc lancer toute une collection d'attaques allant de l'injection directe de trafic à toutes les attaques ciblant les réseaux locaux (ARP cache poisoning, spoofing, DHCP snooping, DNS spoofing, etc.). \subsubsection{Dé-authentification} Cette attaque peut être conduite pour découvrir un SSID caché (i.e. un identifiant non diffusé), pour capturer le 4-Way Handshake WPA ou pour réaliser un déni de service. Le but de cette attaque est de forcer la ré-authentification des clients, elle est rendue possible par le manque d'authentification des trames de contrôle (utilisées pour l'authentification, l'association, etc.) permettant à un attaquant d'usurper les adresses MAC. Un client sans fil peut être dé-authentifié usurpant l'adresse MAC du BSSID pour envoyer un paquet de dé-authentification à l'adresse MAC du client visé. Une dé-authentification massive est aussi possible (mais pas toujours très fiable) en usurpant continuellement le BSSID et en envoyant les paquets de dé-authentification à l'adresse de broadcast. \subsubsection{Déchiffrage d'un paquet sans connaître la clef} Cette attaque est basée sur la technique chopchop, déjà présentée, et permet décrypter un paquet chiffré avec le protocole WEP sans avoir connaissance de la clef. Le contrôle d'intégrité implémenté dans le protocole WEP permet à un attaquant de modifier à la fois le contenu chiffré du paquet et le CRC correspondant. De plus, l'utilisation de l'opérateur XOR au sein du protocole WEP implique qu'un octet dans le message chiffré dépend toujours du même octet du texte en clair. En coupant le message chiffré de son dernier octet, le message devient corrompu mais il est possible de faire un choix sur la valeur de l'octet correspondant du texte en clair et de corriger le texte chiffré. Si le paquet corrigé est réinjecté sur le réseau, il sera supprimé par le point d'accès si le choix fait est incorrect (dans ce cas un nouveau choix doit être fait) mais pour un choix correct il relayera le paquet comme à son habitude. En répétant l'attaque sur tous les octets du message chiffré, il est possible de décrypter l'intégralité du paquet et de retrouver la suite chiffrante associée. Il est important de noter que l'incrémentation de l'IV n'est pas obligatoire dans le protocole WEP, il est donc possible de réutiliser la suite chiffrante pour usurper d'autres paquets (en réutilisant le même IV). Cette méthode est moins automatique que l'attaque précédente de construction de requête ARP mais elle est beaucoup plus modulaire : l'attaquant peut utiliser la suite chiffrante qu'il a découverte pour forger n'importe quel paquet dont la taille est inférieure à la suite chiffrante (dans le cas contraire il doit l'agrandir). \subsubsection{Fausse authentification} Les méthodes pour casser le protocole WEP énoncées précédemment nécessitent un client sans fil légitime (physique ou virtuel) associé au point d'accès pour que ce dernier ne supprime pas les paquets à cause d'une adresse de destination d'un client non associé. Si une authentification ouverte est utilisée, n'importe quel client peut s'authentifier et s'associer sur le point d'accès, ce dernier supprimant ensuite les paquets non envoyés avec la bonne clef WEP. Une demande d'authentification et d'association falsifiée peut donc être envoyée au point d'accès. Ce problème est à l'origine de la création de la norme 802.11i, censée améliorer l'authentification et le chiffrement dans les réseaux 802.11. \p Il apparaît donc clairement que le WEP n'est plus du tout suffisant pour sécuriser de façon acceptable un réseau Wi-Fi. \section{802.1X} \subsection{Présentation} Ce standard, mis au point par l'IEEE en juin 2001, a comme objectif de réaliser une authentification de l'accès au réseau au moment de la connexion physique à ce dernier. Cette authentification intervient avant tout mécanisme d'autoconfiguration (ex. DHCP, PXE...). Dans la plupart des cas, le service autorisé en cas de succès est le service Ethernet. L’objectif de ce standard est donc uniquement de valider un droit d’accès physique au réseau, indépendamment du support de transmission utilisé, et en s’appuyant sur des mécanismes d’authentification existants. \p Trois acteurs principaux interviennent dans ce mécanisme : \begin{itemize} \item Le système à authentifier (supplicant ou client) \item Le point d'accès au réseau local (commutateur, borne wifi etc.) \item Le serveur d'authentification \end{itemize} Tant qu'il n'est pas authentifié, le client ne peut pas avoir accès au réseau, seuls les échanges liés au processus d'authentification sont relayés vers le serveur d'authentification par le point d'accès. Une fois authentifié, le point d'accès laisse passer le trafic lié au client. \p Le chiffrement n'est pas partie intégrante de la norme 802.1x. Tous les chiffrements se placent en dehors de la norme. Par exemple, sur un réseau sans fil, l'EAP utilisera une de ses nombreuses méthodes de chiffrement pour l'authentification. Après cette authentifiaction, les utilisateurs commenceront une conversation en utilisant une autre norme de chiffrement telle que WEP, TKIP, AES ou un autre standard.\\ La norme 802.1x est basée sur d'autres standards comme EAP ou RADIUS. 802.1x est juste un mécanisme qui refuse tout le trafic autre que les paquets EAP. Une fois que EAP a autorisé le client à se connecter au réseau, le protocole 802.1x dit au point d'accés d'autoriser le trafic de cet utilisateur. Ce qui veut dire que ce standard s'occupe de la requête d'authentification et décide si le client est autorisé sur le réseau et accepte ou refuse l'accès. \subsection{Les acteurs} \subsubsection{Le serveur d'authentification} Le serveur d'authentification (appelé parfois NAS, pour Network Authentification Service, traduisez Service d'authentification réseau, voire Network Access Service, pour Serveur d'accès réseau) permet de valider l'identité de l'utilisateur, transmis par le contrôleur réseau, et de lui renvoyer les droits associés en fonction des information d'identification fournies. De plus, un tel serveur permet de stocker et de comptabiliser des informations concernant les utilisateurs afin, par exemple, de pouvoir les facturer à la durée ou au volume (dans le cas d'un fournisseur d'accès par exemple). \subsubsection{Le point d'accès au réseau} C'est la première pièce du réseau sur laquelle l'authentificatio 802.1x s'effectue. C'est dans notre cas le point d'accès, dont le rôle est alors de ne laisser passer que les paquets EAP et d'attendre une réponse du serveur d'authentification. Une fois la réponse reçue (positive ou négative), le point d'accès autorisera ou non le trafic en provenance du client authentifié vers le réseau. \subsubsection{Le système à authentifier} Le client est n'importe quel matériel possèdant une interface réseau. Quand le client veut se connecter au réseau, il doit traverser le pooint d'accès, qui ne laisse passer que l'EAP. Une fois que le serveur d'authentification aura envoyé un réponse positive, le client aura accès au réseau. \subsection{Extensive Authentication Protocol over Local Area Network (EAPOL)} Les paquets EAP sont transportés dans des trames Ethernet spécifiques EAPOL (EAP Over Lan) qui sont marquées avec le numéro de type (Ethertype) égal à 88FE, ce qui permet une encapsulation directe de EAP dans Ethernet. Le dialogue entre le système authentificateur et serveur d’authentification se fait par une simple « ré-encapsulation » des paquets EAP dans un format qui convient au serveur d’authentification, sans modification du contenu du paquet par le système authentificateur. Ce dernier effectue cependant une lecture des informations contenues dans les paquets EAPOL afin d’effectuer les actions nécessaires sur le port contrôlé (blocage ou déblocage). Ainsi, le système authentificateur débloquera le port contrôlé en cas d’authentification réussie, ou il le bloquera s’il y a une demande explicite en ce sens du système à authentifier. \p Ces trames EAPOL peuvent être des quatre types suivants : \begin{itemize} \item \textbf{EAP-Packet} : paquet de dialogue EAP, \item \textbf{EAP-Start} : authentification explicitement demandée par le système qui s’authentifie, \item \textbf{EAP-Logoff} : fermeture du port contrôlé explicitement demandée par le système qui s’authentifie, \item \textbf{EAPOL-Key} : si chiffrement disponible (ex 802.11), \item \textbf{EAPOL-Encapsulated-ASF-Alert} : transport SNMP. \end{itemize} Le type le plus important est l'EAPOL-Key, qui est utilisé par, exemple, pour le changement dynamique de clef WEP. \subsection{Remote Authentication Dial-In User Service (RADIUS)} RADIUS (Remote Authentication Dial-In User Service) est un protocole client-serveur permettant de centraliser des données d'authentification.\\ Le fonctionnement de RADIUS est basé sur un système client/serveur chargé de définir les accès d'utilisateurs distants à un réseau. Il s'agit du protocole de prédilection des fournisseurs d'accès à internet car il est relativement standard et propose des fonctionnalités de comptabilité permettant aux FAI de facturer précisément leurs clients.\\ Le protocole RADIUS repose principalement sur un serveur (le serveur RADIUS), relié à une base d'identification (base de données, annuaire LDAP, etc.) et un client RADIUS, appelé NAS (Network Access Server), faisant office d'intermédiaire entre l'utilisateur final et le serveur. L'ensemble des transactions entre le client RADIUS et le serveur RADIUS est chiffrée et authentifiée grâce à un secret partagé. \p Le poste utilisateur (supplicant dans les RFC) transmet une requête d'accès à un client RADIUS pour entrer sur le réseau. Ce client se charge de demander les informations identifiant l'utilisateur : le nom d'utilisateur (login) et le mot de passe par exemple.\\ Le client RADIUS génère selon le protocole une requête Access-Request contenant les informations d'authentification. Le serveur RADIUS peut traiter lui-même cette requête ou la transmettre à un autre serveur RADIUS par un mécanisme appelé Proxy Radius. Le serveur Radius chargé de l'identification finale (appelé Home Radius) peut traiter la demande s'il dispose de suffisamment d'éléments dans l'access request ou demander des informations supplémentaires par un renvoi de paquet Access Challenge, auquel le client répondra par un autre Access Request, et ainsi de suite. Les échanges sont retransmis par la chaîne de serveurs Radius proxy intermédiaires dans un sens et dans l'autre.\p Quand le serveur Radius dispose de suffisamment d'éléments (jusqu'à une douzaine d'échanges pour les protocoles complexes de type EAP) le serveur RADIUS valide ou refuse la requête en renvoyant un paquet de type : Access-Accept ou Access-Reject. \p RADIUS connaît nativement deux protocoles de mot de passe : PAP (échange en clair du nom et du mot de passe), et CHAP (échange basé sur un hachage de part et d'autre avec échange seulement du 'challenge'). Le protocole prévoit deux attributs séparés : User-Password et CHAP-Password. \subsection{Extensible Authentication Protocol (EAP)} EAP (Extensible Authentication Protocol) est un mécanisme d'identification universel, fréquemment utilisé dans les réseaux sans fil et les liaisons Point-A-Point.\\ Bien qu’il soit utilisable sur des réseaux filaires, ce mécanisme est le plus souvent utilisé dans les réseaux sans fils. Les standards WPA et WPA2 ont officiellement adopté 5 types d’EAP comme mécanismes officiels d’identification : \subsubsection{EAP-TLS} EAP-TLS est un Standard ouvert IETF, On le retrouve implémenté chez de nombreux fabricants de matériel sans fil. C'est le seul protocole EAP qui doit obligatoirement être implémenté sur un matériel pour pouvoir porter le logo WPA ou WPA2. \p Il offre une bonne sécurité. En effet il utilise deux certificats pour la création d'un tunnel sécurisé qui permettra ensuite l'identification : un côté serveur et un côté client. Cela signifie que même si le mot de passe est découvert, il ne sera d'aucune utilité sans le certificat client. Bien que EAP-TLS fournisse une excellente sécurité, l'obligation de disposer d'un certificat client est peut-être son talon d'Achille. En effet lorsque l'on dispose d'un grand parc de machines, il peut s'avérer difficile et coûteux de gérer un certificat par machine. C'est pour se passer du certificat client que les protocoles PEAP et EAP-TTLS ont été créés. \p TLS est considéré comme le successeur du standard SSL. Il utilise une PKI pour sécuriser les communications d'identification entre les clients et le serveur RADIUS. \subsubsection{EAP-TTLS/MSCHAPv2} EAP-Tunneled Transport Layer Security, a été co-développé par Funk Software et Certicom, c'est également un standard ouvert IETF. Il est supporté sur de nombreuses plates-formes, et offre un très bon niveau de sécurité. Il utilise des certificats X-509 uniquement sur le serveur d'identification. Le certificat est optionnel du côté client. \p Le défaut de EAP-TTLS par rapport à PEAP est de ne pas être présent nativement sur les systèmes Microsoft et Cisco. Par contre il est légèrement plus sécurisé que PEAP car il ne diffuse pas le nom de l'utilisateur en clair. \subsubsection{PEAP} Protected Extensible Authentication Protocol, Protected EAP, ou plus simplement PEAP, est une méthode de transfert sécurisée d'informations d'authentification, pour les réseaux sans fil. Ce protocole a été développé conjointement par Microsoft, RSA Security et Cisco Systems. C'est un standard ouvert de l'IETF(Internet Engineering Task Force). Il faut noter que PEAP n'est pas une méthode de chiffrement, c'est juste une procédure pour authentifier un client sur un réseau. \p PEAP est très semblable à une autre méthode EAP : EAP-TTLS. Protected EAP a été créé pour contrer EAP-TTLS qui était jusque là, la seule méthode EAP à n'utiliser une PKI (Public Key Infrastructure) que du coté serveur, pour la création d'un Tunnel TLS (Transport Layer Security) protégeant l'authentification. Dans ces deux standards, l'utilisation d'une clef publique coté client est optionnelle. \p PEAP se déroule en 2 phases : \begin{itemize} \item La phase 1 permet l'authentification du Serveur grâce une PKI. Une fois le serveur authentifié il y a la création d'un tunnel sécurisé qui permettra à la phase 2 d'être chiffrée. \item La phase 2 permet l'authentification du client au travers du tunnel chiffré. \end{itemize} \p Il existe 2 versions de PEAP Certifiées WPA (mise à jour) et WPA2 : PEAPv0/EAP-MSCHAPv2 et PEAPv1/EAP-GTC. \subsubsection{EAP-SIM} EAP-SIM est une méthode EAP pour les clients GSM. Il est utilisé pour l'identification et la distribution de clefs au travers du réseau Global System for Mobile Communications (GSM), et signifie Subscriber Identity Module (SIM). \section{WPA et WPA2} Wi-Fi Protected Access (WPA et WPA2) est un mécanisme pour sécuriser les réseaux sans-fil de type Wi-Fi. Ils ont été créés en réponse aux nombreuses et sévères faiblesses que des chercheurs ont trouvées dans le mécanisme précédent, le WEP. WPA respecte la majorité de la norme IEEE 802.11i et a été prévu comme une solution intermédiaire pour remplacer le WEP en attendant que la norme 802.11i soit terminée. WPA a été conçu pour fonctionner avec toutes les cartes Wi-Fi, mais pas nécessairement avec la première génération des points d'accès Wi-Fi. WPA2 respecte la norme entière, mais ne fonctionnera pas avec certaines des cartes les plus anciennes. \subsection{WPA} WPA a été conçu pour être utilisé en collaboration avec un serveur d'identification 802.1X chargé de distribuer les différentes clefs à chaque utilisateur. Cependant, il peut aussi être utilisé dans un mode moins sécurisé, appelé pre-shared key (PSK), dans lequel tous les utilisateurs partagent une même phrase secrète. La Wi-Fi Alliance désigne la version pre-shared key, WPA-Personal ou WPA2-Personal et la version avec identification 802.1X WPA-Enterprise ou WPA2-Enterprise. \p Les données sont chiffrées en utilisant l'algorithme de chiffrement par flot RC4, avec une clef de 128 bits et un vecteur d'initialisation (initialization vector ou IV en anglais) de 48 bits. Une des améliorations majeures du WPA par rapport au WEP est le protocole Temporal Key Integrity Protocol (TKIP), qui échange de manière dynamique les clefs lors de l'utilisation du système. Ce protocole, associé au vecteur d'initialisation beaucoup plus grand que dans le WEP, empêche certaines attaques sur WEP aujourd'hui bien connues.\\ En plus de l'identification et du chiffrement, WPA garantit aussi une intégrité nettement améliorée des données. Le cyclic redundancy check (CRC) utilisé pour le WEP est, de manière intrinsèque, peu sûr : il est possible d'altérer les données et de mettre à jour le CRC du message sans connaître la clef WEP. Un algorithme d'identification des messages (message authentication code ou MAC en anglais, mais appelé MIC pour Message Integrity Code dans le cadre du WPA) plus sécurisé est utilisé pour le WPA : il s'agit d'un algorithme prénommé « Michael ». Le MIC utilisé pour le WPA inclut, de plus, un compteur de trame qui empêche les attaques par rejeu, une autre faiblesse du WEP.\\ Le WPA a été conçu comme une étape intermédiaire sur le chemin vers une meilleure sécurité de la norme 802.11. Ceci pour deux raisons. Premièrement, le travail sur la norme 802.11i a duré beaucoup plus longtemps que prévu, s'étalant sur quatre ans pendant lesquels l'inquiétude au sujet de la sécurité des réseaux sans fil allait grandissante. Deuxièmement, il rassemble, dans un sous-ensemble de la norme 802.11i, les éléments qui sont compatibles avec le WEP des tous premiers adaptateurs 802.11b. Des mises à jour WPA ont été fournies pour la très grande majorité des cartes Wi-Fi déjà existantes. Les points d'accès vendus avant 2003 ont généralement besoin d'être remplacés. \p WPA n'intègre donc pas toutes les recommandations de la norme 802.11i : \begin{itemize} \item Sécurisation des réseaux multipoints Ad-Hoc. \item Sécurisation des paquets de dé-authentification et dé-association. \item N'implémente pas AES comme algorithme de chiffrement. \end{itemize} \p En augmentant la taille des clefs et des vecteurs d'initialisation, en réduisant le nombre de paquets envoyés avec des clefs (re)liées, et en ajoutant un mécanisme d'identification des messages, le WPA rend la pénétration d'un réseau local sans fil beaucoup plus difficile. L'algorithme Michael est l'algorithme le plus résistant que les concepteurs du WPA pouvaient inclure sans abandonner la compatibilité avec la plupart des anciennes cartes réseaux. \p WPA n'est donc qu'une solution de transition entre le WEP et le WPA2, qui implémente la totalité de la norme 802.11i. \subsection{WPA2} \subsubsection{Préseantation} En janvier 2001, le groupe de travail i fut crée à l'IEEE pour améliorer l'authentification et le chiffrement des données au sein des réseaux 802.11. En avril 2003, la Wi-Fi Alliance (une association promouvant et certifiant les équipements Wi-Fi) publia une recommandation pour répondre aux inquiétudes des entreprises concernant la sécurité des réseaux sans fil. Ces derniers étaient aussi au courant que les clients n'étaient pas prêt à remplacer leurs équipements existants. En Juin 2004, la version finale de la norme 802.11i fut adoptée et le nom commercial WPA2 fut choisi par la Wi-Fi Alliance. \p La norme IEEE 802.11i introduit des changements fondamentaux comme la séparation de l'authentification utilisateur et le chiffrement/contrôle d'intégrité des messages, cela permettant une architecture de sécurité robuste passant à l'échelle et convenant parfaitement tant aux entreprises qu'aux particuliers. La nouvelle architecture pour les réseaux sans fil est appelée RSN (Robust Security Network) et utilise l'authentification 802.1X, la rotation et la distribution des clefs et de nouveaux mécanismes d'intégrité et de chiffrement. Bien que l'architecture RSN soit plus complexe, elle a le mérite de proposer une solution sécurisée pouvant passer facilement à l'échelle. Un RSN devrait typiquement accepter uniquement des équipements capables de supporter les RSN mais l'IEEE 802.11i a aussi défini une architecture temporaire TSN (Transitional Security Network) dans laquelle les équipements RSN et les systèmes WEP peuvent coexister permettant ainsi aux utilisateurs de mettre à jour leurs équipements. Si la procédure d'authentification ou d'association utilisée entre deux stations est basé sur le 4-Way Handshake, l'association est appelée RSNA (Robust Security Network Association). \p Un contexte de communication sécurisé s'effectue en quatre phases : \begin{enumerate} \item La mise en accord sur la politique de sécurité. \item L'authentification 802.1X, \item La dérivation et la distribution des clefs, \item Le chiffrement et l'intégrité au sein d'une RSN \end{enumerate} \begin{figure}[H] \centering \includegraphics[width=11cm]{images/802.11i_phases.eps} \caption{Les différentes phases 802.11i} \end{figure} \subsubsection{Phase 1 : Mise en accord sur la politique de sécurité} \begin{figure}[H] \centering \includegraphics[width=11cm]{images/802.11i_politiques.eps} \caption{802.11i - Phase 1 : Mise en accord sur la politique de sécurité} \label{802.11i_phase1} \end{figure} La première phase permet aux deux parties communicantes de s'accorder sur la politique de sécurité à utiliser. Les politiques de sécurité supportées par le point d'accès sont diffusées dans les trames Beacon et Probe Response (suivant un message Probe Request du client). Une authentification ouverte standard constitue l'étape suivante. La réponse du client aux politiques de sécurité supportées est incluse dans le message Association Request validé par le message Association Response du point d'accès. Les informations de la politique de sécurité sont envoyées dans le champ RSN IE (Information Element) détaillant : \begin{itemize} \item Les méthodes d'authentification supportées (802.1X, clef pré-partagée (PSK))/ \item Le protocole de sécurité pour le chiffrement du trafic vers une seule destination (unicast) (CCMP, TKIP, etc.) : suite de chiffrement pairwise. \item Le protocole de sécurité pour le chiffrement du trafic en diffusion (multicast) (CCMP, TKIP, etc.) : suite de chiffrement de groupe. \item Le support de la pré-authentification permettant aux utilisateurs de se pré-authentifier avant de basculer sur un nouveau point d'accès. \end{itemize} \subsubsection{Phase 2 : L'authentification 802.1x} \p \begin{figure}[H] \centering \includegraphics[width=12cm]{images/802.11x.eps} \caption{802.11i - Phase 2 : L'authentification 802.1x} \label{802.11i_phase2} \end{figure} La seconde phase consiste en l'authentification 802.1X basée sur EAP et la méthode spécifique choisie: EAP/TLS avec certificat client et serveur (nécessitant une infrastructure à clef publique), EAP/TTLS ou PEAP pour des authentifications hybrides (où le certificat est uniquement nécessaire côté serveur), etc. L'authentification 802.1X est initiée lorsque le point d'accès demande les données d'identification du client, la réponse du client contient alors la méthode d'authentification préférée. Différents messages – dépendant de la méthode spécifique choisie – sont alors échangés par la suite entre le client et le serveur d'authentification afin de générer une clef maîtresse (Master Key – MK). À la fin de la procédure, un message Radius Accept est envoyé du serveur d'authentification au point d'accès contenant la MK ainsi qu'un message final EAP Success pour le client. \subsubsection{Phase 3 : Dérivation et distribution de la clef} \p \begin{figure}[H] \centering \includegraphics[width=12cm]{images/802.11i_derivation.eps} \caption{802.11i - Phase 3 : Dérivation et distribution de la clef} \label{802.11i_phase3} \end{figure} La sécurité des transmissions repose essentiellement sur des clefs secrètes. Dans les RSN, chaque clef a une durée de vie limitée et de nombreuses clefs sont utilisées, organisées dans une hiérarchie. Quand un contexte de sécurité est établi après une authentification réussie, des clefs temporaires (de sessions) sont créées et régulièrement mises à jour jusqu'à la fermeture du contexte. La génération et l'échange des clefs est le but de cette troisième phase. Deux poignées de main (Handshake) ont lieu pour dériver les différentes clefs (voir la Figure ~\ref{802.11i_phase3}) : \begin{itemize} \item Le 4-Way Handshake pour la dérivation de la PTK (Pairwise Transient Key) et de la GTK (Group Transient Key), \item Le Group Key Handshake pour le renouvellement de la GTK. \end{itemize} \p La dérivation de la PMK (Pairwise Master Key) dépend de la méthode d'authentification choisie : \begin{itemize} \item si la PSK (Pre-Shared Key) est utilisée, PMK = PSK. La PSK est générée à partir de la phrase secrète (composée de 8 à 63 caractères) ou directement à partir d'une chaîne de 256 bits, cette méthode est adaptée pour les particuliers n'ayant pas de serveur d'authentification. \item si un serveur d'authentification est utilisé, la PMK est dérivée de la MK issue de l'authentification 802.1X. \end{itemize} \p La PMK en elle même n'est jamais utilisée pour le chiffrement ou le contrôle d'intégrité. Néanmoins, elle est utilisée pour la génération de clefs de chiffrement temporaires – pour le trafic à destination d'une machine il s'agit de la PTK (Pairwise Transient Key). La taille de la PTK dépend du protocol de chiffrement choisi : 512 bits pour TKIP et 384 bits pour CCMP. La PTK consiste en plusieurs clefs temporelles dédiées : \begin{itemize} \item KCK (Key Confirmation Key – 128 bits) : clef pour authentifier les messages (MIC) durant le 4-Way Handshake et le Group Key Handshake, \item KEK (Key Encryption Key – 128 bits) : clef pour la confidentialité des données durant le 4-Way Handshake et le Group Key Handshake, \item TK (Temporary Key – 128 bits) : clef pour le chiffrement des données (utilisée dans TKIP ou CCMP), \item TMK (Temporary MIC Key – 2x64 bits) : clef pour l'authentification des données (utilisée seulement par Michael dans TKIP). Une clef dédiée est utilisée pour chaque sens de communication. \end{itemize} \p \begin{figure}[H] \centering \includegraphics[width=15cm]{images/802.11i_pairwise.eps} \caption{802.11i - Phase 3 : Hierarchie de clef pairwise} \label{802.11i_pairwize} \end{figure} Cette hiérarchie peut être résumée en Figure ~\ref{802.11i_pairwize}. Le 4-Way Handshake, initié par le point d'accès, permet : \begin{itemize} \item de confirmer la connaissance de la PMK par le client. \item de dériver une nouvelle PTK. \item d'installer les clefs de chiffrement et d'intégrité. \item de chiffrer le transport de la GTK. \item de confirmer la suite de chiffrement choisie. \end{itemize} \p Quatre messages EAPOL-Key sont échangés entre le client et le point d'accès durant le 4-Way Handshake. Voir la Figure ~\ref{802.11i_4way}. La PTK est dérivée de la PMK, d'une chaîne de caractère fixe, de l'adresse MAC du point d'accès, de l'adresse MAC du client et de deux nombres aléatoires (ANonce et SNonce, générés respectivement par le contrôleur et le client). Le point d'accès initie le premier message en choisissant un nombre aléatoire ANonce puis l'envoie au client sans le chiffrer et l'authentifier. Le client génère ensuite son propre nombre aléatoire SNonce et est maintenant en mesure de calculer la PTK et de dériver les clefs temporelles, il envoie donc SNonce et le MIC calculé sur le second message en utilisant la clef KCK. Quand le contrôleur reçoit le deuxième message, il peut extraire SNonce (car le message n'est pas chiffré) et calculer la PTK puis dériver les clefs temporelles. Il est maintenant en mesure de vérifier la valeur du MIC contenu dans le second message, il s'assure ainsi que le client connaît la PMK et a correctement dérivé la PTK puis les clefs temporelles. Le troisième message est envoyé par le contrôleur au client et contient la GTK (chiffrée avec la clef KEK), dérivée d'une GMK et d'un GNonce aléatoire, accompagnée d'un MIC calculé sur le troisième message en utilisant la clef KCK. Quand le client reçoit ce message, le MIC est vérifié pour s'assurer que le contrôleur connaît la PMK et qu'il a correctement dérivé la PTK puis les clefs temporelles. Le dernier message acquitte la réussite de tous le Handshake et indique que le client a correctement installé les clefs et qu'il est prêt à commencer le chiffrement des données. Après réception du message, le contrôleur installe ses clefs et vérifie la valeur du MIC. De cette façon, le client mobile et le point d'accès ont obtenus, calculés et installés les clefs de chiffrement et d'intégrité et sont maintenant en mesure de communiquer sur un canal sûr pour le trafic à destination d'une machine ou en diffusion. \begin{figure}[H] \centering \includegraphics[width=15cm]{images/802.11i_4wayhandshake.eps} \caption{802.11i - Phase 3 :4-way HandShake} \label{802.11i_4way} \end{figure} \p Le trafic en diffusion est protégé par une autre clef, la GTK (Group Transient Key), générée à partir d'une clef maîtresse GMK (Group Master Key), d'une chaîne fixe, de l'adresse MAC du point d'accès et d'un nombre aléatoire GNonce. La longueur de la GTK dépend du protocole de chiffrement – 256 bits pour TKIP et 128 bits pour CCMP. La GTK est divisée en des clefs temporelles dédiées : \begin{itemize} \item GEK (Group Encryption Key) : clef pour le chiffrement des données (utilisée par CCMP pour l'authentification et le chiffrement et par TKIP), \item GIK (Group Integrity Key) : clef pour l'authentification des données (utilisée seulement par Michael avec TKIP). \end{itemize} \p Deux messages EAPOL-Key sont échangés entre le client et le point d'accès durant le Group Key Handshake. Cette poignée de main se base sur les clefs temporelles générées durant le 4-Way Handshake (la KCK et la KEK). Ce processus est illustré en Figure ~\ref{802.11i_groupkey}. Le Group Key Handshake est seulement nécessaire en cas de désassociation d'un client ou lors du renouvellement de la GTK suite à une demande client. Le contrôleur initie le premier message en choisissant le nombre aléatoire GNonce et en calculant une nouvelle GTK. Il envoie la GTK chiffrée (en utilisant la KEK), le numéro de séquence de la GTK et le MIC calculé sur ce message grâce à la KCK au client. Quand le message est reçu par le client, le MIC est vérifié et la GTK déchiffrée. Le second message acquitte la réussite du Group Key Handshake en envoyant le numéro de séquence de la GTK et le MIC calculé sur ce second message. Après réception du message, le contrôleur installe la nouvelle GTK (après avoir vérifié la valeur du MIC). Une STAkey Handshake existe aussi, mais elle ne sera pas détaillée ici. Elle permet la génération d'une clef transitoire appelée STAkey à l'aide du point d'accès pour les connexions de type ad-hoc. \begin{figure}[H] \centering \includegraphics[width=15cm]{images/802.11i_groupkeyhandshake.eps} \caption{802.11i - Phase 3 :GroupKey HandShake} \label{802.11i_groupkey} \end{figure} \subsubsection{Phase 4 : Chiffrement et intégrité au sein d'une RSNA} Toutes les clefs générées précédemment sont utilisées dans les protocoles de chiffrement et d'intégrité au sein d'une RSNA : \begin{itemize} \item TKIP (Temporal Key Hash), \item CCMP (Counter-Mode/Cipher Block Chaining Message Authentication Code Protocol), \item WRAP (Wireless Robust Authenticated Protocol). \end{itemize} \p Un concept important doit être compris avant de détailler chacun de ces protocoles : la différence entre un MSDU (MAC Service Data Unit) et un MPDU (MAC Protocol Data Unit). Les deux se réfèrent à un simple paquet de données, mais le MSDU représente un paquet de données avant sa fragmentation alors que le MPDU représente les multiples unités de données après fragmentation. Cette différence est importante dans le protocole de chiffrement TKIP et CCMP car dans TKIP le MIC est calculé sur le MSDU tandis que dans CCMP il est calculé sur le MPDU. Tout comme le WEP, TKIP est basé sur l'algorithme de chiffrement RC4 mais il existe seulement pour une raison : afin de permettre une mise à jour aux systèmes à base de WEP pour bénéficier d'un protocole plus sécurisé. TKIP est nécessaire pour la certification WPA et est inclu de manière optionnel dans le RSN 802.11i. \paragraph{TKIP\\} TKIP procure des corrections pour chaque faille du WEP détaillée précédemment : \begin{itemize} \item l'intégrité des messages : un nouveau MIC (Message Integrity Code) basé sur l'algorithme Michael peut être implémenté de manière logicielle sur des processeurs lents. \item IV : nouvelle méthode de sélection de valeur des IV, réutilisation de l'IV en temps que compteur anti-rejeu (TSC, ou TKIP Sequence Counter) et augmentation de la taille de l'IV pour éviter sa réutilisation. \item Per Packet Key Mixing : pour obtenir des clefs en apparence non liées. \item gestion des clefs : nouveau mécanisme pour la génération et la distribution des clefs. \end{itemize} \p Le schéma TKIP de mixage des clefs est divisé en deux phases. \p La phase 1 implique les champs statiques – la clef de session secrète TEK, l'adresse MAC du transmetteur TA (incluse pour éviter la collision d'IV) et les 32 bits de poids fort de l'IV. La phase 2 implique la sortie de la phase 1 et les 16 bits de poids faible de l'IV, changeant ainsi tous les bits du champ Per Packet Key pour chaque nouvel IV. La valeur de l'IV commence toujours à 0 et est incrémenté de 1 pour chaque paquet transmis, tout message ayant un TSC inférieur ou égal au message précédent doit être rejeté. La sortie de la phase 2 et une partie de l'IV étendu (ainsi qu'un octet factice) sont l'entrée de l'algorithme RC4, ce dernier générant une suite chiffrante que l'on XOR avec le texte en clair de la MPDU, le MIC calculé sur le MPDU et le vieux ICV issu du WEP (voir la Figure ~\ref{802.11i_tkip}).\\ \begin{figure}[H] \centering \includegraphics[width=15cm]{images/tkip.eps} \caption{802.11i - Schéma TKIP de mixage des clefs et de chiffrement} \label{802.11i_tkip} \end{figure} Le calcul du MIC utilise l'algorithme Michael développé par Niels Ferguson. Il a été créé pour TKIP et dispose d'un niveau de sécurité voulu de 20 bits (cet algorithme n'utilise pas de multiplications pour des raisons de performance car il se doit d'être supporté sur des vieux équipements pour permettre leur mise à jour vers WPA). \p À cause de cette limitation, des contre-mesures sont nécessaires pour éviter la construction du MIC. Les erreurs relatives au MIC doivent se maintenir en dessous de deux par minute pour éviter une mise en quarantaine de 60 secondes et une re-négociation des clefs (GTK et PTK). Le MIC est calculé en utilisant l'adresse source (SA), l'adresse destination (DA), le texte en clair MSDU et la TMK appropriée (dépendant du sens de la communication, une clef différente étant utilisée pour la transmission et la réception). \paragraph{CCMP\\} CCMP est basé sur le chiffrement par bloc AES (Advanced Encryption Standard) dans son mode d'opération CCM avec une taille de clef et de bloc de 128 bits. \p AES est à CCMP ce que RC4 est à TKIP mais contrairement à TKIP, qui a été fait pour s'accommoder du matériel WEP existant, il n'est pas un compromis de sécurité mais une nouvelle architecture de protocole. CCMP utilise le mode compteur en combinaison avec la méthode d'authentification des messagesappeléee Cipher Block Chaining (CBC-MAC) permettant de produire un MIC. Des propriétés intéressantes furent aussi ajoutées comme l'utilisation d'une simple clef pour le chiffrement et l'authentification des données (avec un vecteur d'initialisation différent pour chacun) ou l'authentification de données non chiffrées. \p Le protocole CCMP ajoute 16 octets au MPDU : 8 octets pour l'en-tête CCMP et 8 octets pour le MIC. L'en-tête CCMP est un champ non chiffré inclu entre l'en-tête MAC et la partie des données chiffrées contenant les 48 bits du PN (Packet umber = IV étendu) et le Group Key KeyID. Le PN est incrémenté de un pour chaque MPDU. \p Le calcul du MIC utilise l'algorithme CBC-MAC qui chiffre un bloc aléatoire de départ (obtenu grâce au champ Priority, à l'adresse source du MPDU et au PN incrémenté) et XOR les blocs suivants pour obtenir un MIC final sur 64 bits (le MIC final fait 128 bits mais les 64 bits de poids faible sont écartés). Le MIC est alors concaténé aux données en clair pour le chiffrement AES en mode compteur. Ce compteur est construit sur une valeur aléatoire identique à celle utilisée pour le MIC combinée à un compteur incrémenté de 1 pour chaque bloc. \begin{figure}[H] \centering \includegraphics[width=15cm]{images/ccmp.eps} \caption{802.11i - Chiffrement CCMP} \label{802.11i_ccmp} \end{figure} \paragraph{WRAP\\} Le dernier protocol est le WRAP, aussi basé sur AES, ais utilisant le schéma de chiffrement et d'authentification OCB (Offset Codebook Mode). OCB fut le premier mode sélectionné par le groupe de travail IEEE 802.11i mais il fut abandonné à cause de problèmes de propriété intellectuelle et d'une éventuelle licence. CCMP fut alors adopté comme obligatoire. \subsection{Les faiblesses de WPA et WPA2} Quelques faiblesses ont été découvertes dans WPA/WPA2 depuis leur sortie, aucune d'entre elles n'est critique si des recommandations simples de sécurité sont suivies.\\ \subsubsection{Attaque par dictionnaire} La vulnérabilité la plus exploitable est une attaque contre la clef PSK utilisée dans WPA/WPA2. Comme déjà mentionné précédemment, la PSK est une alternative à la génération de la PMK par des échanges 802.1X basés sur un serveur d'authentification. La PSK est une chaîne de caractères de 256 bits ou une phrase secrète comprise entre 8 et 63 caractères de laquelle on extrait la chaîne de caractères par un algorithme con- nu : PSK = PMK = PBKDF2 (phrase secrète, SSID, longueur du SSID, 4096, 256) où PBKDF2 est une méthode issue de PKCS\#5, 4096 est le nombre de hachage successifs et 256 la taille de la sortie. La PTK est dérivée de la PMK en utilisant le 4-Way Handshake et toute les informations nécessaires à son calcul sont transmises en clair. \\ La force de la PTK repose uniquement sur la valeur de la PMK, qui dans le cas de la PSK repose sur la force de la phrase secrète l'ayant générée. Comme souligné par Robert Moskowitz, le second message du 4-Way Handshake peut être sujet à des attaques par dictionnaire et force brute hors ligne. L'architecture du protocole (4096 hachage pour chaque tentative de phrase secrète) implique que les attaques de type brute force soient très lentes (quelques centaines de phrases secrètes par seconde). La PMK ne peut pas être pré-calculée (et mise dans des tables) car la phrase secrète dispose d'une graine basé sur l'ESSID.\\ Une phrase secrète n'apparaissant dans aucun dictionnaire (et de taille supérieur à 20 caractères) doit être choisie pour se protéger contre cette faiblesse.\\ \p Pour réaliser cette attaque, un attaquant doit capturer les messages du 4-Way Handshake en scrutant passivement les trames du réseau sans fil ou en utilisant l'attaque par dé-authentification (décrite précédemment) pour accélérer le processus. En fait, seul les deux premiers messages sont requis pour tester les choix de PSK. On se souvient que la PTK est dérivée de la PMK, d'une chaîne de caractère fixe, de l'adresse MAC du point d'accès, de l'adresse MAC du client et de deux nombres aléatoires (ANonce et SNonce, générés respectivement par le contrôleur et le client), où la PMK est égale à la PSK dans notre cas.\\ Après la transmission du second message, l'attaquant connaît ANonce (grâce au 1 er message) et SNonce (grâce au 2 ème message) et peut commencer à choisir une PSK pour calculer la PTK et dériver les clefs temporelles. Si la PSK est correctement choisie, le MIC du second message peut être obtenu avec la KCK correspondante, sinon un nouveau choix doit être effectué. \\ Le 4-Way Handshake peut être obtenu grâce à une attaque par dé-authentification, présentée précédemment.\\ L'étape finale consiste à lancer l'attaque par dictionnaire. \subsubsection{Déni de Service} L'autre faille principale du WPA est un possible déni de service durant le 4-Way Handshake. Le premier message du 4-Way Handshake n'est pas authentifié et chaque client doit stocker chaque $1^{er}$ message jusqu'à réception d'un troisième message (signé), laissant alors le client potentiellement vulnérable à une saturation de mémoire. En usurpant le premier message envoyé par le point d'accès, un attaquant peut réaliser un déni de service sur le client si plusieurs sessions simultanées peuvent coexister simultanément au niveau du client.\\ \subsubsection{Faiblesses de l'algorithme Michael} L'algorithme Michael utilisé pour calculé le MIC a aussi des faiblesses résultant de son design (voulues par le groupe de travail 802.11i). La sécurité de Michael repose sur le fait qu'il est chiffré au sein du paquet. Les fonctions cryptographiques pour calculer des MIC sont habituellement résistante au attaques en clair connu (où l'attaquant dispose du message en clair et du MIC), mais Michael s'avère vulnérable a ce type d'attaque car il est inversible. En connaissant un message et sa valeur MIC associée, il est possible de découvrir la clef secrète servant à calculer le MIC, le secret du MIC est donc critique. \subsubsection{Attaque théorique sur le Temporal Key Hash} La dernière vulnérabilité connue est une attaque théorique possible sur les Temporal Key Hash du WPA en réduisant la complexité de l'attaque (de $\partial 128$ à $\partial 105$) sous certaines conditions (connaissance de certaines clefs RC4). \subsubsection{Autres faiblesses} Le WPA/WPA2 est aussi sujet a des vulnérabilités affectant d'autre mécanismes standard au sein de la norme 802.11i comme les attaques par usurpation des messages 802.1X (EAPoL Logoff, EAPoL Start, EAP Failure etc.) une nouvelle fois dûes au manque d'authentification.\\ Enfin il est important de noter que l'utilisation des protocoles WPA/WPA2 n'empêchera pas des attaques sur les couches basses tels que le brouillage radio, les dénis de service par violation de la norme 802.11, les dé-authentifications, les dé-associations, etc. \section{Conclusions} Il est clair que le protocole de chiffrement WEP ne garantie pas une sécurité suffisante pour les réseaux sans fil Wi-Fi, il ne peut qu'être utilisé en complémentarité d'une solution de chiffrement de plus haut niveau (comme les technologies VPN). Le WPA représente une solution sécurisée pour les équipements supportant une mise à jour mais ne pouvant passer au WPA2 mais ce dernier représente une solution plus pérenne et sera à l'avenir le standard en terme de sécurité des réseaux sans fils Wi-Fi. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Solutions indirectes %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Solutions indirectes} \section{Filtrages} \subsection{Par adresse MAC} Tous les périphériques de communication réseau ont une adresse physique (adresse MAC) unique d’une longueur de 96 bits. Il est alors possible pour un point d’accès de lister les identifiants des matériels qui sont autorisés à se connecter au réseau. On parle alors de liste de droits d’accès (ACL).\\ Cette technique peu contraignante de limiter l’accès au réseau présuppose que le point d’accès connaisse tous les clients qui souhaitent utiliser le réseau, ce qui le rend statique. Elle n’est de plus pas à l’abri d’une usurpation d’adresse physique. \section{VPN} \subsection{Définitions} Un réseau privé virtuel repose sur un protocole, appelé protocole de tunnelisation (tunneling), c'est-à-dire un protocole permettant aux données passant d'une extrémité à l'autre du VPN d'être sécurisées par des algorithmes de cryptographie. \p Le terme de « tunnel » est utilisé pour symboliser le fait qu'entre l'entrée et la sortie du VPN les données sont chiffrées et donc incompréhensibles pour toute personne située entre les deux extrémités du VPN, comme si les données passaient dans un tunnel. Dans le cas d'un VPN établi entre deux machines, on appelle client VPN l'élément permettant de chiffrer les données à l'entrée et serveur VPN (ou plus généralement serveur d'accès distant) l'élément déchiffrant les données en sortie.\\ Ainsi, lorsqu'un système extérieur à un réseau privé (client nomade, agence ou travailleur à domicile) souhaite se connecter au réseau de son entreprise : \begin{itemize} \item Les paquets (qui contiennent les données) sont "cryptés" par le client VPN (selon l'algorithme décidé par les deux interlocuteurs lors de l'établissement du tunnel VPN) et éventuellement signées - ils ont transmits par le biais du réseau transporteur (internet en général). \item Ils sont reçus par le serveur VPN qui les décrypte et traités si les vérifications requises sont correctes \end{itemize} \p Les trois principaux protocoles de tunneling sont : \begin{itemize} \item IPsec : un protocole de niveau 3, permettant de transporter des données chiffrées pour les réseaux IP, réalisé dans le but de fonctionner avec le protocole IPv6, il fut adapté pour l'actuel protocole IP : IPv4.\\ Lors de l'établissement d'une connexion IPsec, plusieurs opérations sont effectuées : \begin{itemize} \item Un canal d'échange de clefs, sur une connexion UDP. \item Un ou plusieurs canaux de données par lesquels le trafic du réseau privé est véhiculé (protocoles AH et ESP). \end{itemize} Indépendamment des deux protocoles possibles AH/ESP, deux modes sont possibles, tunnel ou transport. Dans le cadre du mode transport, on peut choisir le protocole AH, ESP ou les deux. Dans le cadre du mode tunnel, on doit choisir entre le protocole AH ou ESP. Ce mode crée un nouveau paquet IP encapsulant celui qui doit être transporté. \p \item SSL/TLS : Dans la pile de protocole TCP/IP, SSL se situe entre les couches applications et la couche transport TCP. \p \item PPTP (Point-to-point tunneling protocol) est un protocole de niveau 2 d'encapsulation PPP sur IP conçu principalement par Microsoft. Ce protocole ouvre deux canaux de communication entre le client et le serveur : \begin{itemize} \item Un canal de contrôle pour la gestion du lien. \item Un canal de données transportant le trafic (pouvant être chiffré) du réseau privé. \end{itemize} \end{itemize} \subsection{Sécurité d'un réseau wifi} Les protocoles de sécurisation vus jusqu'à présent apportent un premier niveau de sécurité sur le transport des flux entre le poste de travail WiFi et le point d’accès WiFi mais jamais au-delà. Le VPN amène un niveau de sécurisation supplémentaire dans la mesure où les communcations entre un client et un serveur situé sur le réseau seront cryptés de bout en bout. \p Un exemple de configuration permettant d'exploiter une solution VPN pour sécuriser son réseau sans fil est la suivante : \begin{figure}[H] \centering \includegraphics[width=15cm]{images/vpn.eps} \caption{Solution VPN} \label{vpn} \end{figure} Les différents équipements du réseau sans fil ainsi que la passerelle VPN sont placés dans une DMZ (De-Militarized Zone), un chiffrement (WEP, WPA) pouvant eventuellement être mis en place sur ceux-ci.\\ Cette DMZ est alors séparée du reste du réseau par un pare-feu, qui ne laisse passé que le trafic provenant de la passerelle VPN.\\ Un client ne s'étant pas authentifié auprès du VPN n'aura donc pas accès au reste du réseau et restera alors confiné dans cette DMZ. \subsection{Bilan} L’utilisation de VPN en association avec les réseaux WiFi publics constitue la meilleure garantie de sécurité dispo- nible dans l’état actuel des technologies disponibles. Il ne s'agit pas d'une technique née d’une génération « spontanée », le VPN est déjà adopté par nombre d'entreprises de toutes tailles qui utilisent des accès distants. Si cette technologie est mature, elle continue néanmoins son évolution.Le cortège des solutions de VPN est aujourd’hui tracté par les offres de VPN/SSL.\\ Néanmoins, réduire la vision de la sécurité à la seule protection du « média de transport » réduirait la portée de cette analyse à imposer une amélioration de la sécurité de l’ensemble de la chaîne cinématique en incluant dans cette démarche le traitement des postes de travail de façon globale. L ’identification de l'usage, l’évaluation des coûts et la bonne connaissance des capacités de l’entreprise à déployer et exploiter les moyens de sécurité détermineront les choix du décideur en matière de solution et de technologie. %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% % % Conclusion % %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% \chapter{Conclusion} Les réseaux sans fil sont intrinsèquement très vulnérables à l'écoute non autorisée des messages qui y transitent. A cela s'ajoute une grande complexité pour les sécuriser lorsqu'ils sont le support de communications "sensibles". \p Le moyen de protection de base le plus connu est l'utilisation d'une clé WEP publique diffusée aux clients autorisés. Cependant, ce type de chiffrement est très facile à contourner et n'est utile que dans le cadre d'une politique de sécurité poussée recommandant de changer régulièrement la clé. \p D'autres solutions sont préférables comme l'utilisation de la norme 802.1x ou mieux encore l'application de WPA2, qui se base sur la norme 802.11i. \p Il est toutefois préconisé pour une sécurité vraiment efficace de compléter le système par la mise en place d'un VPN. \chapter{Annexes} \section{Glossaire} \textbf{AP} – \textbf{\textit{Access Point}}, station de base pour un réseau Wi-Fi (appelé aussi point d'accès ou borne) interconnectant les clients sans fil entre eux ainsi qu'au réseau filaire. \\\\ \textbf{ARP} – \textbf{\textit{Address Resolution Protocol}} – protocole faisant la correspondance entre adresse IP et adresse MAC \\\\ \textbf{BSS} – \textbf{\textit{Basic Service Set}} – cellule de base dans un réseau 802.11b. \\\\ \textbf{BSSID} – \textbf{\textit{Basic Service Set Identifier}} – adresse MAC du point d'accès. \\\\ \textbf{CCMP} – \textbf{\textit{Counter-Mode/Cipher Block Chaining Message Authentication Code Protocol}} – protocole de chiffrement utilisé dans WPA2 basé sur l'algorithme de chiffrement par bloc AES. \\\\ \textbf{CRC} – \textbf{\textit{Cyclic Redundancy Check}} – algorithme de pseudo-intégrité utilisé par le protocole WEP (comporte de nombreuses faiblesses). \\\\ \textbf{CSMA/CA} – \textbf{\textit{Carrier Sense Multiple Access with Collision Avoidance}} – mécanisme d'esquive de collision basé sur un principe d'accusé de réception réciproques. \\\\ \textbf{DSSS} – \textbf{\textit{Direct Sequence Spread Spectrum}} – méthode d'utilisation des fréquences dans les réseaux sans fil. \\\\ \textbf{EAP} – \textbf{\textit{Extensible Authentication Protocol}} – cadre de travail pour des méthodes d'authentification variées. \\\\ \textbf{EAPOL} – \textbf{\textit{EAP Over LAN}} – protocole utilisé dans les réseaux sans fil pour le transport d'EAP. \\\\ \textbf{ESS} – \textbf{\textit{Extended Service Set}} – élément d'un réseau 802.11 formé par un BSS et le pont qui le contrôle. \\\\ \textbf{ESSID} – \textbf{\textit{Extended Service Set Identifier}} – identifiant du réseau sans fil (identique au SSID). \\\\ \textbf{FCS} – \textbf{\textit{Frame Check Sequence}} – code de détection d'erreurs ajouté à la fin d'une trame. \\\\ \textbf{FHSS} – \textbf{\textit{Frequency Hopping Spread Spectrum}} – méthode d'utilisation des fréquences dans les réseaux sans fil. \\\\ \textbf{GEK} – \textbf{\textit{Group Encryption Key}} – clef de chiffrement pour le trafic en diffusion (aussi utilisée pour l'intégrité des données dans CCMP). \\\\ \textbf{GIK} – \textbf{\textit{Group Integrity Key}} – clef d'intégrité pour le trafic en diffusion (utilisé dans TKIP). \\\\ \textbf{GMK} – \textbf{\textit{Group Master Key}} – clef maîtresse de la hiérarchie de groupe. \\\\ \textbf{GTK} – \textbf{\textit{Group Transient Key}} – clef dérivée de la GMK. \\\\ \textbf{IBSS} – \textbf{\textit{Independent Basic Service Set}} – configuration de type peer-to-peer utilisée majoritairement pour de petits réseaux. \\\\ \textbf{ICV} – \textbf{\textit{Integrity Check Value}} – champ de donnée concaténé aux données en clair pour garantir l'intégrité (basé sur l'algorithme faible CRC32). \\\\ \textbf{IV} – \textbf{\textit{Initialization Vector}} – donnée combinée à la clef de chiffrement afin de produire une suite chiffrante unique. \\\\ \textbf{KCK} – \textbf{\textit{Key Confirmation Key}} – clef d'intégrité utilisée pour protéger les échanges de clef. \\\\ \textbf{KEK} – \textbf{\textit{Key Encryption Key}} – clef de confidentialité utilisée pour protéger les échanges de clef. \\\\ \textbf{LLC} – \textbf{\textit{Logical Link Control}} – sous-couche permettant de fiabiliser le protocole MAC par un contrôle d'erreur et un contrôle de flux. \\\\ \textbf{MAC} – \textbf{\textit{Medium Access Control}} – couche de niveau 2 OSI, qui régit l'accès à un segment du réseau. \\\\ \textbf{MIC} – \textbf{\textit{Message Integrity Code}} – champ de donnée ajouté aux données en clair pour garantir l'intégrité (basé sur l'algorithme Michael). \\\\ \textbf{MK} – \textbf{\textit{Master Key}} – clef maîtresse connue du client 802.1x et du serveur d'authentification à l'issu du processus d'authentification 802.1x. \\\\ \textbf{MPDU} – \textbf{\textit{Mac Protocol Data Unit}} – paquet de donnée avant fragmentation. \\\\ \textbf{MSDU} – \textbf{\textit{Mac Service Data Unit}} – paquet de donnée après fragmentation. \\\\ \textbf{NAS} – \textbf{\textit{Network Authentification Service}} – service d'authentification réseau. \\\\ \textbf{PAE} – \textbf{\textit{ Port Access Entity}} – port logique 802.1x. \\\\ \textbf{PMK} – \textbf{\textit{Pairwise Master Key}} – clef maîtresse de la hiérarchie de clef pairwise. \\\\ \textbf{PSK} – \textbf{\textit{Pre-Shared Key}} – clef dérivée d'un mot de passe, remplaçant la PMK normalement issue d'un vrai serveur d'authentification. \\\\ \textbf{PTK} – \textbf{\textit{Pairwise Transient Key}} – clef dérivée de la PMK. \\\\ \textbf{RADIUS} – \textbf{\textit{Remote Authentication Dial-In User Service}} – système d'authentification client/serveur par login et mot de passe. \\\\ \textbf{RSN} – \textbf{\textit{Robust Security Network}} – méchanismes de sécurité 802.11i (TKIP, CCMP etc.). \\\\ \textbf{RSNA} – \textbf{\textit{Robust Security Network Association}} – association de sécurité utilisée dans RSN. \\\\ \textbf{RSN IE} – \textbf{\textit{Robust Security Network Information Element}} – champ contenant les informations RSN inclues dans les trames Probe Response et Association Request. \\\\ \textbf{SSID} – \textbf{\textit{Service Set Identifier}} – identifiant du réseau sans fil (identique à l'ESSID). \\\\ \textbf{STA} – \textbf{\textit{Station}} – un client sans fil. \\\\ \textbf{TK} – \textbf{\textit{Temporary Key}} – clef pour le chiffrement des données à destination d'une machine (unicast) (utilisé pour le calcul des données d'intégrité dans le protocole CCMP). \\\\ \textbf{TKIP} – \textbf{\textit{Temporal Key Integrity Protocol}} – protocole de chiffrement utilisé dans le WPA, basé sur l'algorithme de chiffement RC4 (comme le WEP). \\\\ \textbf{TMK} – \textbf{\textit{Temporary MIC Key}} – clef pour l'authenticité des données du trafic à destination d'une machine (unicast) (utilisé dans TKIP). \\\\ \textbf{TSC} – \textbf{\textit{TKIP Sequence Counter}} – compteur anti-rejeu utilisé dans TKIP (basé sur l'IV étendu). \\\\ \textbf{TSN} – \textbf{\textit{Transitional Security Network}} – méchanismes de sécurité pre-802.11i (WEP etc.). \\\\ \textbf{WEP} – \textbf{\textit{Wired Equivalent Privacy}} – protocole de chiffrement par défaut des réseaux sans fil de type 802.11. \\\\ \textbf{WPA} – \textbf{\textit{Wireless Protected Access}} – implémentation d'une pré-version de la norme 802.11i basée sur le protocole de chiffrement TKIP. \\\\ \textbf{WRAP} – \textbf{\textit{Wireless Robust Authenticated Protocol}} – ancien protocole de chiffrement utilisé dans le WPA2. \begin{thebibliography}{2} \bibitem{wp} http://wikipedia.org \bibitem{cle} Matthew Gast, \textit{802.11 Wireless Networks: The Definitive Guide}, O'REILLY, 2002 \bibitem{auber} Aaron E. Earle, \textit{Wireless Security Handbook}, Auerbach Publications, 2006 \bibitem{graw} Stewart S. Miller, \textit{Wi-Fi Security}, McGraw-Hill, 2003 \bibitem{graw2} Mike Horton, Clinton Mugge, \textit{Network Security}, McGraw-Hill, 2003 \bibitem{hack} Lee Barken, \textit{Wireless haking}, Syngress, 2004 \bibitem{hakin9} \textit{Sécurité Wi-Fi - WEP, WPA et WPA2}, hakin9, 2006 \end{thebibliography} \end{document}