1 Yan Chen Northwestern University Lab for Internet and Security Technology (LIST) in Northwestern.

1<#>

Yan ChenNorthwestern University

Lab for Internet and Security Technology (LIST) in

Northwestern

Introduction• Work on network security, measurement

and monitoring

• Five Ph.D. students and two M.S. students

• Collaborate widely – NU colleagues: Peter Dinda, Ming-Yang Kao,

Aleksandar Kuzmanovic, Gokhan Memik, and Hai Zhou (and their students)

– Other industry & academia researchers, e.g., Judy Fu, Phil Robert and Pete McCann in Motorola.

2<#>

3<#>

Automatic Vulnerability Checking of Wireless

Protocols through TLA+

Published in Workshop of Network Protocol Security 2006

4<#>

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

• Avoid state space explosion in property checking• Model attackers’ capabilities for finding realistic attacks

5<#>

Case Studies

•Initial ranging •Authentication process

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

6<#>

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.

7<#>

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)

8<#>

DOS during Initial Ranging (found by TLC Model

Checking)

DL SubframeContention-based Initial Ranging Slots

UL Subframe

REQ

REQ

REQ

REQ

9<#>

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

10<#>

Ongoing 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

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

Intrusion Detection and Mitigation for WiMAX Networks

(WAIDM)

Published in IEEE Symposium on Security and Privacy, ACM SIGCOMM, IEEE/ACM Transaction on Networking, IEEE Infocom, ACM SIGCOMM IMC, IEEE ICDCS

12

The Spread of Sapphire/Slammer Worms

13

How can it affect cell phones?•Cabir worm can infect a cell phone

– Infect phones running Symbian OS

– Started in Philippines at the end of 2004, surfaced in Asia, Latin America, Europe, and US

– Posing as a security management utility

– Once infected, propagate itself to other phones via Bluetooth wireless connections

– Symbian officials said security was a high priority of the latest software, Symbian OS Version 9.

•With ubiquitous Internet connections, more severe viruses/worms for mobile devices will happen soon …

Adaptive Intrusion Detection and Mitigation for WiMAX Networks

(WAIDM)• Attached to a switch connecting BS as a black box

• Enable the early detection and mitigation of global scale attacks

• Could be differentiator for Motorola’s 802.16 products

Original configuration WAIDM deployed

Internet

802.16BS

Users

(a)

(b)

802.16BS

Users

Switch/BS controller

Internet

sca

n

po

rtW

AID

Msy

ste

m

802.16BS

Users

802.16BS

Users

Switch/BS controller

Features of WAIDM •Scalability (ready for field testing)

–Online traffic recording » Reversible sketch for data streaming computation

» Record millions of flows (GB traffic) in a few hundred KB

» Infer the key characteristics (e.g., source IP) of culprit flows for mitigation

–Online sketch-based flow-level anomaly detection»Adaptively learn the traffic pattern changes

•Accuracy (initial design & evaluation done)Integrated approach for false positive reduction

– Automatic polymorphic worm signature generation(Hamsa)

– Network element fault Diagnostics

WAIDM Architecture

Reversiblesketch monitoring

Filtering

Sketch based statistical anomaly detection (SSAD)

Local sketch records

Sent out for aggregation

Remote aggregatedsketchrecords

Per-flow monitoring

Streaming packet data

Normal flows

Suspicious flows

Intrusion or anomaly alarms

Keys of suspicious flows

Keys of normal flows

Data path Control pathModules on the critical path

Signature-based detection

Polymorphic worm detection (Hamsa)

Part ISketch-basedmonitoring & detection

Part IIPer-flowmonitoring & detection

Modules on the non-critical path

Network fault diagnosis (ODD)

Hamsa: First Network-based Zero-day Polymorphic Worm Signature Generation

System• Fast: in the order of seconds

• Noise tolerant and attack resilient

• Detect multiple worms in one protocolProtocolClassifier

UDP1434

HamsaSignatureGenerator

WormFlow

Classifier

TCP137

. . .TCP80

TCP53

TCP25

NormalTraffic Pool

SuspiciousTraffic Pool

Signatures

NetworkTap

KnownWormFilter

Normal traffic reservoir

Real time

Policy driven

18<#>

Thanks

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<#>

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