Desde esta página wiki :

WPA y WPA2 usan claves derivadas de un protocolo de enlace EAPOL para cifrar el tráfico. A menos que los cuatro paquetes de protocolo de enlace estén presentes para la sesión que está intentando descifrar, Wireshark no podrá descifrar el tráfico. Puede usar el filtro de pantalla eapol para localizar paquetes EAPOL en su captura.

He notado que el descifrado también funciona con (1, 2, 4), pero no con (1, 2, 3). Hasta donde yo sé, los dos primeros paquetes son suficientes, al menos para lo que concierne al tráfico de unidifusión. ¿Alguien puede explicar exactamente cómo Wireshark trata eso, en otras palabras, por qué solo funciona la secuencia anterior, dado que el cuarto paquete es solo un reconocimiento? Además, ¿está garantizado que (1, 2, 4) siempre funcionará cuando (1, 2, 3, 4) funcione?

Caso de prueba

Este es el apretón de manos comprimido (1, 2, 4) y un ARPpaquete cifrado (SSID:, SSIDcontraseña :) passworden la base64codificación:

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

Decodificar con:

$ base64 -d | gunzip > handshake.cap

Ejecute tsharkpara ver si descifra correctamente el ARPpaquete:

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

Debería imprimir:

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

Los intercambios EAPOL también se utilizan para renovar las claves temporales. Las nuevas claves se instalan en el Suplicante después de que envía 4/4, y se instalan en el Autenticador cuando recibe 4/4 [1]. Si Wireshark debe manejar la reimpresión correctamente, solo debe usar las teclas después de leer el paquete 4/4 en el marco, porque los paquetes pueden seguir fluyendo durante la reimpresión (incluso en caso de que no lo hagan, debido al almacenamiento en búfer)

Para el primer 4WHS, no es posible esperar 4/4, pero es perfectamente comprensible que solo fueran flojos para implementarlo. 3/4 sigue siendo necesario ya que contiene claves de grupo (incluso si no está interesado en ellas, pero sepa que no verá las solicitudes ARP del AP o un cliente para el que no tiene parte de su 4WHS) y claves de administración. También puede omitir 3/4, pero no tiene confirmación de que el intercambio se realizó correctamente, ya que 3/4 se utiliza para verificar que el Autenticador conoce el PMK.

[1] Tenga en cuenta que con el esquema actual, si se pierde el mensaje 4/4, entonces el solicitante comenzó a usar la nueva clave, y el autenticador aún usa la clave anterior, y reenviar 3/4 cifrado con la clave anterior no ayudará. . Este problema, entre muchos otros con WPA2, se aborda en el último estándar 802.11 2012 manteniendo dos claves en paralelo.

Toda la información necesaria para construir el PTK se intercambia en los pasos 1 y 2. Esto debería ser suficiente para descifrar el tráfico de unidifusión.

Sin el paso 3, no tendrá el GTK, por lo que no será posible descifrar la multidifusión / transmisión.

El paso 4 no es realmente necesario para descifrar el tráfico de captura, pero si no hay un paso 4, el cliente / AP no comenzará a usar el cifrado. Wireshark puede desconectarse de esto antes de que también intente descifrar los datos.

Bueno, obviamente la documentación de WireShark está mal. :-)

Saliendo de la documentación aquí :

• Después de EAPOL 1 y 2, ambos lados conocen la clave temporal que se utilizará para descifrar el tráfico.
• El tercer mensaje es una prueba de que ambas partes conocen la clave temporal e indica que el Autenticador (la estación base) está listo para comenzar a usar la clave temporal.
• El cuarto mensaje activa el cambio de la configuración PMK antes de EAPOL a la clave temporal derivada en EAPOL

Entonces con eso, tiene sentido. WireShark no necesita el mensaje 3 para nada. Conoce las claves después de los mensajes 1 y 2, pero espera comenzar a usarlas para descifrar el tráfico hasta que reciba el mensaje 4.

No hay garantías para nada en la vida, especialmente el comportamiento del software libre, pero es una apuesta razonable que no habrá un requisito para que el mensaje 3 esté presente para que WireShark descifre la sesión.

Esto no explica por qué, pero citando el airdecap-ng documentación de todos modos,

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.