A partir desta página wiki :

O WPA e o WPA2 usam chaves derivadas de um handshake EAPOL para criptografar o tráfego. A menos que todos os quatro pacotes de handshake estejam presentes na sessão que você está tentando descriptografar, o Wireshark não poderá descriptografar o tráfego. Você pode usar o eapol do filtro de exibição para localizar pacotes EAPOL em sua captura.

Notei que a descriptografia funciona com (1, 2, 4) também, mas não com (1, 2, 3). Tanto quanto sei, os dois primeiros pacotes são suficientes, pelo menos para o tráfego unicast. Alguém pode explicar exatamente como o Wireshark lida com isso, em outras palavras, por que apenas a sequência anterior funciona, dado que o quarto pacote é apenas um reconhecimento? Além disso, é garantido que o (1, 2, 4) funcionará sempre quando (1, 2, 3, 4) funcionar?

Caso de teste

Este é o handshake compactado com gzip (1, 2, 4) e um ARPpacote criptografado (SSID :, SSIDsenha :) passwordna base64codificação:

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

Decodifique com:

$ base64 -d | gunzip > handshake.cap

Execute tsharkpara verificar se ele descriptografou corretamente o ARPpacote:

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

Deve imprimir:

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

As trocas EAPOL também são usadas para renovar as chaves temporais. As novas chaves são instaladas no suplicante após o envio de 4/4 e instaladas no autenticador quando ele recebe 4/4 [1]. Se o Wireshark precisar manipular o rekeying corretamente, ele deverá usar as chaves somente após a leitura do pacote 4/4 no quadro, pois os pacotes ainda poderão estar fluindo durante o rekeying (mesmo no caso em que não devem, por causa do buffer)

Para o primeiro 4WHS, não é possível esperar por 4/4, mas é perfeitamente compreensível que eles tenham sido preguiçosos em implementá-lo. 3/4 ainda é necessário, pois contém chaves de grupo (mesmo que você não esteja interessado nelas, mas saiba que não verá solicitações de ARP do AP ou de um cliente para o qual você não faz parte do seu 4WHS) e chaves de gerenciamento. Você também pode pular 3/4, mas não tem confirmação de que a troca foi bem-sucedida, pois 3/4 é usado para verificar se o Autenticador conhece o PMK.

[1] Observe que, com o esquema atual, se a mensagem 4/4 for perdida, o suplicante começará a usar a nova chave e o autenticador ainda usará a chave antiga. O reenvio de 3/4 criptografado com a chave antiga não ajudará. . Esse problema, entre muitos outros com o WPA2, é solucionado no mais recente padrão 802.11 2012, mantendo duas chaves em paralelo.

Todas as informações necessárias para construir o PTK são trocadas nas etapas 1 e 2. Isso deve ser suficiente para descriptografar o tráfego unicast.

Sem a etapa 3, você não terá o GTK, portanto, descriptografar multicast / broadcast não será possível.

A etapa 4 não é realmente necessária para descriptografar o tráfego de captura, mas se não houver uma etapa 4, o cliente / ponto de acesso não começará a usar a criptografia. O Wireshark pode desativar isso antes de tentar descriptografar os dados também.

Bem, obviamente a documentação do WireShark está errada. :-)

Saindo da documentação aqui :

• Após o EAPOL 1 e 2, os dois lados conhecem a chave temporal que será usada para descriptografar o tráfego.
• A terceira mensagem é prova de que os dois lados conhecem a chave temporal e indica que o autenticador (a estação base) está pronto para começar a usar a chave temporal.
• A quarta mensagem aciona a troca do PMK configurado antes do EAPOL para a chave temporal derivada no EAPOL

Então, com isso, faz sentido. O WireShark não precisa da mensagem 3 para nada. Ele conhece as chaves após as mensagens 1 e 2, mas aguarda para começar a usá-las para descriptografar o tráfego até depois de receber a mensagem 4.

Não há garantias para nada na vida, especialmente o comportamento do software livre, mas é uma aposta razoável que não haverá um requisito para que a mensagem 3 esteja presente para o WireShark descriptografar a sessão.

Isso não explica por que, mas citando o-ng airdecap documentação de qualquer maneira,

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.