Von dieser Wiki-Seite :

WPA und WPA2 verwenden Schlüssel, die von einem EAPOL-Handshake abgeleitet sind, um den Datenverkehr zu verschlüsseln. Solange nicht alle vier Handshake-Pakete für die Sitzung vorhanden sind, die Sie entschlüsseln möchten, kann Wireshark den Datenverkehr nicht entschlüsseln. Sie können den Anzeigefilter eapol verwenden, um EAPOL-Pakete in Ihrer Erfassung zu lokalisieren.

Ich habe bemerkt, dass die Entschlüsselung auch mit (1, 2, 4) funktioniert, aber nicht mit (1, 2, 3). Soweit ich weiß, reichen die ersten beiden Pakete zumindest für den Unicast-Verkehr. Kann jemand bitte genau erklären, wie Wireshark damit umgeht, mit anderen Worten, warum funktioniert nur die vorherige Sequenz, da das vierte Paket nur eine Bestätigung ist? Ist auch garantiert, dass (1, 2, 4) immer funktioniert, wenn (1, 2, 3, 4) funktioniert?

Testfall

Dies ist der gzippte Handshake (1, 2, 4) und ein verschlüsseltes ARPPaket (SSID :, SSIDpassword :) passwordbei der base64Codierung:

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

Dekodieren mit:

$ base64 -d | gunzip > handshake.cap

Führen tsharkSie Folgendes aus, um zu überprüfen, ob das ARPPaket korrekt entschlüsselt wurde :

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

Es sollte drucken:

  1 0,000000 D-Link_a7: 8e: b4 -> HonHaiPr_22: 09: b0 EAPOL-Schlüssel
  2 0,006997 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 EAPOL-Schlüssel
  3 0.038137 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 EAPOL-Schlüssel
  4 0.376050 ZyxelCom_68: 3a: e4 -> HonHaiPr_22: 09: b0 ARP 192.168.1.1 ist um 00: a0: c5: 68: 3a: e4

EAPOL-Vermittlungen werden auch verwendet, um die temporären Schlüssel zu erneuern. Die neuen Schlüssel werden nach dem Senden von 4/4 auf dem Supplicant installiert und beim Empfang von 4/4 auf dem Authenticator [1] installiert. Wenn Wireshark die Neuverschlüsselung korrekt handhaben muss, darf es die Schlüssel erst nach dem Lesen des 4/4-Pakets im Frame verwenden, da möglicherweise noch Pakete während der Neuverschlüsselung fließen (auch wenn dies aufgrund der Pufferung nicht der Fall sein sollte).

Beim ersten 4WHS ist es möglich, nicht auf 4/4 zu warten, aber es ist durchaus verständlich, dass die Implementierung nur faul war. 3/4 ist weiterhin erforderlich, da es Gruppenschlüssel enthält (auch wenn Sie nicht daran interessiert sind, aber wissen, dass Sie keine ARP-Anforderungen vom AP oder einem Client sehen, für den Sie keinen Teil des 4WHS haben) und Verwaltungsschlüssel. Sie können auch 3/4 überspringen, haben aber keine Bestätigung, dass der Austausch erfolgreich war, da mit 3/4 überprüft wird, ob der Authentifikator das PMK kennt.

[1] Beachten Sie, dass mit dem aktuellen Schema, wenn die 4/4-Nachricht verloren geht, der Supplicant den neuen Schlüssel verwendet und der Authentifikator weiterhin den alten Schlüssel verwendet und das erneute Senden von mit dem alten Schlüssel verschlüsselten 3/4 nicht hilft . Dieses Problem, unter anderem mit WPA2, wird im neuesten 802.11 2012-Standard behoben, indem zwei Schlüssel parallel gehalten werden.

Alle zum Aufbau des PTK erforderlichen Informationen werden in den Schritten 1 und 2 ausgetauscht. Dies sollte ausreichen, um den Unicast-Verkehr zu entschlüsseln.

Ohne Schritt 3 ist die GTK nicht verfügbar, sodass Multicast / Broadcast nicht entschlüsselt werden kann.

Schritt 4 ist nicht wirklich erforderlich, um den erfassten Datenverkehr zu entschlüsseln. Wenn jedoch kein Schritt 4 ausgeführt wird, verwendet der Client / AP die Verschlüsselung nicht. Wireshark kann dies deaktivieren, bevor es versucht, Daten ebenfalls zu entschlüsseln.

Nun, offensichtlich ist die WireShark-Dokumentation falsch. :-)

Abgehend die Dokumentation hier :

• Nach EAPOL 1 und 2 kennen beide Seiten den Zeitschlüssel, der zum Entschlüsseln des Datenverkehrs verwendet wird.
• Die dritte Nachricht ist ein Beweis dafür, dass beide Seiten den Zeitschlüssel kennen, und zeigt an, dass der Authentifikator (die Basisstation) bereit ist, den Zeitschlüssel zu verwenden.
• Die vierte Nachricht löst den Wechsel von der vor dem EAPOL eingerichteten PMK zu dem im EAPOL abgeleiteten Zeitschlüssel aus

Das macht also Sinn. WireShark benötigt für nichts Nachricht 3. Er kennt die Schlüssel nach den Nachrichten 1 und 2, wartet jedoch, bis er die Nachricht 4 empfangen hat, damit, den Datenverkehr zu entschlüsseln.

Es gibt keine Garantie für irgendetwas im Leben, insbesondere für das Verhalten freier Software, aber es ist eine vernünftige Wette, dass keine Nachricht 3 vorhanden sein muss, damit WireShark die Sitzung entschlüsseln kann.

Dies erklärt nicht, warum, aber trotzdem aus der Dokumentation der Flugsicherung zu zitieren,

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.