De cette page wiki :

WPA et WPA2 utilisent des clés dérivées d'une négociation EAPOL pour crypter le trafic. À moins que les quatre paquets de négociation ne soient présents pour la session que vous essayez de déchiffrer, Wireshark ne sera pas en mesure de déchiffrer le trafic. Vous pouvez utiliser le filtre d'affichage eapol pour localiser les paquets EAPOL dans votre capture.

J'ai remarqué que le déchiffrement fonctionne aussi avec (1, 2, 4), mais pas avec (1, 2, 3). Pour autant que je sache, les deux premiers paquets sont suffisants, du moins pour ce qui concerne le trafic unicast. Quelqu'un peut-il expliquer exactement comment Wireshark gère cela, en d'autres termes pourquoi seule la séquence précédente fonctionne, étant donné que le quatrième paquet n'est qu'un accusé de réception? De plus, est-il garanti que (1, 2, 4) fonctionnera toujours lorsque (1, 2, 3, 4) fonctionnera?

Cas de test

Il s'agit de la poignée de main gzippée (1, 2, 4) et d'un ARPpaquet crypté (SSID :, SSIDmot de passe :) passworddans l' base64encodage:

H4sICEarjU8AA2hhbmRzaGFrZS5jYXAAu3J400ImBhYGGPj / n4GhHkhfXNHr37KQgWEqAwQzMAgx
6HkAKbFWzgUMhxgZGDiYrjIwKGUqcW5g4Ldd3rcFQn5IXbWKGaiso4 + RmSH + H0MngwLUZMarj4Rn
S8vInf5yfO7mgrMyr9g / Jpa9XVbRdaxH58v1fO3vDCQDkCNv7mFgWMsAwXBHMoEceQ3kSMZbDFDn
ITk1gBnJkeX / GDkRjmyccfus4BKl75HC2cnW1eXrjExNf66uYz + VGLl + snrF7j2EnHQy3JjDKPb9
3fOd9zT0TmofYZC4K8YQ8IkR6JaAT0zIJMjxtWaMmCEMdvwNnI5PYEYJYSTHM5EegqhggYbFhgsJ
9gJXy42PMx9JzYKEcFkcG0MJULYE2ZEGrZwHIMnASwc1GSw4mmH1JCCNQYEF7C7tjasVT + 0 / J3LP
gie59HFL + 5RDIdmZ8rGMEldN5s668eb / tp8vQ + 7OrT9jPj / B7425QIGJI3Pft72dLxav8BefvcGU
7 + kfABxJX + SjAgAA

Décoder avec:

$ base64 -d | gunzip > handshake.cap

Exécutez tsharkpour voir s'il déchiffre correctement le ARPpaquet:

$ tshark -r handshake.cap -o wlan.enable_decryption:TRUE -o wlan.wep_key1:wpa-pwd:password:SSID

Il devrait imprimer:

  1 0.000000 D-Link_a7: 8e: b4 -> HonHaiPr_22: 09: b0 Clé EAPOL
  2 0,006997 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Clé EAPOL
  3 0,038137 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Clé EAPOL
  4 0.376050 ZyxelCom_68: 3a: e4 -> HonHaiPr_22: 09: b0 ARP 192.168.1.1 est à 00: a0: c5: 68: 3a: e4

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 l'envoi de 4/4 et sont installées sur l'Authenticator lorsqu'il reçoit 4/4 [1]. Si Wireshark doit gérer correctement la recomposition, il ne doit utiliser les clés qu'après avoir lu le paquet 4/4 dans le cadre, car les paquets peuvent toujours circuler pendant la recomposition (même s'ils ne le devraient pas, en raison de la mise en mémoire tampon)

Pour le premier 4WHS, il n'est pas possible d'attendre le 4/4, mais il est parfaitement compréhensible qu'ils étaient juste paresseux pour le mettre en œuvre. 3/4 est toujours nécessaire car il contient des clés de groupe (même si cela ne vous intéresse pas, mais sachez que vous ne verrez pas les demandes ARP de l'AP ou d'un client pour lequel vous n'avez aucune partie de ses 4WHS) et des clés de gestion. Vous pouvez également ignorer 3/4, mais vous n'avez aucune confirmation que l'échange a réussi, car 3/4 est utilisé pour vérifier que l'authentificateur connaît le PMK.

[1] Notez qu'avec le schéma actuel, si le message 4/4 est perdu, alors le demandeur a commencé à utiliser la nouvelle clé, et l'authentificateur utilise toujours l'ancienne clé, et renvoyer 3/4 crypté avec l'ancienne clé n'aidera pas . Ce problème, parmi tant d'autres avec WPA2, est résolu dans la dernière norme 802.11 2012 en gardant 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 être suffisant pour décrypter le trafic unicast.

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

L'étape 4 n'est pas vraiment nécessaire pour déchiffrer le trafic de capture, mais s'il n'y a pas d'étape 4, le client / AP ne commencera pas à utiliser le chiffrement. Wireshark peut également désactiver cette fonctionnalité avant d'essayer de décrypter les données.

Eh bien, évidemment, la documentation de WireShark est erronée. :-)

En sortant de la documentation ici :

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

Donc avec ça, ça a du sens. WireShark n'a besoin du message 3 pour rien. Il connaît les clés après les messages 1 et 2, mais il attend de commencer à les utiliser pour déchiffrer le trafic jusqu'à ce qu'il reçoive le message 4.

Il n'y a aucune garantie à quoi que ce soit dans la vie, en particulier le comportement des logiciels libres, mais il y a fort à parier qu'il ne sera pas nécessaire que le message 3 soit présent pour que WireShark déchiffre la session.

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

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.