1. Cryptographic Review and PKEX
Month Year
doc.: IEEE yy/xxxxr0
September 2016
Cryptographic Review and PKEX
Date:
Authors:
Paul A. Lambert (Marvell)
John Doe, Some Company

2. Month Year
doc.: IEEE yy/xxxxr0
September 2016
Abstract
The Fast Initial Link Setup project (FILS, P802.11ai) is introducing several new authentication mechanisms.
Reviews of one of these authentication mechanisms, PKEX, has identified serious issues with the cryptographic design of the protocol.
This presentation provides a brief summary of PKEX functionality and issues. Options for mitigation of the issues with PKEX are provided.
Paul A. Lambert (Marvell)
John Doe, Some Company

3. September 2016
PKEX Background
The PKEX protocol is defined within the IEEE draft specification for Fast Initial Link Setup (FILS)
PKEX is one of several new authentication mechanisms being introduced into IEEE by the FILS project.
This review of PKEX is based on Draft P802.11ai_D10.0
PKEX claims to provide:
A means to ‘trust’ a public key from a peer by proof of a shared passphrase
Public keys are exchanged that are intended for subsequent use for creation/validation of digital signatures and other authorization purposes.
PKEX has been included by reference in the draft specification for the Wi-Fi Alliance Device Provisioning Protocol (DPP)
PKEX is included in DPP as means to ‘bootstrap’ trust in keys with a shared secret
As part of the review of DPP, summaries of PKEX have been reviewed and flaws in the design identified
Paul A. Lambert (Marvell)

4. September 2016
FILS and PKEX
The Fast Initial Link Setup (FILS) project was started in May 2010 and defines mechanisms that provide IEEE networks with fast initial link set-up methods which do not degrade the security currently offered by Robust Security Network Association (RSNA) already defined in IEEE
The project’s primary need comes from an environment where mobile users are constantly entering and leaving the coverage area of an existing extended service set (ESS).
(a) scale with a high number of users simultaneously entering an ESS
(b) minimize the time spent within the initial link set-up phase
(c) securely provide initial authentication.
PKEX was introduced into FILS on February 27th, 2015 with comment 7267
CID
Submission
Comment
Proposed Change
Resolution
7267
11-15/0291r0
how does one obtain a raw (uncertified) public key from a peer in a trustworthy manner?
add a simple protocol to exchange raw public keys in a manner that is trustworthy and does not require certificates
:17:49Z) -- REVISED: a corresponding protocol has been added; See 11-15/291r1 for details
Paul A. Lambert (Marvell)

5. PKEX Issues Issues have been identified with PKEX:
September 2016
PKEX Issues
Issues have been identified with PKEX:
Related Key Attack (8/23)
Mitigated by changes in ai-mods-to-pkex.docx
Fixes incorporated into P802.11ai_D10.0
Multiple issues from brief open review (8/31)
Review was on the mailing list for the Crypto Forum Research Group (CFRG)
Comments on this forum included:
There s a off-line dictionary attack on the password.
“I can't even tell what the workflow is.  Who generates a password, who types it where, and who sends what?”
“PKEX, as vaguely described here, doesn't sound like a properly designed short authentication string.”
“But why oh why is the group inventing its own crypto?”
The protocol is susceptible to a MiTM attack.
Paul A. Lambert (Marvell)

6. Cryptographic Notation
September 2016
Cryptographic Notation s
private key used to generate the public key G
generator element of the group used for public key operations +
associative group operation (point addition for ECC) *
scalar multiplication is the repeated addition of a group element with itself P
public key where P=s*G
H()
hash function
Kdf()
key derivation function
F()
the ‘hunt and peck’ algorithm used to map a arbitrary string (passphrase) to a group element (ECC point) defined in section 3.2 of RFC 7664 k
symmetric secret key developed from DH key agreement
[ ]
fields contained in brackets are optional
PA PB
Subscripts indicate the entity that controls the key pair (Alice ‘A’ , Bob ‘B’)
Alice sA
PA = sA*G
Bob sB
PB = sB*G
Paul A. Lambert (Marvell)

7. PKEX Overview September 2016 sA PA = sA*G macA sB PB = sB*G macB Alice
Bob
shared secret pw
Pwe = F(pw)
mA = H(macA)
nonceA = random()
CA = PA + mA*Pwe
Pwe = F(pw)
mB = H(macB)
nonceB = random()
CB = PB + mB*Pwe
macA, nonceA, CA
macB, nonceB, CB
m’B = H(macB)
P’B = CB - m’B*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)
m’A = H(macA)
P’A = CA - m’A*Pwe
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))
checkB = HMAC(k, PB || P’A || macB|| macA)
checkA
checkB
Validate
checkB == HMAC(k, PB || PA || macB|| macA)
Validate
checkA == HMAC(k, PA || P’B || macA|| macB)
After the exchange: - Alice has Bob’s public key PB and has validated its ownership to that of the owner of the shared secret
- Bob has Alice’s public key PA and has validated its ownership to that of the owner of the shared secret
Paul A. Lambert (Marvell)

8. PKEX MiTM Attack September 2016 sB = random() PB = sB*G macB
shared secret pw
Alice
Bob
sE= random()
PE= sE*G
PA, PB
Pwe = F(pw)
mA = H(macA)
nonceA = random()
CA = PA + mA*Pwe
Pwe = F(pw)
mB = H(macB)
nonceB = random()
CB = PB+mB*Pwe
Eve
macA, nonceA, CA
macA, nonceA, CEB = CA – PA + PE
macB, nonceB, CEA = CB – PB + PE
macB, nonceB, CB
m’B = H(macB)
PE = CEA - m’B*Pwe
x = H(nonceB || nonceA)
k = Kdf(x, "PKEX Key Confirmation", CEA || CA || macB || macA || sA*PE))
checkAE = HMAC(k, PA || PE || macA||macB)
Eve first obtains both Alice and Bob’s public key (PA and PB). The public key are assumed to be “public” and have been exposed or directly provided to Eve.
m’A = H(macA)
P’A = CA - m’A*Pwe
x = H(nonceA || nonceB)
k = Kdf(x, "PKEX Key Confirmation", CEA || CA || macB || macA ||sB*P’A))
checkEA = HMAC(k, PE || PA || macB|| macA)
checkAE
checkEA
Validate
checkEA == HMAC(k, PE || PA || macB|| macA)
After the exchange: - Alice has Eve’s public key PE and believes it belongs to Bob
- Bob has Eve’s public key PE and believes it belongs to Alice (not shown but same as Alice attack)
Paul A. Lambert (Marvell)

9. September 2016
PKEX MiTM Mitigation
The MiTM attack on PKEX could be mitigated by additional changes to the protocol
For example, changes are proposed in: ai-kdf-prf-pkex.docx
With this change it’s unclear why the H(macA)*Pwe term would be needed in processing.
It would be more productive to look at alternative key exchanges than to incrementally make patches.
Paul A. Lambert (Marvell)

10. TGai Options for PKEX Options:
Month Year
doc.: IEEE yy/xxxxr0
September 2016
TGai Options for PKEX
Options:
Fix PKEX
+ New draft of TGai would be quickly available
- Large shared one-time passphrases are a bad user experience
- Would not fix bad reviews of security design
- Magnet for more comments and could cause indefinite TGai delay
Remove PKEX
No public key ‘introduction’ mechanism would be available with TGai
Replace PKEX
+ Functionality and cryptographic design could be improved to provide valuable feature
- Delay to TGai
Paul A. Lambert (Marvell)
John Doe, Some Company