1. Analysis of the 802.16e 3-way Handshake Protocol Vijay Chauhan Srinivas Inguva

2. 802.16 Recap • Basic Idea: Metropolitan area wireless broadband service. • Main roles involved in 802.16: • Base Station (BS) • Mobile Station (MS) / Subscriber Station (SS) • Two security protocols of interest: • Authentication/Authorization protocol, establishes a shared Authorization Key (AK) • 3-way Traffic Encryption Key (TEK) Handshake

3. 3-way TEK Handshake • After authentication, BS initiates a 3-way handshake to transfer TEKs to MS • TEKs generated by BS • Have a specified lifetime, after which new TEK is requested by MS • Structure of the 3-way handshake: Challenge: BS → MS: NBS, PN, AKID, HMAC/CMAC Request: MS → BS: NBS,NMS, PN, AKID, Capabilities, Parameters, Settings, HMAC/CMAC Response: BS → MS: NBS,NMS, PN, AKID, SAID, E_KEK{TEK}, Parameters, HMAC/CMAC

4. Project Overview • Modelled the 3-way TEK handshake • Rational reconstruction of the protocol • Modelled a DoS attack in Murphi on a simplified version of the handshake • Noticed some vulnerabilities in the 802.16e spec that could be exploited

5. Modelling the Handshake • Assumptions: • Shared AK securely established • Physical layer attacks outside of our scope • Dolev-Yao intruder model • Used Murphi to build model • Started with minimal protocol and added fields/invariants e.g. MACs and PNs • Goal: verify basic security properties

6. Murphi Model of Handshake • MS / BS can engage in multiple handshakes • Intruders can: • Intercept/record messages • Replay messages • Forge messages with known nonces/MACs • Security Properties: • Protocol Completes as expected: If MS is done then associated BS must also be done and they share a TEK • Messages not accepted out of order: If MS is waiting for challenge, BS cannot have finished the handshake

7. Simplified 3-way Handshake • No packet numbers (PN) • Modelled TEK as a nonce (NTEK ) [CLG] BS → MS: NBS, MAC{NBS} [REQ] MS → BS: NBS,NMS, MAC{NBS,NMS} [RES] BS → MS: NBS,NMS, NTEK, MAC{NBS,NMS, NTEK} • As modelled, no attacks found by Murphi

8. DoS Attack on Simplified Handshake • Previously recorded challenge can be replayed by an attacker • Hopes to cause MS to frequently re-key and interrupt normal operation • How to model this attack? • Need to represent the effects of an attack over time • Scenario we modelled: • One honest MS / BS pair • Expect to engage in one handshake • Reflects the common case of a key exchange followed by an extended period of operation

9. Representing a DoS Attack in Murphi • Used ideas from Meadows(2000) • General setup: • Create a cost set for protocol actions • Compute costs of actions in the protocol • Determine a threshold cost for an attacker to cause a defender to expend more than a given cost • Costs tabulated in Murphi rules for MS/BS • Thresholds written as Murphi invariants

10. Action Costs • Cost Set = {1=Cheap, 2=Medium, 3=Expensive} • Basic honest operations and their costs: • Generate Nonce = 1 • Generate/Verify MAC = 2 • Encrypt/Decrypt TEK = 3 • Send/Receive = 3 • Basic intruder operations and their costs: • Store/Lookup = 1 • Send/Receive = 3 • Assemble message = 1

11. Message Costs BS → genNonce, genMAC, send [6] → MS recv, verMAC [5] MS →genNonce, genMAC, send [6] → BS recv, verMAC [5] BS → buildTEK, genMAC, send [8] → MS recv, verMAC, decryptTEK [8] • Intruder Actions: • Intercept Message: recv, store [4] • Replay Message: lookup, send [4] • Compose Message: assemble, send [4]

12. Attack Threshold • Murphi invariant used to make assertions about Attacker-Defender costs -- If MS is done => MS costs = RecvCLG + SendREQ + RecvRES invariant "If MS is DONE => costs = MS_PROTOCOL_COSTS and intCosts > INT_THRESHOLD" forall i: BSId do forall j: MSId do (ms[j].associations[i].session.state = MS_DONE) -> (ms[j].associations[i].session.costs <= MS_PROTOCOL_COSTS | ms[j].associations[i].session.intCosts > INT_THRESHOLD) end end;

13. Results of DoS Model • An attacker can cause a BS/MS to re-engage in a 3-way handshake • Asymmetric attacker/MS costs indicate a DoS • Explains the need for a PN • After updating our Murphi model to include PNs, this attack is no longer seen

14. Potential Vulnerabilitiesin the 802.16e specification • Before authentication, these security capabilities are negotiated in the clear • Authentication protocol version number • PN window size • Spec should explicitly handle these cases, to avoid: • PKM version rollback [deprecate PKMv1?] • Zero PN window size [recheck this value after authentication, and fail if different?]

15. Conclusions • 3-way handshake is a well designed protocol: • Not susceptible to the types of attacks seen in 802.11i • Murphi can be used to model DoS attacks, assuming we can: • Compute protocol action costs • Determine attacker cost thresholds • Network Protocol Analysis is fun

16. Questions?