View
214
Download
0
Category
Tags:
Preview:
Citation preview
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
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
Recommended