Pour bien comprendre comment on casse un algorithme ou un protocole, il faut d'abord comprendre comment il fonctionne. Dans cette première partie, nous allons donc regarder le fonctionnement de WEP. WEP est un protocole cryptographique dont l'objet est 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 s'appuie sur l'algorithme de chiffrement de flux RC4 et sur une somme CRC32.

Le contrôle d'intégrité est donc réalisé par calcul d'une somme CRC32 sur les données du message. Cette somme sera placé à la suite des données, l'ensemble étant par la suite chiffré. Ce chiffrement est assuré par RC4. Cet algorithme reprend le principe du masque jetable (OTP). Il est constitué d'un générateur de données pseudo-aléatoire dont la sortie dépend d'une clé de 64 ou 128 bits 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 clés. C'est pourquoi on va découper notre clé 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 clé fixe de 40 ou 104 bits, dite clé WEP (K), selon qu'on désire un chiffrement à 64 ou 128 bits. Ainsi, on espère faire tourner les clés de chiffrement. Pour un message M clair (|| représentant l'opérateur de concaténation et ICV le calcul du CRC32), son chiffré sera donc :

P = RC4(IV||K) XOR (M||ICV(M))

L'authentification, enfin, est réalisée en vérifiant que la partie qui demande à s'authentifier possède bien la clé WEP. Le point d'accès envoie un challenge aléatoire de 128 octets à partir duquel la station désireuse de s'associer devra construire une trame de réponse correctement chiffrée à renvoyer. Il suffira alors à l'AP de vérifier le bon déchiffrement de cette trame.

Déjà, on peut voir plusieurs problèmes. D'abord, ce protocole n'inclue aucun mécanisme permettant d'empêcher le rejeu ou l'injection arbitraire de données, ce qui, nous le verrons, donnera à un attaquant des outils très efficace dans le cassage de WEP. Ensuite, un CRC32 est généralement utilisé pour détecter des erreurs de transmissions (cf. ethernet) parce que, léger soucis, 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 ainsi 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. Et quand on voit que l'opération XOR est également linéaire, les premières idées commencent à germer. Le contrôle d'intégrité ne fonctionne donc pas.

Ensuite, on voit tout de suite que l'authentification est unilatérale. Si l'AP authentifie la station, cette dernière n'a aucun moyen d'authentifier l'AP auquel elle s'associe. Un AP malicieux pourrait en outre transformer un client en oracle en lui fournissant des messages à chiffrer sous forme de challenge. Mais la plus belle faille vient du mécanisme d'authentification lui-même qui entraîne l'envoie du challenge d'abord en clair, puis chiffré. Nous avons donc une attaque en clair connu qui nous permet d'extraire suffisament de données pour pouvoir par la suite répondre à n'importe quel challenge, et donc nous authentifier sans connaissance préalable de la clé. Si on appelle G le challenge et R sa réponse :

R = RC4(IV||K) XOR (G||ICV(G))

Soit :

RC4(IV||K) = R XOR (G||ICV(G))

Un attaquant ayant observé une authentification connait R et G et peut donc déduire la valeur de RC4(IV+K). S'il reçoit un nouveau challenge G', il calculera sa réponse R' en réutilisant le même IV et donc cette sortie de RC4 :

R' = RC4(IV||K) XOR (G'||ICV(G'))

L'authentification n'est donc pas efficace. Pire, elle introduit une faille qui permet d'extraire des données précieuses qui, comme nous le verrons par la suite, pourront contribuer à casser la clé K.

Enfin, le chiffrement... Il y a trois règles de bases dans l'utilisation de RC4 :

  1. ne jamais utiliser deux fois la même clé dans le même contexte ;
  2. jeter les 512 premiers octets de la sortie RC4 pour éviter les problèmes liés à l'utilisation de clés faibles ;
  3. ne pas chiffrer plus de 2^36 octets de données avec la même clé.

On pourrait naïvement croire que l'espace des clés utilisées sur un réseau protégé par WEP est de 64 ou 128 bits. En fait, il n'en est rien. En effet, la clé RC4 est contruite par concaténation de l'IV et de la clé WEP K qui est fixe. La seule partie changeante est donc l'IV, ce qui nous donne un espace de clés de 24 bits seulement. Si on applique le fameux théorème des anniversaires, on s'aperçoit qu'une collision de clé 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 utilisables pour réduire l'effort nécessaire à la découverte de la clé. Si deux trames C et C' sont chiffrée avec le même IV, on aura :

P = RC4(IV||K) XOR (M||ICV(M)
P' = RC4(IV||K) XOR (M'||ICV(M')

En posant C = M||ICV(M), on obtient après bidouillage :

P XOR P' = C XOR C'

Ensuite, la seconde règle n'est pas respectée non plus, ce qui rend le système vulnérable à l'utilisation de clés faibles. Or il se trouve qu'on reconnait les clés faibles à leurs trois premiers octets, c'est à dire 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 clés faibles, et ensuite, comme nous le verrons plus tard, d'attaquer RC4. 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.

Il apparait 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 clés 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ées sans modifier le protocole lui-même.

Normallement, vous devez commencer à saliver. Nous avons pleins de vulnérabilités un peu partout, comment les exploiter pour effectivement casser WEP ? C'est ce que je vais expliquer dans un second épisode à venir, parce que je dois filer, on m'attend à l'autre bout de Paris :)