Sto indagando sull'attacco KRACK basato sul paper pubblicato e sul loro video di YouTube.
In gran parte comprendo gli attacchi proposti nel documento, eccetto il completamento delle strette di mano da parte dell'autenticatore per quanto riguarda i seguenti 3 aspetti. Purtroppo non ho potuto ottenere come / perché questo è fatto sulla base del documento. Apprezzerei molto ogni idea o suggerimento su uno qualsiasi di questi punti :).
1) Secondo la mia comprensione, il loro attacco Anrdoid è quello mostrato nella figura 5 del loro articolo. Affermano che Android ha installato un All-Zero-Key quando Msg3 viene prima ritardato e quindi due versioni di Msg3 vengono inviate al client.
- Ho ragione che possono decifrare o riprodurre solo un frame? Ecco come appare il loro attacco proposto in Fig. 5 e Fig. 6 per questi casi. Sarebbe di qualche utilità se il bug All-Zero-Key non fosse installato?
- Quando un ist All-Zero-Key ist installato sul lato client in questo momento, questo sarebbe sufficiente. Dovrebbe "cifrare" tutti i frame di dati con la Zero-Key, ma avere i flag impostati che mostrano che la crittografia sarebbe sul posto. Presumo, il client dovrebbe anche impostare un ID chiave corrispondente alla chiave di sessione negoziata? Tuttavia, questa chiave di sessione sarebbe quella "corretta" impostata sul lato dell'autenticatore. Quindi perché ogni AP accetta traffico che non è adeguatamente protetto? Nei loro video di Youtube abilitano esplicitamente l'inoltro dei pacchetti, ma non capisco come dovrebbe funzionare visto che non hanno accesso alla rete da soli? L'AP dovrebbe rifiutare tutti questi frame codificati erroneamente?
2) In Fig. 4 (e presumo che farebbero lo stesso in Fig. 5 e 6?), lo stage 4 dovrebbe terminare l'handshake sul lato dell'autenticatore. C'è qualche motivo specifico per trasmettere Enc_ptk (Msg4 (r + 2)) o perché viene trasmesso per primo? Come solo Msg4 (r + 1) è accolto e funziona solo se sono accettati i vecchi contatori di riproduzione non riesco a capire perché questo è fatto.
3) FT-Handshake in Fig. 9. Penso che alla ricezione del replayed ReassoResp nella fase 3 ricevuta dal client, il client dovrebbe anche reinstallare il suo PTK. C'è qualche ragione per cui questo è stato gestito in modo diverso rispetto alla stretta di mano a 4 vie o si sono dimenticati di disegnare una scatola lì? (Non sono riuscito a trovare un paragrafo corrispondente nello standard, ma avrei potuto trascurare qualcosa?)