Understanding WPAWPA2 Pre-Shared-Key Cracking PDF
Understanding WPAWPA2 Pre-Shared-Key Cracking PDF
ins1gn1a.com/understanding-wpa-psk-cracking/
December 27,
2015
Intro
The few weaknesses inherent within the authentication handshake process for WPA/WPA2
PSKs have been known for a long time. This blog post does not serve anything that is new or
has not been previously seen in the wild or conference talks and actually references other
sites (such as RFCs) that can supply further information. It does, however, provide some
clarity in to what is actually performed during the authentication and thus cracking process,
but was mainly an exercise for me to learn how everything works at a lower level. Perhaps it
will be useful to someone else in the same scenario.
Overview
During the authentication process the supplicant (client) and authenticator (access point)
each attempt to prove that they independently know the pre-shared-key (`PSK`)
1/6
passphrase without disclosing the key directly. This is done by each encrypting a message
using the Pairwise-Master-Key (`PMK`) that they have generated, transmitting each way,
and then decrypting the message they've each received. The four-way handshake is used to
establish a new key called the Pairwise-Transient-Key (`PTK`), which is comprised of the
following concatenated data:
The result is then processed through a Pseudo-Random-Function (PRF). Another key that is
used for decrypting multicast traffic, named the Group-Temporal-Key, is also created during
this handshake process.
[!] At this point an attacker would have been able to intercept enough of the handshake to
perform a password cracking attack.
HMAC-SHA1 is the Pseudo Random Function used, whilst 4096 iterations of this function are
used to create the 256 bit PMK. The SSID is used as a salt for the resulting key, and of course
the PSK (passphrase in this instance) is used as the basis for this entire process.
2/6
The HMAC function used:
H(K XOR opad, H(K XOR ipad, passphrase))
Further information on HMAC-SHA1 from RFC2104 can be seen below, but is out of my
depth:
opad = 0x5C * B
ipad = 0x36 * B
(1) append zeros to the end of K to create a B byte string (e.g., if K is of length 20 bytes and B=64, then K
will be appended with 44 zero bytes 0x00)
(2) XOR (bitwise exclusive-OR) the B byte string computed in step (1) with ipad
(3) append the stream of data 'text' to the B byte string resulting from step (2)
(4) apply H to the stream generated in step (3)
(5) XOR (bitwise exclusive-OR) the B byte string computed in step (1) with opad
(6) append the H result from step (4) to the B byte string resulting from step (5)
(7) apply H to the stream generated in step (6) and output the result
Here is a simple Python script that can be used to compute the raw key from the SSID and
PSK passphrase. Within the Python module I've used (can be installed via python-pip) the
default MAC and hash algorithm is HMAC-SHA1:
#! /usr/bin/env python
from pbkdf2 import PBKDF2
Key Confirmation Key (`KCK`) - Used during the creation of the Message Integrity
Code.
Key Encryption Key (`KEK`) - Used by the access point during data encryption.
Temporal Key (`TK`) - Used for the encryption and decryption of unicast packets.
MIC Authenticator Tx Key (`MIC Tx`) - Only used with TKIP configurations for unicast
packets sent by access points.
MIC Authenticator Rx Key (`MIC Rx`) - Only used with TKIP configurations for unicast
packets sent by clients.
3/6
The resulting order:
- 128 bits -.- 128 bits -.- 128 bits -.- 64 bits -.- 64 bits -
| KCK | KEK | TK | MIC Tx | MIC Rx |
The only reference to a usable PRF512 function within Python was an excerpt of code from a
question on Stack Overflow from back in 2012:
def customPRF512(key,A,B):
blen = 64
i =0
R = ''
while i<=((blen*8+159)/160):
hmacsha1 = hmac.new(key,A+chr(0x00)+B+chr(i),hashlib.sha1)
i+=1
R = R+hmacsha1.digest()
return R[:blen]
Some sample code just to get a visualisation of what happens in the background:
4/6
#! /usr/bin/env python
import hmac,hashlib,binascii,sha
from pbkdf2 import PBKDF2
def customPRF512(key,A,B):
blen = 64
i =0
R = ''
while i<=((blen*8+159)/160):
hmacsha1 = hmac.new(key,A+chr(0x00)+B+chr(i),hashlib.sha1)
i+=1
R = R+hmacsha1.digest()
return R[:blen]
The PMK and PTK are then printed to the terminal, with the first 16 bytes of the PTK being
the KCK.
This whole process is re-run for every dictionary entry (or brute force attempt) in during
password cracking, which is the reason why for the slow performance of Hashcat, Cowpatty,
and John The Ripper (although I still manage 100k hashes P/s with Oclhashcat, which goes
to show how fantastically optimised Atom's code is).
5/6
The MIC is calculated using HMAC_MD5, which takes its input from the KCK Key within the
PTK. Unfortunately I wasn't able to come up with some Python code to compute the MIC,
even after reviewing aircrack-ng and Cowpatty source code (my C skills are severely lacking).
Expand on the above and let me know if anyone has an idea!
Conclusions
If anything, knowing the amount of computation that is performed for each attempt at
comparing the MICs puts me at somewhat ease regarding the security of using PSK auth on
personal networks, however it does prove how invaluable random passphrases are within
various cryptographic implementations such as this, especially passphrases that are longer
and contain more entropy. Use a 15 character passphrase for your PSK, which includes a
combination of upper and lower alpha, numeric, and special characters, which isn't a
dictionary word. Oh, and also change it regularly. If I or anyone else happen to crack your
passphrase, then an attacker wouldn't get much use of it is void should they go back there
in a months time can't connect because it's changed to a new value.
More importantly, don't use PSK authentication for your corporate networks. Whilst there
are some vulnerabilities within certain EAP configurations they are a lot easier to squash
than an offline attack such as what is capable against PSKs.
If any of the aforementioned information is incorrect please feel free to drop me an email
and I'll make the necessary amendments and credit appropriately.
References
I have used some external sources to further understand these processes. They are in no
particular order:
6/6