thanks... and how we can derive authkey manually?? ... before starting attack:
we have KDK = HMAC-SHA-256DHKey (N1 || EnrolleeMAC || N2)... DHkey= SHA-256(g^AB mod p)... and
AuthKey || KeyWrapKey || EMSK = kdf(KDK, “Wi-Fi Easy and Secure Key Derivation”, 640)
so we should know the value on the right side of equation ... so we have authkey.... right??
i want to study about attack in details...thanks...
Last edited by lllhamedlll; 2015-07-31 at 09:09.
All the answers to your questions can be found here: http://cfile28.uf.tistory.com/attach...50FCFFCB3EC74E
Look on page 37.
You can also watch Dominique's video: http://video.adm.ntnu.no/pres/549931214e18d and look at his slides: http://archive.hack.lu/2014/Hacklu20...ack_on_wps.pdf
They'll help you a lot Glad to see someone who, like me, wants to understand the attack rather than just do it
The WPS protocol uses the Diffie-Hellman key exchange which is a method of securely exchanging cryptographic keys over a public channel. The AP wants to talk to the Client but they don't want anyone else to be able to eavesdrop they conversation.
To accomplish this, they both generate a pair of keys (a public key and a private key):
- First the AP generates a (hopefully) random private key (A).
- Then it generates its public key, PKe = g^A mod p, where g and p are known and described by the WPS protocol, and sends it to the Client (with M1).
Now, it's the turn of the Client to generate its pair of keys:
- random private key (B)
- PKr = g^B mod p, and sends PKr to the AP (with M2).
At this point they both have each others public key and find the 'shared secret', a common key used to set up a secure channel.
To find the shared secret (g^(AB) mod p):
- the AP does: shared_secret = PKr^A mod p (which is equal to g^(AB) mod p)
- the Client does: shared_secret = PKe^B mod p (which is equal to g^(AB) mod p)
It may seems magic at first but it's simple math.
From this point on the WPS protocol imposes these steps:
- DHKey = SHA-256(shared_secret)
- KDK = HMAC-SHA-256{DHKey}(Enrollee nonce || Enrollee MAC || Registrar nonce), DHKey is used as key for the hash function
- AuthKey || KeyWrapKey || EMSK = kdf(KDK, “Wi-Fi Easy and Secure Key Derivation”, 640)
where || denotes concatenation (kdf ouputs a sequence of bytes, the first 256 are for AuthKey...).
AuthKey stands for Authentication session Key and it is, in fact, a session key.
Now if you are thinking at something like, "I sniff packets with Wireshark and then I generate AuthKey with the data collected". No, you can't. The Diffie-Hellman key exchange does not allow eavesdropping. It all starts with the pair of keys (public and private). To get to AuthKey you need the private key of one of the two involved entities (AP or Client). So Pixiewps needs AuthKey to work, which is provided by Reaver/Bully.
After M2 (before M3) they both have a secure channel to talk in.
However, Reaver >= 1.3 has a feature called "Small Diffie-Hellman keys" (-S, --dh-small). Enabling this feature causes Reaver to choose a static, not random private key, specifically the number 1.
So if we use this feauture with Reaver then the shared_secret becomes: g^(AB) mod p = PKe^B mod p = PKe mod p = PKe (g = 2, B = 1, p > 2).
PKe is calculated as g^A mod p, meaning that, PKe mod p = PKe (< p).
EDIT: of course you can calculate AuthKey everytime you know the private number (it doesn't have to be 1). With 1 it's just simplier.
Last edited by wiire; 2015-08-01 at 09:46. Reason: Added more info, fixed typo