Perché l'exploit KRACK non è stato scoperto prima? [chiuso]

La specifica 802.11 che descrive WPA2 (802.11i) è dietro un paywall ed è stata progettata da alcuni individui chiave dell'IEEE. Lo standard fu esaminato da ingegneri, non da crittografi. I dettagli della funzionalità (ad esempio la ritrasmissione) non erano ampiamente conosciuti o studiati dai professionisti della sicurezza.

Il crittografo Matthew D Green ha scritto un post sul blog su questo argomento, e penso che questa sezione riassuma molto bene:

One of the problems with IEEE is that the standards are highly complex and get made via a closed-door process of private meetings. More importantly, even after the fact, they’re hard for ordinary security researchers to access. Go ahead and google for the IETF TLS or IPSec specifications — you’ll find detailed protocol documentation at the top of your Google results. Now go try to Google for the 802.11i standards. I wish you luck.

The IEEE has been making a few small steps to ease this problem, but they’re hyper-timid incrementalist bullshit. There’s an IEEE program called GET that allows researchers to access certain standards (including 802.11) for free, but only after they’ve been public for six months — coincidentally, about the same time it takes for vendors to bake them irrevocably into their hardware and software.

In some sense, it feels like this should have been obvious.

Ricordati di Heartbleed, Shellshock, POODLE, TLS Triple Handshake attack, "goto fail", ...?

Con il senno di poi, la maggior parte di questi problemi sembra essere ovvia e avrebbe potuto essere prevenuta se le persone giuste avessero appena dato un'occhiata più da vicino al momento giusto nel posto giusto. Ma c'è solo un numero limitato di persone con le giuste competenze tecniche e di solito hanno anche molte altre cose da fare. Per favore non aspettarti che siano perfetti.

Invece di avere illusioni sul fatto che gli standard siano perfettamente progettati, che il software sia privo di bug e che i sistemi siano sicuri al 100%, si dovrebbe accettare che ciò è impossibile da ottenere nella pratica per i sistemi complessi di oggi. Per mitigare questo si dovrebbe preoccupare di più della resilienza e della robustezza, cioè di stare al sicuro e al sicuro anche se alcune parti si rompono mettendo a rischio la sicurezza, non fidandosi completamente di nulla e avendo dei piani se qualcosa si rompe.

Il documento che descrive KRACK tratta questo stesso problema nella sezione 6.6.

Un paio di punti: c'erano delle ambiguità nelle specifiche. Anche le dimostrazioni formali delle specifiche si basano su un modello della specifica, e ci sono volte in cui quel modello non corrisponde alle specifiche effettive, molto meno la corrispondenza con le implementazioni basate su tale specifica.