Automatic Vulnerability Checking of
Wireless Protocols through TLA+
Prasad Narayana, Ruiming Chen, Yao Zhao,
Yan Chen and Hai Zhou
Lab for Internet and Security Technology
Northwestern University, Evanston IL
Z. Judy Fu
Motorola Labs, Schaumburg IL
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 testbenches 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
Stop
No
Attacker
TLA+
Specification
TLC
Model
Checking
Found
Vulnerability ?
Yes
Property
TLA+
Specification
Weaken
Attacker
Analyze
Severity
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 Subframe
UL Subframe
Contention-based
Initial Ranging Slots
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
PKMv2 Authentication Process
• 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
BS
SS/MS
uest
q
e
R
h
t
u
A
Auth Respons
e
Auth ACK
SATEK Challe
nge
quest
e
R
K
E
T
SA
SATEK Respo
nse
est
Ke y R e q u
Key Response
28<#>
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
29<#>