MASY: Management of Secret keYs in

Mobile Federated Wireless Sensor Networks

Jef MaerienIBBT DistriNet Research Group

Department of Computer ScienceKatholieke Universiteit Leuven

Leuven, Belgium jef.maerien@cs.kuleuven.be

Overview

• Context• Related work• Architecture• Evaluation• Future work and conclusion

01/26/10

Context : Container tracking• Containers travel across the world

• Visiting many ports / storage facilities

• Many parties present• Container Owners• Infrastructure provider• Work together in federation

• Wireless sensors monitor the cargo• Send data back to owner

01/26/10

Context

• Sensors from many different parties• Each container owner has own sensors

• Internet enabled• Needed to send data• Provided by infr. provider through GW

• Each party has back-end server• Needed to receive monitoring feed

• Light weight nodes• Nodes do not support assymetric encryption• Too heavy weight for the lightest nodes

Key management in WSN

• Pre-shared key with gateway (SPINS / LEAP)– Gateway = key distribution center

• Pre-shared key ring (PIKE)– Compare rings -> generate secret– Use of 3th node if needed

• Assymetric encryption (SIZZLE)– limited certificates, assumed preloaded– Still memory intensive

Shortcomings

• Limited mobility

• Limited scalability

• No internet - connectivity

Soldier dropping an ADSID 1967(Air Delivered Seismic Intrusion Detector)

VANET security research

• Vehicle has 2 key pairs: Long term / Short term• Short term : local key

– Signed by local CA / Trusted by local vehicles

• Long term : global key– Signed by RA (DMV)– Trusted by local CA‘s– Local CA deploys STK using LTK

Architecture : General concept

01/26/10

PKI Infrastructure

Long Term Secret Key

Gateway

Nodes in NetworkCompany Sensor Node

Company Server

Short Term Group Key

Architecture

1: hello:M,CompIP,N,{msg}SK

2: relay hello

3: {hello,GK}SSL

4: reply: M,{GK}SK

5: relay reply

6: reply

Gateway

Relaying nodeNode entering new network with MAC M

Back-end server @ CompIP

msg

Evaluation

• Implementation on• Tmote-Sky : Contiki• Sunspot : Squawk VM

• Evaluate• Message Overhead• RAM Overhead• ROM Overhead

01/26/10

Message size

• Hello– [NodeMac,CompIP,Nonce,Signature]

8B 4B 4B 16B• Total 32 bytes• Signature = {NodeMac,CompIP,Nonce}SK

• Reply– [NodeMac,{GK} SK]

8B 16B• Total 24 bytes

Memory overhead

• Contiki - Tmote Sky: • Limited ROM// RAM overhead :

• ROM :Contiki 23.2kB, AES 5kB, protocol 1 kB • RAM : 300 bytes

• Squak VM - SunSPOT:• More overhead :

• ROM: 68.5kB (with crypto libs) protocol ca 7kB• RAM : 10 total kB (unefficient implementation => OO)

Comparison : MASY-LEAP-Sizzle

Comparis MASY(Tmote) MASY(SPOT) LEAP Sizzle

RAM (byte) 300 7000 600 3500

ROM (kB) 5,7 17 10.9 49

Message Overhead (bit)

448 448 256* 600*

01/26/10

Infrastructure

• Gateway : • Incompatible MAC -> Separate impl.• Written in Java + C (Contiki ) / Java (SunSPOT)

• Back-end : • Web Service• Implemented in Java

01/26/10

Future work

• Multi node configuration• Nodes travel in groups : 1 message to deploy key

• Drain attack prevention• Periodically forward connection requests (e.g. 1/min)

• Use combination asymmetric – symmetric keys• Powerful nodes can use certificates• Weaker nodes use symmetric keys

Conclusion

• A new key management scheme for mobile federated Wireless Sensor Networks

• Resource rich trusted entity establishes the trust relationship

• Internet-connectivity to handle additional complexity

• Prototype shows limited additional overhead

Questions

Jef MaerienIBBT DistriNet Research GroupDepartment of Computer ScienceKatholieke Universiteit Leuven Leuven, Belgium jef.maerien@cs.kuleuven.be

Approach

• Step 1: New node detects new network, sends out a token containing own ID and compIP

• Step 2: Relay node relays request to GW• Step 3: Gateway receives token,

contacts the node owner and sends group key• Step 4: Owner verifies gateway, encrypts group key in token and

sends it back to GW• Step 5: GW sends token to relay node• Step 6: Relay sends token to new node

• Relay node can be skipped if new node is in range of GW01/26/10

Context: container tracking

01/26/10

• High Mobility

•Many Nodes

•Limited memory

•Limited CPU

•Limited comm

• Federated environment

Requirements

• Limited resources (The WSN constraint)– Limited communication– Limited processing– Limited Energy– => light weight key infrastructure on node

• Secure key deployment : – Confidential / authentication– Only authorized parties can know the group key

• Network key not known in advance– Pre-agreeing keys = fairly insecure– Possible breaches require rekeying

Attacker model

• Active External Attacker• Monitor network• Inject Messages• Subvert nodes

• Does not want to be detected =>• No flooding• No DOS

Analysis

• New Node : – limit hello send / trust in BE is required : rekey

• Networked node – Requires detection mechanism => rekey without

• Gateway : – no trust in Gw => no conn / BE must trust Gw

• Outsider : – no info on group key / knows BE or node identity