Lightweight Security Protocol Security in Networked Embedded Systems

Lightweight Security Protocol “Security in Networked Embedded Systems” TAEJOON PARK Real-Time Computing Laboratory Department of EECS The University of Michigan

How to Secure Systems ? CRYPTOGRAPHY CRYPTO KEY • Only use ciphers carefully studied • Resistence to cryptanalysis £ Processing £ • Key search attack ? e. g. , DES ~ 256 • Secure only if key length large enough >> 75 bits (M. Blaze) • Nullifying effect of key in ciphertext ? e. g. , 802. 11 WEP Secure System CHALLENGES • Security £ Efficiency, user-friendlyness ¤ • • Confidentiality Integrity, Authenticity Access Control Availability • Same key forever ? KEY MANAGEMENT • Process to generate, store, protect, transfer, use & destroy key • Dynamic, unmanned, renewable • Also trust management, pricing, privacy • Compatible with existing app/svc • e-Business, Pay. TV, Internet

Security in Networked Embedded Systems No fixed infrastructure, self-organizing Battery-powered A large number of nodes Dynamic addition / removal Possibly mobile, unattended CHALLENGES Wireless OUR APPROACH Lightweight easier eavesdropping, jamming Not sacrificing security level Limited Energy Distributed, P 2 P Large-scale Tailored to Threat / Svc

Threat Model OUTSIDER INSIDER Data Attacks • Traffic capture / replay • Spoofing if unencrypted • Man-in-the-middle attack Data Attacks • Traffic injection / flooding • Unlimited spoofing • Do. S attack Radio Attacks • High-power jamming • Detection of radio sources, Hot spots Service Disruption Attacks • Routing – altered route updates, selective relaying • Disruption of clock synch. Physical Attacks • Reprogram as malicious • Destroy device • Extract key material Misc. • Service/data to adversary • Malicious service to net.

Why Li. SP ? THREAT Attack on Data • Eavesdropping • Data Modification/ injection • Service disruption Do. S Attack on Devices The adversary can • capture • reverse-engineer • re-program • clone sensor device(s) DEFENSE PROBLEM SOLUTION Shared secret-key Globally shared Group-based Key Management • Globally • Group-based • Pairwise Re-keying • Periodically • Event-triggered H/W • Vulnerable to node compromises Group-shared • Large overhead of (unicast) re-keying Distributed Key Management Pairwise-shared • Large overhead of encr/decr per link • Peer-to-peer nets • via Distributed Key Servers Tamper resistance • Expensive • Not absolutely safe • Obfuscation • O: No security • RC, SD: Incurs runtime overhead • SD: How to protect decryption routine? S/W • Result Checking • Self-Decrypting programs • Hierarchical nets • via Key Broadcast Soft Tamper-Proofing via Program-Integrity Verification

Li. SP Architecture Goal: A lightweight security framework for various NEST applications PROGRAM INTEGRITY VERIFICATION suspicious sensor INTRUSION DETECTION Probe Activate / Lock compromised sensor KEY MANAGEMENT Monitor new sensor Re-key Reconfigure SECURITY TRADEOFF Reconfigure

Group Key Management OBJECTIVE Static Preloaded Key à Dynamic Key Periodic Renewal of Group-Key (GK) Maximize Performance given Key Renewal Frequency KEY IDEA Unicasting àBroadcasting (without retransmissions / ACKs) Authentication & Recovery of GK using One-Way Hash Function Authenticate GK without dedicated MAC field Detect / recover lost (corrupted) GK Double-Buffering for Robustness to Inter-Sensor Clock Skews

Group Key Management GK 1 H GK 2 H GK 3 H GK 4 Ucast Key Buffer GK 2 = H(GK 3) GK 1 = H(GK 2) Key Slots Communication vs Processing H GK 5 H lost/corrupted Bcast GK 3 GK 1 GK 2 GK 6 H GK 4 GK 7 KEY SERVER Bcast GK 4 GK 6 SENSOR GK 5 = H(GK 6) GK 3 GK 5 GK 4 Much less C at the expense of reasonable P Energy-efficient because C >>> P

DARPA Demo 1. Key Distribution Visualize rekeying process via GUI & Mote LEDs 2. Key Recovery Randomly skipping key disclosure(s) 3. Tradeoffs Adjust rekeying period & length of key buffer Tool for Visualizing Key Management