1. 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 jef.maerien@cs.kuleuven.be

2. Overview Context Related work Architecture Evaluation Future work and conclusion 01/26/10

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

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

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

6. Shortcomings Limited mobility Limited scalability No internet - connectivity Soldier dropping an ADSID 1967 (Air Delivered Seismic Intrusion Detector)

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

8. Architecture : General concept 01/26/10

9. Architecture

10. Evaluation Implementation on Tmote-Sky : Contiki Sunspot: Squawk VM Evaluate Message Overhead RAM Overhead ROM Overhead 01/26/10

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

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

13. Comparison : MASY-LEAP-Sizzle ComparisMASY(Tmote)MASY(SPOT)LEAPSizzle RAM (byte)30070006003500 ROM (kB)5,71710.949 Message Overhead (bit) 448 256*600* 01/26/10

14. Infrastructure Gateway : Incompatible MAC -> Separate impl. Written in Java + C (Contiki ) / Java (SunSPOT) Back-end : Web Service Implemented in Java 01/26/10

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

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

17. Questions Jef Maerien IBBT DistriNet Research Group Department of Computer Science Katholieke Universiteit Leuven Leuven, Belgium jef.maerien@cs.kuleuven.be

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

19. Context: container tracking 01/26/10 High Mobility Many Nodes Limited memory Limited CPU Limited comm Federated environment

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

21. Attacker model Active External Attacker Monitor network Inject Messages Subvert nodes Does not want to be detected => No flooding No DOS

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