Calculer le keystream

patience.
A ce stade, vous comprenez ceci :

Message1 + CRC = Plaintext1 
IV + Secret Key = Keystream
Plaintext1 XOR Keystream =
   Ciphertext

  Je veux analyser la faiblesse dont souffre cette équation

: le calcul du keystream. WEP ne dicte pas la méthode de calcul de IV

pour chaque paquet et n’exige pas que chaque paquet ait une valeur IV

différente. Ces limitations ont conduit de nombreux fournisseurs à 
appliquer des calculs IV élémentaires et prévisibles, qui réduisent

considérablement le nombre de keystreams uniques qu’un réseau utilise.

Si un appareil met la valeur IV à  0 à  chaque réinitialisation et

l’augmente de 1 chaque fois que le NIC s’initialise, cet
appareil peut être limité aux valeurs IV de 0 à  4. Un calcul binaire

dicte que les possibilités 25 résultantes ne produisent
qu’un maximum de 32 valeurs IV possibles – ce qui est insuffisant pour
un mécanisme de sécurité efficace. Un
appareil sans fil peut générer des milliers
de paquets par jour. Multipliez ces
milliers par le nombre d’appareils sans
fil présents sur le réseau et vous aurez
une idée du nombre de paquets – chacun
avec une valeur IV correspondante
– qui emprunte votre réseau sans fil
chaque jour.

  
Le protocole WEP transmet la valeur
IV en texte clair en même temps
que le texte chiffré. Par conséquent,
pour obtenir les valeurs IV qu’un réseau
utilise, il suffit à  un assaillant d’espionner
passivement le trafic du réseau
sans fil. S’il détecte deux
messages qui utilisent la même valeur
IV, il lui suffit d’appliquer une fonction
XOR à  ces deux messages. (La fonction
XOR requiert deux éléments de données.)
L’assaillant peut ensuite obtenir
les valeurs XOR des deux messages en
texte clair. Comme le trafic IP est souvent
prévisible et très redondant, la
connaissance de ces valeurs XOR permet
à  l’assaillant de conduire des attaques
statistiques pour récupérer en
définitive les messages en clair.
Dès lors qu’un assaillant possède
les valeurs du texte clair et du texte
chiffré, quelques calculs simples – inspirés
de l’équation indiquée précédemment
– peuvent déterminer la valeur
du keystream. Si l’assaillant place
ces calculs dans un script ou un programme
(qui exécute automatiquement
tous les paquets interceptés au
travers du programme pour construire
la base de données décrite), il peut assembler
une base de données qui
contient les valeurs IV et les valeurs
keystream correspondantes de tout un
réseau – en supposant que tout le
monde sur le réseau utilise la même
clé. Par conséquent, ce renifleur de trafic
nouvellement armé serait capable
de capturer un paquet, de comparer sa
valeur IV non cryptée à  la base de données
des valeurs keystream, d’extraire
la valeur keystream correspondante et
l’appliquer au paquet – afin de décrypter
automatiquement l’information
cryptée.

  Dans l’idéal, chaque paquet aura
une valeur IV différente – c’est-à -dire
une valeur keystream différente – de
sorte que les éventuels efforts pour obtenir
et suivre ce type d’information
solliciteraient trop le processeur en
l’état actuel de la technique. Mais le
standard 802.11 n’exige pas que
chaque paquet ait une valeur IV différente
(bien qu’il le suggère) et il ne
propose pas de méthode pour calculer
des valeurs IV aléatoires.