Z tej strony wiki :

WPA i WPA2 używają kluczy pochodzących z uzgadniania EAPOL do szyfrowania ruchu. O ile nie są dostępne wszystkie cztery pakiety uzgadniania dla sesji, którą próbujesz odszyfrować, Wireshark nie będzie w stanie odszyfrować ruchu. Możesz użyć filtru wyświetlania eapol, aby zlokalizować pakiety EAPOL w twoim przechwytywaniu.

Zauważyłem, że deszyfrowanie działa również z (1, 2, 4), ale nie z (1, 2, 3). O ile wiem, dwa pierwsze pakiety są wystarczające, przynajmniej w odniesieniu do ruchu emisji pojedynczej. Czy ktoś może wyjaśnić dokładnie, jak sobie z tym radzi Wireshark, innymi słowy, dlaczego działa tylko poprzednia sekwencja, skoro czwarty pakiet jest tylko potwierdzeniem? Czy jest też zagwarantowane, że (1, 2, 4) zawsze będzie działać, gdy (1, 2, 3, 4) działa?

Przypadek testowy

To zgzipowany uścisk dłoni (1, 2, 4) i zaszyfrowany ARPpakiet (SSID :, SSIDhasło :) passwordw base64kodowaniu:

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

Dekoduj za pomocą:

$ base64 -d | gunzip > handshake.cap

Uruchom, tsharkaby sprawdzić, czy poprawnie odszyfrowuje ARPpakiet:

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

Powinien wydrukować:

  1 0,000000 D-Link_a7: 8e: b4 -> HonHaiPr_22: 09: b0 Klucz EAPOL
  2 0,006997 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Klucz EAPOL
  3 0,038137 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Klucz EAPOL
  4 0,376050 ZyxelCom_68: 3a: e4 -> HonHaiPr_22: 09: b0 ARP 192.168.1.1 jest o 00: a0: c5: 68: 3a: e4

Wymiana EAPOL służy również do odnawiania kluczy tymczasowych. Nowe klucze są instalowane w Dostawcy po wysłaniu 4/4 i są instalowane w Authenticator, gdy otrzymuje on 4/4 [1]. Jeśli Wireshark musi poprawnie obsługiwać ponowne generowanie klucza, musi korzystać z kluczy tylko po odczytaniu pakietu 4/4 w ramce, ponieważ pakiety mogą nadal przepływać podczas ponownego generowania klucza (nawet w przypadku, gdy nie powinny, ze względu na buforowanie)

W przypadku pierwszego 4WHS możliwe jest nie czekanie na 4/4, ale jest całkowicie zrozumiałe, że byli po prostu leniwi, aby go wdrożyć. 3/4 jest nadal konieczne, ponieważ zawiera klucze grupy (nawet jeśli nie jesteś nimi zainteresowany, ale wiesz, że nie zobaczysz żądań ARP od AP lub klienta, dla którego nie masz części jego 4WHS) i kluczy zarządzania. Możesz także pominąć 3/4, ale wtedy nie masz potwierdzenia, że ​​wymiana się powiodła, ponieważ 3/4 służy do sprawdzenia, czy Authenticator zna PMK.

[1] Zauważ, że przy obecnym schemacie, jeśli wiadomość 4/4 zostanie utracona, suplikant zaczął używać nowego klucza, a wystawca uwierzytelnienia nadal używa starego klucza, a ponowne przesłanie 3/4 zaszyfrowanego starym kluczem nie pomoże . Problem ten, między innymi w przypadku WPA2, został rozwiązany w najnowszym standardzie 802.11 2012 poprzez równoległe połączenie dwóch kluczy.

Wszystkie informacje niezbędne do zbudowania PTK są wymieniane w krokach 1 i 2. To powinno wystarczyć do odszyfrowania ruchu emisji pojedynczej.

Bez kroku 3 nie będziesz mieć GTK, więc odszyfrowanie multiemisji / emisji nie będzie możliwe.

Krok 4 nie jest tak naprawdę konieczny do odszyfrowania przechwytywania ruchu, ale jeśli nie ma kroku 4, klient / AP nie zacznie używać szyfrowania. Wireshark może to wyłączyć, zanim spróbuje również odszyfrować dane.

Cóż, oczywiście dokumentacja WireShark jest błędna. :-)

Wyjście z dokumentacji tutaj :

• Po EAPOL 1 i 2 obie strony znają klucz czasowy, który będzie używany do odszyfrowywania ruchu.
• Trzeci komunikat jest dowodem na to, że obie strony znają klucz czasowy i wskazuje, że Authenticator (stacja bazowa) jest gotowy do rozpoczęcia korzystania z klucza czasowego.
• Czwarty komunikat uruchamia przejście z PMK skonfigurowanego przed EAPOL-em do klucza czasowego wyprowadzonego w EAPOL-u

Ma to więc sens. WireShark do niczego nie potrzebuje komunikatu 3. Zna klucze po wiadomościach 1 i 2, ale czeka na ich użycie do odszyfrowania ruchu, dopóki nie otrzyma wiadomości 4.

W życiu nie ma żadnych gwarancji, w szczególności zachowania wolnego oprogramowania, ale rozsądne jest założenie, że nie będzie wymogu obecności komunikatu 3 w celu odszyfrowania sesji przez WireShark.

To nie wyjaśnia dlaczego, ale cytowanie z airdecap-ng dokumentacji anyways,

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.