46

I'm trying to learn how ephemeral keys in WPA2 4-way handshake are derived.

Starting from 4 EAPOL packets sniffing, I successfully derived PMK and PTK reading ANonce, SNonce, and knowing ASCII-PSK and the SSID.

From PTK I derived, by splitting it, the KCK (128bit), the KEK (128bit), TK for ENC (128bit) and the TK for MIC (128bit).

I'm stuck in a GTK derivation.

If I understood correctly, the GTK is transmitted encrypted from AP to ST in WPA Key Data field using the chiper suite described in first field of Key Information, in my case "AES Cipher.

In WPA2 AES is used in CTR mode for confidentiality, so i tried to decrypt the Key Data using OpenSSL, using KEK as key and filed Key IV as IV. I obtain 6c 1b 11 38 1f 8e 01 ee e1 d0 7b [...] from decryption, but reading the IEEE 802.11 I saw that the first Key Data's octect in EAPOL Key Frame is Type and should be0xdd, so decryption fails.

What's wrong?

spazio dati
  • 561
  • 3
  • 4

2 Answers2

1

It seems using key decryption found in OpenSSL isn't really going to do it. If you are using a Linux box that has apt-get you can apt-get install pyrit, which is designed to crack WPA2 using various techniques. Even if it doesn't crack, you will get a better idea how a cracking application like this works simply by typing the command followed by the -h option.

Julia
  • 11
  • 4
-4

At minimum you need to have the preshared key/wireless password as well as have captured the EAPOL packets between the router and Device B to decrypt the packets.

With AES and PBKDF2 used in WPA and WPA2, they are designed to not be able to be decripted without the key/password.

Cracking the key is designed to be infeasible on consumer equipment for a very long time.

MikeP
  • 1,159
  • 7
  • 12
  • 1
    How AES and PBKDF2 is implemented in WPA and WPA2 is not what he/she asked. The fact that it was created to be implausible to be cracked by bruteforce on consumer-grade equipment is not what he/she asked. Hence, this answer makes no sense in relation to the question. – Yokai Oct 31 '16 at 07:01
  • Dealing with intelligence agency budgets and hardware is beyond the scope of stackexchange, thus one could assume that they don't have such budget nor money, thus the assumption that consumer equipment is relevant. – MikeP Oct 31 '16 at 20:28
  • 1
    It is possible that the OP may be looking into learning the guts of key derivation to locate an unknown zero day exploit for bug bounties. Actually cracking keys isn't effective any longer but if one can find exploits in key processing/handling, and bypass having to crack any keys, this would be a worthy cause for learning me thinks. – Yokai Nov 01 '16 at 07:14
  • @Yokai, This site is not for that. "IT Security Stack Exchange is for Information Security professionals to discuss _protecting_ assets from threats and vulnerabilities..."; "questions on the deeper aspects of _cryptography_ belong on crypto.SE." – MikeP Dec 04 '16 at 03:25
  • 1
    "IT Security Stack Exchange is for Information Security professionals to discuss protecting assets from threats and vulnerabilities..." I would say that securing assets is crypto's staple purpose... To declare the deeper aspects to not be fit for IT security professionals is disingenuous to the community. Stop trying to port off questions you don't know the answer to on others. – Yokai Dec 04 '16 at 06:04
  • @Yokai, so, what is the answer? – MikeP Dec 05 '16 at 01:24
  • If I had the answer to his question I would post it. I am merely explaining that the question is just as relevant here as anywhere else dealing with IT security. crypto.SE may have been a better place to post it, however this is a minor issue. – Yokai Dec 05 '16 at 04:03