MASY: Management of Secret keYs in Mobile Federated Wireless Sensor Networks Jef Maerien IBBT DistriNet Research Group Department of Computer Science Katholieke Universiteit Leuven Leuven, Belgium

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

Architecture

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 ComparisMASY(Tmote)MASY(SPOT)LEAPSizzle RAM (byte) ROM (kB)5, Message Overhead (bit) *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 Maerien IBBT DistriNet Research Group Department of Computer Science Katholieke Universiteit Leuven Leuven, Belgium

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 GW 01/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