1 / 16

Analysis of the 802.16e 3-way Handshake Protocol

Analysis of the 802.16e 3-way Handshake Protocol. Vijay Chauhan Srinivas Inguva. 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:

marly
Télécharger la présentation

Analysis of the 802.16e 3-way Handshake Protocol

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  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?

More Related