Le contrôle d'intégrité : algorithme MIC

Défini à l'origine dans PEM^5.2 pour l'authentification via MD2 ou MD5, le MIC (Message Integrity Code/Check) remplace le CRC32 qui servait à protéger l'intégrité des données dans WEP. En effet, le CRC32 est un procédé qui calcule un code d'intégrité sur 32 bits calculé de façon linéaire :

$$CRC(X + Y) = CRC(X) + CRC(Y)$$

Puisque plusieurs messages peuvent avoir le même code CRC32, on peut alors, si l'on modifie le message, en modifier une autre partie (non importante) afin de retomber sur le même CRC32. Ainsi, l'intégrité du message sera considéré comme correct alors qu'il aura été modifié.

Il nous faut donc, afin de conserver une bonne intégrité, un autre moyen de contrôler l'intégrité des messages : c'est le rôle de MIC. Contrairement au CRC32, le MIC n'est pas seulement calculé à partir des données de la trame mais à partir de la trame complète, en-tête comprise. Cela va permettre de protéger les en-têtes contre les modifications, notamment les champs de longueur, afin de prévenir tout rajout/suppression de données.

L'algorithme commence donc par calculer le MIC à partir de la trame claire complète et d'une des deux clés d'intégrité (celle correspondant au sens de l'envoi). Le résultat est concaténé à la trame puis le tout est envoyé au moteur de chiffrement WEP. Un CRC32 est aussi calculé, comme prévu pour le WEP.

Le fait d'utiliser des clés pour le calcul de la somme d'intégrité empèche la modification de la trame sans trace. En effet, il est impossible de recalculer le MIC sans la clé adéquate.

La seule attaque possible est alors le déni de service : lors d'une collision accidentelle, la vérification du CRC32 génèrera un rejet pur est simple sans vérification du MIC de la trame, le CRC32 sera erroné. Ainsi, dans le cas où le MIC serait vérifié, aucune erreur n'aurait été détectée dans la trame, ce qui par son caractère peu probable, est un signe d'attaque si cela arrive trop souvent. La norme veut qu'une erreur de ce type soit tolérée par tranche de 60 secondes. Au-delà, l'association doit être refaite et les clés changées. Un attaquant pourrait donc injecter des trames avec un CRC correct mais un MIC erroné afin de provoquer des désassociations. Cela est heureusement évité par l'impossibilité de rejeu (ré-utilisation de séquences d'authentification impliqué par le fait qu'une trame est rejetée si l'IV qu'elle utilise l'a déjà été lors de la session en cours.