leap: efficient security mechanisms for large-scale distributed sensor networks by: sencun zhu,...
Post on 22-Dec-2015
215 views
TRANSCRIPT
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.