Understanding PKEX Issues in IEEE 802.11-16/1261r2

This presentation delves into the problems related to PKEX (Public Key Exchange) in the context of IEEE 802.11-16/1261r2 standard. It discusses the PKEX exchange process, associated vulnerabilities, and the need for ensuring secure key exchange to prevent offline dictionary attacks and man-in-the-middle attacks.

• PKEX Issues
• IEEE 802.11
• Key Exchange
• Security Vulnerabilities
• Authentication

lpran Follow

Uploaded on Sep 06, 2024 | 1 Views

Download Presentation

Please find below an Image/Link to download the presentation.

The content on the website is provided AS IS for your information and personal use only. It may not be sold, licensed, or shared on other websites without obtaining consent from the author. Download presentation by click this link. If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.

Presentation Transcript

1. September 2016 doc.: IEEE 802.11-16/1261r2 PKEX issue in 802.11ai Date: 2016-09-13 Authors: Name Dan Harkins Affiliations Address HPE Phone email Submission Slide 1 Dan Harkins, HPE

2. September 2016 doc.: IEEE 802.11-16/1261r2 Abstract This presentation discusses the PKEX issues. Submission Slide 2 Dan Harkins, HPE

3. September 2016 doc.: IEEE 802.11-16/1261r2 PKEX Exchange Intended to allow two parties to exchange a raw public key for use with FILS public key authentication Uses a password to authenticate the exchange and encrypt the exchanged public keys Submission Slide 3 Dan Harkins, HPE

4. doc.: IEEE 802.11-16/1261r2 PKEX Exchange sA PA = sA*G sB PB = sB*G Bob Alice shared secret pw Pwe= F(pw) mA = H(macA) CA = PA + mA*Pwe Pwe= F(pw) mB = H(macB) CB = PB + mB*Pwe CA CB m B = H(macB) P B = CB - m B*Pwe m A = H(macA) P A = CA - m A*Pwe if (min(nonceA, nonceB) == nonceA x = H(nonceB|| nonceA) k = Kdf(x, "PKEX Key Confirmation", CB || CA || macB || macA || F(S)) else x = H(nonceA || nonceB) k = Kdf(x, "PKEX Key Confirmation", CA || CB || macA || macB || F(S)) checkA = HMAC(k, PA|| P B || macA|| macB) if (min(nonceB, nonceA) == nonceB x = H(nonceA || nonceB) k = Kdf(x, "PKEX Key Confirmation", CA || CB || macA || macB || F(S)) else x = H(nonceB|| nonceA) k = Kdf(x, "PKEX Key Confirmation", CB || CA || macB || macA || F(S)) checkA checkB = HMAC(k, PB|| P A || macB|| macA) checkB Validate Validate checkA == HMAC(k, PA|| P B || macA|| macB) checkB == HMAC(k, PB || PA || macB|| macA) After the exchange: - Alice has Bob s public key PB and has validated its ownership to that of the owner of the shared secret Slide 4 Septe mber Dan Harkins, HPE Submission - Bob has Alice s public key PA and has validated its ownership to that of the owner of the shared secret

5. September 2016 doc.: IEEE 802.11-16/1261r2 What s the Problem? Only truly secure when the same public key is not used in multiple PKEX runs Running PKEX multiple times with the same public key opens up two attacks: Off-line dictionary attack to determine the password(s) used Man-in-the-middle attack to insert an adversary s public key Submission Slide 5 Dan Harkins, HPE

6. September 2016 doc.: IEEE 802.11-16/1261r2 Off-line Dictionary Attack Adversary watches two exchanges in which she knows that the same public key was used both times (let s say from Alice ) CA1 = PA + QA1 = PA + (mA*Pwe1) CA2 = PA + QA2 = PA + (mA*Pwe2) Therefore, adversary knows CA1 - CA2 = QA1 - QA2 Adversary can go offline and check all N2 password combinations where N is number of possible passwords Birthday paradox makes this an O(N) attack not O(N2) Submission Slide 6 Dan Harkins, HPE

7. September 2016 doc.: IEEE 802.11-16/1261r2 Off-line Dictionary Attack If the adversary learns the password after the exchange is over the so what? Keys are exchanged, nothing is subverted If dictionary attack can be done in real-time though, the exchange can be subverted by inserting the adversary s public key into the exchange Dictionary attacks are getting faster and faster Submission Slide 7 Dan Harkins, HPE

8. September 2016 doc.: IEEE 802.11-16/1261r2 Man-in-The-Middle Attack Adversary knows that the same key is being used a second time (let s say by Bob ) Adversary gets C1, modifies C2 = C = PB + QB by determining QB (knows PB) and inserts adversary s key But adversary cannot decrypt PA to complete attack because she doesn t know QA To determine QA, it is necessary to take a discrete logarithm from an unknown root An Nth root equation where N is a 256-bit number! Extremely unlikely this compute power is readily available But the fix is easy, add the password to the KDF Submission Slide 8 Dan Harkins, HPE

9. September 2016 doc.: IEEE 802.11-16/1261r2 Man-in-The-Middle Attack There is an easier attack but it requires both parties to exchange the same key multiple times There is really no reason why people would do PKEX twice with the same keys if they exchanged their keys once what s the point? Somewhat of a contrived attack, but the fix is the same, add the password to the KDF Submission Slide 9 Dan Harkins, HPE

10. September 2016 doc.: IEEE 802.11-16/1261r2 Conclusion The Man-In-The-Middle attack is an easy fix The dictionary attack is more severe 802.11 has a history of releasing security protocols with flaws PSK mode, WEP It is possible to replace PKEX with something that does not suffer from the problems presented here PKEX is not critical to FILS, it s optional and it s still possible exchange raw public keys in a manner outside the scope of the standard. Let s just get rid of PKEX Submission Slide 10 Dan Harkins, HPE

11. September 2016 doc.: IEEE 802.11-16/1261r2 References Submission Slide 11 Dan Harkins, HPE