Les échanges EAPOL sont également utilisés pour renouveler les clés temporelles. Les nouvelles clés sont installées sur le Supplicant après qu'il ait envoyé 4/4, et sont installées sur l'Authentificateur lorsqu'il reçoit 4/4 [1]. Si Wireshark doit gérer correctement le renouvellement des clés, il ne doit utiliser les clés qu'après avoir lu le paquet 4/4 dans la trame, car les paquets peuvent continuer à circuler pendant le renouvellement des clés (même dans les cas où ils ne devraient pas, à cause de la mise en mémoire tampon).

Pour le premier 4WHS, ne pas attendre le 4/4 est possible, mais il est parfaitement compréhensible qu'ils aient été simplement paresseux pour l'implémenter. Le 3/4 est toujours nécessaire car il contient les clés de groupe (même si elles ne vous intéressent pas, mais sachez que vous ne verrez pas les requêtes ARP de l'AP ou d'un client pour lequel vous n'avez aucune partie de son 4WHS) et les clés de gestion. Vous pouvez également sauter les 3/4, mais vous n'avez alors aucune confirmation que l'échange a réussi, car les 3/4 sont utilisés pour vérifier que l'Authentificateur connaît la PMK.

[1] Notez qu'avec le schéma actuel, si le message 4/4 est perdu, alors le suppliant a commencé à utiliser la nouvelle clé, et l'authentificateur utilise toujours l'ancienne clé, et renvoyer 3/4 chiffré avec l'ancienne clé ne sera pas utile. Ce problème, parmi de nombreux autres avec WPA2, est résolu dans la dernière norme 802.11 2012 en conservant deux clés en parallèle.

Toutes les informations nécessaires à la construction du PTK sont échangées aux étapes 1 et 2. Cela devrait suffire pour décrypter le trafic unicast.

Sans l'étape 3, vous n'aurez pas le GTK, donc le décryptage du multicast/broadcast ne sera pas possible.

L'étape 4 n'est pas vraiment nécessaire pour décrypter le trafic de capture, mais s'il n'y a pas d'étape 4, le client/AP ne commencera pas à utiliser le cryptage. Wireshark peut s'en servir comme clé avant d'essayer de décrypter les données.

Eh bien, il est évident que la documentation de WireShark est erronée :-)

Sortir de la documentation aquí :

• Après EAPOL 1 et 2, les deux parties connaissent la clé temporelle qui sera utilisée pour décrypter le trafic.
• Le troisième message est la preuve que les deux parties connaissent la clé temporelle et indique que la Authentificateur (la station de base) est prêt à démarrer en utilisant la touche temporelle.
• Le quatrième message déclenche le passage de la PMK établie avant l'EAPOL à la clé temporelle dérivée dans l'EAPOL.

Donc avec ça, ça a du sens. WireShark n'a pas besoin du message 3 pour quoi que ce soit. Il connaît les clés après les messages 1 et 2, mais il attend de commencer à les utiliser pour décrypter le trafic après avoir reçu le message 4.

Il n'y a aucune garantie dans la vie, en particulier le comportement du logiciel libre, mais il est raisonnable de parier qu'il n'y aura pas besoin que le message 3 soit présent pour que WireShark puisse décrypter la session.

Cela n'explique pas pourquoi, mais en citant l'airdecap-ng documentation de toute façon,

WPA/WPA2 Requirements

The capture file must contain a valid four-way handshake. For this purpose having (packets 2 and 3) or (packets 3 and 4) will work correctly. In fact, you don't truly need all four handshake packets.