Qual Exam

1
Qual Exam

• Bill Donkervoet
• 22 February, 2005

2
An Interleaved Hop-by-Hop Authentication Scheme
for Filtering of Injected False Data in Sensor
Networks

• Sencun Zhu, Sanjeev Setia, Sushil Jajodia, and
• Peng Ning

3
IHop Problem

• Sensor networks consist of many stationary nodes.
• Nodes are scattered and resource-limited.
• Compromised nodes can inject false data into
  network leading to
• Improper decision due to false information.
• Wasted power due to extraneous messages.

4
IHop Goals

• Deliver secure, authenticated messages in a
  sensor network environment.
• Detect and drop injected false data as soon as
  possible to conserve power.
• Do all of this as efficiently as possible because
  of typical constrained resources of sensor
  networks.

5
IHop Environment

• Sensor network consisting of
• Uncompromised base station (BS).
• Cluster of sensor nodes.
• Cluster head (CH) that aggregates data from
  sensor nodes.
• Communication nodes link cluster head and base
  station.
• All nodes are vulnerable to compromise.

6
IHop Details

• System parameter t
• System secure as long as ltt nodes are
  compromised.
• False data can propagate at most t2 hops.
• BS accepts a report if t1 nodes have verified
  it.
• System uses one well-defined path that can be
  adjusted if necessary.

7
Node Association

• Each communication node is associated with other
  nodes t1 hops away.
• Each cluster node is also associated with a
  communication node.
• In below example, t3.

8
Initialization

• All nodes have unique IDs and key with BS.
• Each node establishes a pairwise-key with each
  neighbor.
• Association discovery
• BS sends HELLO message down all nodes and back
  up.
• Nodes discover their upper and lower associated
  nodes.
• Associated nodes establish pairwise keys.

9
Message Authentication Code

• Each node creates up to five MACs
• Individual MAC shared with BS.
• Pairwise MACs shared with each associated node.
• Pairwise MACs shared with each neighbor node.
• Kuv is pairwise key shared by u and v.
• XMAC(E) is XOR of multiple MACs of event E.

10
Message Creation

• Each cluster node generates individual MAC of
  verified event.
• Each cluster node also generates pairwise MAC
  with upper associated node.
• CH aggregates messages from cluster nodes
• XORs individual MACs.
• Appends pairwise associated MACs.
• Message is then sent upstream towards BS.

11
Generated Report

• E, Ci, v1,v2,v3,CH, XMAC(E), MAC(KCHu4,E),MAC(K
  v3u3,E), MAC(Kv2u2,E), MAC(Kv1u1,E),
• E is event being reported with timestamp.
• Ci is cluster ID (assuming multiple clusters per
  BS).

12
Report Verification

• Each communication node
• Checks number of pairwise MACs attached to
  report.
• Removes and verifies last pairwise MAC with lower
  associated node's.
• Attaches its pairwise MAC with upper associated
  node t beginning of MAC list.
• Resulting report is forwarded upstream toward BS.
• If any step fails, the report is dropped.

13
BS Verification

• Upon receiving the report, the BS
• Computes MACs over E for verifying nodes in list.
• XORs resulting MACs and checks against XMAC.
• If the MACs do not match, the report is ignored
  as false.
• If the MACs do match, the BS knows that t1 nodes
  have verified the report and it is accepted.

14
Path Repair

• IHop depends on an established path for
  association authentication.
• This requires repair of associations upon loss or
  known-compromise of a node.
• However, this goes against the dynamic
  node-stability and routing nature of sensor
  networks.

15
IHop Security

• Secure from outside attacks because of hop-by-hop
  authentication.
• Cluster insider attacks
• t compromised cluster nodes generate false event.
• 1 uncompromised node u generates true event.
• All t1 MACs must be included to be forwarded.
• When u's MAC is checked by upper associated node,
  it will not match event E and message is dropped.

16
More Insider Attacks

• Compromised communication nodes
• Can forward anything to next upstream node.
• Can corrupt reporting or association process.
• Typical case
• Compromised node knows t secret keys.
• Generates report with those keys.
• False report will be dropped after t hops.

17
Worst Case Insider Attack

• Compromised nodes separated by t uncompromised
  nodes.
• During association phase, compromised nodes trick
  last t nodes giving them compromised IDs.
• Thus, a false message can be propagated for t
  hops t times for a total of t2 uncompromised hops.

X1
X2
CH
Y
X1
X2
CH
Y
X1
X2
CH
Y
CH
X1
X2
18
IHop Modification

• Rather than check for only lower associated node,
  a node can check for lower associated set.
• This allows false reports to be rejected
  immediately.
• A node must, however, establish pairwise keys
  with each node in lower associated set.

19
IHop Results

• IHop requires computing two more MACs than
  regular authenticated hop-by-hop communication.
• Additionally, t1 pairwise MACs are tacked onto
  each message for transmittal.

20
IHop Comments

• Even if false message is received by BS, it will
  be rejected unless t1 nodes have verified it.
• Thus, IHop only saves power of nodes by dropping
  message.
• All cluster nodes assumed within broadcast range
  of CH limiting network layout.
• Packet size of TinyOS???

21
More IHop Comments

• IHop only authenticates upstream communication,
  downstream must use another method such as
  µTESLA.
• Location-based authentication techniques - GPSR

22
A Scalable Location Service for Geographic Ad Hoc
Routing
Jinyang Ji, John Jannotti, Douglas De Couto,
David Karger, Robert Morris
23
GLS Environment

• Wireless nodes roaming around.
• Aware of location and current speed (i.e. GPS).
• Each node has unique ID number.
• Messages sent from source to destination
• Source looks up location of destination with GLS.
• Source sends message hop-by-hop using
  closest-neighbor.
• GLS operates in well-defined grid environment.

24
Grid Location System Goals

• Location service should be well distributed to
  eliminate bottlenecks.
• Unreliable nodes should still produce reliable
  lookup.
• Queries for local hosts should require only local
  communication.
• The location service should scale well to large
  numbers of nodes.

25
GLS Grid

• Area partitioned into grid
• four order-n squares compose one order-(n1)
  square.
• all order-n squares have lower-left corner at
  (a2n-1, b2n-1) for integer a, b.

26
GLS Location Information

• All nodes within order-1 square know of each
  other through periodic HELLO messages.
• Node A's location is stored by closest node in
  other three order-n squares.
• Thus, density of location servers is high closer
  to A and falls off exponentially.

27
GLS Location Example

• Node B's ID is 17.
• Location servers are closest nodes in other
• order-1 squares (2, 23, 63)
• order-2 squares (26, 31, 43)
• order-3 squares (37, 19, 20)

28
GLS Bootstrapping

• Initially, location information must be
  distributed.
• All nodes know all other nodes in order-1 square.
• LOCATION UPDATE message sent to each order-2
  square where it is routed to closest node.
• Then sent to each order-3, then order-4, ....

29
GLS Location Query

• Source node sends query to closest node, A, in
  its order-1 square (or itself).
• A sends query to closest node, B, in its order-2
  square.
• This continues until the destination is found.
• Destination replies directly to sender and all
  remaining communication is done using
  closest-neighbor routing.

30
GLS Query Example

• Two queries
• 76 -gt 17
• 90 -gt 17

31
GLS Node Mobility

• A node updates its location information based on
  its speed and the location server's order
• order-2 after moving d.
• order-n after moving 2n-2d.
• On leaving a square, a node leaves forwarding
  pointers with others.

32
GLS Analysis

• Query never leaves the smallest order-n square
  containing source and destination.
• Thus, at most n steps are required for lookup.
• Simulation using wireless-ns.
• Average query only requires 6 more hops than
  shortest path.

33
GLS Scalability

• Queries succeed on first try even with many nodes.

• Traffic scales well with increasing nodes.

34
GLS Stability

• With all nodes unstable, GLS achieves gt60
  success.

• Location database also scales well as network
  increases.

35
GLS Comments

• Variable-size order-1 squares possible.
• More efficient partitioning schemes rectangle
  with aspect ratio 1/v2 needs 2/3 location
  servers.
• No error-handling in prototype implementation.
• Routing around holes.
• Retransmission.

36
More GLS Comments

• Proactive mobility handling
• Account for movement in LOCATION UPDATE.
• Redistribute location data before leaving a
  square.
• (dis)advantages, future, etc...
• worst-case possible overlaps to prevent???