Security Review of WAI

1. Security Review of WAI Authors: Date: 2009-01-12 Dan Harkins, Aruba Networks

2. Abstract This presentation provides a broad look at the results of a security analysis of WAI found in document 11-10/0040r1. Dan Harkins, Aruba Networks

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. Dan Harkins, Aruba Networks

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. Dan Harkins, Aruba Networks

5. 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 Dan Harkins, Aruba Networks

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. ASUE AE token, IDASU, CertAE [token, NASUE, ExpASUE, IDAE, CertASUE,]SigASUE [NASUE, NAE, ExpAE, IDAE, IDASUE] SigAE (some uninteresting things are left out of some messages) Dan Harkins, Aruba Networks

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”. Dan Harkins, Aruba Networks

8. WAI Authentication Exchange (Signatures) signed content WAI header signature identity digital signature • 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. “signature attribute” Dan Harkins, Aruba Networks

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. Dan Harkins, Aruba Networks

10. WAI Authentication (Key Derivation) Key (y • x • P) • 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. 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) Dan Harkins, Aruba Networks

11. Certificate Authentication Exchange ASE AE • 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. MACAE, MACASUE, NAE, NASUE, CertASUE, CertAE, ASEList MACAE, MACASUE, [ NAE, NASUE, CertASUE, CertAE ], SigASE Dan Harkins, Aruba Networks

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. ASUE AE flags, BKID, USKID, MACASUE, MACAE, NAE flags, BKID, USKID, MACASUE, MACAE, NASUE, NAE, IEASUE, MIC flags, BKID, USKID, MACASUE, MACAE, NASUE, IEAE, MIC Dan Harkins, Aruba Networks

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. ASUE AE flags, MSKID, USKID, MACASUE, MACAE, Seq, IV, {mkey}, MIC flags, MSKID, USKID, MACASUE, MACAE, IV, MIC Dan Harkins, Aruba Networks

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. Dan Harkins, Aruba Networks