L'ANonce che viene inviata nel primo messaggio non è in effetti protetta. Viene scelto a caso dall'AP e inviato in chiaro.
Il MIC nel secondo messaggio protegge solo SNonce e quindi non può essere usato per verificare ANonce. Tuttavia, al ricevimento di SNonce, l'AP calcolerà il PTK, in base a:
- l'ANONCE generato casualmente nel primo passaggio
- lo SNonce ricevuto dal richiedente (che non è stato ancora convalidato, poiché il MIC può essere convalidato solo con un PTK valido)
L'AP ha quindi calcolato il PTK e può facilmente verificare il MIC e quindi SNonce. Tuttavia, se il MIC esegue il check out, ne consegue che probabilmente l'ANonce non è stato falsificato , altrimenti il PTK calcolato dall'AP sarebbe diverso dal PTK calcolato dal supplicant (poiché utilizzavano un ANONCE diverso ), e il MIC non verrebbe controllato.
Gli stati standard (ovviamente), che nel caso in cui il MIC non controlli, il messaggio deve essere scartato. Quindi, mentre un avversario PU CAN modificare l'ANonce, questo porterà a una stretta di mano non riuscita.
Inoltre, come difesa aggiuntiva , ANonce viene di nuovo inviato in un EAPOL-Keyframe nel 3 ° messaggio dell'handshake (vedi immagine sotto). Il destinatario DEVE verificare che ANONCE in questo EAPOL-Keyframe protetto sia lo stesso di ANONCE che è stato inviato nel messaggio 1. Detto semplicemente, il messaggio 1 è ripetuto qui, ma ora con un MIC per proteggere l'ANONCE, proprio come l'hai suggerito dovrebbe essere fatto, tuttavia dato che non avevamo abbastanza informazioni per calcolare un MIC nel passaggio 1, è fatto qui al punto 3. (fonte: 802.11i standard )
Questo sito ha schermate di Wireshark che mostrano che l'ANonce viene inviato sia nel messaggio 1 e nel messaggio 3, e che il terzo messaggio contiene un MIC per proteggere l'ANONCE (comparativamente, il messaggio 2 contiene SNONCE e MIC per proteggerlo). Li ho copiati qui per scopi di archiviazione:
Messaggio 1:
Messaggio2: 
Messaggio3: 
Messaggio4: 