LEAP: Efficient Security Mechanisms for Large-Scale Distributed Sensor Networks

By: Sencun Zhu, Sanjeev Setia, and Sushil Jajodia

Presented By: Daryl Lonnon

Assumptions Static sensor nodes. Basestation is laptop class device. Nodes can store hundreds of bytes of

keying material. Neighbors not known in advance. Adversaries can eavesdrop, inject

packets, and replay old packets. Resistant to physical jamming (i.e.

spread spectrum).

Design Goals Support Various Communication

Patterns: Unicast Local Broadcast Global Broadcast

Support In-Network Processing Data Aggregation Passive Participation

Survivability Energy Efficient Avoid Message Fragmentation

LEAP Overview LEAP: Localized Encryption and

Authentication Protocol Several different types of packets:

Control Packets vs. Data Packet Broadcast Packets vs. Unicast Packets Query or Command Packets vs. Sensor

Reading Packets. Different packet types have different

cryptographic requirements.

Four Keys Leap supports four different types of

keys to meet the various cryptographic requirements: Individual Keys shared with base station Group Key shared by the base station and a

group of nodes Cluster Key shared by a node and it’s

neighbors Pairwise shared key shared by a node and

an individual neighbor

LEAP Notation is the number of nodes in the network. are principals such as communication

nodes. is a family of peudo-random functions. means encrypting message s with key

k. is the message authentication code

of message s using a symmetric key k.

vu,N

kf

ks

),( skMAC

Establishing Encryption and Authentication Keys Encryption keys and Authentication

keys are derived from a parent key K.

)0(Kencryption fK

)1(KtionAuthentica fK

Establishing Individual Node Keys Recall: individual keys are only

shared with the base station. To calculate key for node u, we

calculate: where is a master key known only to the base station.

muK

)(ufK mK

mu mK

Establishing Pairwise Shared Keys (Assumptions)

Nodes are not tamper resistant, but the time required to compromise a node after capture is bounded by some

The key establishment phase requires some time in order to finish.

estT

minT

estTT min

Establishing Pairwise Keys Key pre-distribution,

Each node is preloaded with key Each node generates master key

Neighbor Discovery At deployment, each node sets a timer to fire at Each node broadcasts a HELLO containing the

node id. Each neighbor responds with an ACK containing

Each node derives to verify the MAC.

IK)(ufK

IKu

minT

)(vfKIKv

uu :*

)|,(,: vuKMACvuv v

Establishing Pairwise Keys Pairwise Key Establishment

Each node then calculates Key Erasure

When the timer fires, each node erases and all the neighbor master keys

Simplification: don’t send ACK if a node has already heard an ACK.

If both and are calculated, only keep one.

)(ufKvKuv

IKvK

vuKuvK

Establishing Pairwise Keys (Sleeping Nodes)

Can establish keys with nodes that are sleeping by asking neighbors their neighbor list.

or use a neighbor to do path key establishment when the node awakens.

Why would you have sleeping nodes at deployment?

Performance Analysis of Pairwise Key Setup A joining node needs to verify a MAC

from each neighbor and generate a pairwise key.

Each neighbor needs to compute a MAC and generate a pairwise key.

Communication consists of a HELLO packet and a ACK from each neighbor.

Initial key storage consists of a single initial key.

Final key storage conists of one key per neighbor, plus one individual key.

Security Analysis of Pairwise Key Setup As long as then the

protocol is secure. HELLO packets are unverified, we can

preload a group key as well in order to verify HELLO packets.

minest T T

Time Slicing to Increase Security

We divide node addition into m time slices, each time slice has it’s own master key.

Each node is preloaded with the master key of the time slice it will be deployed in, as well as, Individual Keys for each subsequent time slice.

Each node then performs the pairwise key establishment algorithm based on the time slice it’s currently on.

Attacker that compromise a node within Tmin, only obtain pairwise keys established within that time slice.

Use of random number to increase security. Recall: HELLO broadcasts are unverified. Each node to be added in time slice m has a

preloaded id based on a number taken from a random stream generated from a well known random function and a seed

After time, an authenticated broadcast, like is used to send out and (the number of numbers in the stream).

If a new node is not in the stream, it is discarded as an imposter.

is

minT TESLAiNis

Establishing Cluster Keys After pairwise keys have been setup

with each neighbor , node u generates a random key , then transmits to each neighbor:

Communication and storage cost is equal to the number of neighbor nodes per node.

mvvv ,,, 21 cuK

iuvKcui Kvu )(:

Establishing Group Keys We could preload each node with a group

key. However, this does not solve group re-

keying if a node is compromised. Existing schemes have issues fitting

messages into a single packet (logical tree based methods) or send too many packets (unicast methods) or require too much encryption/decryption (cluster key methods).

Authenticated Node Revocation Required for Group Re-keying Uses uTesla in order to remove node u from

the network. The base station sends:

When a node receives this message, it stores off the verification key, and remove pairwise keys with u and recalculates it’s cluster key if u was a neighbor.

keyTESLAnextk

keyonverificatif

where

fukMACfunBasestatio

Ti

k

k

Tik

g

gg

__

_)0(

:

))0(|,(),0(,:*

'

''

Secure Key Distribution Encrypted with cluster keys, is

recursively sent to each node down whatever routing tree exists.

Each node verifies the new group key using the verification key sent in the uTesla message.

The basestation should update the group key periodically (or each node should choose a new group key based on the old one ).

'gk

)0('gk

f

)0('

gKg fK

Local Broadcast Authentication Problem: cluster keys cannot be used for

local broadcast, because they are shared with potentially compromised nodes.

Each node generates a hash chain, and sends the commitment to it’s neighbors.

When a node sends a message, it appends the next key (the AUTH key) unto the message. The AUTH key can be xor’ed with the cluster key for more security.

Performance Evaluation of Group Re-Keying

Each neighbor node to the revoked node needs to recalculate it’s cluster keys.

While sending out the group key: Each node needs to decrypt once (to get the

key) = N. Each parent needs to encrypt once (at most

N). Giving us a total of encryptions

and decryptions per node Communication cost is similar (under

worst case).

2)1(

)1(2 2

N

d

Storage Evaluation Each node stores 4 types of keys. If a node has d neighbors, it needs to

store one individual key, d pairwise keys, d cluster keys, one group key, d AUTH keys and L AUTH keys of it’s own.

Total number of keys to store is 3d+2+L.

Note: The above total does not include any keys used if doing addition of nodes using time slicing.

Security Analysis: Survivability A compromised nodes can:

Use individual key to send false sensor readings to the base station.

Use pairwise and cluster keys to inject bad routing info and erroneous sensor readings to neighbors (note: must be done with the compromised nodes id, due to local broadcast authentication).

Use of group key allows a compromised node access to viewing (but not sending) basestation broadcasts.

Defending against attacks on Routing Local Broadcast Authentication prevents

most outsider attacks (except wormhole attacks, then only during neighbor discovery phase).

Spoofing, altering or replaying routing info requires a node to hear then jam the initial message, then resend using the heard AUTH. Difficult to do, and may be overheard by the original sender.

Defending against routing attacks. HELLO flood attacks prevented since

each node only accepts packets from authenticated neighbors.

Sybil attacks fail due to the same reason.

Note: I think both of these are foiled by the random number stream as id algorithm and/or preloaded group ids.

Implementation Implemented on TinyOS using nesC. Used RC5 for all of it’s security primitives. Found that ACKs often collided, so added a

random backoff based on node density. HELLO’s also collided, so added a random

(upto 3 seconds) time after deployment before sending and multiple (3 times) resends at 3 seconds.

Assumed to be 12 seconds.minT

Implementation (continued)

Added a three-way handshake for exchanging pairwise AND cluster keys:

Code (without group keys or uTesla) was run on Mica2 Motes. Code space was 17.9KB ROM. RAM was based on number of neighbors.

).}{|,(,}{,:

).}{||,(,}{,:

.:*

vv

vv

KcuvK

cu

KcvvK

cv

KuKMACKuvu

KvuKMACKvuv

uu

Conclusions LEAP supports four types of keys: Individual,

Pairwise, Cluster, and Group. LEAP provides authenticated local broadcast. Allows for in-network processing, while limiting the

effect of compromised nodes to their immediate vicinity.

LEAP prevents or increases the difficulty of many security attacks vs. sensor networks.

LEAP has efficient key updating procedures and storage requirements per node are small.

LEAP is feasible for current generation sensor nodes.