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 Communications Automatic Vulnerability Checking of Wireless Protocols through TLA+
41
Embed
1 Prasad Narayana, Ruiming Chen, Yao Zhao, Yan Chen and Hai Zhou Northwestern University, Evanston IL Z. Judy Fu Motorola Labs, Schaumburg IL Funded by.
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
Prasad Narayana, Ruiming Chen, Yao Zhao, Yan Chen and Hai Zhou
Northwestern University, Evanston IL
Z. Judy FuMotorola Labs, Schaumburg IL
Funded by Motorola Center for Seamless Communications
Automatic Vulnerability Checking of Wireless Protocols through
TLA+
2<#>
Outline
•Motivation•Our approach•Background on TLA+•General methods and
challenges•Results on WiMAX initial ranging
and authentication•Conclusions and future work
3<#>
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
4<#>
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]
5<#>
Outline
•Motivation•Our approach•Background on TLA+•General methods and
challenges•Results on WiMAX initial ranging
and authentication•Conclusions and future work
6<#>
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
7<#>
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
8<#>
Outline
•Motivation•Our approach•Background on TLA+•General methods and
challenges•Results on WiMAX initial ranging
and authentication•Conclusions and future work
9<#>
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
• Modularity is employed for large specs• Systems automatically model-checked by TLC
10<#>
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
11<#>
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
12<#>
Example: Simplifed SSL
•CS: (C, VerC, SuiteC)
•SC: (VerS, SuiteS, KeyS)
•CS: (EKeyS(SecretC))
13<#>
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:
14<#>
Attacker Spec
Intercept SC messages
Intercept CS2 messages
15<#>
Property of Secrecy
Secrecy == [](secret=0)
•Model check:
Protocol /\ Attacker Secrecy
16<#>
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
17<#>
Outline
•Motivation•Our approach•Background on TLA+•General methods and challenges
•Results on WiMAX initial ranging and authentication
•Conclusions and future work
18<#>
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
19<#>
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
20<#>
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
21<#>
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
22<#>
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
23<#>
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)
24<#>
Property Spec Challenges
• Challenge: TLC cannot check all properties expressible in TLA+
• Our Solution: Specify properties in restricted format
25<#>
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
26<#>
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
27<#>
Outline
•Motivation•Our approach•Background on TLA+•General methods and
challenges•Results on WiMAX initial ranging and authentication
•Conclusions and future work
28<#>
Case Studies
•Initial ranging •Authentication process
•Choices based on the criticality of function and the probability of vulnerability
29<#>
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.
30<#>
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)
31<#>
DOS during Initial Ranging (found by TLC Model
Checking)
DL SubframeContention-based Initial Ranging Slots
UL Subframe
REQ
REQ
REQ
REQ
32<#>
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
33<#>
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
34<#>
Outline
•Motivation•Our approach•Background on TLA+•General methods and
challenges•Results on WiMAX initial ranging
and authentication•Conclusions and future work
35<#>
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
36<#>
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
37<#>
Thanks
38<#>
Our Approach
Identify critical parts of function to assess the vulnerability aspect of those parts
TLA Modeling:
Formal Specification of
Protocol Process and Attacker
actions using TLA
Logic-based Analysis and Verification:
Rigorous, Logic-based Analysis using Model-Checking and Simulation using TLC
39<#>
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