January 2010 doc IEEE 802 11 -10 0056

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 Security Review of WAI Date: 2009 -01 -12 Authors: Submission 1 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 Abstract This presentation provides a broad look at the results of a security analysis of WAI found in document 11 -10/0040 r 1. Submission 2 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 What is WAI? • The key exchange protocols used by WAPI to obtain an authenticated and secret key to use in establishing a secret channel over the air. – WAI Certificate Authentication procedure: perform mutual authentication of a STA and AP, derive a key shared between them. Think of this as what 802. 1 x/EAP does in 802. 11. Think of the derived key as a PMK. – Unicast Key Exchange: use the secret key (the PMK) to derive session-specific keys to use to protect data sent between STA and AP. Think of this as the 4 -way handshake. – Multicast Key Exchange: distribute a broadcast/multicast key. Think of this as the Group Key Exchange. Submission 3 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 The Actors in WAPI • The ASUE – This is the non-AP STA. The client. The supplicant. • The AE – This is the AP. The authenticator. • The ASE aka the ASU – This is not the AS. This is a clearing house for certificates. The ASE/ASU is merely asked, “is this certificate good? ”and it responds either yes or no. Submission 4 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 WAI Certificate Authentication Exchange ASUE AE ASE Open Authentication and Association “Certificate Authentication Exchange” WAI Authenticate Activation Access WAI Authentication Request Certificate Authentication Request “WAI Authentication Exchange” Certificate Authentication Response Access WAI Authentication Response Submission 5 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 WAI Authentication Exchange • The first message is for bootstrapping initial authentication only. • Core exchange is a two message Diffie-Hellman exchange. • Authentication is done with digital signatures. • Exchange performs authentication and secret key establishment (important!) but fails to meet goals of typical secure key exchange protocols. Submission ASUE AE token, IDASU, Cert. AE [token, NASUE, Exp. ASUE, IDAE, Cert. ASUE, ]Sig. ASUE [NASUE, NAE, Exp. AE, IDASUE] Sig. AE (some uninteresting things are left out of some messages) 6 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 WAI Authentication Exchange • Security beyond the basic– secret key establishment and peer authentication-- would be difficult to prove. • Neither side proves it has the key, explicitly or implicitly. – Impossible with a two message Diffie-Hellman exchange. – Need another round-trip for explicit key confirmation. For implicit key confirmation, put the AE’s exponential in the first message and make it a three message exchange always– make it into the ISO 9798 -3 exchange, a provably secure key exchange protocol. • Does not meet the consistency principle. The two sides establish state but it is not cryptographically bound to the exchange. – Not only are the exponentials not explicitly bound (fixed by implicit key confirmation) the nonces are not either. Nonces are used in generation of the “PMK”. Submission 7 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 WAI Authentication Exchange (Signatures) WAI header signature identity signed content • Signature does not cover WAI header. digital signature “signature attribute” – Modifications to header are undetected. • Signature has a separate identity encoded in it. – The identity is not necessarily the same as the identity exchanged in the message nor is it the same as the identity in the certificate– a significant disconnect in authentication! – Information is duplicated indicating some unstated requirement. Document is woefully underspecified. – Signature identity is not part of the signed content. – Enables cut-and-paste attack: the certificate for the ASE to check, can be signed by someone else. Submission 8 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 WAI Authentication Exchange (Signatures) • In spite of what WAPI states, digital signature is not ANSI X 9. 62 -compliant • WAI uses SHA 256 and an elliptic curve based on a 192 bit prime number. • ANSI X 9. 62 (and FIPS 186 -3) says that when the prime number on which the elliptic curve is based is less than the digest output to use the leftmost length-of-prime bits of the digest to compute the signature. • WAI uses the whole 256 -bits to compute the signature. • Signature operations are done on different numbers so the signature result is different. Submission 9 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 WAI Authentication (Key Derivation) Key (y • x • P) KD_HMAC_SHA-256((y • x • P)abscissa, NAE | NASUE | “base key expansion for key and additional nonce”) 48 octets Basic Key (16 octets) Challenge Seed (32 octets) • KD_HMAC_SHA 256() requires a uniformly random key. The result of the Diffie-Hellman is not uniformly random. • Can be fixed by using the concatenated nonces as the key and the Diffie-Hellman result as (part of) the data. Submission 10 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 Certificate Authentication Exchange • • • The first message is completely unauthenticated! An authoritative statement from the ASE can be constructed to put 2 entities at any MAC address using any nonce (useful tool for attacking lack of consistency in auth exchange) MAC addresses are not covered by the ASE’s signature! MACAE, MACASUE, NASUE, Cert. AE, ASEList MACAE, MACASUE, [ NAE, NASUE, Cert. AE ], Sig. ASE – A lying AE is undetected. • • Possible DDo. S attack against ASE and AE. This should be a 3 -party protocol involving unforgable attestation by the ASUE and AE to the ASE. Submission ASE AE 11 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 Unicast Key Exchange • Man-in-the-middle attack possible against “rekey” bit. • Fails in protocol consistency. • When using PSK mode the BK (used in this exchange) is derived directly from PSK ASUE flags, BKID, USKID, MACASUE, MACAE, NASUE, NAE, IEASUE, MIC – Susceptible to off-line dictionary attack – Successful attack will be three orders of magnitude faster than a similar attack against IEEE 802. 11. flags, BKID, USKID, MACASUE, MACAE, NASUE, IEAE, MIC • PSK used directly with KDF, but PSK is not uniformly random. Cryptographic primitive is misused. Submission AE 12 Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 Multicast Key Exchange • Multicast key is encrypted in OFB mode with a predictable IV. • Security is reduced to ECB mode. • Not a huge problem (key recovery is not possible) but OFB is supposed to address attacks against ECB mode. This removes the entire justification for using OFB in the first place. • Should use a provably-secure cipher mode designed especially for key wrapping: SIV. Submission 13 ASUE AE flags, MSKID, USKID, MACASUE, MACAE, Seq, IV, {mkey}, MIC flags, MSKID, USKID, MACASUE, MACAE, IV, MIC Dan Harkins, Aruba Networks

January 2010 doc. : IEEE 802. 11 -10/0056 r 0 References • • • 11 -10 -0040 -01 -0 jtc-security-analysis-of-wai. doc P. Gupta and V. Shmatikov, “Key confirmation and adaptive corruptions in the protocol security logic”, 2006. H. Krawczyk, “SIGMA: The ‘Si. Gn-and-Mac’ Approach to Authenticated Diffie. Hellman and its use in the IKE Protocols”, 2003. ISO/IEC 9798 -3: 1998, “Information technology-- Security techniques-- Entity authentication-- Part 3: Mechanisms using digital signature techniques”, 1998. ANSI X 9. 62, “Public Key Cryptography for the Financial Services Industry, The Elliptic Curve Digital Signature Algorithm (ECDSA)”, 2005. R. Shalteil, “Recent developments in explicit constructions of extractors”, 2002. H. Krawczyk, “On Extract-then-Expand Key Derivation Functions and an HMACbased KDF”, 2008. S. Kent and K. Seo, “Security Architecture for the Internet Protocol (RFC 4301)”, 2005. E. Rescorla and N. Modadugu, “Datagram Transport Layer Security (RFC 4347)”, 2006. Draft P 802. 11 s version 4. 0, “Wireless LAN Medium Access Control (MAC) and Physical Layer (PHY) specifications, Amendment 10: Mesh Networking”, 2009. P. Rogaway and T. Shrimpton, “Deterministic Authenticated Encryption, A Provable-Security Treatment of the Key-Wrap Problem”, 2006. Submission 14 Dan Harkins, Aruba Networks