Upload
belinda-dawson
View
214
Download
2
Embed Size (px)
Citation preview
January 2010
Dan Harkins, Aruba Networks
Slide 1
doc.: IEEE 802.11-10/0056r0
Submission
Security Review of WAIDate: 2009-01-12
Name Affiliations Address Phone email Dan Harkins Aruba Networks 1322 Crossman ave,
Sunnyvale, CA +1 408 227 4500
dharkins at arubanetworks dot com
Authors:
January 2010
Dan Harkins, Aruba Networks
Slide 2
doc.: IEEE 802.11-10/0056r0
Submission
Abstract
This presentation provides a broad look at the results of a security analysis of WAI found in document 11-10/0040r1.
January 2010
Dan Harkins, Aruba Networks
Slide 3
doc.: IEEE 802.11-10/0056r0
Submission
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.
January 2010
Dan Harkins, Aruba Networks
Slide 4
doc.: IEEE 802.11-10/0056r0
Submission
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.
January 2010
Dan Harkins, Aruba Networks
Slide 5
doc.: IEEE 802.11-10/0056r0
Submission
WAI Certificate Authentication Exchange
ASUE AE ASEOpen 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”
January 2010
Dan Harkins, Aruba Networks
Slide 6
doc.: IEEE 802.11-10/0056r0
Submission
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)
January 2010
Dan Harkins, Aruba Networks
Slide 7
doc.: IEEE 802.11-10/0056r0
Submission
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”.
January 2010
Dan Harkins, Aruba Networks
Slide 8
doc.: IEEE 802.11-10/0056r0
Submission
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 WAIheader
signature identity
digitalsignature
“signature attribute”
January 2010
Dan Harkins, Aruba Networks
Slide 9
doc.: IEEE 802.11-10/0056r0
Submission
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.
January 2010
Dan Harkins, Aruba Networks
Slide 10
doc.: IEEE 802.11-10/0056r0
Submission
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, NAE | NASUE | “base key expansion for key and additional nonce”)
Key (y • x • P)
January 2010
Dan Harkins, Aruba Networks
Slide 11
doc.: IEEE 802.11-10/0056r0
Submission
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
MACAE, MACASUE, NAE, NASUE,
CertASUE, CertAE, ASEList
MACAE, MACASUE, [ NAE, NASUE,CertASUE, CertAE ], SigASE
January 2010
Dan Harkins, Aruba Networks
Slide 12
doc.: IEEE 802.11-10/0056r0
Submission
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 AEflags, BKID, USKID,MACASUE, MACAE, NAE
flags, BKID, USKID,MACASUE, MACAE, NASUE, NAE, IEASUE, MIC
flags, BKID, USKID,MACASUE, MACAE, NASUE, IEAE, MIC
January 2010
Dan Harkins, Aruba Networks
Slide 13
doc.: IEEE 802.11-10/0056r0
Submission
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
January 2010
Dan Harkins, Aruba Networks
Slide 14
doc.: IEEE 802.11-10/0056r0
Submission
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.