Automatic Vulnerability Checking of
Wireless Protocols through TLA+
Prasad Narayana, Ruiming Chen, Yao Zhao,
Yan Chen and Hai Zhou
Northwestern University, Evanston IL
Z. Judy Fu
Motorola Labs, Schaumburg IL
Funded by Motorola Center for Seamless
1<#>
Communications
Outline
•
•
•
•
•
Motivation
Our approach
Background on TLA+
General methods and challenges
Results on WiMAX initial ranging
and authentication
• Conclusions and future work
2<#>
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
3<#>
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]
4<#>
Outline
•
•
•
•
•
Motivation
Our approach
Background on TLA+
General methods and challenges
Results on WiMAX initial ranging
and authentication
• Conclusions and future work
5<#>
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
6<#>
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
7<#>
Outline
•
•
•
•
•
Motivation
Our approach
Background on TLA+
General methods and challenges
Results on WiMAX initial ranging
and authentication
• Conclusions and future work
8<#>
Why TLA+
• A logic resulted from the past 20 years research
on concurrent reactive systems
• One language for both system spec and proof logic
• Language is based on normal mathematics
– Both abstract and detailed specs can be done at the
right levels
– System concepts are clean in math:
composition: /\ nondeterministic: \/ implementation: 
• Modularity is employed for large specs
• Systems automatically model-checked by TLC
9<#>
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
10<#>
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
11<#>
Example: Simplifed SSL
• CS: (C, VerC, SuiteC)
• SC: (VerS, SuiteS, KeyS)
• CS: (EKeyS(SecretC))
12<#>
Protocol Spec
• Step 1: Client C sends message to server S:
• Step 2: Sever S responds to C with its public key KeyS:
• Step 3: Client C sends SecretC encrypted by KeyS:
13<#>
Attacker Spec
Intercept SC messages
Intercept CS2 messages
14<#>
Property of Secrecy
Secrecy == [](secret=0)
• Model check:
Protocol /\ Attacker  Secrecy
15<#>
Result from TLC
•
•
•
•
•
•
•
Error: Invariant Correctness is violated. The behavior up to this point is:
STATE 1: <Initial predicate>
/\ secret = 0
/\ msg = << >>
STATE 2: <Action line 9, col 10 to line 11, col 75 of module ssl>
/\ secret = 0
/\ msg = [type |-> "CS1", Name |-> "C", Ver |-> 1, Suite |-> 2]
STATE 3: <Action line 13, col 8 to line 15, col 71 of module ssl>
/\ secret = 0
/\ msg = [type |-> "SC", Ver |-> 6, Suite |-> 7, Key |-> 4]
STATE 4: <Action line 22, col 12 to line 25, col 46 of module ssl>
/\ secret = 0
/\ msg = [type |-> "SC", Ver |-> 6, Suite |-> 7, Key |-> 5]
STATE 5: <Action line 17, col 10 to line 20, col 66 of module ssl>
/\ secret = 0
/\ msg = [type |-> "CS2", Key |-> 5, Secret |-> 3]
STATE 6: <Action line 27, col 12 to line 31, col 44 of module ssl>
/\ secret = 3
/\ msg = [type |-> "CS2", Key |-> 4, Secret |-> 3]
Secret is known
by attacker
Client and Sever do not know
that the secret is not a “secret”
now
16<#>
Outline
•
•
•
•
•
Motivation
Our approach
Background on TLA+
General methods and challenges
Results on WiMAX initial ranging
and authentication
• Conclusions and future work
17<#>
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
18<#>
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
19<#>
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 designing protocols in TLA+
– Consult standards committee, product
implementation teams among other
things
20<#>
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,
21<#>
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
22<#>
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)
23<#>
Property Spec Challenges
•
Challenge: TLC cannot check all
properties expressible in TLA+
•
Our Solution: Specify properties
in restricted format
24<#>
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
25<#>
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
26<#>
Outline
•
•
•
•
•
Motivation
Our approach
Background on TLA+
General methods and challenges
Results on WiMAX initial ranging
and authentication
• Conclusions and future work
27<#>
Case Studies
• Initial ranging
• Authentication process
• Choices based on the criticality of
function and the probability of
vulnerability
28<#>
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.
29<#>
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)
30<#>
DOS during Initial Ranging
(found by TLC Model Checking)
DL Subframe
UL Subframe
Contention-based
Initial Ranging Slots
REQ
REQ
31<#>
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
32<#>
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
33<#>
Outline
•
•
•
•
•
Motivation
Our approach
Background on TLA+
General methods and challenges
Results on WiMAX initial ranging
and authentication
• Conclusions and future work
34<#>
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
35<#>
Future Work
• Development of a rigorous process in
protocol specification using TLA+
• Check vulnerabilities in other parts of
802.16 standards such as mobility
support and handoff procedures
• Exploration of more security
properties: secrecy, resource
exhaustion DoS
36<#>
Thanks
37<#>
Our Approach
TLA Modeling:
Identify critical parts
of function to assess
the vulnerability
aspect of those parts
Formal
Specification of
Protocol Process
and Attacker
actions using TLA
Logic-based Analysis
and Verification:
Rigorous, Logicbased Analysis using
Model-Checking and
Simulation using TLC
38<#>
Related Work (2)
• Automatically check with formal language
– For security network protocols
» CSP and FDR [Lowe96]
» MurØ [Shmatikov98]
» Symbolic traces and PS-LTL [Corin06]
– For DoS attack
» “A formal specification and verification method
for the prevention of denial of service” [Yu88]
» “Game-based analysis of denial-of-service
prevention protocols” [Mahimkar05]
39<#>
Example: Euclid's Algorithm
• Init == x=a /\ y=b
• Next == (x>y /\ x'=x-y) \/ (y>x /\
y'=y-x)
• Euclid(a,b) == Init /\ [][Next]<x,y>
• Property == <>[](x=GCD(a,b))
• Correct == (a>0 /\ b>0) /\ Euclid(a,b)
=>Property
40<#>
DOS during Initial Ranging
(found by TLC Model Checking)
DL Subframe
UL Subframe
Contention-based
Initial Ranging Slots
Attacker fills all slots, making its requests collide with requests from
other SS, thereby denying all new SS a chance to complete ranging
41<#>