WSN: SECURITY

Peter ChapinAbe Barth-WerbRob RohrDiana Tatar

CS295/361Wireless Sensor NetworksFeb. 12, 2008

Agenda Security Overview

Peter Chapin

Simulation Environment – TOS1.xAbe Barth-Werb

TinySec – TOS1.xRob Rohr

MiniSec – TOS2.xDiana Tatar

WSN Security(Background)

Peter C. Chapin

Security Services, Part 1 Confidentiality

Keep data from unauthorized eyes (encryption) Authentication

Only accept packets from authorized senders (MAC, not expensive digital signatures)

Data Integrity Ensure packets not maliciously modified in

flight (MAC replaces normal CRC). BUT... don't interfere with in-network data

aggregation (so no end-to-end protection).

Security Services, Part 2 Anti-Replay

Reject authenticated packets that are “replayed” by an adversary to confuse the network. Can't keep arbitrary amounts of information about

past packets. One approach: label each outgoing packet with a

counter. Receiver ignores old labels. TinySec does nothing to protect against replays.

Authors argue this is outside the scope of the link layer.

Other Kinds of Attacks Traffic Analysis

A concern when the fact communication has taken place is itself revealing.

Normally thwarted by generating spurious traffic. Obvious this is undesirable in a WSN

Denial of service Keep nodes busy with many queries. Prevents

nodes from engaging in normal activity. Sleep Deprivation

A form of denial of service specifically intended to wear down batteries.

Special Challenges, Part 1 Small Computational Resources

Public key methods too computational intensive (even ECC is too hard).

Symmetric algorithms must be selected carefully Must be easy to compute Must have small memory footprint (instruction and

data) No space for large arrays of pre-computed data.

Skipjack seems favored by some researchers. MiniSec authors used OCB mode

Computes MAC and cipher text in a single pass.

Special Challenges, Part 2 Extremely Powerful Adversaries

Adversary not limited to mote technology! Can use a cluster of workstations to crack

security in recorded packets. Can use powerful antennae and transceivers

to interact with WSN from a “safe” distance. BUT...

WSN can't send/receive packets too quickly. Hard for adversary to collect data or execute

trial-and-error style attacks.

Special Challenges, Part 3 No Physical Security!

Adversary who steals a mote can: Manipulate sensors to generate bogus data. Attempt to extract key material from it.

Countermeasures: Tamperproof packaging

Does it really exist? Key revocation protocols

Not all applications suffer from a lack of physical security.

Special Challenges, Part 4 Low Power Operation

Must minimize radio overhead. Can't bulk up packets with security headers.

Large IVs, large nonces, long time stamps... All bad.

Must use clever techniques to minimize packet size Pack bits into other header fields Maintain synchronized state on two

communicating motes; use headers only to keep synchronized.

Key Distribution How do the nodes get the keys?

Use a single, network-wide key Simple to deploy Allows easy network auto-configuration and

self-healing. BUT... a single node compromise breaks the

network. Use a different key for each communicating

pair Introduces a key distribution problem. Lots of research on this.

Probabilistic Key Sharing

“A Key Management Scheme for Distributed Sensor Networks”Eschenauer and Gligor, CCS '02

Each node has kkeys drawn randomlyfrom a pool of size P

Shared keys

Radioconnectivity

SNEP / TinySec / MiniSec SNEP

Oldest of the three Relatively high packet overhead (8 bytes)

TinySec Leaves out key distribution and anti-replay

MiniSec Provides anti-replay support using synchronized

counters. But uses clever methods to keep counters in synch

OCB mode for faster MAC + ciphertext computation.

TinyOS Simulation EnvironmentTOSSIM, TinyViz

Abe Barth-Werb

BEWARE!Tiny OS 1 ONLY!!!

Cool stuff from 40,000 feet Radio Loss Simulation

Lossy builder Packet Injection

SerialForwarder TOSSIM Power TinyViz

TinyViz plug-ins

DEMO-O-CLOCK!!!!

TINYSECAN OVERVIEW

It’s tiny. Really.And somewhat secure.

Rob Rohr

TinySec Architectural Features Single shared global cryptographic

key Link layer encryption and integrity

protection transparent to applications New radio stack based on original

Cryptography based on a block cipher

KKK

TinySec Summary Security properties

Access control Integrity Confidentiality

Performance 5 bytes / packet overhead Peak bandwidth (8 bytes data):

25 packets/sec vs. 40 packets/sec (TinySec) (MHSR)

Block Ciphers Pseudorandom permutation

(invertible) DES, RC5, Skipjack, AES Maps n bits of plaintext to n bits of

ciphertext

Used to build encryption schemes and message authentication codes (MAC)

nKnk

k

E }1,0{}1,0{: }1,0{

Packet Format

Key DifferencesNo CRC -2 bytesNo group ID -1 bytesMAC +4 bytesIV +4 bytes

Total: +5 bytes

dest

AM IV

len

gt

h data MAC

2 1 4 1 4

Encrypted

MAC’ed

TinySec Interfaces

TinySec TinySecM: bridges radio stack and crypto libraries

BlockCipher 3 Implementations: RC5M, SkipJackM,

IdentityCipher (SRI has implemented AES)

BlockCipherMode CBCModeM: handles cipher text stealing

No length expansion when encrypting data MAC

CBCMACM: computes message authentication code using CBC

MHSRTinySecM

TinySecM

CBC-ModeM

RC5M

CBC-MACM

Security Analysis Access control and integrity

Probability of blind MAC forgery 1/232

Replay protection not provided, but can be done better at higher layers

Confidentiality – Reused IVs can leak information IV reuse will occur after 216 messages from each node

[1 msg / min for 45 days] Solutions

increase IV length adds packet overhead key update protocol adds complexity

Applications have different confidentiality requirements Need a mechanism to easily quantify and configure

confidentiality guarantees Applications may provide IVs implicitly (e.g.

timestamps) Apps may guarantee sufficient variability in their messages

Cipher Performance

2 block cipher operations per block, which take 1.0 ms/block For comparison, takes an ~4.8 ms to send one block over radio Encryption and MAC can be overlapped with

transmission/reception

Implementation

Block Operation Time (cycles)

Block Operation Time (ms)

RC5 C only ~5750 + 1.70 ms

RC5 SPINS: C + asm

~2775 avg 0.75 ms

SkipJack

TinySec: C only

~2500 0.70 ms

RC5 TinySec: C + asm

~1775 avg 0.50 ms

Discussion Short packets have more overhead

Min data size is 8 bytes (size of block cipher)

Packet length not affected for more than 8 bytes of data

Acknowledgments can be authenticated with no extra work or overhead 1/256 chance of forgery

Group ID no longer supported

Usage: How does this change my life? Need to be aware of keys & keyfile

Currently, keys part of program, not intrinsic to mote (similar to moteID)

Makerules generates a keyfile if none exists, used for programming all motes;

Keyfile resides in user’s home directory. Manual transfer needed to install motes from different computers.

Only application level code change: Just use SecureGenericComm instead of GenericComm

Works in simulator

Conclusions TinySec can provide transparent

security for applications Access control Integrity Confidentiality

Problems not addressed: Jamming Node or key compromise Replay Denial of service

MINISEC:A SECURE SENSOR NETWORK COMMUNICATION ARCHITECTURE

Developed by Carnegie Mellon University

Diana Tatar

Goal: Design a secure sensor network

communication protocol that provides Data secrecy Authentication Replay protection Freshness

Low energy consumption Resilient to Lost Messages

Comparison

Energy Consumption

Low High

Low

High

Secu

rity

ZigBee

TinySec

MiniSec SPINS

MiniSec-U: Unicast Communication

Offset Codebook Mode (OCB) - Encryption Block cipher mode of operation Authenticated encryption in a single pass

OCB

Plaintext

Ciphertext MAC/Tag

OCBKey

IV/Nonce

CiphertextMAC/Tag

Plaintext Error Initialization vector (IV) ensures that same

plaintext does not encrypt to same ciphertext Needs to be non-repeating An incrementing counter is used

KeyIV/Nonce

Method 1: Send IV with Packet

E

Plaintext

KeyIV

CiphertextMAC/Tag

D KeyIV

CiphertextMAC/Tag

Plaintext

Ciphertext TagIVTinySec

20 – 30 bytes2 bytes

Disadvantage: ~ 10% packet overhead

Method used by TinySec

Method 2: Synchronized IV

SPINS IV kept as incrementing counter on both parties Advantage: Eliminate IV in each packet sent Disadvantage: Counter resynchronization

IV = 2 IV = 2

CiphertextTag

CiphertextTag

CiphertextTag

IV = 3

IV = 1 IV = 1IV = 0 IV = 0

Resynchronize Counter, IV=3Tag

MiniSec-U: IV Management

IV management is core issue Strike a compromise to attain minimum

energy consumption Send last x bits of the IV

Low communication overhead Keep x low

No counter resynchronization Resynchronizes implicitly

Send partial IV(MiniSec)

Entire IV(TinySec, ZigBee)

None(SPINS)

IV Sent with Each Packet

Comparison

Pros Cons

TinySec No counter resynchronization

Low packet overhead

ZigBee No counter resynchronization

High packet overhead

SPINS No packet overhead Counter resynchronization

MiniSec No packet overhead Implicit counter resynchronization

MiniSec-B:Broadcast Communication Many-to-many communication

All nodes share symmetric key OCB-Authentication & Encryption Replay protection

Timing based – detect replays outside of timing window

Bloom filter – detect replays within timing window

TinySec: No protection

Ciphertext MACIV

Ciphertext MACIV

Disadvantage: No replay protection

SPINS and ZigBee: Per Sender State

IVAB = 1000 IVAB = 1000

Ciphertext1

IVAB = 1001 IVAB = 1001

BA C

IVBC = 0000 IVBC = 0000IVBC = 0001 IVBC = 0001

Ciphertext2

Disadvantage: Stored state grows at O(n)n is number of senders

Ciphertext1

MiniSec-B: Timing Based Approach

plaintext1

kOCBE1

ciphertext1, tag1

Ciphertext1Tag1

Time

E1

E3

E2

E1

E3

E2

Ciphertext1Tag1

OCBkE1

ciphertext1tag1

OCBkE3

ciphertext1tag1

MiniSec-B: Bloom Filter Based Approach

Bloom filter1

Counterca= 0

plaintext2

plaintext1

k OCBE1 || ca

ciphertext1, tag1

Time

E1 E1

Ciphertext1Tag1ca

MiniSec-B: Bloom Filter Based Approach

Bloom filter1

Counterca= 0

plaintext2

kE1 || ca

ciphertext2, tag2

OCB

plaintext1

k OCBE1 || ca

ciphertext1, tag1

Time

E1 E1

Ciphertext1Tag1ca

Ciphertext2Tag2ca

MiniSec-B: Bloom Filter Based Approach

Bloom filter1

Counterca= 0

plaintext2

kE1 || ca

ciphertext2, tag2

OCB

plaintext1

k OCBE1 || ca

ciphertext1, tag1

Time

E1 E1

Ciphertext1Tag1ca

Ciphertext2Tag2ca

Ciphertext2Tag2ca

ComparisonPros Cons

TinySec No counter resynchronization

No stored state

Packet overhead No replay protection

ZigBee No counter resynchronization

Replay protection

High packet overhead O(n) state

SPINS No packet overhead Replay protection

Counter resynchronization O(n) state

MiniSec No packet overhead Implicit counter resynch Constant state Probabilistic replay

protection

Loose time synchronization

Conclusion Existing protocols either optimize

for high security or low energy utilization

MiniSec Low energy consumption High security

Bibliography Team project web site

http://sharepoint.uvm.edu/sites/tinysec

WSN Security TBA

TinySec TinySec: A Link Layer

Security Architecture for Wireless Sensor Networkshttp://naveen.ksastry.com/papers/tinysec-sensys04.pdf

TinySec: User Manualhttp://www.tinyos.net/tinyos-1.x/doc/tinysec.pdf

MiniSec MiniSec: A Secure Network

Communication Architecturehttp://sparrow.ece.cmu.edu/group/minisec.html

Simulation TOSSIM: A Simulator for

TinyOS Networks http://www.cs.berkeley.edu/~pal/pubs/nido.pdf

TinyViz: TOSSIM and TinyVizhttp://webs.cs.berkeley.edu/retreat-1-03/slides/1-03-tossim-tinyviz.pdfAlso, TOS1.x Tutorial, Lesson 5

PowerTOSSIM: Efficient Power Simulation for TinyOS Applications (SenSys ’04)http://www.eecs.harvard.edu/~shnayder/ptossim/