Prasad Narayana, Ruiming Chen, Yao Zhao, Yan Chen and Hai Zhou Lab for Internet and Security Technology Northwestern University, Evanston IL Z. Judy Fu.

Prasad Narayana, Ruiming Chen, Yao Zhao, Yan Chen and Hai Zhou

Lab for Internet and Security TechnologyNorthwestern University, Evanston IL

Z. Judy FuMotorola Labs, Schaumburg IL

Automatic Vulnerability Checking of Wireless Protocols

through TLA+

Motivation

•High-speed Wireless Metropolitan Area Networks (MAN) poised to become the Next Big Thing

•IEEE 802.16 (WiMAX) with enormous backing from the industry is set to lead the broadband wireless network space

•Security is especially critical for open air wireless protocols

•However, security analysis of the IEEE 802.16 protocol largely confined to manual analysis– Incomplete– Inaccurate

Motivation (II)•Formal methods for automatic

vulnerability checking highly desirable–With completeness and correctness

guarantees

•Previous studies focus on security protocols and security properties only–CSP and FDR [Lowe96], MurØ

[Shmatikov98], Symbolic traces and PS-LTL [Corin06]

•Non-security protocol analysis focus on resource exhaustion DoS attacks and ignore protocol malfunction attacks !– [Yu88], [Meadow99], and [Meadow02]

Our Approach

Systematic and automatic checking through formal methods. –Formally specify a protocol in TLA+ (Temporal

Logic of Actions)–Formally model an attacker in TLA+–Specify requested properties–Then automatically model-check for

vulnerabilities Vulnerability analysis of 802.16e specs

and WiMAX standards

Potential Benefits

•TLA+ specs of 802.16e can be used as golden model for implementations– Implementation correctness can be

model-checked

•TLA+ attacker models and properties can be reused as test-benches when the protocol evolves–Correctness of modifications can be

quickly checked

Outline

•Motivation and our approach•Background on TLA+•General methods and

challenges•Results on WiMAX initial ranging

and authentication•Conclusions and future work

Why TLA+

• A logic resulted from the past 20 years research on concurrent reactive systems

• One language for both system spec and proof logic

• Modularity is employed for large specs• Systems automatically model-checked by TLC

• There are some lightweight formal techniques such as Alloy/Aloca– Limited expressiveness

» Cannot check temporal properties

– Cannot prove a property » Instead, check whether a property is satisfied by a trace

TLA+ for Security

•A protocol can be specified as one monolithic system

•Or, it can be specified as a composition of many components:Protocol == CompA /\ CompB /\ \A i\in

(1..n): Comp(i)•An attacker can be specified

similarly•Checking security is to prove

Protocol /\ Attacker Property

Outline

•Motivation and our approach•Background on TLA+•General methods and challenges

•Results on WiMAX initial ranging and authentication

•Conclusions and future work

TLA+ Vulnerability Checking Flow

TLA+ Protocol

Specification

Attacker TLA+

Specification

TLC Model

Checking

Found Vulnerability ?

Analyze Severity

Weaken Attacker

Property TLA+

Specification

Stop

Yes

No

TLA+ Protocol Specification

•Protocol specification in TLA+ can be easy or difficult–FSM easily translate to TLA+–Tricky from English description to TLA+

spec: ambiguity, re-design, etc.

•Process of protocol specification:– Identify principals–Modularize principal behaviour using

TLA+–Combine principal specs to form a

protocol spec

TLA+ Protocol Specification Challenges

• Challenge: Vagueness in English specification and the correctness in its translation to TLA+.

• Common problem for all approaches• Solutions:

– No easy solution exists! – Best to design protocols in TLA+– Consult standards committee,

product implementation teams among other things

Attacker Modelling

Attacker capability model similar to Dolev-Yao model:

•Basically, attackers can:–Eavesdrop on and store messages.–Replay old messages.– Inject or spoof unprotected messages.–Corrupt messages on the channel by

causing collisions.

•Assume the ideal cryptography: unforgeable signatures, safe encryption, and safe digest

Attacker Modelling Challenges

• Challenge: How to find all realistic attacks?– Model too strong: hide stealthy attacks

– Model too weak: missing vulnerabilities• Our solution:

– Start with a relatively strong attacker model» TLC model-checks may yield unrealistic attacks.

– Then weaken the attacker model» E.g.: the attacker can continuously corrupt a response

from the BS. » Add restrictions on attacker to exclude such attacks.

• This dynamic modification of attacker model will end up with – a complete robustness proof OR– report of all attacks

Model Checking by TLC

•TLC is a model checker for TLA+•Has both simulation mode and model

checking mode–We run simulations before a complete model

checking

•Terminate w/o violation: robustness proved

•Produce violation sequence: attack trace

Model Checking Challenges

• Challenge: State space explosions

• Our Solutions– Combine similar states without loss of

functionality into one state

– Identify symmetry in system, which will treat the different states as one common state.

– Replace some random numbers with constants having some additional properties to simulate the effects of randomness

Outline

•Motivation and our approach•Background on TLA+•General methods and

challenges•Results on WiMAX initial ranging and authentication

•Conclusions and future work

Case Studies

•Initial ranging •Authentication process

•Choices based on the criticality of function and the probability of vulnerability

Initial Ranging Process• Initial ranging: the first step

an SS communicates with a BS via message exchanges.

• An SS acquires correct timing offset and power adjustments

• The request-response communication happens until the BS is satisfied with the ranging parameters.

• ’Actual’ data communication can happen only if the initial ranging is successful.

Property to Check

•SS can get service (getting into “Done” state) infinitely often

[]<>(SSstate = “Done”)–Need to make sure that such a property is

true even without an attacker (weakest attacker model)

DOS during Initial Ranging (found by TLC Model

Checking)

DL SubframeContention-based Initial Ranging Slots

UL Subframe

REQ

REQ

REQ

REQ

Conclusions•First step towards automatic

vulnerability checking of WiMAX protocol with completeness and correctness guarantees

•Use TLA+/TLC to model malfunction DoS attacks–Avoid state space explosion in property

checking–Model attackers’ capabilities for finding

realistic attacks

•Analyzed initial ranging and authentication process in 802.16 protocols

Ongoing Work

•Development of a rigorous process in protocol specification using TLA+

•Enhance the attacker model•Check vulnerabilities in other parts

of 802.16 standards such as mobility support and handoff procedures

•Examination of WiMAX upper layer protocols: Proxy Mobile IPv4, Mobile IPv6, etc.

Thanks !http://

list.cs.northwestern.edu/

Intro to TLA+

• TLA+ is a simple extension of linear temporal logic– Temporal operations: []—forever, <>—eventually

– With primed variable (x’) for next state

– A predicate with both non-primed and primed variables defines an action: x'=x-y /\ x>y

• A system is usually specified as

Init /\ [] [Next]x

−the system satisfies Init initially and satisfies Next for all transitions

−Or simply, the system starts in Init and will do Next forever

Property Spec

•Focus on malfunction DoS attacks currently–Client needs to reach a termination

<>[] (\A i\in PartySet: Party[i].state=ObjState)

–Client may not terminate[]<>(\A \in PartySet: Party[i].state=ObjState)

Property Spec Challenges

• Challenge: TLC cannot check all properties expressible in TLA+

• Our Solution: Specify properties in restricted format

28<#>

PKMv2 Authentication Process

BS SS/MS

Auth Response

SATEK Challenge

SATEK Response

Key Response

Auth Request

Auth ACK

SATEK Request

Key Request

• SS and BS mutually authenticate each other and exchange keys for data encryption

• PKMv2 is directed by two state machines in the SS – Authentication State Machine

– TEK State Machine

• PKMv2 employs a SATEK three-way handshake for the BS and the SS to exchange security capabilities

29<#>

Authentication – TLA Model

• Each key has a life time, so the SS needs to get authorized from time to time– SS will reach the “Authorized” state infinite times

[]<>(SSstate =”Authorized”)

• TLC encounters space explosion problem–We restrict the SS to reach “Authorized”

state at most a given # of times.• With our attacker model, TLC model checking

completed w/o violation• Hence, authentication process is resistant to

any attempt under the given attacker model