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.

Establishing Encryption and Authentication Keys Encryption keys and Authentication keys are derived from a parent key K.

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.

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.

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.

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.

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.

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.

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.

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.

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 ).

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).

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.

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.

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.