Cryptographic Review and PKEX Month Year doc.: IEEE 802.11-yy/xxxxr0 September 2016 Cryptographic Review and PKEX Date: 2016-09-20 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. Review 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 Security Issues have been identified with PKEX: September 2016 PKEX Issues Security 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 Off-line Dictionary attack (8/31) From review on the mailing list for the Crypto Forum Research Group (CFRG) https://www.ietf.org/mail-archive/web/cfrg/current/msg08531.html For N different possible passphrases this is a O(sqrt(N)) attack. MiTM Attack (8/31) Identified on CFRG mailing list MiTM attacker simply swaps it’s public key for each of the peer’s during the exchange Details of the protocol and the details of the off-line dictionary attack and MiTM attack are provided in the following slides. 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 hap() 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’) macA macB MAC address Alice sA PA = sA*G Bob sB PB = sB*G Paul A. Lambert (Marvell)

PKEX Overview Preconditions Protocol Exchange Post Conditions September 2016 PKEX Overview sA PA = sA*G macA, macB shared secret pw sB PB = sB*G macA, macB Preconditions Alice Bob macA, macB, nonceA, CA Protocol Exchange macB, macA, nonceB, CB macA, macB, checkA macB, macA, checkB PB PA Post Conditions After the exchange the claimed properties are: - Alice has Bob’s public key PB and has validated its ownership to that of the owner of the shared secret ‘pw’ - Bob has Alice’s public key PA and has validated its ownership to that of the owner of the shared secret ‘pw’ Assumed security properties: - The shared secret ‘pw’ has not been exposed in a manner that would allow more than one guess of the value per run of the protocol. - The long-term public keys (PA, PB) may be subsequently be used for signature creation, signature validation, access control or authorization. This implies that Alice and Bob may have interacted with other peers so PA and PB may be commonly known and shared in the system. Paul A. Lambert (Marvell)

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

PKEX Off-line Dictionary Attack September 2016 PKEX Off-line Dictionary Attack sA PA = sA*G macA, macB sB PB = sB*G macB, macA Alice Bob shared secret pw Pwe = hap(pw) mA = H(macA) nonceA = random() CA = PA + mA*Pwe Pwe = hap(pw) mB = H(macB) nonceB = random() CB = PB + mB*Pwe macA, macB, nonceA, CA Given observation of CA and macA with prior knowledge of PA: CA = PA + H(macA)*hap(pw) Attacker calculates: H(macA)*hap(pw) = PA - CA This exposes an off-line dictionary attack of the passphrase ’pw’ on the term: H(macA)*hap(pw) For N=2^n possible passphrases the search space is: O( N ) A ‘good PAKE’ has a larger search space than O( N ) that is typically of order or greater than O ( q ) where ‘q’ is the order of the PAKE group operations.

PKEX MiTM Attack September 2016 sA PA = sA*G macA, macB sB PB = sB*G macB, macA Alice Bob shared secret pw sE PE= sE*G PA , PB Pwe = hap(pw) mB = H(macB) nonceB = random() CB = PB+mB*Pwe Pwe = hap(pw) mA = H(macA) nonceA = random() CA = PA + mA*Pwe Eve macA, macB, nonceA, CA macA, macB, nonceA, CEB = CA – PA + PE macB, macA, nonceB, CEA = CB – PB + PE macB, macA, 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 keys 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 ||sE*P’A)) checkEA = HMAC(k, PE || PA || macB|| macA) macA, macB, checkAE macB, macA, checkEA Validate checkEA == HMAC(k, PE || PA || macB|| macA) After the exchange the MiTM attack properties are: - 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 Such changes are proposed in: 11-16-1151-00-00ai-kdf-prf-pkex.docx The off-line dictionary attack is not mitigated by this change 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 features - Delay to TGai PKEX was removed from TGai 9/14/2016 Paul A. Lambert (Marvell) John Doe, Some Company