Sécurité

Sécurité

Un réseau WiFi est traditionnellement beaucoup plus vulnérable qu'un réseau filaire. L'attaquant n'a pas besoin de pénétrer dans les locaux et de brancher sa machine à une prise. Il peut tranquillement tenter d'attaquer le réseau depuis une voiture dans la rue.

La norme 802.11 a pendant longtemps ignoré les problèmes de sécurité en ne proposant qu'un mécanisme extrêmement faible. Cela a conduit à la création d'un marché aux solutions disparates, rendant difficile le choix d'une solution de sécurité.

Nous allons présenter dans ce chapitre les objectifs que nous nous sommes fixés en matière de sécurité puis nous ferons un tour rapide des diverses solutions disponibles actuellement sur le marché avant de présenter la solution retenue et de discuter de sa sécurité.

Les objectifs en matière de sécurité

Quel que soit le type de réseau, il y a généralement trois objectifs à la sécurisation de celui-ci :

La confidentialité consiste à s'assurer que les communications d'un utilisateur ne soient pas visibles par un tiers, qu'il soit ou non un utilisateur légitime du réseau. Cette contrainte permet d'assurer à un utilisateur que ses actions ne soient pas espionnées. Un exemple classique est par exemple la transmission du numéro de carte bleue à un site marchand.
L'authenticité consiste à assurer chacun l'identité de son partenaire. Elle comprend souvent un volet intégrité permettant de s'assurer que les informations qui circulent ne peuvent pas être modifiées par un attaquant. Elle prend également en compte le rejeu qui consiste à renvoyer un message qui a déjà circulé sur le réseau. Si une telle manoeuvre était possible, un attaquant pourrait renvoyer à l'envi une demande de débit de 10 € que la victime a envoyé une seule fois. Cette dernière serait alors débitée plusieurs fois.
Le déni de service est une tactique consistant à perturber le fonctionnement du réseau pour empêcher les utilisateurs de l'exploiter correctement. La protection contre ce type d'attaque est très délicate, notamment avec des technologies radio où il est difficile d'empêcher le brouillage.

Pour la conception de notre réseau WiFi, nous nous sommes fixé les objectifs suivant :

En matière de confidentialité, un attaquant extérieur ne doit pas pouvoir obtenir d'informations sur les données échangées par un utilisateur du réseau, du moins jusqu'au point d'accès à Internet puisque nous ne maîtrisons pas le réseau au-delà. De plus, nous ne voulons pas qu'un utilisateur légitime puisse espionner les données du voisin.
En ce qui concerne l' authenticité, nous voulons une authentification mutuelle : l'utilisateur doit être assuré qu'il parle bien à nos équipements et nous devons être assurés de l'identité de l'utilisateur et pouvoir accéder à tout moment aux données propres à cette authentification. L' intégrité et le non-rejeu fait aussi partie de nos objectifs. Encore une fois, nous ne pouvons assurer ces propriétés au-delà de nos équipements.
Le problème du déni de service est plus délicat comme indiqué plus haut. Nous nous efforcerons simplement de mettre en œuvre les contre-mesures nécessaires, dans la limite du possible. Nous sommes toutefois limités par la technologie utilisée. Notre réseau filaire ne doit pas souffrir des dénis de service propres au WiFi.
Ajoutons enfin que, parallèlement à l'authenticité, nous désirons exercer un contrôle d'accès afin qu'il ne soit pas possible d'exploiter le réseau WiFi de manière frauduleuse, que ce soit pour contacter d'autres clients WiFi ou pour tenter d'accéder à certains services indus : seule une authentification réussie doit permettre d'accéder à l'ensemble des services.

L'existant

À l'origine, la norme 802.11 ne comprenait qu'un mécanisme relativement faible pour assurer la sécurité des données. Ce mécanisme est appelé WEP pour Wired Equivalent Privacy. Conscients de la faiblesse de cette protection, les fabriquants de matériel WiFi ont développé une seconde solution appelée WPA pour WiFi Protected Access. Cette solution n'étant qu'une rustine de la première, l'IEEE s'est mise à plancher sur la norme 802.11i pour développer un mécanisme de sécurité beaucoup plus fiable. À ce jour, cette norme n'est toujours pas ratifiée.

Ces trois technologies sont propres aux réseaux WiFi. Il existe d'autres solutions plus génériques applicables aux réseaux WiFi. Ces solutions sont connues sous le nom Virtual Private Network (VPN).

Le WEP

Le sigle WEP signifie Wired Equivalent Privacy. Il était donc, dès l'origine, peu ambitieux. Aucun mécanisme de distribution de clefs n'a été prévu, ce qui fait que habituellement tout le monde partage la même clef. Cela signifie que deux utilisateurs légitimes du réseau peuvent s'observer mutuellement sans aucune difficulté. Il est cependant possible de mettre en place l'infrastructure nécessaire pour que chaque utilisateur dispose de sa propre clef. Sa mise en place est toutefois très rare.

Il n'y a de plus aucun mécanisme d'authentification en dehors de cette clef. Il n'est donc pas possible d'identifier précisément l'utilisateur qui peut donc se faire passer pour un autre utilisateur légitime. De plus, le mécanisme d'authentification ne fonctionne que dans un seul sens : il est tout à fait possible de mettre en œuvre un point d'accès pirate et ainsi de détourner les communications des utilisateurs. Il n'y a de plus aucune protection contre le rejeu.

WEP utilise un moteur de chiffrement par flux RC4 pour la confidentialité. L'intégrité est assurée par une simple somme de contrôle CRC32. Cette dernière n'a jamais été prévue pour résister à un attaquant : elle sert à l'origine à détecter des erreurs. Il est donc très simple de modifier les trames envoyées.

De nombreux papiers font état des faiblesses structurelles extrêmement importantes de WEP : \cite{borisov01intercepting,ossmann04wep,fluhrer01weaknesses,housley03wep,blancher04wep}. En août 2001, \cite{fluhrer01weaknesses} présente une méthode de cryptanalyse sur le WEP qui permet de récupérer de manière totalement passive la clef utilisée pour le chiffrement en quelques heures. De nombreux outils implémentent cette attaque. Elle se base sur certaines faiblesses qui ont été depuis évitées par les fabriquants qui filtrent les clefs permettant à cette attaque de réussir : ce mécanisme est connu sous le nom de weak key avoidance.

Cependant, en août 2003, un hacker connu sous le nom de Korek publie un outil qui rend de nouveau les attaques contre WEP très faciles. De nombreux outils implémentent désormais cette attaque qui permet de récupérer une clef WEP en quelques minutes ou quelques heures. Airsnort \cite{airsnort} et Aircrack \cite{aircrack} sont deux de ces outils.

Il apparaît donc clairement que le WEP n'est pas du tout adapté à assurer la sécurité d'un réseau : de nombreuses attaques pratiques existent actuellement.

Le WPA

Devant le manque flagrant de sécurité du WEP, les fabriquants devaient trouver une parade sous peine de voir leurs ventes affectées. L'IEEE préparait alors la norme 802.11i qui était basée sur le chiffrement AES \cite{daemen98aes}. Cependant, cela nécessitait de remettre à jour tout le parc : les cartes wifi actuelles n'ont pas la puissance nécessaire pour faire du chiffrement AES.

Un WEP amélioré

WPA est donc un protocole qui repose sur WEP et permet ainsi de conserver le matériel existant en nécessitant uniquement une mise à jour du firmware, qui est le logiciel embarqué dans le matériel.

Pour résoudre le problème de confidentialité du WEP qui permettait de récupérer la clef utilisée pour chiffrer, WPA met en oeuvre TKIP (Temporal Key Integrity Protocol qui permet de dériver d'une clef d'autres clefs temporaires. À partir d'une clef maître, ce mécanisme est donc capable de générer une nouvelle clef pour chaque paquet. Cette clef est passée au moteur WEP qui sert donc toujours à effectuer le chiffrement mais comme chaque paquet est chiffré avec une clef différente, l'attaque décrite pour le WEP n'est plus possible en pratique.

Pour le problème de l'intégrité, un nouveau mécanisme a été ajouté. Celui-ci s'appelle MIC pour Michael Integrity Check. Il s'agit cette fois-ci d'un mécanisme cryptographique et il est donc beaucoup plus difficile de l'attaquer.

WPA peut fonctionner avec une clef partagée par tous les utilisateurs ou avec une clef par utilisateur. La première méthode est connue sous le nom WPA Personal. Tous les utilisateurs partageant le même secret, ils peuvent voir les données échangées par le voisin. La seconde méthode nécessite la mise en place d'une PKI (Public Key Infrastructure). C'est cette dernière qui offre le plus de sécurité.

On peut se référer à \cite{blancher04wep} pour une description plus précise de WPA, notamment à propos des différents mécanismes d'authentification qu'il propose.

Et les défauts ?

Actuellement, WPA est ce qui semble s'imposer dans le monde du WiFi. Il est pour le moment en pratique assez sûr et il est supporté par une grande partie du matériel existant.

Toutefois, plusieurs défauts persistent. Conceptuellement, il apporte les sécurités que nous avons énoncées, mais il est condamné sur le long terme en raison des faiblesses de chacun de ses éléments. Il est encore un peu trop jeune pour avoir été étudié extensivement, mais des failles importantes ont déjà été trouvées. On pourra par exemple se reporter à \cite{moen04wpa} qui décrit comment l'espace de recherche peut être réduit de 128 bits à 105 bits. Cela ne permet toujours pas directement une attaque, mais c'est une faille très importante pour un protocole cryptographique. Il y a donc un risque pour que dans un an, d'autres techniques soient découvertes et permettent de casser WPA assez facilement. Il sera certes toujours possible d'adopter 802.11i, mais les données actuelles pourront alors être déchiffrées[[FootNote(Il est important de bien comprendre que les données confidentielles actuellement peuvent l'être demain. Un schéma de chiffrement doit donc assurer une protection suffisante dans le temps : un attaquant peut enregistrer un flux chiffré et attendre deux ou trois ans que la technologie nécessaire pour le décrypter soit disponible. DES a assuré la sécurité des données qu'il protégeait pendant une trentaine d'année. La même performance est attendue d'AES.)]].

WPA dispose d'autres défauts comme la nécessité de mettre en place une PKI et de distribuer des certificats. C'est un mécanisme assez lourd à mettre en place malgré le gain non négligeable de sécurité d'une telle procédure.

À noter également que le support de WPA est inégal. Si le matériel actuel le supporte sans problème, des cartes wifi plus anciennes peuvent ne pas le supporter, même après une mise à jour. Au niveau logiciel, certains systèmes ont un support inégal du WPA. Par exemple, pour Mac OS X, la version 10.3 est nécessaire. Pour Linux, la procédure est assez ardue et seule certaines cartes sont supportées.

Ces défauts sont cependant loin d'être rédhibitoires.

Le 802.11i

802.11i \cite{80211i} est une norme en cours de développement par l'IEEE. Elle est parfois appelée WPA2 bien qu'elle en soit très éloignée. Elle repose cette fois sur le chiffrement AES au lieu de WEP. AES, pour Advanced Encryption Standard \cite{daemen98aes}, est un mécanisme de chiffrement adopté comme un standard par le gouvernement américain en remplacement du vieillissant Data Encryption System (DES). AES a été développé par deux cryptographes belges et a été sélectionné face à d'autres algorithmes proposés. Il a été étudié par de très nombreux cryptographes et est donc, a priori, très solide. AES assure à lui seul une bonne partie des propriétés de sécurité.

802.11i s'annonce donc particulièrement solide. Il existe déjà du matériel supportant ce protocole, mais étant donné que celui-ci n'est pas encore ratifié, il est possible que ce matériel ne soit plus conforme à la spécification lorsque celle-ci sera ratifiée.

Son grand défaut est donc sa faible diffusion, pour le moment.

Les VPN

Il existe des solutions de chiffrement et d'authentification qui ne sont pas propres au WiFi. Initialement, ces solutions ont été développées pour permettre à un utilisateur nomade de se connecter en toute sécurité depuis son domicile vers son entreprise en passant par Internet. Il est toutefois possible de les mettre en œuvre pour assurer la sécurité d'un réseau WiFi.

Il existe de nombreuses technologies de VPN. La question de l'interopérabilité est alors assez épineuse. Deux technologies ont émergé :

PPTP, pour Point-to-Point Tunneling Protocol, est un protocole publié par Microsoft. Il est donc disponible sur les versions les plus courantes de Windows et mis en avant par Microsoft. Il repose toutefois sur des mécanismes d'authentification relativement faibles et n'est donc pas considéré comme sûr. D'ailleurs, Microsoft a cessé son développement en faveur de L2TP par-dessus IPsec. On pourra se référer à \cite{schneier98cryptanalysis} pour connaître l'ensemble des problèmes de PPTP.
IPsec, pour IP security, est un protocole ratifié par l'IETF mettant en œuvre un ensemble de mécanismes destinés à assurer la confidentialité et l'authenticité des paquets qu'il véhicule. Il est le fruit de nombreuses années de travail et dispose de très nombreuses implantations et du support de nombreux industriels. Il est capable d'utiliser AES comme algorithme de chiffrement, DH (Diffie-Hellman) et DSA (Digital Signature Algorithm) pour l'échange de clefs via le protocole IKE \cite{perlman00ike} et HMAC-SHA1 pour l'intégrité. Il reste un protocole assez ardu à mettre en œuvre. Pour une évaluation de IPsec, on pourra se reporter à \cite{rfc2402,rfc2401,rfc2406,rfc2409,ferguson00cryptographic,guttman00ipsec}. Nous retiendrons essentiellement qu'IPsec a été décortiqué pendant plusieurs années par des cryptographes et qui en ont déduit sa solidité.

La solution retenue par le Cr@ns

Les deux solutions qui nous semblaient répondre aux critères de sécurité énoncés ci-dessus et qui étaient exploitables à l'époque du choix étaient donc WPA et IPsec. Cependant, le support WPA était (et est toujours, dans une moindre mesure) extrêmement spartiate sous Linux, ce qui a motivé le choix d'IPsec.

Adopter un protocole de classe militaire ne suffit cependant pas pour assurer la sécurité de l'ensemble. Nous allons donc détailler ici en quoi cette sécurité est assurée. IPsec n'est alors qu'un des composants de celle-ci.

Le modèle réseau en couches

Pour bien comprendre les problèmes de sécurité réseau, il est nécessaire de comprendre dans un premier temps le modèle en couches qui décrit les protocoles réseau. Il existe généralement deux modèles. Le premier est celui de l'OSI \cite{osi}. Il constitue le modèle académique. Pour illustrer notre propos, nous allons plutôt utiliser le second modèle, dit DoD \cite{dod} pour Department of Defense, qui en est une version simplifiée en quatre couches.

L'idée du modèle en couches est que chaque couche constitue un protocole qui n'utilise que les fonctions offertes par le modèle qui lui est immédiatement inférieur et n'offre ces fonctions qu'au modèle qui lui est immédiatement supérieur. On peut agencer les couches comme on le désire pourvu qu'il y ait compatibilité des interfaces entre les couches. Quand on a réussi à empiler un certain nombre de couches, on obtient ce que l'on appelle une pile de protocoles. On l'illustre comme dans la figure suivante :

Le modèle DoD dispose donc de quatre couches :

Network access est la couche qui permet d'échanger des informations sur un réseau local. Sur ce type de réseau, chaque machine peut directement contacter une autre machine. 802.11 est une telle couche, au même titre que Ethernet. Cet couche offre donc comme service la possibilité pour une machine de contacter et d'échanger des informations avec une autre machine sur le même réseau physique.
Internet est la couche qui permet à des machines de réseaux différents de communiquer entre elles. Cela correspond au protocole IP. Chaque machine est identifiée par un numéro IP comme 138.231.136.6 et connaît le moyen de contacter directement ou indirectement les autres machines. Le fait de contacter indirectement une autre machine induit le processus de routage : un paquet à destination d'une machine qui n'est pas sur le même réseau est passé à une autre machine qui transmet, directement ou indirectement, le paquet. Cette couche utilise la couche d'accès au réseau qui lui est inférieure pour donner le paquet à une machine du même réseau (qui est soit le destinataire final, soit l'intermédiaire choisi pour relayer le message).
Transport est la couche qui va réellement permettre de transmettre des données entre plusieurs machines. Cela correspond à TCP \cite{rfc761} ou UDP. Cette couche assure le multiplexage des paquets entre les différents services à l'aide de la notion de ports : un service est associé à un port sur une machine donnée. Elle utilise le service de transport entre machines n'appartenant pas au même réseau de la couche Internet pour envoyer les paquets d'une machine à l'autre. Un paquet a alors comme source une IP et un port et comme destination une IP et un port. Le port permet de savoir à quelle application est destinée le paquet. TCP assure en plus un service d'intégrité, de fiabilité, d'ordonnancement et de non duplication des données. Il offre de plus la notion de connexion permettant à deux applications de communiquer entre elles dans le cadre d'une session unique.
Process layer est la dernière couche et correspond aux applications. À l'aide des services offerts par TCP et UDP dans la couche inférieure, les applications vont mettre en œuvre un protocole qui leur est propre pour communiquer entre elles, sur des machines distantes. Un serveur de mail va par exemple pouvoir envoyer un mail à un autre serveur de mail via le protocole SMTP (de niveau 4 donc). Pour cela, il va utiliser les services de TCP (de niveau 3) pour ne pas avoir à gérer les problèmes de pertes de paquets et s'adresser directement au serveur de mail (port 25) distant. TCP à son tour va utiliser IP pour faire voyager le paquet et sur les réseaux locaux, IP va utiliser Ethernet (ou autre) pour transmettre les données physiquement. Si l'application n'est pas intéressée par les services offerts par TCP, elle peut utiliser UDP qui lui assure toujours le multiplexage mais ne lui garantit pas de recevoir tous les paquets.

Ajoutons enfin que tous les équipements ne travaillent pas au même niveau. Un switch est un équipement de niveau 1, il ne connaît donc pas les autres couches. Un routeur est un équipement de niveau 2. Il existe également des équipements de niveau 4. Un équipement de niveau 1 ne prend pas en compte les informations contenues dans le niveau 2. Ainsi, un switch ne prend pas en compte les informations comme l'adresse IP, sauf cas particuliers...

Une autre façon d'illustrer le modèle en couches est présenté dans la figure suivante. Chaque niveau émet des trames ou des paquets d'un format donné et encapsulent dans leurs corps les niveaux supérieurs. Quand un paquet doit être examiné au niveau n, les entêtes au niveau n-1 sont détruits tandis que quand il doit être transmis pour être envoyé sur le réseau, on lui rajoute les entêtes du niveau n.

La sécurité dans le modèle en couches

TCP/IP n'a pas été prévu dans une optique de sécurité. Il n'offre aucun mécanisme de défense contre un adversaire capable d'observer les trames réseau. Cela n'a longtemps pas été un problème vu qu'il était difficile d'effectuer cette observation passive. Ce n'est plus du tout le cas avec des réseaux WiFi vu que tout le monde est à même d'effectuer cette observation.

Toutefois, la sécurité n'est qu'un service comme un autre dans le modèle en couches. Si une des couches assure par exemple la confidentialité, toutes les couches supérieures en bénéficient automatiquement. Il convient d'éviter les conclusions hâtives : si par exemple, on chiffre le niveau 1, on assure la confidentialité sur le segment chiffré uniquement. Si le segment se trouvant derrière est lui aussi chiffré, cela n'assure pas la sécurité de toute la chaîne si l'élément intermédiaire travaille au niveau 2. En effet, celui-ci va déchiffrer ce qui arrive d'un côté et le rechiffrer pour le renvoyer. Un attaquant peut alors agir sur cet équipement pour récupérer le clair.

C'est un scénario que l'on peut retrouver très facilement en pratique. Imaginons que nous utilisions des bornes wifi avec WPA (qui chiffre la couche 1). Malgré le bon niveau de chiffrement, il suffira pour un attaquant de pirater la borne wifi pour obtenir tout ce qui y transite, en clair. Ce n'est pas improbable vu que celles-ci se trouvent généralement dans des endroits non protégés. C'est en pratique encore plus simple vu que le chiffrement se fait uniquement sur les ondes radio. La partie filaire ne l'est pas. Il suffit donc de se placer derrière la borne pour obtenir tout le trafic en clair ! Cette attaque ne faisant appel à aucun exploit technique est décrit dans la figure suivante :

Un autre piège concerne l'authentification. Si la couche de niveau 1 assure l'authentification, les couches supérieures en bénéficient automatiquement. Cependant, l'authentification se fait avec les éléments disponibles au niveau 1, c'est-à-dire les adresses des cartes réseau. Les éléments de niveau 2, c'est-à-dire les adresses IP, ne sont pas authentifiés. Il est ainsi possible de prendre une fausse IP. Il faut donc penser à lier l'adresse physique et l'adresse IP pour s'assurer de l'authenticité des paquets.

Enfin, le déni de service est également un service. Si une couche est sensible au déni de service, toutes les couches supérieures en « bénéficient ». C'est pour cette raison qu'il est vain de tenter de contrer le déni de service avec le WiFi : il est quasiment impossible de protéger le niveau 1 de ce type d'attaque. On veillera par contre à ce que celle-ci ne se propage pas au-delà des segments touchés : il ne faudrait pas que le réseau filaire en souffre.

Description de la mise en œuvre

Nous avons déjà expliqué que nous mettons en œuvre IPsec. Il s'agit d'un protocole de niveau 2. En fait, ce protocole est un protocole de type IP dans IP : il utilise les services de IP (donc serait plutôt de niveau 3), mais il fournit les mêmes services qu'IP (donc serait plutôt de niveau 2). Pour des raisons de simplicité, on va donc considérer qu'il s'agit d'une altération d'IP et qu'il travaille au niveau 2.

Toutefois, IPsec n'est qu'une partie de la solution. Détaillons donc la solution au complet. Nous disposons d'un routeur, appelé ici Nectaris (maintenant, ce routeur a changé au profit de Ragnarok), qui est une passerelle IPsec. Les clients communiqueront en IPsec avec cette machine. La communication sera donc chiffrée de bout en bout entre cette machine et les clients. Nous disposons également d'un certain nombre de bornes wifi. Celles-ci vont agir comme des switchs un peu spéciaux. Il aurait été possible à peu de coût de transformer ces bornes en routeur et ainsi s'abstraire d'un certain nombre de problèmes qui vont apparaître par la suite. Toutefois, nous désirions qu'il soit possible de conserver la même IP quelle que soit la borne sur laquelle nous nous connectons et rendre possible la migration d'une borne à une autre. Ceci est beaucoup plus facile avec un équipement de niveau 1 qui dispose d'un protocole (ARP) pour « localiser » les clients qu'avec un équipement de niveau 2 qui doit savoir par avance à quelle borne s'adresser pour savoir où envoyer un paquet.

Pour résumer, un client wifi se connecte à une borne (au niveau 1). Il communique, à travers cette borne, avec Nectaris en IPsec (au niveau 2), de bout en bout. La figure suivante représente le schéma du réseau au niveau 1 tandis que la seconde figure celui au niveau 2.

Étude de la sécurité

Nous allons donc étudier plus en détail la sécurité de la solution en se basant sur le modèle en couches. Nous ne nous intéressons qu'à la sécurité entre le client et nectaris. La sécurité sur le reste du réseau est hors de propos ici.

Confidentialité et authenticité

La confidentialité est assurée à partir du niveau 2 grâce à IPsec qui utilise l'algorithme de chiffrement AES \cite{daemen98aes} dans ce but. Le chiffrement est assuré de bout en bout : lorsqu'un client émet des données, les équipements intermédiaires ne voient passer qu'un flux chiffré. Seul Nectaris est capable de déchiffrer celui-ci. Les autres clients ne partagent pas la même clef, ils sont donc également incapables de déchiffrer le flux. La confidentialité est donc assurée pour le niveau 2 et les niveaux supérieurs. Le niveau 1 n'est donc pas sécurisé. Cela permet d'obtenir comme information les adresses MAC et les adresses IP sans aucun effort. Nous considérons ces informations comme publiques. Leur divulgation n'est donc pas notre soucis.

L' authentification entre le client et Nectaris est mutuelle : le client ne parlera qu'avec Nectaris et celui-ci n'acceptera de parler qu'avec le client. Les deux entités partagent une clef [[FootNote(Une architecture utilisant des certificats serait encore plus sûre. Il est possible de la mettre en place assez facilement au niveau technique tout en conservant tout ce qui est dit ici. Cependant, la gestion de certificats est assez lourde administrativement. Nous ne nous sommes donc pas lancé là-dedans.)]] connue de eux seuls. Les paramètres de l'authentification sont les adresses IP des deux parties et la clef partagée. Ainsi, le client est assuré de parler avec une machine ayant l'IP de Nectaris et partageant le même secret qu'elle. À moins de révéler le secret, il n'est donc pas possible qu'il parle en fait à un intrus. Inversement, Nectaris est sûre de parler avec le client. L'IP est donc liée fortement au client et le client ne peut pas falsifier celle-ci. L'authentification fournie par IPsec donne gratuitement l' intégrité des données et le non-rejeu. Le niveau 2 remplit bien nos conditions sur l'authenticité des paquets. Les niveaux supérieurs également mais les paramètres restent les IP. Généralement, on ne demande pas d'autres données : on cherche principalement à identifier les utilisateurs et les IP sont suffisantes pour cette fonction.

Usages frauduleux

Laissons le déni de service de côté et regardons quels sont les usages non autorisés du réseau qu'un intrus pourrait effectuer. Au niveau de la couche 2, il ne pourra pas discuter avec Nectaris, par contre, il pourrait accéder aux autres services du réseau et discuter avec un autre client ou avec une autre machine de notre réseau. Il existe deux parades possibles :

S'arranger pour qu'il n'existe sur le réseau comme seul équipement de niveau 2 (le niveau 1 ne donne accès à aucun service) que Nectaris. C'est possible physiquement, mais coûteux au niveau matériel. Une solution intermédiaire est d'utiliser les VLAN. Il s'agit d'une technologie permettant de compartimenter un réseau local en plusieurs réseaux locaux. Il serait ainsi possible de faire un réseau virtuel ne contenant que Nectaris et les clients WiFi. Cela ne suffit pas puisqu'il faut encore protéger les autres clients. De plus, nous n'avions pas les moyens de mettre en place un tel réseau car certaines bornes sont hébergées par des adhérents qui branchent ensuite leur PC dessus. Cependant, c'est désormais le cas.
Tricher un peu avec le modèle en couches et rendre les bornes plus intelligentes. Tout client passe automatiquement par une borne pour toutes ses communications, y compris avec les autres clients. Nous avons donc configuré les bornes pour qu'elles empêchent au client de se voir entre eux (au niveau 2) et pour qu'ils ne puissent parler qu'avec Nectaris (au niveau 2). Nous avons donc des équipements de niveau 1 qui prennent en compte le niveau supérieur. Nous avons également interdit tout autre protocole que IPsec ¹ au niveau 2.

Nous vérifions de plus que lorsqu'un client prétend parler avec Nectaris au niveau 2, il parle bien avec Nectaris au niveau 1 ; plus en détail, nous vérifions que l'adresse MAC correspond à l'adresse IP. Ainsi, chaque client ne peut parler qu'avec Nectaris, garante de la politique de sécurité.

Dénis de service

Comme nous l'avons indiqué précédemment, il n'est pas possible de se prémunir entièrement du déni de service. Un attaquant peut brouiller les signaux radios et ainsi empêcher les clients de se connecter. Nous ne tenterons rien de ce côté.

L'attaquant dispose de deux autres sources de déni de service qui peuvent nuire au réseau. Il peut envoyer ce que bon lui semble au niveau 1. Cependant, les bornes assurent que seuls les paquets IPsec peuvent circuler au niveau 2. Elles laissent également passer des paquets ARP. ARP, pour Address Resolution Protocol, est un protocole permettant de faire la correspondance entre une IP et une adresse MAC. Fausser cette correspondance pourrait conduire une machine à s'adresser au mauvais destinataire. Une attaque appelée ARP poisoning consiste à exploiter la faiblesse de ce protocole pour intercepter toutes les données destinées à une machine. On pourra se référer à \cite{bruschi03sarp} pour une description précise de cette attaque et des solutions possibles. Dans notre cas, cette attaque peut uniquement aboutir à un déni de service (l'attaquant ne peut rien faire des données récupérées, il s'agit d'IPsec).

Cependant, pour minimiser cet aspect, les bornes effectuent un filtrage des requêtes ARP et vérifient la correspondance MAC/IP à l'aide d'une table. Il n'est donc pas possible d'émettre de fausses requêtes ARP.

L'attaquant peut encore tenter de falsifier le niveau 1 pour des paquets contenant de l'IPsec. S'il modifie l'adresse MAC cible, il sera arrêté par les bornes qui vérifient que l'adresse MAC est celle de Nectaris. Il lui reste l'adresse MAC source qui lui permettrait de fausser la correspondance MAC/port des switchs et ainsi faire perdre à certaines machines des paquets (les switchs croyant que la machine a changé de port). Pour éviter cette attaque, les bornes vérifient sur toutes les trames Ethernet la correspondance entre la MAC source et l'IP source. Cette attaque n'est donc pas possible.

Les services en clair

Nous avons dit précédemment que le niveau 2 ne voyait circuler que de l'IPsec. En fait, nous permettons aussi la circulation de trames IP non chiffrées contenant au niveau 4 des trames HTTP, HTTPS (qui correspondent au Web), des trames DHCP (qui est un protocole de configuration automatique) et des trames DNS (qui permettent de faire la conversion de noms en IP).

Le cas du DHCP

Le DHCP \cite{rfc951} nous permet de configurer automatiquement les clients. Ceux-ci, quand ils se connectent, émettent une requête à destination des serveurs DHCP qui leur donnent en retour leur adresse IP, le réseau sur lequel ils se trouvent et le routeur par défaut. Tout le monde peut se faire passer pour un serveur DHCP. Il est donc possible pour un attaquant de répondre de fausses informations. Selon la vigilance de l'utilisateur, cela peut conduire à un déni de service ou à un vol de données. En effet, l'utilisateur ne parviendra pas à établir la connectivité IPsec. Il peut donc décider de ne pas l'activer et émettre les données en clair à destination de l'attaquant. Il est donc important qu'un utilisateur s'assure du succès de la connexion IPsec avant d'envoyer des données. Sous Windows, Mac OS X et GNU/Linux, il n'est pas possible d'émettre des données si l'établissement de la connexion IPsec échoue.

Afin d'éviter qu'un serveur DHCP pirate ne perturbe tout le réseau, les bornes ne laissent en réalité pas passer les trames DHCP. Elles embarquent un relais DHCP. Les perturbations seront alors localisées à une seule borne.

Enfin, les informations véhiculées par le DHCP ne sont pas confidentielles.

Le cas de l'HTTP et de l'HTTPS

Nous laissons également passer l'HTTP (correspondant au Web) afin que les nouveaux clients puissent télécharger les programmes et les instructions nécessaires à la configuration de leur connexion WiFi. Ces données ne sont pas confidentielles. Par contre, il est important que le client s'assure de l'identité du site Web distant : il ne faut pas qu'il télécharge un virus ou un autre programme malicieux. Le second problème est de s'assurer que cette entrée ne permet pas d'accéder à autre chose que le site web en question. Ce dernier est localisé sur Nectaris.

Au niveau 2, les bornes s'assurent que seules les trames à destination de Nectaris passent (et leurs réponses). Au niveau 1, les adresses MAC sont vérifiées. Au niveau 3, seules les trames à destination du serveur Web passent. En bonus, toutes les requêtes qui ne sont pas à destination de Nectaris mais qui sont des requêtes Web sont redirigées sur Nectaris. Ainsi, quelqu'un qui tente d'accéder à un site extérieur tombera sur les instructions nécessaires pour configurer son accès WiFi.

Nectaris dispose d'un serveur Web capable de répondre en SSL ou non. S'il ne répond pas en SSL, il renvoie alors le client sur le serveur qui répond en SSL. SSL, pour Secure Socket Layer, est un protocole de niveau 4 assurant la confidentialité et l'authenticité. Une analyse de ce protocole est disponible dans \cite{mitchell98finitestate}. Dans notre cas, l'authentification ne se fait que dans un seul sens : le client peut s'assurer de l'identité du serveur à l'aide du certificat que celui-ci lui présente. Il ne nous paraît pas utile d'avoir à authentifier le client. Si un attaquant monte un faux serveur Web et redirige le client sur celui-ci, celui-ci obtiendra un avertissement.

En pratique, cette approche dispose d'une faiblesse : peu d'utilisateurs vérifient que le certificat correspond bien au site web et ignorent les avertissements éventuels. Si l'attaquant renvoie sur un site en clair, il n'y aura même pas d'avertissement et le client devra se rendre compte de lui-même que le site n'est pas sécurisé, ce qui n'est pas évident vu que l'utilisateur ne va pas entrer ou consulter des données confidentielles comme il le ferait sur un site bancaire. Enfin, notre certificat est signé par CAcert, une autorité pas encore reconnue par défaut dans les navigateurs usuels. Nous utilisons en interne des certificats CAcert pour tous les services et encourageons les utilisateurs à enregistrer le certificat racine de CAcert dans leur navigateur, mais un nouveau venu ne pourra pas savoir s'il s'agit vraiment du bon. Il serait nécessaire qu'il le télécharge d'une source sûre.

Le cas du DNS

Le DNS, Domain Name Service \cite{rfc1034}, est un protocole qui permet de convertir un nom comme www.crans.org en une IP comme 138.231.136.6. Nous devions laisser l'accès à ce service pour permettre aux connectés d'accéder au site Web. Dans le cas contraire, ils auraient été contraints de taper l'IP. Les bornes redirigent toutes les requêtes DNS vers leur propre serveur qui répond invariablement l'adresse IP de Nectaris. Nous ne sommes donc pas concernés par les problèmes de confidentialité ou d'authenticité à ce niveau : cette adresse IP n'est pas secrète et fournir une fausse IP ne mènera nulle part vu qu'au niveau IP, seule Nectaris est accessible.

Une attaque courante sur les hotspots est de mettre en place un tunnel par-dessus le protocole DNS afin d'accéder de manière non autorisée à Internet. Imaginons que nous contrôlions le domaine machin.com. Cela signifie que nous pouvons contrôler les réponses du serveur de DNS qui sert ce domaine. Nous allons utiliser cette possibilité pour encapsuler des données arbitraires dans le flux DNS et ainsi utiliser de manière frauduleuse le réseau. Par exemple, si on veut faire passer l'information zorglub à la machine distante, on peut demander à résoudre le nom zorglub.machin.com. Cette requête va parvenir au serveur de DNS que nous contrôlons et celui-ci saura donc que nous lui avons passé l'information zorglub. En retour, il peut par exemple répondre qu'il s'agit d'un alias sur compris.machin.com. Nous recevrons alors cette réponse.

Cette attaque n'est pas possible ici car le serveur DNS des bornes n'interrogent aucun DNS et se contentent de répondre l'adresse IP de Nectaris.

Conclusion

Au regard du modèle en couches, nous pouvons donc affirmer que la solution retenue est sûre du point de vue de la confidentialité et de l'authenticité, à hauteur de la sécurité fournie par IPsec. L'attaquant ne dispose pas de moyens techniques simples d'accéder aux données de l'utilisateur. Quand bien même il mettrait la main sur les bornes, pour les remplacer par des versions modifiées, cela ne l'avancerait guère : elles se contentent de laisser passer le signal chiffré et ne contiennent absolument aucun secret.

Du point de vue déni de service, un certain nombre de contre-mesures sont en place et les risques sont relativement faibles et resteront localisés.

Enfin, l'attaquant n'ayant pas d'accès au réseau ne dispose que de services extrêmement limités : il n'a guère accès qu'au serveur DHCP et au site Web. Cependant, s'il a un accès physique aux bornes, il dispose d'un accès plus complet aux services du réseau car ce sont les bornes qui le maintiennent en dehors de celui-ci. Cette faiblesse sera grandement amoindrie quand nous mettrons en place les VLAN.

Bibliographie

Aircrack, a 802.11 sniffer and wep key cracker. http://www.cr0.net:8040/code/network/.
Airsnort, a wireless lan encryption keys recovery. http://airsnort.shmoo.com/.
Isc dynamic host configuration protocol. http://www.isc.org/sw/dhcp/.
The kame project. http://www.kame.net.
Matrixssl, an open source embedded ssl. http://twistedmatrix.com.
Openbsd. free, functional and secure since 1995. http://www.openbsd.org.
Python, an interpreted, interactive, object-oriented programming language. http://www.python.org.
Twisted, an event-driven networking framework written in python. http://twistedmatrix.com.
Dod standard : Transmission control protocol, 1980. http://www.faqs.org/rfcs/rfc761.html.
Cédric Blancher. La sécurité des réseaux 802.11 : quoi de neuf depuis un an ? MISC 12, Mars 2004.
Nikita Borisov, Ian Goldberg, and David Wagner. Intercepting mobile communications : The insecurity of 802.11. http://www.isaac.cs.berkeley.edu/isaac/wep-faq.html, 2001.
D. Bruschi, A. Ornaghi, and E. Rosti. S-arp : a secure address resolution protocol. In ACSAC '03 : Proceedings of the 19th Annual Computer Security Applications Conference, page 66. IEEE Computer Society, 2003.
Mitchell Burton. Channel overlap calculations for 802.11b networks. Technical report, Cirond Technologies Inc, Nov 2002.
Nancy Cam-Winget, Tim Moore, Dorothy Stanley, and Jesse Walker. IEEE 802.11i overview. Technical report, IEEE, 2004.
Vinton Cerf and Ed Cain. The dod internet architecture model. Computer Networks, pages 307^U318, July 1983.
B. Croft and J. Gilmore. Bootstrap protocol (bootp). IETF Networking Group RFC 951, September 1985.
Joan Daemen and Vincent Rijmen. Aes proposal : Rijndael. http://www.esat.kuleuven.ac.be/~rijmen/rijndael/.
John D. Day and Hubert Zimmermann. The OSI reference model, pages 38--44. IEEE Computer Society Press, 1995.
Autorité de Régulation des Télécommunications. Évolution du régime d'autorisation pour les rlan à partir du 25 juillet 2003. http://www.art-telecom.fr/publications/lignedir/evol-rlan-250703.pdf.
Niels Ferguson and Bruce Schneier. A cryptographic evaluation of IPsec. Technical report, Counterpane, 3031 Tisch Way, Suite 100PE, San Jose, CA 95128, USA, 2000.
Scott R. Fluhrer, Itsik Mantin, and Adi Shamir. Weaknesses in the key scheduling algorithm of RC4. Lecture Notes in Computer Science, 2259 :1--24, 2001.
Joshua Guttman, Amy Herzog, and Javier Thayer. Authentication and confidentiality via ipsec. In ESORICS 2000. The MITRE Corporation, Springer-Verlag, 2000.
D. Harkins and D. Carrel. The internet key exchange (ike). IETF Networking Group RFC 2409, November 1998.
Russ Housley and William Arbaugh. Security problems in 802.11-based networks. Commun. ACM, 46(5) :31--34, 2003.
IEEE. Part 11 : Wireless LAN Medium Access Control and Physical Layer specifications : Higher-Speed Physical Layer Extension in the 2.4 GHz Band, supplement to ieee standard for information technology, telecommunications and information exchange between systems local and metropolitan area networks, 2002. http://standards.ieee.org/reading/ieee/std/lanman/802.
S. Kent and R. Atkinson. Ip authentication header (ah). IETF Networking Group RFC 2402, November 1998.
S. Kent and R. Atkinson. Ip encapsulating security payload (esp). IETF Networking Group RFC 2406, November 1998.
S. Kent and R. Atkinson. Security architecture for the internet protocol. IETF Networking Group RFC 2401, November 1998.
D. Maughan, M. Schertler, M. Schneider, and J. Turner. Internet security association and key management protocol (isakmp). IETF Networking Group RFC 2408, November 1998.
John C. Mitchell. Finite-state analysis of security protocols. In Computer Aided Verification, pages 71--76, 1998.
P. Mockapetris. Domain names, concepts and facilities. IETF Networking Group RFC 1034, November 1987.
Vebjørn Moen, Håvard Raddum, and Kjell J. Hole. Weaknesses in the temporal key hash of wpa. SIGMOBILE Mob. Comput. Commun. Rev., 8(2) :76--83, 2004.
Michael Ossmann. Wep : Dead again. In Security Focus, December 2004. http://www.securityfocus.com/infocus/1814.
Radia Perlman and Charlie Kaufman. Key exchange in ipsec : Analysis of ike. IEEE Internet Computing, 4(6) :50--56, 2000.
Bruce Schneier. Cryptanalysis of microsoft's point-to-point tunneling protocol (PPTP). In ACM Conference on Computer and Communications Security, pages 132--141, 1998.