|
802.11b ou le WEP remis en cause |
Introduction
802.11b est un protocole réseau wireless qui est actuellement de plus en plus utilisé pour les réseaux locaux (entreprises, conférences, particuliers, etc). Contrairement au protocole Bluetooth, 802.11 permet des débits élevés (11 Mbit/s dans sa version b) à de grandes distances (plusieurs centaines de mètres). Il intègre en option un protocole de sécurité au niveau liaison, le Wired Equivalent Privacy ou WEP; celui-ci est très simple à administrer et facile à utiliser mais malheureusement peu sûr. Le but de ce document est d'en exposer les faiblesses au travers des récentes études sur le sujet.
Failles du protocole
Chaque périphérique 802.11 (cartes, etc…) utilise une clé qui est soit un mot de passe, soit une clé dérivée de ce mot de passe. La même clé est utilisée par tous les éléments accédant au réseau, le but est donc d'interdire l'accès à toutes les personnes ne connaissant pas ce mot de passe.
La faille provient de la façon dont l'algorithme de chiffrement (RC4) est implémenté et plus précisément de la façon dont sont spécifiés les vecteurs d'initialisation (IV).
Certaines cartes utilisent des IVs à 0 puis les incrémentent de 1 à chaque utilisation ; cela implique nécessairement des réutilisations de vecteurs et donc des flots de données similaires (c.f. la formule du chiffrement ci-dessous). Les attaques inhérentes à ces problèmes sont très simples mais peu généralisables [3]. L'autre type d'attaques, plus efficace, a d'abord été présenté sous forme théorique par Fluhrer, Mantin et Shamir [1]. Il a récemment été implémenté très facilement, démontrant ainsi que le protocole WEP n'est pas du tout sécurisé.
Approche théorique
De façon très succincte, le chiffrement utilisé par WEP peut-être décrit comme suit : la clé partagée est notée K. Au moment de la transmission des données M, celles-ci sont d'abord concaténées avec leur checksum c(M). Parallèlement à cela le vecteur d'initialisation est concaténé à la clé K, et passé en entrée à la fonction de chiffrement RC4. Le résultat subit un XOR avec les données :
C = (M || c(M)) XOR RC4 (IV || K)
La structure du RC4 se compose de 2 parties distinctes ; la première, ou key scheduling algorithm, génère une table d'état S à partir des données secrètes, à savoir soit 64 bits (40 bits de clé secrète et 24 bits d'IV) ou 128 bits (104 bits de clé secrète et 24 bits d'IV). La deuxième partie de l'algorithme RC4 est le générateur de données en sortie, qui utilise la table S et 2 compteurs. Ces données en sortie forment une séquence pseudo-aléatoire.
Fluhrer, Mantin et Shamir présentent 2 faiblesses dans la spécification de l'algorithme RC4. La première repose sur le fait qu'il existe de larges ensembles de clés dites faibles, c'est-à-dire des clés dont quelques bits seulement suffisent à déterminer de nombreux bits dans la table d'état S (avec une forte probabilité), ce qui affecte directement les données produites en sortie ; c'est l'attaque nommée «invariance weakness».
La deuxième attaque de Fluhrer, Mantin et Shamir est la «known IV attack ». Elle nécessite la connaissance de l'IV ce qui est le cas puisqu'il circule en clair sur le réseau, et la connaissance du premier octet de M (à deviner). Dans un certain nombre de cas (« les cas résolus », suivant l'expression de Fluhrer, Mantin et Shamir ) , la connaissance de ces 2 éléments permet de déduire des informations sur la clé K.
Selon les auteurs, ces 2 attaques sont applicables et peuvent permettre une récupération complète de la clé avec une efficacité bien supérieure à l'attaque par recherche exhaustive.
Mise en pratique
L'implémentation de cette deuxième attaque par Stubblefield, Ioannidis et Rubin [2] a pris une semaine, requis 2h de codage et 100$ d'investissement. Leur principale difficulté a été de deviner le premier octet des données brutes (le plaintext M) ; or malgré les différents types de protocoles utilisés (notamment de l'ARP et de l'IP), il s'est avéré que 802.11 rajoute une couche supplémentaire en encapsulant tous ses paquets (header SNAP de 802.2). Ainsi, tous les paquets capturés commençaient par le même octet 0xAA.
Selon les auteurs, 256 cas «résolus» suffisent pour retrouver l'intégralité de la clé de 128 bits ; ils ont également optimisé leur méthode d'attaque et ont estimé qu'un jour ou deux suffiraient à un attaquant inexpérimenté pour arriver au même résultat. Une des optimisations a consisté à tester directement des caractères simples, c'est-à-dire mémorisables par les utilisateurs. En effet, d'une part la passphrase était utilisée à l'état brut (sans hachage) dans le cas étudié, et d'autre part cette passphrase se devait d'être suffisamment simple pour être retenue par tous les utilisateurs.
Conclusion
En conclusion, les auteurs ont souligné les points suivants :
- La couche liaison de 802.11 n'offre aucune sécurité.
- Il faut utiliser des protocoles de sécurité supplémentaires tel que IPSec, SSL ou SSH et en aucun cas s'appuyer sur WEP pour assurer la sécurité.
- Toutes les entités utilisant 802.11 doivent être considérées comme externes et donc placées à l'extérieur du firewall.
- Il faut toujours avoir à l'esprit que toute personne se trouvant dans le rayon d'émission (et même au-delà grâce à des dispositifs amplifiants) peut être susceptible de communiquer sur le réseau en tant qu'utilisateur valide.
Bibliographie
[1] FLUHRER, MANTIN et SHAMIR, Weaknesses in the key scheduling algorithm of RC4, English Annual Workshop on Selected Areas in Cryptography (08/2001).
[2] STUBBLEFIELD, IOANNIDIS et RUBIN, Using the Fuhrer, Mantin and Shamir Attack to Break WEP, AT&T Labs Technical Report TD-4ZCPZZ (08/2001).
[3] BORISOV, GOLDBERG et WAGNER, Intercepting mobile communications : the insecurity of 802.11, MOBICOM 2001 (2001)
| |
| 
