a modular security analysis of eap and ieee 802.11 - phd ... · a modular security analysis of eap...

A Modular Security Analysis ofEAP and IEEE 802.11PhD defense

Håkon JacobsenDepartment of Information Security andCommunication Technology

October 25, 2017

IEEE 802.11 – WPA2-PSK

Client Access point

Server

Internet

2 / 31 Intro AKE models EAP EAP-TLS 802.11

WPA2-Enterprise

• Used in large organizations

– infeasible to share a singleshared key

– user authenticationcentrally managed

• Example: eduroam

WPA2-Enterprise

Client Authenticator Server

EAP-TLS

Key Transport

IEEE 802.11

WPA2Enterprise

Thm 1: 3P-AKEweak forward secrecyThm 2: 3P-AKE

full forward secrecy

Thm 3: 2P-AKEfull forward secrecy

Thm 4: 2P-AKEno forward secrecy

[JKSS12, KPW13, BFS+13,KSS13, LSY+14, . . . ]:

2P-ACCE

Thesis goal

Conduct a formal computational security analysis of the EAPframework, including:

1. the WPA2-Enterprise framework

2. the EAP-TLS key exchange protocol

3. the 802.11 protocol

4. meta-goal: establish the results in a modular fashion; reusingexisting analyses whenever possible

Thesis goal

Conduct a formal computational security analysis of the EAPframework, including:

1. the WPA2-Enterprise framework

2. the EAP-TLS key exchange protocol

3. the 802.11 protocol

4. meta-goal: establish the results in a modular fashion; reusingexisting analyses whenever possible

Acknowledgments

Chris BrzuskaHamburg University of Technology

Douglas StebilaMcMaster University, Hamilton

Our formal security model

Extended Bellare-Rogaway model adapted from [BPR00]

Adversary A can:

• Control all networkcommunication

• Learn session keys sk

• Learn long-term keys

• Cannot learn internalrandomness

π′A

πB πC

Adversary A can:

π′A

πB πC

Adversary A can:

π′A

πB πC

Adversary A can:

π′A

πB πC

Adversary A can:

π′A

πB πC

Authenticated key exchange (AKE) security goals

• Key-secrecy: attacker should learn nothing about sk for a freshsession πU

• Authentication: sk should only be shared with πU ’s intendedpeer

• Key-confirmation: the intended peer actually computed sk

Authenticated key exchange (AKE) security goals

• Key-secrecy: attacker should learn nothing about sk for a freshsession πU

• Authentication: sk should only be shared with πU ’s intendedpeer

• Key-confirmation: the intended peer actually computed sk

Forward secrecy

• Loss of a long-term key should not compromise previouslyestablished session keys

– Full forward secrecy: adversary A can get long-term keys afterπU completed

– Weak forward secrecy: A can get long-term keys after πUcompleted—but only if A was passive

– No forward secrecy: A cannot get long-term keys

Forward secrecy

Main results

1. EAP is a secure 3P-AKE protocol with weak forward secrecy

2. EAP + key-confirmation is a secure 3P-AKE protocol with fullforward secrecy

3. EAP-TLS is a secure 2P-AKE protocol (with full forward secrecy)

4. 802.11 handshake protocol (WPA2-PSK) is a secure 2P-AKEprotocol with no forward secrecy

5. WPA2-Enterprise is a secure3P-AKE protocol with fullfull secrecy

EAP method

Key transportEAP

EAP-TLS

IEEE 802.11

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

Main results

EAP method

Key transportEAP

EAP-TLS

Key confirmation

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

Main results

EAP method

Key transportEAP

EAP-TLS

IEEE 802.11

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

Main results

EAP method

Key transportEAP

EAP-TLS

IEEE 802.11

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

Main results

EAP method

Key transportEAP

EAP-TLS

IEEE 802.11

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

Our results – caveats

• Being “secure” is not an unconditional statement

• All results are relative to our model of the protocol and relies onvarious assumptions

• Model might not completely cover practice

Extensible Authentication Protocol (EAP)

• Generic authentication framework underlying WPA2-Enterprise

• Specifies:

1. a three-party architecture consisting of a client, a server and anauthenticator

2. a way of encapsulating concrete authentication mechanismsinside EAP methods

— EAP-TLS— EAP-TTLS— EAP-IKEv2— EAP-PWD— EAP-PSK

— EAP-SIM— EAP-AKA— EAP-GTC— PEAP— LEAP

— EAP-FAST— EAP-POTP— EAP-EKE— EAP-MD5— ...

• Specifies:

EAP framework

EAP method

Key transportEAP

EAP-TLS

Key confirmation

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

Composition Theorem 1

Modeling EAP without key-confirmation

EAP method, “C”, “A”

“C”+“C”+

“B” +“B” +

← KDF( , “C”, “A”)← KDF( , “C”, “A”)

← KDF( , “C”, “B”)

Theorem 1: EAP is a secure 3P-AKE protocol with weak forwardsecrecy

An attack

C A B S

“C”+“C”+

“B” +“B” +

← KDF( , “C”, “A”)← KDF( , “C”, “A”)

← KDF( , “C”, “B”)

An attack

C A B S

EAP method, “C”,��XX“A” “B”

“C”+“C”+ “B” +“B” +

← KDF( , “C”, “A”)← KDF( , “C”, “A”)

← KDF( , “C”, “B”)

An attack

C A B S

“C”+“C”+

“B” +“B” +

← KDF( , “C”, “A”)← KDF( , “C”, “A”)

← KDF( , “C”, “B”)

Channel binding

“C”+“C”+

“B” +“B” +

← KDF( , “C”, “A”)← KDF( , “C”, “A”)

← KDF( , “C”, “B”)

Channel binding

“C”+“C”+

“B” +“B” +

← KDF( , “C”, “A”)

← KDF( , “C”, “B”)

Channel binding

C A B S

“C”+“C”+ “B” +“B” +

← KDF( , “C”, “A”)← KDF( , “C”, “A”)

← KDF( , “C”, “B”)

Channel binding

C A B S

“C”+“C”+ “B” +“B” +

← KDF( , “C”, “A”)

← KDF( , “C”, “B”)

Channel binding

C A B S

“C”+“C”+

“B” +“B” +

← KDF( , “C”, “A”)← KDF( , “C”, “A”)← KDF( , “C”, “B”)

“C”+“C”+

“B” +“B” +

← KDF( , “C”, “A”)

← KDF( , “C”, “B”)

EAP method

Key transportEAP

EAP-TLS

IEEE 802.11

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

Theorem 2: EAP + key-confirmation is a secure 3P-AKE protocolwith full forward secrecy

EAP method

Key transportEAP

EAP-TLS

Key confirmation

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

EAP method

Key transportEAP

EAP-TLS

Key confirmation

WPA2Enterprise

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

EAP method

Key transportEAP

EAP-TLS

Key confirmation

WPA2Enterprise

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

EAP-TLS

EAP-Transport Layer Security

EAP method

Key transportEAP

EAP-TLS

Key confirmation

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

• EAP-TLS = certificate-based TLS encapsulated inside EAP

EAP method

Key transportEAP

EAP-TLS

IEEE 802.11

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

EAP method

Key transportEAP

EAP-TLS

IEEE 802.11

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

EAP method

Key transportEAP

EAP-TLS

IEEE 802.11

WPA2Enterprise

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

Proving that EAP-TLS is a secure 2-party AKE protocol

• Idea: modify existing proofs of TLS to work for EAP-TLS

• Problem: not modular

• Alternative: use existing results on TLS to prove EAP-TLS

• Problem: TLS is not a secure authenticated key exchange (AKE)protocol, but rather a secure channel establishment protocol

Authenticated and Confidential Channel Establishment(ACCE) protcols [JKSS12]

• All-in-one-definition: authenticated key exchange (AKE) protocol+ encryption algorithm

• Security goal: session key established by the AKE should besafe to use for encryption algorithm

• Less stringent requirement than AKE

• Many results showing that TLSv1.2 is a secure ACCE protocol([JKSS12, KPW13, KSS13, BFS+13, LSY+14])

Our result

“A secure ACCE =⇒ a secure AKE”

Our result

Theorem 3:

a secure TLS-like ACCE protocol+

a key-collision resistant KDF =⇒ a secure AKE+

a random oracle

IEEE 802.11

EAP method

Key transportEAP

EAP-TLS

Key confirmation

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

IEEE 802.11

EAP method

Key transportEAP

EAP-TLS

IEEE 802.11

WPA2Enterprise

EAPTLS

EAP packets

, NC , NS , NC , NS

← KDF( , NC‖NS)

Wi-Fi Protected Access 2 (WPA2)

• Protocol used to protect Wi-Fi networks

• Consists of:1. a 2-party key exchange protocol (4-Way Handshake)

2. an encryption algorithm (CCMP)

3. a group key exchange protocol

Wi-Fi Protected Access 2 (WPA2)

• Protocol used to protect Wi-Fi networks

• Consists of:1. a 2-party key exchange protocol (4-Way Handshake)

2. an encryption algorithm (CCMP)

3. a group key exchange protocol

802.11 4-Way Handshake (WPA2-PSK)

NC ,MAC( ,NC )

NAP ,MAC( ,NAP)

MAC( , “Finished”)

NAP ← {0, 1}256NC ← {0, 1}256← KDF( ,NC‖NAP)

← KDF( ,NC‖NAP)

Theorem 4: The 4-Way Handshake is a secure 2P-AKE protocol withno forward secrecy

802.11 4-Way Handshake (WPA2-PSK)

NC ,MAC( ,NC )

NAP ,MAC( ,NAP)

MAC( , “Finished”)

NAP ← {0, 1}256NC ← {0, 1}256← KDF( ,NC‖NAP)

← KDF( ,NC‖NAP)

Theorem 4: The 4-Way Handshake is a secure 2P-AKE protocol withno forward secrecy

Putting it all together: WPA2-Enterprise

EAP-TLS

Key Transport

4-Way Handshake

WPA2Enterprise

2P-ACCE

Theorem: WPA2-Enterprise is a secure 3P-AKE protocol with fullforward secrecy

EAP-TLS

Key Transport

4-Way Handshake

WPA2Enterprise

Thm 1: 3P-AKEweak forward secrecy

2P-ACCE

EAP-TLS

Key Transport

4-Way Handshake

WPA2Enterprise

2P-ACCE

EAP-TLS

Key Transport

4-Way Handshake

WPA2Enterprise

2P-ACCE

EAP-TLS

Key Transport

4-Way Handshake

WPA2Enterprise

2P-ACCE

EAP-TLS

RADIUS

4-Way Handshake

WPA2Enterprise

2P-ACCE

EAP-TLS

RADIUS-over-TLS

4-Way Handshake

WPA2Enterprise

2P-ACCE

EAP-TLS

RADIUS-over-TLS

4-Way Handshake

WPA2Enterprise

2P-ACCE

EAP-TLS

RADIUS-over-TLS

4-Way Handshake

WPA2Enterprise

2P-ACCE

KRACK attack on WPA2

KRACK and our results

• Does not invalidate our proofs

• Attack does not break the key exchange protocol (4-WayHandshake) nor the encryption algorithm (CCMP) individually,but rather when combined

• Points out a discrepancy between our formal model and thereal-world protocol

• After patches, real-world protocol is now in line with our model!

KRACK and our results

• Does not invalidate our proofs

• Attack does not break the key exchange protocol (4-WayHandshake) nor the encryption algorithm (CCMP) individually,but rather when combined

• Points out a discrepancy between our formal model and thereal-world protocol

• After patches, real-world protocol is now in line with our model!

The end

Thank you

Christina Brzuska, Marc Fischlin, Nigel P. Smart, BogdanWarinschi, and Stephen C. Williams.Less is more: relaxed yet composable security notions for keyexchange.International Journal of Information Security, 12(4):267–297,2013.

Mihir Bellare, David Pointcheval, and Phillip Rogaway.Authenticated key exchange secure against dictionary attacks.In Bart Preneel, editor, EUROCRYPT 2000, volume 1807 ofLNCS, pages 139–155. Springer, Heidelberg, May 2000.

Tibor Jager, Florian Kohlar, Sven Schäge, and Jörg Schwenk.On the security of TLS-DHE in the standard model.In Reihaneh Safavi-Naini and Ran Canetti, editors,CRYPTO 2012, volume 7417 of LNCS, pages 273–293. Springer,Heidelberg, August 2012.

Hugo Krawczyk, Kenneth G. Paterson, and Hoeteck Wee.On the security of the TLS protocol: A systematic analysis.

In Ran Canetti and Juan A. Garay, editors, CRYPTO 2013, Part I,volume 8042 of LNCS, pages 429–448. Springer, Heidelberg,August 2013.

Florian Kohlar, Sven Schäge, and Jörg Schwenk.On the security of TLS-DH and TLS-RSA in the standard model.Cryptology ePrint Archive, Report 2013/367, 2013.http://eprint.iacr.org/2013/367.

Yong Li, Sven Schäge, Zheng Yang, Florian Kohlar, and JörgSchwenk.On the security of the pre-shared key ciphersuites of TLS.In Hugo Krawczyk, editor, PKC 2014, volume 8383 of LNCS,pages 669–684. Springer, Heidelberg, March 2014.

a modular security analysis of eap and ieee 802.11 - phd ... · a modular security analysis of eap...

Documents