Avant de commencer, vous noterez que l'article de ITWorld sur l'attaque de Tews et Beck que je vous annonçais la semaine dernière, relayé par Slashdot, exagère pas mal l'impact et n'est pas un modèle de précision technique. On pourrait même dire qu'il est relativement flou, voire contradictoire, ce que certains n'ont pas manqué de remarquer. Toujours est-il que je suis tout à fait d'accord avec Dragos quand il dit :

Its just the starting point. Erik and Martin have just opened
the box on a whole new hacker playground.

Comme indiqué dans l'article, le code de l'attaque, tkiptun-ng, est sur le SVN de aircrack-ng en version très alpha. En parlant de ce SVN, vous verrez également que Thomas d'Otreppe vient d'y poster un outil permettant de circonvenir le fameux WEP Cloaking, airdecloak-ng.


Maintenant, revenons à TKIP et remettons-nous un peu dans le contexte. Quand vous êtes en WPA ou WPA2, tout commence par une authentification. Celle-ci peut être réalisée soit à l'aide d'un secret partagé, le fameux mode PSK si cher à notre brute-forcers, ou sur un serveur RADIUS par le biais du protocole EAP. Dans les deux cas, une authentification réussie permet la mise en place d'un certain nombre de clés entre le client et le point d'accès. Parmi elles, on trouve une clé de session, la PTK[1]. Ces étapes sont décrites plus en détail dans la présentation que Simon et moi avons faite à BA-Con. Je ne reviendrai pas là-dessus.

Cette fameuse PTK va alors être découpée en plusieurs sous-clés. D'abord deux clés de 128 bits chacune[2] destinées à protéger des échanges de clés futurs, typiquement le renouvellement de la clé de groupe[3]. La clé suivante, également d'une longueur de 128 bits, est la clé de chiffrement proprement dite, la TEK[4]. À partir de là, nous pouvons avoir deux cas :

  • si nous avons négocié un chiffrement en CCMP, alors la TEK sert à la fois au chiffrement et au contrôle d'intégrité, et nous n'avons pas besoin d'autre clé, ce qui nous donne une PTK de 384 bits ;
  • si nous avons négocié un chiffrement en TKIP nous allons avoir besoin de deux clés supplémentaires[5] de 64 bits chacunes, une pour chaque sens de communication, pour générer les MIC[6], ce qui nous donne une PTK de 512 bits.

Comme c'est le dernier cas qui nous intéresse, nous commençons donc à chiffrer nos données utiles en TKIP dès lors que nous sommes en possession d'une TEK de 128 bits et de deux MK de 64 bits chacune.


Aussi surprenant que cela puisse paraître, le chiffrement des paquets va se faire à l'aide du bon vieux moteur WEP dont on connait le fonctionnement et les vulnérabilités par cœur, ou presque. En fait, la partie chiffrement de TKIP consiste surtout en un nouvel algorithme de génération de clés pour WEP qui vise à éviter le rejeu de paquets, la réutilisation de keystream et les corrélations entre clés en utilisant les 128 bits disponibles.

Ceci est réalisé par deux fonctions de hashage successives, dites "Key Mixing Phases". La première prend entrée la TEK, l'adresse MAC de la station émettrice ainsi qu'un compteur de séquence appelé TSC[7] pour produire une clé intermédiaire appelée TTAK[8]. La seconde prend en entrée la TTAK, le TSC et la TEK. Elle fournit en sortie une clé de 128 bits, dite PPK[9], différente pour chaque valeur du TSC. Comme le TSC est incrémenté pour chaque paquet à chiffrer, la PPK change également. Cette clé va alors être fournie comme entrée au moteur de chiffrement WEP. Comme ce dernier attend, en plus des données à chiffrer, un vecteur d'initialisation[10] de 24 bits et une clé WEP de 104 bits, on va découper notre PPK en deux morceaux, un de 24 bits, l'autre de 104, et les fournir au moteur WEP en tant qu'IV et clé WEP.

En notant MP la phase de hashage, TA l'adresse MAC de l'émetteur et n le numéro de la trame à chiffrer, on pourrait représenter le mécanisme de la sorte :

MP1(TA, TEK, TSCn) = TTAKn
MP2(TEK, TSCn, TTAKn) = PPKn = (IVn || Kn)

Ce qui fait qu'on peut tout à fait voir notre TKIP comme un algorithme permettant de faire du WEP en renouvelant la clé à chaque paquet. C'est ce qu'on appelle un Key Scheduling, et c'est ce qui permet ici de lutter contre les attaques en réutilisation de keystream d'une part et les attaques plus étoffées comme la FMS ou la PTW d'autre part.


Le contrôle d'intégrité est quant à lui délégué à un algorithme appelé Michael qui brille essentiellement par sa faiblesse. Cette dernière impose sa protection par un chiffrement. Un MIC sera calculé à partir de la MK affecté au sens de communication utilisé, des adresses MAC source et destination[11], et bien évidemment les données en clair contenues dans le payload de la trame, qu'on appelle MSDU[12].

Michael(DA, SA, MSDUn, MK) = MICn

Ce MIC sera alors ajouté au payload en clair, constituant alors la charge amenée à être chiffrée.


Si on note Pn le payload à chiffrer, on peut alors représenter le principe de chiffrement global ainsi :

MPDU[13] = WEP(IVn, Kn, Pn)
        = RC4(IVn || Kn) XOR (Pn || CRC32(Pn))

Où :

Pn = MSDUn || MICn

Je vous concède que ça fait un peu usine à gaz, mais c'est le prix à payer pour obtenir la compatibilité avec un compromis performances vs. sécurité acceptable. En français dans le texte, ça nous donne les étapes suivantes :

  • on prend les données en clair ;
  • on calcule le MIC à partir de la MK, des adresses (SA et DA) et des données en clair (MSDU) ;
  • on place le MIC à la suite des données en clair ;
  • on incrémente le TSC ;
  • on calcule une PPK à partir du TSC courant, de la TEK et de son adresse MAC (TA) ;
  • on présente la PPK au moteur WEP comme 24 bits d'IV et 104 bits de clé WEP ;
  • on chiffre les données et le MIC en WEP ;
  • on envoie la trame.

De l'autre côté, on déchiffre la trame reçue comme suit :

  • on reçoit la trame ;
  • on extrait le TSC et on vérifie qu'il correspond bien à la valeur attendue ;
  • on génère la PPK à partir du TSC, de la TEK et de l'adresse MAC de l'émetteur (TA) ;
  • on présente la PPK au moteur WEP comme 24 bits d'IV et 104 bits de clé WEP ;
  • on déchiffre le payload chiffré en WEP ;
  • on récupère les données en clair et le MIC ;
  • on vérifie le MIC à partir de la MK, des adresses et des données ;
  • si tout s'est bien passé, on passe le payload à la couche supérieure.

Tout ceci est décrit dans 802.11i, pages 43 à 45.


Qu'est-ce qui peut mal se passer là-dedans ? Pleins de choses.

D'abord, une mauvaise valeur de TSC, en cas de rejeu par exemple. Depuis la mise en place de la session entre la station et le point d'accès, chacun possède son propre TSC, mais garde également la trace du TSC de son correspondant[14]. Si un attaquant réinjecte une trame déjà envoyée, le destinataire verra que le TSC a déjà été utilisé ou ne correspond pas à la séquence normale et refusera la trame.

Ensuite, on peut avoir une trame annonçant le bon TSC, mais chiffré avec une mauvaise PPK. Typiquement, un attaquant va injecter du trafic avec un TSC valide, mais ne connaissant la TEK, il ne pourra pas générer la bonne PPK. Dans ce cas, c'est le déchiffrement WEP qui va échouer par une erreur de CRC et la trame sera détruite silencieusement.

Enfin, si par quelque miracle bien senti, la trame injectée par l'attaquant s'avérait valide du point de vue du WEP, donc affichant un TSC valide et une PPK valide, il lui resterait le problème du MIC qui demande une MK valide, que l'attaquant n'est pas censé connaître. Sa trame a donc de fortes chances d'arriver avec un MIC dont la vérification va échouer. Cependant, comme on vient de le voir, ce type d'erreur n'arrive que si l'attaquant possède une PPK valide, mais pas la MK qui va bien. Situation fort embarrasante s'il en est, qui doit donner lieu à la mise en route de contre-mesures. Le récepteur qui va détecter une telle erreur va alors mettre en route un timer de soixante secondes. Si une seconde erreur se produit dans ce laps de temps, alors on va casser l'association et tout renégocier. Dans la pratique, s'il s'agit d'un AP, ce dernier va tout simplement jeter le client en question et attendre qu'il se ré-authentifie. S'il s'agit d'une station, celle-ci va émettre un paquet signalant l'erreur à l'AP. Si une seconde erreur est détectée dans les soixante secondes suivantes, elle va envoyer une nouvelle erreur à l'AP. Les deux entités procèderont alors à la destruction de l'association.

Il doit cependant être noté qu'une trame présentant le bon TSC et chiffrée avec la bonne PPK associée peut être synonyme de possession par l'attaquant de la TEK, seul élément secret entrant dans la génération des PPK. Or, s'il possède la TEK, il est capable de déchiffrer n'importe quel paquet ayant transité sur la réseau et se trouve en possession des payloads et des MICs correspondants en clair. Étant donné la faiblesse de Michael, cette situation va lui permettre de déduire quasi immédiatement les deux MK. On comprend bien alors que le but du contrôle d'intégrité est d'empêcher quelqu'un de déduire la TEK ou les MK par modification opportuniste et rejeu des paquets, bref par oracle.


Voilà. Maintenant, vous savez presque tout sur TKIP. Les plus curieux iront lire le code de l'attaque et, fort de ces informations et de quelques lectures éclairées, ne devraient pas mettre très longtemps à voir le principe de l'attaque et en comprendre les implications.

À mardi ou mercredi pour la suite.

Notes

[1] Pairwise Transcient Key.

[2] La KCK, pour Key Confirmation Key, et la KEK, pour Key Encryption Key.

[3] GTK, pour Groupwise Transcient Key.

[4] Transcient Encryption Key.

[5] MK, pour MIC Key.

[6] Message Integrity Check.

[7] TKIP Sequence Counter.

[8] TKIP-mixed Transmit address and Key.

[9] Per Packet Key, ou WEP Seed.

[10] IV, pour Initialisation Vector.

[11] Attention, l'adresse MAC source de la trame n'est pas forcément celle de l'émetteur. C'est par exemple la situation lorsqu'un AP relaie une trame venant du réseau filaire...

[12] MAC Service Data Unit

[13] MAC Protocol Data Unit.

[14] Dans le cas d'un AP, ce sera ses correspondants...