Da questa pagina wiki :

WPA e WPA2 utilizzano chiavi derivate da una stretta di mano EAPOL per crittografare il traffico. A meno che tutti e quattro i pacchetti di handshake non siano presenti per la sessione che stai tentando di decifrare, Wireshark non sarà in grado di decifrare il traffico. È possibile utilizzare il filtro di visualizzazione eapol per individuare i pacchetti EAPOL nell'acquisizione.

Ho notato che la decrittazione funziona anche con (1, 2, 4), ma non con (1, 2, 3). Per quanto ne so, i primi due pacchetti sono sufficienti, almeno per quanto riguarda il traffico unicast. Qualcuno può spiegare esattamente in che modo Wireshark gestisce questo, in altre parole perché funziona solo la sequenza precedente, dato che il quarto pacchetto è solo un riconoscimento? Inoltre, è garantito che (1, 2, 4) funzionerà sempre quando (1, 2, 3, 4) funziona?

Caso di prova

Questa è la stretta di mano gzip (1, 2, 4) e un ARPpacchetto criptato (SSID :, SSIDpassword :) passwordnella base64codifica:

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

Decodifica con:

$ base64 -d | gunzip > handshake.cap

Esegui tsharkper vedere se decodifica correttamente il ARPpacchetto:

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

Dovrebbe stampare:

  1 0.000000 D-Link_a7: 8e: b4 -> HonHaiPr_22: 09: b0 Chiave EAPOL
  2 0.006997 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Chiave EAPOL
  3 0.038137 HonHaiPr_22: 09: b0 -> D-Link_a7: 8e: b4 Chiave EAPOL
  4 0.376050 ZyxelCom_68: 3a: e4 -> HonHaiPr_22: 09: b0 ARP 192.168.1.1 è a 00: a0: c5: 68: 3a: e4

Gli scambi EAPOL sono anche usati per rinnovare le chiavi temporali. Le nuove chiavi vengono installate sul Supplicant dopo che ha inviato 4/4 e vengono installate sull'Autenticator quando riceve 4/4 [1]. Se Wireshark deve gestire correttamente la ripetizione della riproduzione, deve utilizzare le chiavi solo dopo aver letto il pacchetto 4/4 nel frame, poiché i pacchetti potrebbero continuare a fluire durante la ripetizione della riproduzione (anche nel caso in cui non dovrebbero, a causa del buffering)

Per i primi 4WHS, non è possibile attendere 4/4, ma è perfettamente comprensibile che fossero solo pigri per implementarlo. 3/4 è ancora necessario in quanto contiene chiavi di gruppo (anche se non ti interessano, ma sappi che non vedrai richieste ARP dall'AP o da un client per il quale non hai parte dei suoi 4WHS) e chiavi di gestione. Puoi anche saltare 3/4, ma poi non hai alcuna conferma che lo scambio è andato a buon fine, perché 3/4 viene utilizzato per verificare che l'Autenticatore conosca il PMK.

[1] Notare che con lo schema corrente, se il messaggio 4/4 viene perso, il supplicant ha iniziato a utilizzare la nuova chiave e l'autenticatore utilizza ancora la vecchia chiave e rinviare 3/4 crittografati con la vecchia chiave non aiuterà . Questo problema, tra molti altri con WPA2, viene risolto nell'ultimo standard 802.11 2012 mantenendo due chiavi in ​​parallelo.

Tutte le informazioni necessarie per costruire il PTK vengono scambiate nei passaggi 1 e 2. Ciò dovrebbe essere sufficiente per decrittografare il traffico unicast.

Senza il passaggio 3, non avrai la GTK, quindi non sarà possibile decodificare il multicast / broadcast.

Il passaggio 4 non è realmente necessario per decrittografare il traffico di acquisizione, ma se non è presente un passaggio 4, il client / AP non inizierà a utilizzare la crittografia. Wireshark potrebbe staccarsene prima di provare a decifrare anche i dati.

Bene, ovviamente la documentazione di WireShark è sbagliata. :-)

Andando fuori dalla documentazione qui :

• Dopo EAPOL 1 e 2 entrambe le parti conoscono la chiave temporale che verrà utilizzata per decrittografare il traffico.
• Il terzo messaggio dimostra che entrambe le parti conoscono la chiave temporale e indica che l' Autenticatore (la stazione base) è pronto per iniziare a utilizzare la chiave temporale.
• Il quarto messaggio attiva il passaggio dal PMK impostato prima di EAPOL alla chiave temporale derivata in EAPOL

Quindi, con ciò, ha senso. WireShark non ha bisogno del messaggio 3 per nulla. Conosce le chiavi dopo i messaggi 1 e 2, ma attende di iniziare a usarle per decrittografare il traffico fino a quando non riceve il messaggio 4.

Non ci sono garanzie per nulla nella vita, in particolare il comportamento del software libero, ma è ragionevole scommettere che non sarà necessario che il messaggio 3 sia presente affinché WireShark decifri la sessione.

Questo non spiega perché, ma citando comunque la documentazione di 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.