e n'aurais pas dû, me direz-vous. Mais je l'ai fait. En prenant nonchalamment mon café, j'ai attrapé un Hakin9 qui traînait et j'ai commencé à le feuilleter. C'était le numéro 2/2009, celui qui annonçait en couverture un Plus intitulé "Nouvelles faiblesses dans la technologie WiFi ! Attaques WPA par force brute, Techniques les plus récentes". Je le sentais mal, et effectivement, arrivé page 44, j'ai failli recracher la moitié de mon mug sur le journal...
J'exagère un peu, forcément, mais je n'en était pas loin. Par la suite, comme le nom de l'auteur me disait quelque chose, j'ai googlé un peu pour voir et me suis rappelé avoir lu sa tribune sur TKIP qu'il avait écrite en novembre dernier sur la faille TKIP dans le Journal du Net. Tribune dont le contenu ne dépareille guère en fait...
Je sais, je ne devrais pas sauter à la gorge d'un confrère sur ses écrits. Tout le monde fait des erreurs, des confusions, des fautes d'orthographe, de grammaire, des typos, etc. Moi autant qu'un autre, peut-être même davantage. Mais bon, un peu de critique déplacée ne fait jamais de mal, et puis il paraît que rentrer dans les gens, ça fait des hits... Plus sérieusement, je dois avouer que la bonne rengaine "WPA est cassé" commence un peu à chatouiller le bout des doigts, surtout quand c'est pour lire que pour corriger le problème, il suffira de passer à WPA2... Bref, si je n'ai rien contre l'auteur[1] personnellement, je sens que je vais quand même me faire un nouveau copain en commentant ses deux articles...
L'article de Hakin9 s'intitule "Nouvelle faiblesse dans la technologie WiFi". Vous noterez que depuis la page de garde, on est passé du pluriel au singulier quand il s'agit de faiblesse. En somme l'article veut surtout nous présenter la faiblesse publiée par Tews et Beck en novembre dernier sur TKIP. Il parle également des attaques en recherche de PSK annoncées par Elcomsoft. Et de finir par un sympathique "mais pourquoi pas mettre du VPN par dessus", genre ceinture et bretelles...
Loin d'être mauvais, cet article empile cependant les erreurs et approximations dans la partie brute-forcing. Et ça commence dès la première phrase du paragraphe :
La sécurité de WPA repose sur une clé, en réalité un mot de passe, qui sert à chiffrer les données échangées.
Objection, votre honneur ! Ce serait vrai si WPA n'offrait qu'un mode d'authentification par clé partagée, autrement dit si on n'avait à notre disposition que WPA-PSK, aussi appelé WPA Personal. Or on sait bien, en tout cas ceux qui me lisent, que WPA permet également de mettre en œuvre une authentification 802.1x qui offre un choix de méthodes relativement large. C'est le mode qu'on appelle WPA Enterprise, qu'on trouve même sur quelques routeurs grand public et qui est mis à profit par un service comme Wifiradis. Donc affirmer que la sécurité WPA repose sur une passphrase est bien plus qu'un raccourci. Et qu'on ne me rétorque pas que l'article se veut grand public, à destination de Mme Michu, quand on en appelle plus loin au VPN SSL, à IPSEC, à du reverse proxy ou à du VDI...
Bref, WPA ne veut pas dire authentification PSK, donc être capable de casser de la PSK ne veut pas dire casser du WPA. Continuons...
Cette clé, appelée PSK (Pre-Shared Key), a une longueur pouvant aller de 8 à 256 bits, soit de 8 à 63 caractères ASCII.
Faux. Outre le fait qu'il faut être un sacré contortionniste pour arriver à faire correspondre 8 bits et 8 caractères ASCII d'un côté, et 256 bits et 63 caractères de l'autre[2], il se trouve qu'une PSK ne se donne qu'en ASCII. La mention de la taille en bits pourrait même se révéler assez déroutante, en ce qu'elle laisse entendre une vague correspondance avec une longueur de clé telle qu'on la conçoit pour des algorithmes de chiffrement symétriques, ce qui est très, très loin d'être le cas. Bref, une passphrase, ça fait entre 8 et 63 caractères. Point.
Ce qui fait 256 bits, et vraiment 256 bits, genre ni plus ni moins, c'est la PMK qui sera dérivée de la passphrase via la fonction PBKDF2. Or, le standard prévoit qu'on puisse, quand on fait du WPA-PSK, fournir directement cette PMK directement comme secret partagé, sans fournir de PSK. Ça fait un peu pinaillage, mais c'est tout de même important à noter. Ce mode de fonctionnement est notable lorsque vous vous amusez avec WZCook qui permet d'extraire les secrets Wi-Fi qu'une machine Windows. Dans le cas d'une PSK WPA/WPA2, il vous sortira une PMK, puisque c'est sous cette forme que Windows stocke le secret, pour ne pas avoir à rejouer PBKDF2 à chaque association.
Il n'en reste pas moins qu'une clé de 8 caractères - dont chacun pourra être une minuscule, une majuscule ou un signe, soit 26+26+10 possibilités par caractère
Ben non. Ce ne sont pas les caractères alphanumériques qui sont autorisés mais bien plus, à savoir une bonne partie du jeu de caractères imprimables. 95 caractères[3] en fait. Ça ne change rien à la conclusion du paragraphe quant à la faisabilité de l'attaque, mais quand on parle de crackage de password ou de recherche de passphrase comme c'est ici le cas, il n'y a pas que la longueur du secret qui compte et la possibilité d'avoir recours à des caractères spéciaux est d'une grande aide, en particulier si on a affaire à des attaques basées sur des dictionnaires... Comme c'est le cas ici...
engendrera tout de même 628 possibilités
Je pense qu'on a affaire à un caractères qui a sauté à l'impression puisqu'il doit s'agir de 62^8. Même si en réalité, on parle de 95^8. Pour le nombre de possibilités autorisées par une clé de 63 caractères, j'ai du mal à trouver la faute de frappe dans la passage suivant :
la clé peut monter jusqu'à 63 caractères, soit 8 10112 possibilités.
On est par contre complètement d'accord sur la conclusion. Passons maintenant à TKIP, à commencer par son histoire :
au départ, WPA devait s'appuyer sur le protocole AES-CCMP mais celui-ci est si gourmand en calcul qu'il est nécessaire de lui mettre à disposition un processeur spécialisé
Euh oui, mais non en fait. Si TKIP existe, c'est surtout parce que le moteur de chiffrement WEP était implémenté en hard sur les cartes pour décharger l'hôte du chiffrement. Or, et ceux qui font de la sécurité Wi-Fi depuis un bon moment s'en souviennent encore, il était difficile à l'époque d'injecter des trames arbitraires complètes en bypassant cet étage, fonctionnalité nécessaire à l'implémentation en soft d'un nouvel algorithme de chiffrement. D'où la nécessité de construire quelque chose qui s'appuierait quand même sur WEP, à savoir TKIP. Ceci dit, Lorsque l'injection est possible, ça se fait très bien et ça marche. On peut en effet faire de l'AES-CCMP sans aucun soucis avec des chipset qui ne supportent clairement pas AES en hard genre Prism2 ou Aironet 340 sur pleins de plate-formes différentes, y compris des choses pas très puissantes comme des PDA[4]. La raison d'être principale de TKIP est la compatibilité avec le matériel existant, ce qui est clairement indiqué dans le standard :
A design aim for TKIP was that the algorithm should be implementable within the capabilities of most devices supporting only WEP, so that many such devices would be field-upgradeable by the supplier to support TKIP.
Pour ce qui est des performances, même si j'avoue n'avoir pas fait le benchmark proprement dit, il est loin d'être évident que AES-CCMP est horriblement plus lent que TKIP, au point de nécessiter un processeur dédié. OpenSSL en mode benchmark me donne RC4 comme deux fois plus rapide qu'AES et ça tend à se tasser quand la taille du bloc de données augmente. Il est alors légitime de se demander ce que ça donnerait pour le chiffrement d'un bloc de 1000 octets, nettement plus représentatif de la taille d'une trame que les blocs utilisés par OpenSSL. En outre, TKIP nécessite la génération d'une clé distincte par trame à chiffrer[5], ce qui suppose le passage par deux fonctions de mixage dont l'impact est loin d'être négligeable.
Bref, l'argument comme quoi AES est tellement gourmand qu'on ne pourrait pas le faire en soft est un poil tiré par les cheveux si vous suivez mon raisonnement. On aurait parlé de 3DES, je n'aurais peut-être pas objecté, vu qu'il a été écarté lors de la définition du standard justement pour des problèmes de performance. Le problème de la performance, il s'est surtout posé quand il a fallu définir TKIP, pour trouver des fonctions de mixage et un algorithme de MIC nettement moins gourmands que des choses à base de hashes classiques genre MD5 ou SHA1...
Point intéressant, on notera que l'auteur précise qu'on peut faire du WPA avec du chiffrement en AES-CCMP :
WPA peut fonctionner en s'appuyant sur TKIP ou CCMP
Ce qui veut dire qu'une méthode extrêmement simple et largement supportée par les équipements du marché depuis la sortie de 802.11i pour pallier le problème relevé par Tews et Beck consiste à faire du WPA en AES-CCMP, à défaut de passage à WPA2. Cette solution n'est pas mentionnée dans l'article et c'est bien dommage, en particulier quand on sait que pas mal de boitiers ISP genre Freebox ou encore Livebox[6] ne supportent pas WPA2, mais bel et bien le chiffrement AES-CCMP sur WPA[7]
En faisant ma recherche sur l'auteur, je suis certes retombé sur cette tribune du JdN, mais je me suis surtout aperçu qu'elle avait également été publiée sur le blog sécurité d'Orange Business Services. Là encore, on retrouve le même genre de confusions et d'approximations, à commencer par un sympathique trait d'humour :
une annonce dans les mailing-lists 'underground' a fait grand bruit
Les mailing lists "underground" dont on parle, c'est DailyDave, Full-Disclosure, Bugtraq, Wireless-Security et consors, auxquelles on ajoutera évidemment toutes les publications spécialisées en ligne qui ont aussitôt repris l'info. Du pur underground bien l33tz disponible pour tout le monde, et que toute personne un tant soit peu intéressée par la sécurité informatique parcours, au moins en partie, même d'un œil distrait...
Et c'est reparti :
WPA repose lui sur la qualité de la PSK (Pre-Shared Key), sorte de clé/mot de passe que le client et le serveur doit connaitre pour pouvoir dialoguer.
Fail again... Sing that song of pain...
C'en est maintenant fini avec WPA suite à la découverte des chercheurs Erik Tews et Martin Beck, qui ont trouvé une faiblesse au niveau de TKIP
Non plus. Comme nous l'avons vu précédemment, et de l'aveu même de l'auteur, la plupart des implémentations de WPA disponibles sur le marché proposent AES-CCMP et ne sont plus vulnérables à cette attaque si c'est ce dernier qui est choisi comme algorithme de chiffrement. Ce qui veut dire que WPA ne signifie pas chiffrement TKIP.
la faiblesse principale de WEP était la faiblesse de l'algorithme utilisé pour générer le checksum.
Certainement pas. La faiblesse du CRC32 utilisé dans WEP est clairement une faille qui est exploitée avec brio dans l'attaque chopchop. Mais c'est loin d'être la vulnérabilité la plus intéressante, et surtout pas celle qui permet de récupérer des clés WEP. Quand on parle de faiblesses principales de WEP, je pense plus à des choses comme la récupération et le rejeu de keystream du fait des collisions d'IV, et surtout au problème des clés faibles de RC4 qui fournit les bases aux attaques genre FMS, son optimisation par Korek et enfin PTW.
En fait, c'est surtout les deux commentaires qui me font réagir dans ce billet. En effet, peu après sa mise en ligne, un certain mickael demandait :
A quand le wpa2 sur la livebox?
On comprend bien la motivation de la question. Si, comme le précise l'article, WPA est cassé, il est fort légitime de se demander quand le support WPA2 sera disponible pour les Livebox, qui ne le supportent pas à l'heure actuelle, pour autant que je sache. Or, on l'a vu précédemment, le passage à WPA2 n'est pas forcément nécessaire pour se protéger de cette attaque, puisqu'il suffit de chiffrer en AES-CCMP. Et la réponse de l'auteur est... intéressante...
L'entité R&D de France Télécom a déjà émis un document dans lequel la technique présentée succinctement ici est expliquée en profondeur, ainsi que les conséquences de son utilisation. Ce document a été déjà traité par la Direction de la Sécurité qui a évalué les risques associés et fait les recommandations. Enfin, ces recommandations ont été envoyées à toutes les équipes d'ingénierie concernées, incluant celle de la Livebox.
Genre on se dit chouette alors, un bon gros rapport bien technique, rédigé par des gens très compétents, qui a bien dû mettre les pendules à l'heure, et en particulier de dégager quelques recommandations en ce qui concerne les Livebox. Je veux dire, ce n'est pas comme s'il y avait des gens à FT R&D qui maîtrisent bien le sujet[8] et ne sont certainement pas passé à côté d'une recommandation aussi simple que faire du WPA en AES, déjà disponible sur une bonne partie des équipements sus-cités. Ben je ne sais pas ce qui c'est passé, mais manifestement, ce genre de proposition n'est pas arrivé jusqu'à ce blog puisque, même si ça commence bien, on en reste à du bien compliqué et surtout hors du contrôle de l'utilisateur :
Cependant, il faut garder à l'esprit que WPA2 n'est pas encore nécessaire pour cette faiblesse. En effet, la réduction de la durée de vie de la clé, à 2 minutes par exemple, suffit à rendre cette technique inopérante.
La suite rejoint l'article de Hakin9 :
De plus, il faut également savoir que WPA2, basé sur l'algorithme de chiffrement AES, est très gourmand en processeur et par conséquent il lui faut une unité de calcul dédiée, autrement dit, un nouveau hardware Livebox dans notre cas.
Fail. Méga fail même puisqu'il est est démenti par les fonctionnalités offertes par les Livebox déployées puisque d'après ce qu'on me dit[9] et ce que je lis, les Sagem supportent AES, ainsi que les modèles plus récents.
Si le département Livebox décide d'initier cette approche de mise à jour matériel, il faudra encore que le nouveau hardware soit construit et testé. Sans avoir de réponse officielle, je doute que ce soit pour 2008.
Ben manifestement, ce ne sera pas trop la peine, puisque AES est déjà supporté, depuis un petit moment maintenant. Et comme le reste, c'est du software, une simple mise à jour de firmware devrait pouvoir amener du WPA2 sur les Livebox, à part si j'ai loupé un affreux détail. Genre la bonne volonté du fournisseur par exemple...
Voilà. Cet article et ce billet sont les impeccables miroirs de pas mal de conneries qu'on a pu trouver, et qu'on trouve encore de fait, sur ces histoire de brute-force de PSK et de faille TKIP. Non, WPA ne veut pas dire PSK + TKIP. À l'inverse, casser de la PSK ou du TKIP ne veut pas dire casser WPA. Ce genre d'approximation est d'autant plus dommageable qu'elle laisse des gens dans des configurations vulnérables quand WPA2 ne leur est pas offert alors qu'ils pourraient se protéger efficacement (cf. juste au-dessus), mais surtout qu'elle laisse à penser qu'un simple passage à WPA2 les protègera alors que c'est faux.
En effet, le problème des PSK faibles touche WPA2 de la même manière que WPA pour une bonne et simple raison : le mécanisme d'authentification est le même. De plus, même si son support n'est pas obligatoire dans 802.11i, une écrasante majorité des implémentations WPA2 supportent TKIP et sont donc vulnérables à l'attaque de Beck et Tews quand elle permettent son utilisation, de la même manière qu'une implémentation WPA. Comme je vous le disais dans un autre billet, WPA est en fait basé sur un draft de 802.11i, et les différences avec WPA2 sont tellement ténues que, tant qu'à faire des raccourcis, on en ferait un bien meilleur que tout ce qu'on a lu avant en affirmant que c'est la même chose...
Mais bon. J'ai quand même réussi à finir mon café, une bonne chose étant donné que c'était la dernière capsule. Ce qui me ramène à des considérations bien plus importantes : planifier un réapprovisionnement en carburant...
Et pour finir sur un bon gros coup de mauvaise foi, je vous propose la minute de Maître Capelo. D'abord, on notera que pallier, avec deux l[10], est un verbe transitif et qu'on écrit donc, par exemple, "pour pallier ces carences". Ensuite, le mot apocryphe ne veut pas dire obsolète, en tout cas pas plus qu'il ne désigne un dieu égyptien ou un personnage de Stargate SG-1. Sa définition est en effet la suivante :
- Que l’église ne tient pas pour canonique.
- (Par extension) Se dit des écrivains dont l’autorité est suspecte, des livres, des histoires dont l’authenticité n’est pas établie.
On a donc un peu mal à comprendre en quoi une annonce quelconque pourrait rendre "WPA apocryphe".
Notes
[1] Juste ces écrits précis...
[2] Surtout si on considère qu'un caractère ASCII est codé sur 7 bits...
[3] Entres les codes 32 et 126.
[4] J'ai un Zaurus SL-C3k qui utilise ça avec bonheur sur un XScale à 400MHz, et j'avais un Pentium 233MMX qui en faisait autant sans broncher...
[5] Les fameuses PPK.
[6] L'exemple n'est pas anodin, comme on pourra le voir plus bas...
[7] Ce n'est pas le cas de toutes les Livebox, mais c'est vrai pour les plus récentes.
[8] Je vous laisse chercher ceux qui ont fait des publications intéressantes en sécurité Wi-Fi...
[9] Je ne suis pas abonné Orange, je n'ai pas vérifier moi-même, mais c'est confirmé par des amis.
[10] J'ai fait déjà le search and replace qui va bien sur l'intégralité du blog :)