11-11-2012, 10:50 AM
Hi qweased, perhaps I can help. If I understand correctly the simplified flow looks like this (just after glossary):
PSK - Pre-Shared Ky, aka the password you want to break
SSID - Service Set IDentifier, wireless network's name
PMK - Pairwise Master Key, generated from PSK & SSID and not exposed directly
PRF - psuedo-random function
PTK - Pairwise Temporal Key, generated via PRK from PMK & session-specific info
PBKDF2 - Password-Based Key Derivation Function 2, a key stretching/strengthening algorithm utilizing multiple rounds of hashes. In this case the hashing algorithm is HMAC-SHA1
KCK - EAPOL-Key confirmation key
MIC - Message Integrity Codes, use KCK as only secret component
ANonce - random nonce value sent to client
SNonce - random nonce value sent to AP
AA - Authenticator Address, MAC address of AP
STA - Station Address, MAC address of client
# The PSK acts as a salt, SSID acts as the data to be hashed, and 4096 is the number of iterations of HMAC-SHA1
PMK = PBKDF2(PSK, SSID, 4096)
# The PMK becomes the PTK through the PRF (psuedo-random function) which normally performs 3-4 rounds of HMAC-SHA1 operations (3 for CCMP, 4 for TKIP), however we don't need to do the whole computation as we only need part of the PTK (the first 128 bits) called the KCK (EAPOL-Key confirmation key).
KCK = PTK[0:127] = HMAC-SHA1(PMK, “Pairwise key expansion\0â€, Min(AA,SPA) || Max(AA,SPA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) || 0)
The KCK is used to verify the MIC (Message Integrity Codes) which are used in all of the handshake messages after the first one. By deriving the KCK as above we can confirm guesses just as a WPA client verifies messages against the MIC, create the expected MIC from the message using KCK and make sure it matches the one sent. If it does, you have the right KCK, therefore the right PMK, and therefore the right password. How you create a MIC depends on whether you're using CCMP or TKIP, but suffice to say it is not a particularly expensive/intensive operation.
This is probably a good point for me to mention that I have no idea if this is the route hashcat uses to verify it's got the right PMK, but it should work at least if you have the whole handshake for reference.
Finally, as to where rainbow tables come in, as you can see by far the most expensive part of this process is the 4096 HMAC rounds deriving the PMK from the PSK and SSID. Also notice that these are the only two piece of data we need to do this derivation. Because of this it is possible to build SSID-specific rainbow tables to pre-compute the most common PSKs and cut down this slowest part of the equation. As appealing as that sounds, however, because they must be SSID-dependent I have found their general utility to be rather lacking.
Anyway, hope that helps. If I screwed up anything in either the derivation flow or how its done in hashcat hopefully atom will correct me.
PSK - Pre-Shared Ky, aka the password you want to break
SSID - Service Set IDentifier, wireless network's name
PMK - Pairwise Master Key, generated from PSK & SSID and not exposed directly
PRF - psuedo-random function
PTK - Pairwise Temporal Key, generated via PRK from PMK & session-specific info
PBKDF2 - Password-Based Key Derivation Function 2, a key stretching/strengthening algorithm utilizing multiple rounds of hashes. In this case the hashing algorithm is HMAC-SHA1
KCK - EAPOL-Key confirmation key
MIC - Message Integrity Codes, use KCK as only secret component
ANonce - random nonce value sent to client
SNonce - random nonce value sent to AP
AA - Authenticator Address, MAC address of AP
STA - Station Address, MAC address of client
# The PSK acts as a salt, SSID acts as the data to be hashed, and 4096 is the number of iterations of HMAC-SHA1
PMK = PBKDF2(PSK, SSID, 4096)
# The PMK becomes the PTK through the PRF (psuedo-random function) which normally performs 3-4 rounds of HMAC-SHA1 operations (3 for CCMP, 4 for TKIP), however we don't need to do the whole computation as we only need part of the PTK (the first 128 bits) called the KCK (EAPOL-Key confirmation key).
KCK = PTK[0:127] = HMAC-SHA1(PMK, “Pairwise key expansion\0â€, Min(AA,SPA) || Max(AA,SPA) || Min(ANonce,SNonce) || Max(ANonce,SNonce)) || 0)
The KCK is used to verify the MIC (Message Integrity Codes) which are used in all of the handshake messages after the first one. By deriving the KCK as above we can confirm guesses just as a WPA client verifies messages against the MIC, create the expected MIC from the message using KCK and make sure it matches the one sent. If it does, you have the right KCK, therefore the right PMK, and therefore the right password. How you create a MIC depends on whether you're using CCMP or TKIP, but suffice to say it is not a particularly expensive/intensive operation.
This is probably a good point for me to mention that I have no idea if this is the route hashcat uses to verify it's got the right PMK, but it should work at least if you have the whole handshake for reference.
Finally, as to where rainbow tables come in, as you can see by far the most expensive part of this process is the 4096 HMAC rounds deriving the PMK from the PSK and SSID. Also notice that these are the only two piece of data we need to do this derivation. Because of this it is possible to build SSID-specific rainbow tables to pre-compute the most common PSKs and cut down this slowest part of the equation. As appealing as that sounds, however, because they must be SSID-dependent I have found their general utility to be rather lacking.
Anyway, hope that helps. If I screwed up anything in either the derivation flow or how its done in hashcat hopefully atom will correct me.