Wireshark WPA handshake de 4 vias

Question

De esta página da wiki :

WPA and WPA2 use keys derived from an EAPOL handshake to encrypt traffic. Unless all four handshake packets are present for the session you're trying to decrypt, Wireshark won't be able to decrypt the traffic. You can use the display filter eapol to locate EAPOL packets in your capture.

Eu notei que a decodificação também funciona com (1, 2, 4), mas não com (1, 2, 3). Até onde eu sei, os dois primeiros pacotes são suficientes, menos para o que diz respeito ao tráfego unicast. Alguém pode por favor explicar exatamente como o Wireshark lida com isso, em outras palavras, por que o trabalho de sequência anterior, dado que o quarto pacote é apenas um reconhecimento? Além disso, é garantido que o (1, 2, 4) será sempre trabalho quando (1, 2, 3, 4) funciona?

Caso de teste

Este é o handshake com gzip (1, 2, 4) e um pacote ARP com criptografia (SSID: SSID , senha: password ) em base64 encoding:

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 tshark para ver se descriptografa corretamente o pacote ARP :

$ 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 EAPOL Key
  2   0.006997 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL Key
  3   0.038137 HonHaiPr_22:09:b0 -> D-Link_a7:8e:b4 EAPOL Key
  4   0.376050 ZyxelCom_68:3a:e4 -> HonHaiPr_22:09:b0 ARP 192.168.1.1 is at 00:a0:c5:68:3a:e4

    

Answer 1

As trocas de EAPOL também são usadas para renovar as chaves temporais. As novas chaves são instaladas no suplicante depois de enviar 4/4 e são instaladas no autenticador quando ele recebe 4/4 [1]. Se o Wireshark tiver que lidar corretamente com recodificadores, ele deve usar as chaves somente depois de ler o pacote 4/4 no quadro, porque os pacotes ainda podem estar fluindo durante a recriação (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 apenas preguiça de 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 ARP do AP ou de um cliente para o qual você não tem parte de suas 4WHS) e chaves de gerenciamento. Você pode pular 3/4 também, mas não tem confirmação de que a troca foi bem-sucedida, porque 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çou a usar a nova chave, e o autenticador ainda usa a chave antiga e reenvia 3/4 criptografado com a chave antiga não vai ajudar. Esse problema, entre muitos outros com o WPA2, é abordado no padrão 802.11 2012 mais recente, mantendo duas chaves em paralelo.

    

Answer 2

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 de unicast.

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

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 / AP não começará a usar a criptografia. O Wireshark pode desativar isso antes de tentar descriptografar os dados também.

    

Answer 3

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

Saindo da documentação aqui :

• Após o EAPOL 1 e 2, ambos os lados conhecem a chave temporal que será usada para descriptografar o tráfego.
• A terceira mensagem é a prova de que ambos os lados conhecem a chave temporal e indicam que o Autenticador (a estação base) está pronto para começar a usar a chave temporal.
• A quarta mensagem aciona o switch da configuração do PMK 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 espera para começar a usá-las para descriptografar o tráfego até receber a mensagem 4.

Não há garantias para nada na vida, especialmente o comportamento do software livre, mas é razoável apostar que não haverá exigência de que a mensagem 3 esteja presente para a WireShark descriptografar a sessão.

    

Answer 4

Isso não explica por que, mas citando a documentação do airdecap-ng 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.