El ANONCE que se envía en el primer mensaje no está protegido. Es elegido al azar por el AP y se envía en texto claro.
El MIC en el segundo mensaje solo protege el SNonce, y por lo tanto no se puede utilizar para verificar el ANonce. Sin embargo, al recibir el SNonce, el AP calculará el PTK basándose en:
- el ANonce se generó aleatoriamente en el primer paso
- la SNonce que recibió del suplicante (que aún no se ha validado, ya que el MIC solo se puede validar con un PTK válido)
El AP ha calculado el PTK y puede verificar fácilmente el MIC y, por lo tanto, el SNonce. Sin embargo, si el MIC verifica, se sigue que el ANonce probablemente no se haya falsificado , de lo contrario, el PTK calculado por el AP sería diferente del PTK calculado por el suplicante (ya que utilizaron un ANonce diferente). ), y el MIC no se retiraría.
Los estados estándar (por supuesto), que en caso de que el MIC no se retire, el mensaje debe ser descartado. Entonces, mientras que un adversario PUEDE modificar el ANONce, llevará a un apretón de manos sin éxito.
Además, como defensa adicional , el ANonce se envía nuevamente en un fotograma clave de EAPOL en el tercer mensaje del saludo (vea la imagen a continuación). El destinatario DEBE verificar que el ANONCE en este fotograma clave protegido de EAPOL es el mismo que el ANonce que se envió en el mensaje 1. Dicho simplemente, el mensaje 1 se repite aquí, pero ahora con un MIC para proteger el ANonce, tal como lo sugirió debe hacerse, sin embargo, como no teníamos suficiente información para calcular un MIC en el paso 1, se realiza aquí en el paso 3. (fuente: 802.11i standard )
Este sitio web tiene capturas de pantalla de Wireshark que muestran que el ANONCE se envía a ambos. en el mensaje 1 y el mensaje 3, y que el tercer mensaje contiene un MIC para proteger el ANonce (de manera similar, el mensaje 2 contiene el SNonce y el MIC para protegerlo). Los he copiado aquí para fines de archivo:
Mensaje 1:
Mensaje2: 
Mensaje3: 
Mensaje4: 