Cryptographic Review and PKEX

1. Paul A. Lambert (Marvell) Cryptographic Review and PKEX • Date: 2016-09-12 Authors:

2. Paul A. Lambert (Marvell) 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.

3. Paul A. Lambert (Marvell) PKEX Background • The PKEX protocol is defined within the IEEE 802.11 draft specification for Fast Initial Link Setup (FILS) • PKEX is one of several new authentication mechanisms being introduced into IEEE 802.11 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

4. Paul A. Lambert (Marvell) FILS and PKEX • The Fast Initial Link Setup (FILS) project was started in May 2010 and defines mechanisms that provide IEEE 802.11 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 802.11. • 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

5. Paul A. Lambert (Marvell) PKEX Issues • Issues have been identified with PKEX: • Related Key Attack (8/23) • Mitigated by changes in 11-16-1100-03-00ai-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)https://www.ietf.org/mail-archive/web/cfrg/current/msg08531.html • 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 802.11 group inventing its own crypto?” • The protocol is susceptible to a MiTM attack.

6. Paul A. Lambert (Marvell) Cryptographic Notation Alice sA PA = sA*G Bob sB PB = sB*G

7. Paul A. Lambert (Marvell) PKEX Overview sAPA = sA*G macA sB PB = sB*G macB Bob Alice shared secretpw 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

8. Paul A. Lambert (Marvell) PKEX MiTM Attack sB = random() PB = sB*G macB shared secretpw Bob Alice sE= random() PE= sE*G PA, PB Pwe= F(pw) mB = H(macB) nonceB = random() CB = PB+mB*Pwe Pwe= F(pw) mA = H(macA) nonceA = random() CA = PA + mA*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 PEand believes it belongs to Bob - Bob has Eve’s public key PEand believes it belongs to Alice (not shown but same as Alice attack)

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

10. Paul A. Lambert (Marvell) 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 • + New draft of TGai would be quickly available • 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