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

Month Year doc.: IEEE 802.11-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

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

September 2016 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 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 2015-03-11 09:17:49Z) -- REVISED: a corresponding protocol has been added; See 11-15/291r1 for details Paul A. Lambert (Marvell)

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

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)

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)

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)

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: 11-16-1151-00-00ai-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)

TGai Options for PKEX Options: Month Year doc.: IEEE 802.11-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