Transcript Securing Wireless Mesh Networks - WiNS Lab

2007 Network/Computer Security Workshop
Lehigh University, May 2007
Securing Wireless Mesh Networks
Yanchao Zhang
Department of Electrical & Computer Engineering
New Jersey Institute of Technology
In collaboration with:
Professor Yuguang “Michael” Fang
Department of Electrical & Computer Engineering
University of Florida
Roadmap
Introduction to wireless mesh networks

Necessity, architecture, state of the art
Security issues
Our solutions
Conclusion & future work
2/43
Mesh Networks: why do we need them?
Ubiquitous broadband Internet access
Cellular networks
PSDN
RNC
Internet
• Wide area coverage (km range)
• Low speed
W-CDMA: 384 kb/s ~ 2 Mb/s
 CDMA2000: 144 kb/s ~ 2.4 Mb/s

• High deployment costs
3/43
Mesh Networks: why do we need them?
Ubiquitous broadband Internet access
Wireless LAN
Interne
t
• High speed

802.11b: 11 Mb/s, 802.11a/g: 54 Mb/s, 802.11n: 540 Mb/s
• Low deployment costs
• Small coverage (up to 300m for 802.11)
4/43
Wireless Mesh Networks (WMNs)
Internet
(Akyildiz et al., 2004)
T1/E1
WiMax
mesh router
mesh
5/43
Merits of Wireless Mesh Networks
High speed
Extended coverage (multi-hop comm.)
Low deployment costs
High robustness (multiple routes)
Simple configuration and maintenance
Good network scalability
…
6/43
Application Scenarios
Broadband home networking
Community and neighborhood networking
Enterprise networking
Metropolitan area networks
Intelligent transportation systems
Security surveillance systems
Building automation
…
7/43
State of the Art
Academia


SIGCOMM, INFOCOM, MobiCom, MobiHoc, ICNP, ICDCS,
IEEE JSAC …
MIT, CMU, Rice, Georgia Tech, UCSB, UF, Stony Brook …
Industry

Microsoft, Intel, Nortel, Nokia, MeshNetworks (Lucent),
Tropos, Kiyon, BelAir, Strix, SkyPilot, MeshDynamics …
Standardization activities

IEEE 802.11/15/16
Deployment practices

Seattle, New York, San Francisco, London, Rome, Paris…
8/43
Roadmap
Introduction to wireless mesh networks

Necessity, architecture, state of the art
Security issues
Our solutions
Conclusion & future work
Other security projects
9/43
Classification
Infrastructure security

Security of signaling and data traffic transmitted
over the wireless mesh backbone
Application security

Security of mesh clients’ concrete applications
Network access security

Security of communications among a mesh router
and mesh clients it serves
10/43
Network Access Security
WMN
backbone
Our goal
Internet
Why difficult to achieve?




Mesh routers are designed to accept open access requests
from most likely unknown mesh clients
Open access to wireless channels
Multi-hop, cooperative communications
Dynamic network topology due to client mobility
11/43
Network Access Security Issues
WMN
backbone
Our goal
Internet
Router-client authentication
Router-client key agreement
Client-client authentication
Client-client key agreement
12/43
Network Access Security Issues
Bogus-beacon flooding attack
WMN
backbone
beacon
Internet

mesh
bogus beacon
Allowing the attacker to
- Beguile mesh clients into always processing beacons
- Impede the Internet access of mesh clients
13/43
Network Access Security Issues
Incontestable billing
Location privacy

Mesh clients can travel incognito
Secure routing and MAC protocols
When Internet marries multi-hop wireless

DoS/DDoS mitigation, worm detection &
prevention, IP traceback, intrusion detection …
14/43
Our Solutions
Router-client authentication
Router-client key agreement
Client-client authentication
Client-client key agreement
Mitigating bogus-beacon flooding attack
Incontestable billing
Location privacy
15/43
Network Model
A large-scale WMN comprises many domains

Each domain is operated by an independent
network operator of arbitrary scale
Multi-hop uplink

A mesh client transmits packets in one hop or
multiple hops to the mesh router
Single-hop downlink
The router sends packets in one hop to all clients
 Merits: save energy of clients; facilitate the
transmission of signaling data …

16/43
Old Home-Foreign Trust Model
roaming agreement
Foreign
domain
Internet/
PSTN
Home
domain
trust
(Used by cellular & mobile IP networks)
Difficult to establish pairwise roaming agreements
among numerous WMN operators
Significant authentication signaling traffic

May invite DoS/DDoS attacks
Long authentication latency
Irresolvable billing disputes
17/43
Our Model: Client-Broker-Operator
broker 1
broker 2
pass
operator 1
operator n
# of brokers << # of WMN operators
18/43
Merits of Client-Broker-Operator Model
For mesh clients

Enjoy single-sign-on on-demand broadband
Internet access from any WMN operator
For WMN operators
Just need to trust one or a few brokers
 Have all mesh clients as potential customers
 Reduce administration & customer-service costs

For brokers

Make profits by imposing transaction/subscription
fees to mesh operators/clients
19/43
Notation
Bi : broker i
Oi : operator i
Ci ,k : NAI of client k of Bi (e.g., Alice@GatorCountry)
PCi ,k : electronic pass of client Ci ,k
KCi ,k : pass-key corresponding to PCi ,k
Ri ,k : NAI of router k of Oi (routerID@operatorID)
PRi ,k : electronic pass of router Ri ,k
K Ri ,k : pass-key corresponding to PRi ,k
h : a hash function such as SHA-1
20/43
Public-Key Cryptography (PKC)
Everyone has a unique public/private key pair
Certificate-based PKC (e.g., RSA or DSA)
Alice’s public key, pubA, is a random string
 Need a certificate binding pubA to Alice
 certA := <Alice, pubA, other fields, CA’s signature>

ID-based PKC (by Shamir, 1984)
Alice’s pubA can be her publicly known identity
information such as her email address
 No need for certificates

21/43
The Pairing Technique
G1 , G2 : two cyclic groups of prime order q (  160 bits)
W : an arbitrary generator of G1
H : hashing inputs to non-zero elements in G1
f : G1  G1  G2 (pairing), such that,
U , V  G1 , a, b  [1, q  1]
 f (aU , bV )  f (aU , V )b  f (U , bV )a  f (U , V ) ab

 f (U , V )  f (V , U ) (symmetric)
(bilinear)
Pairing parameters <G1, G2, W, H> can be predefined
by standards bodies such as IETF, as is done for
Diffie-Hellman parameters for use in IPsec
22/43
Router Pass (R-PASS)
Operator Oi :
 Select a master secret  Oi  (1, q  1)
 Issue to router Ri ,k
 PRi ,k : ( Ri ,k , expiry-time)  router pass (public)
 K :  H ( P )  G
 pass-key (private)
Oi
Ri ,k
1
 Ri ,k
Given <PRi ,k , K Ri ,k >, it is infeasbile to derive  Oi , as
the Discrete Logarithm problem is hard in G1
23/43
Client Pass (C-PASS)
Broker Bi :
 Select a master secret  Bi  (1, q  1)
 Issue to client Ci ,k
 PCi ,k : (Ci ,k , expiry-time)  client pass (public)
 K :  H ( P )  G
 pass-key (private)
Bi
Ci ,k
1
 Ci ,k
Given <PCi ,k , K Ci ,k >, it is infeasbile to derive  Bi , as
the Discrete Logarithm problem is hard in G1
24/43
Authentication & Key Agreement (AKA)
Inter-domain router-client AKA

A client roams from a WMN domain to another
Intra-domain router-client AKA

A client roams in the same WMN domain
Client-client AKA

Two clients in the same WMN domain perform AKA
25/43
Inter-Domain Client-Router AKA
C1,1
R1,1
PR1,1 , t1, otherInfo, SIGKR (t1, otherInfo)


broadcast
1,1
 PR1,1 , K R1,1 
 PC1,1 , KC1,1 
PC1,1 , t2, SIGKC (t2 )


unicast
1,1
O1
O1

P
:

(
C
 C1,1
1,1 , expiry-time) temporary pass
 O1
O1
K
:


H
(
P
temporary pass-key
O1
C1,1 )

 C1,1
PCO1,11 , ENCPC ( KCO1,11 )


unicast
1,1
26/43
Inter-Domain Client-Router AKA
Key agreement
R1,1
 PR1,1 , K R1,1 
R  f ( K R , H ( PCO ))
1
1,1
1,1
,K
C
 f ( KCO1,11 , H ( PR1,1 ))
1,1
1,1 , R1,1
O1
C1,1 C1,1

C1,1
P
O1
C1,1 C1,1
f ( K R1,1 , H ( PCO1,11 ))  f (  O1 H ( PR1,1 ), H ( PCO1,11 ))
 f ( H ( PR1,1 ),  O1 H ( PCO1,11 )) (bilinear)
 f (  O1 H ( PCO1,11 ), H ( PR1,1 )) (symmetric)
 f ( K CO1,11 , H ( PR1,1 ))
27/43
Intra-Domain Router-Client AKA
R1,2
C1,1
PR1,2 , t1, otherInfo, SIGK R (t1, otherInfo)



O
O

P
,
K

broadcast
C
C

1,2
 PR1,2 , K R1,2
C
1,1 , R1,2
PCO1,11 , t2 , h(t1 || t2 || C1,1 , R1,2 )

unicast
1
1
1,1
1,1
 f ( KCO1,11 , H ( PR1,2 ))
28/43
Client-Client AKA
Client-client AKA
Two clients ascertain that they are served by the
same WMN domain
 Two clients establish a shared key to encrypt and
authenticate traffic between them
 Can be done on demand

29/43
Client-Client AKA
C1,1
 PCO1,11 , KCO1,11 
 PCO2,11 , KCO2,11 
PCO1,11 , r1


C
2,1 ,C1,1
C2,1
 f ( KCO2,11 , H ( PCO1,11 ))
PCO2,11 , r2 , h(r1 || r2 || C2,1 ,C1,1 )


C
O1
O1

f
(
K
,
H
(
P
C1,1
C2,1 ))
1,1 ,C2,1
? h ( r1 || r2 || C1,1 ,C2,1 )  h( r1 || r2 || C2,1 ,C1,1 )
h(r1 || r2 || PCO1,11 ||C1,1 ,C1,2 )


? h( r1 || r2 || PCO1,11 || C2,1 ,C1,1 )  h( r1 || r2 || PCO1,11 || C1,1 ,C2,1 )
30/43
Our Solutions
Router-client authentication
Router-client key agreement
Client-client authentication
Client-client key agreement
Mitigating bogus-beacon flooding attack
Incontestable billing
Location privacy
31/43
Bogus-Beacon Flooding Attack
R1,1
WMN
backbone
beacon
Internet
mesh
bogus beacon
Allowing the attacker to


Deceive mesh clients into endless signature verifications to
check authenticity of beacons
Impede the network access of mesh clients
Defense: one-way hash chain
32/43
Defense against Bogus-Beacon Flooding
Router R1,1
Select an integer n and a random secret bn
 Compute by= h(by+1), for 1 ≤ y ≤ n-1
h
h
h
h
h
b1  b2   bn2  bn1  bn


Deriving by from by+1 is very efficient, but the
opposite is computationally infeasible
b1
ts
b2
b3
b4
bn 2
bn 1
bn
b1'

super beacon interval
n
33/43
Defense against Bogus-Beacon Flooding
At time = ts  ( y  1) , router R1,1 broadcasts beacon:
<PR1,1 , ts ,  , b1, SIGK (ts ,  , b1 ), otherInfo, y, by , h(prior fields || by ) 
R1,1
message authentication code
Client C1,1
case 1: mutual authentication has not been done
1. Ascertain that PR1,1 has not expired
2. Validate SIGK R (ts ||  || b1 )
1 ,1
3. Check that b1  h y 1 (by )
4. Compare h (prior fields|| by ) to the received one
5. Record <ts ,  , b1 > and set cb  y , bcb  by
34/43
Defense against Bogus-Beacon Flooding
At time = ts  ( y  1) , router R1,1 broadcasts beacon:
<PR1,1 , ts ,  , b1, SIGK (ts ,  , b1 ), otherInfo, y, by , h(prior fields || by ) 
R1,1
message authentication code
Client C1,1
case 2: mutual authentication has been done
(C1,1 knows  t1 ,  , b1 , cb , bcb  )
1. Ascertain that PR1,1 has not expired
2. Check that cb  y and bcb  h y  cb (by )
3. Compute h (prior fields|| by ) to the received one
4. Set cb  y , bcb  by
35/43
Defense against Bogus-Beacon Flooding
Analysis
A router performs one signature generation every n
broadcast beacons
 A client carries out one signature verification every
n broadcast beacons

b1
ts
b2
b3
b4
bn 2
bn 1
bn
b1'

super beacon interval
n
36/43
Incontestable Billing
R1,1
C1,1
Challenges



WMN operators may overcharge
Mesh clients may deny the received network services
Intermediate clients desire reward for forwarding traffic
Our solution: a real-time hash-chain approach
37/43
Incontestable Billing
R1,1
C1,1
h
h
b1  b2 
h
h
h
 bn2  bn1  bn
C1,1



Create a one-way hash chain with each hash value
associated with a monetary value x0
Send the signed (b1, x0) to R1,1 as a payment commitment
Periodically release hash values in sequence
R1,1


Record the signed (b1, x0) and the last bm s.t. b1=hm-1(bm)
Redeem bm at broker B1 and get paid mx0
38/43
Incontestable Billing
R1,1
C1,1
How to pay intermediate clients?



C1,1 pays R1,1 what R1,1 and others should get
R1,1 pays each client using the hash-chain approach
Merit: each client just has a payment relationship with R1,1
instead of each of other clients
Analysis



Each client must pay in real time to avoid service cutoff
He cannot deny the payment due to the signed commitment
Operators cannot fake hash values to overcharge clients
39/43
Location Privacy
Mesh clients prefer to travel incognito

Remain anonymous to both visited WMN operators
and potentially malicious eavesdroppers
Solution
A client uses dynamic (pass, pass-key) pairs
 A secure, lightweight way to refresh client
pass/pass-key pairs

40/43
Conclusion
Identified security requirements & challenges
in multi-hop wireless mesh networks
Proposed a client-broker-operator trust model
Presented efficient solutions to
Router-client and client-client AKA
 Mitigating bogus-beacon flooding attack
 Incontestable billing
 Location privacy

41/43
Future Work
Secure wireless mesh backbone
Secure routing and MAC protocols
When Internet marries multi-hop wireless
DoS/DDoS mitigation
 Worm detection & prevention
 IP traceback
 Intrusion detection
…

42/43
References
Y. Zhang and Y. Fang, “ARSA: An Attack-Resilient
Security Architecture for Multihop Wireless Mesh
Networks,” IEEE JSAC, 24(10), Oct. 2006
 Y. Zhang and Y. Fang, “A Secure Authentication
and Billing Architecture for Wireless Mesh
Networks,” ACM Wireless Networks, to appear

43/43