1. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 1 Security Review of WAI Date: 2009-01-12 Authors:

2. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 2 Abstract This presentation provides a broad look at the results of a security analysis of WAI found in document 11-10/0040r1.

3. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 3 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.1x/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.

4. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 4 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.

5. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 5 WAI Certificate Authentication Exchange ASUEAEASE Open Authentication and Association WAI Authenticate Activation Access WAI Authentication Request Certificate Authentication Request Certificate Authentication Response Access WAI Authentication Response “WAI Authentication Exchange” “Certificate Authentication Exchange”

6. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 6 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. ASUEAE token, ID ASU, Cert AE [token, N ASUE, Exp ASUE, ID AE, Cert ASUE,]Sig ASUE [N ASUE, N AE, Exp AE, ID AE, ID ASUE ] Sig AE (some uninteresting things are left out of some messages)

7. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 7 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”.

8. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 8 WAI Authentication Exchange (Signatures) Signature does not cover WAI header. –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. signed content WAI header signature identity digital signature “signature attribute”

9. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 9 WAI Authentication Exchange (Signatures) In spite of what WAPI states, digital signature is not ANSI X9.62-compliant WAI uses SHA256 and an elliptic curve based on a 192- bit prime number. ANSI X9.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.

10. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 10 WAI Authentication (Key Derivation) KD_HMAC_SHA256() 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. 48 octets Basic Key (16 octets)Challenge Seed (32 octets) KD_HMAC_SHA-256((y x P) abscissa, N AE | N ASUE | “base key expansion for key and additional nonce”) Key (y x P)

11. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 11 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! –A lying AE is undetected. Possible DDoS attack against ASE and AE. This should be a 3-party protocol involving unforgable attestation by the ASUE and AE to the ASE. AE ASE MAC AE, MAC ASUE, N AE, N ASUE, Cert ASUE, Cert AE, ASEList MAC AE, MAC ASUE, [ N AE, N ASUE, Cert ASUE, Cert AE ], Sig ASE

12. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 12 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 –Susceptible to off-line dictionary attack –Successful attack will be three orders of magnitude faster than a similar attack against IEEE 802.11. PSK used directly with KDF, but PSK is not uniformly random. Cryptographic primitive is misused. ASUEAE flags, BKID, USKID, MAC ASUE, MAC AE, N AE flags, BKID, USKID, MAC ASUE, MAC AE, N ASUE, N AE, IE ASUE, MIC flags, BKID, USKID, MAC ASUE, MAC AE, N ASUE, IE AE, MIC

13. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 13 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. ASUEAE flags, MSKID, USKID, MAC ASUE, MAC AE, Seq, IV, {mkey}, MIC flags, MSKID, USKID, MAC ASUE, MAC AE, IV, MIC

14. doc.: IEEE 802.11-10/0056r0 Submission January 2010 Dan Harkins, Aruba NetworksSlide 14 References 11-10-0040-01-0jtc-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 ‘SiGn-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 X9.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 HMAC- based 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 P802.11s 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.