PKEX Issues in IEEE 802.11-16/1261r2
September 2016
Dan Harkins, HPE
Slide 1
PKEX issue in 802.11ai
Date:
2016-09-13
Authors:
September 2016
Dan Harkins, HPE
Slide 2
Abstract
This presentation discusses the PKEX issues.
September 2016
Dan Harkins, HPE
Slide 3
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
PKEX Exchange
Slide 4
Dan Harkins, HPE
Septe
mber
2016
s
B
P
B
= s
B
*G
s
A
P
A
= s
A
*G
Pwe
= F(pw)
m
A
= H(mac
A
)
C
A
= P
A
+ m
A
*Pwe
C
A
C
B
m’
B
= H(mac
B
)
P’
B
= C
B
- m
’
B
*Pwe
if (min(nonce
A
, nonce
B
) == nonce
A
x = H(nonce
B
|| nonce
A
)
k = Kdf(x, "PKEX Key Confirmation",
C
B
|| C
A
||
m
ac
B
|| mac
A
|| F(S))
else
x = H(nonce
A
|| nonce
B
)
k = Kdf(x, "PKEX Key Confirmation",
C
A
|| C
B
||
m
ac
A
|| mac
B
|| F(S))
check
A
= HMAC(k, P
A
|| P’
B
||
mac
A
|| mac
B
)
c
h
e
c
k
A
A
f
t
e
r
t
h
e
e
x
c
h
a
n
g
e
:
-
A
l
i
c
e
h
a
s
B
o
b
’
s
p
u
b
l
i
c
k
e
y
P
B
a
n
d
h
a
s
v
a
l
i
d
a
t
e
d
i
t
s
o
w
n
e
r
s
h
i
p
t
o
t
h
a
t
o
f
t
h
e
o
w
n
e
r
o
f
t
h
e
s
h
a
r
e
d
s
e
c
r
e
t
- Bob has Alice’s public key P
A
and has validated its ownership to that of the owner of the shared secret
B
o
b
A
l
i
c
e
shared secret
pw
Pwe
= F(pw)
m
B
= H(mac
B
)
C
B
= P
B
+ m
B
*Pwe
m’
A
= H(mac
A
)
P’
A
= C
A
- m
’
A
*Pwe
if (min(nonce
B
, nonce
A
) == nonce
B
x = H(nonce
A
|| nonce
B
)
k = Kdf(x, "PKEX Key Confirmation",
C
A
|| C
B
||
m
ac
A
|| mac
B
|| F(S))
else
x = H(nonce
B
|| nonce
A
)
k = Kdf(x, "PKEX Key Confirmation",
C
B
|| C
A
||
m
ac
B
|| mac
A
|| F(S))
check
B
= HMAC(k, P
B
|| P’
A
|| mac
B
|| mac
A
)
c
h
e
c
k
B
Validate
check
B
== HMAC(k, P
B
|| P
A
|| mac
B
|| mac
A
)
Validate
check
A
== HMAC(k, P
A
|| P’
B
|| mac
A
|| mac
B
)
September 2016
Dan Harkins, HPE
Slide 5
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
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”)
•
C
A1
= P
A
+ Q
A1
= P
A
+ (m
A
*Pwe1)
•
C
A2
= P
A
+ Q
A2
= P
A
+ (m
A
*Pwe2)
•
Therefore, adversary knows C
A1
- C
A2
= Q
A1
- Q
A2
•
Adversary can go offline and check all N
2
password
combinations where N is number of possible passwords
•
Birthday paradox makes this an O(N) attack not O(N
2
)
Slide 6
Dan Harkins, HPE
September 2016
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
Slide 7
Dan Harkins, HPE
September 2016
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 = P
B
+ Q
B
by
determining Q
B
(knows P
B
) and inserts adversary’s key
•
But adversary cannot decrypt
P
A
to complete attack
because she doesn’t know
Q
A
•
To determine Q
A
, 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
Slide 8
Dan Harkins, HPE
September 2016
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
Slide 9
Dan Harkins, HPE
September 2016
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
Slide 10
Dan Harkins, HPE
September 2016
September 2016
Dan Harkins, HPE
Slide 11
References
doc.: IEEE 802.11-16/1261r0
September 2016
Dan Harkins, HPE
Page
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.
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.If you encounter any issues during the download, it is possible that the publisher has removed the file from their server.
You are allowed to download the files provided on this website for personal or commercial use, subject to the condition that they are used lawfully. All files are the property of their respective owners.
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.
E N D
Presentation Transcript
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
September 2016 doc.: IEEE 802.11-16/1261r2 Abstract This presentation discusses the PKEX issues. Submission Slide 2 Dan Harkins, HPE
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
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
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
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
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
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
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
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
September 2016 doc.: IEEE 802.11-16/1261r2 References Submission Slide 11 Dan Harkins, HPE
