Pourquoi l'exploit KRACK n'a-t-il pas été découvert plus tôt?
D'après ce que j'ai lu, le problème est aussi simple que d'effectuer l'étape 3 d'une poignée de main en 4 étapes et les conséquences de l'exécution de cette étape plus d'une fois. Compte tenu de la complexité de ces types d'algorithmes, je suis quelque peu surpris qu'il soit si "simple" d'un concept.
Comment se fait-il qu'un système de cette complexité ait été conçu sans que personne ne réfléchisse à ce qui se passerait si vous exécutiez l'étape deux fois? Dans un certain sens, il semble que cela aurait dû être évident. Ce n'est pas vraiment un truc subtil, c'est un défaut relativement flagrant, ou du moins c'est l'impression que j'ai.
La spécification 802.11 qui décrit WPA2 (802.11i) est derrière un mur payant et a été conçue par quelques personnes clés de l'IEEE. La norme a été révisée par des ingénieurs, pas par des cryptographes. Les détails de la fonctionnalité (par exemple la retransmission) n'étaient pas largement connus ni étudiés par les professionnels de la sécurité.
Le cryptographe Matthew D Green a écrit n article de blog à ce sujet, et je pense que cette section le résume très bien:
L'un des problèmes de l'IEEE est que les normes sont très complexes et se font via un processus à huis clos de réunions privées. Plus important encore, même après coup, ils sont difficiles d'accès pour les chercheurs en sécurité ordinaires. Allez-y et google pour les spécifications IETF TLS ou IPSec - vous trouverez une documentation de protocole détaillée en haut de vos résultats Google. Maintenant, essayez Google pour les normes 802.11i. Je te souhaite bonne chance.
L'IEEE a fait quelques petites étapes pour atténuer ce problème, mais ce sont des conneries incrémentalistes hyper-timides. Il existe un programme IEEE appelé GET qui permet aux chercheurs d'accéder gratuitement à certaines normes (y compris 802.11), mais seulement après qu'elles ont été rendues publiques pendant six mois - par coïncidence, à peu près le même temps qu'il faut aux fournisseurs pour les incorporer irrévocablement dans leur matériel et Logiciel.
Dans un certain sens, il semble que cela aurait dû être évident.
Rappelez-vous Heartbleed, Shellshock, POODLE, TLS Triple Handshake attack, "goto fail", ...?
Avec le recul, la plupart de ces problèmes semblent être évidents et auraient pu être évités si les bonnes personnes avaient simplement regardé de plus près le bon moment au bon endroit. Mais, il n'y a qu'un nombre limité de personnes possédant la bonne expertise technique et celles-ci ont généralement beaucoup d'autres choses à faire aussi. S'il vous plaît, ne vous attendez pas à ce qu'ils soient parfaits.
Au lieu de se faire des illusions sur des normes parfaitement conçues, des logiciels sans bogues et des systèmes 100% sécurisés, il faut accepter que cela soit impossible à réaliser dans la pratique pour les systèmes complexes d'aujourd'hui. Pour atténuer cela, il faut se soucier davantage de la résilience et de la robustesse, c'est-à-dire rester en sécurité même si certaines parties se brisent en superposant la sécurité, ne pas faire entièrement confiance à quoi que ce soit et avoir des plans si quelque chose se brise.
L'article décrivant KRACK traite de ce problème même dans la section 6.6.
Quelques points: il y avait des ambiguïtés dans la spécification. Les preuves de spécification formelles sont également basées sur un modèle de spécification, et il y a des moments où ce modèle ne correspond pas à la spécification réelle, et encore moins aux implémentations basées sur cette spécification.