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 ARP
paquet crypté (SSID :, SSID
mot de passe :) password
dans l' base64
encodage:
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 tshark
pour voir s'il déchiffre correctement le ARP
paquet:
$ 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
la source
Réponses:
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.
la source
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.
la source
Eh bien, évidemment, la documentation de WireShark est erronée. :-)
En sortant de la documentation ici :
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.
la source
Cela n'explique pas pourquoi, mais en citant de toute façon la documentation airdecap-ng ,
la source