Security in Ad-Hoc Wireless Networks of Embedded Devices

1. Security in Ad-Hoc Wireless Networks of Embedded Devices Ehud Meiri Embedded Computing Seminar 2005/6

2. Talk Outline Introduction Security Basics Security in Ad-hoc Wireless Networks Miscellaneous

3. Introduction The Embedded Environment Historical Perspective - Why Do We Need Security?

4. The Embedded Environment • Many devices that communicate with one another in a network • Connections can be peer-to-peer or broadcast • Through wires, RF, lasers, etc. • These devices may have • limited battery power • limited computational power

5. Brief History Example • Cellphones - Analog • Two-Way Radios • Authenticated via live operator • No privacy • Few attacks • First cellphones • Still no privacy • MIN/ESN pairs for authentication • No need for a live operator to connect • Widespread cloning attacks (roaming) http://www.cra.org/Activities/fellows/wagner.pdf http://en.wikipedia.org/wiki/History_of_mobile_phones

6. Brief History Example (2) • Cellphones – Digital • GSM • Good authentication (shared secret) • Bad cryptography, easy to break – no privacy • Who’s to blame? • Viruses! • Homogenous digital environments • Symbian bluetooth viruses http://en.wikipedia.org/wiki/Global_System_for_Mobile_Communications http://wired-vig.wired.com/news/technology/0,1282,11630,00.html http://www.eweek.com/article2/0,1759,1733176,00.asp

7. Conclusions • A wireless network means wireless attacks • New challenges • Usually impossible to detect eavesdropping • Hard to locate attackers • We can classify two network mediums: • Broadcast – Anyone can listen • Private – Eavesdroppers require more effort to listen than the intended audience • Solutions turn broadcast into private or leverage broadcast nature for attack detection

8. Conclusions (2) • Where would we want to enable security? • In public embedded environments • Cellphones • Campuses • Museums • Wireless networks • Wi-fi soho networks • Sometimes it’s a wasted effort • TV remote control

9. Security Basics Security Criteria Encryption Authentication

10. Security Pragmatism • Q: How do you keep your embedded device from being messed with? • A: Turn it off. • Sometimes the best we can hope for is to detect intrusions.

11. Security Criteria • Three main security concerns: • Confidentiality • Data privacy • Availability • Resistance to DOS attacks • Authenticity • Keeping “foreign objects” out, data integrity

12. Encryption • A basic building block of security • Public vs. Symmetric key cryptography • Embedded devices have power constraints • Asymmetric keys are 103-104 times slower • Use symmetric keys (AES, IDEA) • Can use public key cryptography to setup secret key • Key exchange – more on that later • Use efficient hardware implementations http://en.wikipedia.org/wiki/AES http://en.wikipedia.org/wiki/Rsa http://en.wikipedia.org/wiki/IDEA_(cipher)

13. Advanced Encryption Standard (AES) • The Rijndael block cipher was selected by NIST in 2000 to be the AES • Replacementfor DES • Key length of 128, 192, or 256 bits, blockis 128 bits http://www.iaik.tu-graz.ac.at/research/krypto/AES/ - list of articles http://www.quadibloc.com/crypto/co040401.htm http://www.iaik.tugraz.at/research/publications/2005/IEEIFSTINA2005.htm

14. Small Hardware AES-128 Implementations • 5.4 kgates implementation (Satoh et al., 2001) • AES Implementation on a Grain of Sand (Feldhofer et al., 2005) • 3.4 kgates equivalent • 0.25mm² • 9 Mbps • “draws only a current of 3.0 µm when operated at 100 KHz and 1.5 V” http://www.iaik.tugraz.at/research/publications/2005/IEEIFSTINA2005.htm

15. Fast Software Implementations • AES-128 • 226 cycles/block on a P-III (Aoki & Lipmaa, 2002) • 14464 P-III cycles for 1kb • FastIDEA (4-way IDEA) (Lipmaa) • 440 cycles for a 4x64 block using MMX • Poly1035-AES message authentication (Bernstein) • 3.1n + 780 Athlon cycles for an n-byte message • 5361 P-III cycles for 1kb http://www.cs.ut.ee/~lipmaa/aes/rijndael.html http://cr.yp.to/mac/poly1305-20050329.pdf

16. Embedded Encryption • Put the encryption in the network device • Wired (100Base-TX) and wireless (802.11b) versions • Supports WPA, WEP • Does 256 bit AES • Not hardware encryption • 820-1280mW http://www.lantronix.com/device-networking/embedded-device-servers/wiport.html http://www.lantronix.com/device-networking/embedded-device-servers/xport.html

17. Embedded Encryption (2) • Put the encryption in the CPU • VIA chips now offer a built-in security engine • 256 bit AES • Quantum-based random number generator • Montgomery Multiplier for accelerating Public Key Cryptography • Example: Eden-N Processor (smallest) • Thermal Design Power: 2.5W @ 533MHz • Size: 15x15mm http://www.via.com.tw/en/initiatives/padlock/hardware.jsp http://www.via.com.tw/en/products/processors/eden-n/ http://en.wikipedia.org/wiki/Thermal_Design_Point, http://en.wikipedia.org/wiki/Montgomery_reduction http://citeseer.ist.psu.edu/ravi02system.html

18. Authentication Woes • Central Authentication Mechanisms? • Ad-hoc wireless networks aren’t permanent • Not always reachable • Congestion around central authorities • DOS • Expensive to make rapid changes • Nodes may only connect periodically • How do we know we’re talking to who we think we’re talking to?

19. The Resurrecting Duckling • Scenario: embedded device + controller • We need to prevent unauthorized use • Authenticity • The controller is imprinted on the device • Like a duckling, the first controller encountered is the controller for life. • A secret key for symmetric key cryptography http://citeseer.ist.psu.edu/stajano99resurrecting.html

20. The Resurrecting Duckling (2) • Passing control • Kill the duckling and resurrect it (reset the device) • Imprint a new controller onto it • Imprinting wirelessly • man-in-the-middle attack • Solution: imprint through a physical connection

21. The Resurrecting Duckling (3) • Example technology: Bluetooth • Device pairing • By MAC address • Done by the user • Discovery broadcasts • An attack vector for viruses • Solution: disable responses and only talk to paired devices

22. Ad-Hoc Wireless Networking Intro (AODV) Coping with attacks in the network level: peer-to-peer style, in the protocol, with trust Physical & Application levels

23. Ad-Hoc Wireless Networking • Network is created on-the-fly • Routes messages through intermediate nodes • Vulnerable to numerous attacks • Physical layer: eavesdropping, jamming • Network layer: attacker is a peer, a router

24. Ad-hoc On-demand Distance Vector routing protocol (AODV) • On-demand path discovery • Using broadcasts • Protocol builds a route using a distributed Bellman-Ford algorithm (distance vector) • Slow to find shortest paths • Old routes slowly expire from the cache http://en.wikipedia.org/wiki/AODV http://moment.cs.ucsb.edu/AODV/aodv.html

25. AODV Vulnerabilities • Attacker is a peer in the network layer • Routing updates misbehavior • Preventing routes from being built or being built efficiently • Invalidating routes • Packet forwarding misbehavior • Dropping packets • Availability

26. Self-Organized Network Layer Security (Yang, Meng, Lu, UCLA ‘02) • Collective monitoring of peers • A node is given a token from its neighbors • Tokens expire after a while • Token duration increases with each renewal • Key is signed by peers (PK, SK pair for system) • Polynomial secret sharing scheme (polynomial of order k-1) • Each node only has part of the secret key http://citeseer.ist.psu.edu/yang02selforganized.html

27. Self-Organized Network Layer Security (2) • Tokens are revoked for misbehaving • Blackmail attack • “m out of N” strategy for cross-validation of claims • Increasing m decreases the chances for both detection and false detection • Complexity of implementation: unknown, but regular PK is considered expensive

28. Packet Leashes (Hu, Perrig, Johnson, CMU/RICE) • Wormhole attack: forward packets to remote locations (more than 1 hop) • Availability • “Wormholed” packets arrive sooner • In AODV, two nodes may think they are near each other • No need to understand the protocol to attack http://citeseer.ist.psu.edu/hu01packet.html

29. Packet Leashes (2) • Geographical Leashes • Nodes know: • Their location • Loosely synchronized clocks • Global upper bound on node velocity • Packets include location and timestamps • Digitally signed • Via a trusted entity that signs PKs • Via other methods referenced in article • Compute the distance bound

30. Packet Leashes (3) • Temporal Leashes • Requires tightly synchronized clocks • Up to few µs or even 100’s of ns • For example using GPS • Packets contain time signature • Also digitally signed • Receiver can check if a packet has traveled too far • Based on the speed of light and agreed maximum transmission distance

31. Proxy-Based Protocols (Burnside, Clarke, Mills, Devadas, Rivest) • Every device has a trusted proxy • Impoverished devices – external proxies • Powerful devices – internal proxies • Proxy duties • Enabling inter-device communication • Access control • Protocol translation between devices http://citeseer.ist.psu.edu/burnside02proxybased.html

32. Proxy-Based Protocol (2) • Proxies use the SPKI/SDSI public key infrastructure for ACLs • No hierarchy of trust • Must provide a certificate chain to prove authorization • For example if access is allowed only to members of group B, a valid certificate chain may be: • here’s a certificate that states I’m a member of group A, and a certificate that states that every member of A is also a member of B http://citeseer.ist.psu.edu/clarke01certificate.html

33. Jamming/Interference • An attacker may jam our network with a lot of packets or interfere with the signal. • Availability • Coping with jamming/interference attacks • Locate the attacker by measuring LAN signal strength • This can also be used against us (Confidentiality) • Attacker is generating a lot of requests – prioritize service • Attacker is generating noise at the physical level -Spread Spectrum technology http://citeseer.csail.mit.edu/537210.html - Only a starting point…

34. Sensor Networks • Attacker can contribute faulty data • Authenticity, Reliability • In this context, the attacker is a “Byzantine” node • Solution: distributed consensus protocols • Classic asynchronous problem impossible (FLP83) • Possible with digital signatures http://theory.lcs.mit.edu/tds/papers/Lynch/jacm85.pdf

35. Miscellaneous Sleep Deprivation Torture Security Bugs

36. Battery Exhaustion • “Sleep Deprivation Torture” - DOS • Availability • Keep a battery powered device busy so that its battery runs out • Solution: Standard DOS coping strategies • Throttle services • Flood protection • Alert the supervisor

37. Buggy Software • Software bugs may trigger an attack • Authenticity, Confidentiality, and Availability • Solutions • Standard preventive programming measures • Unit tests • Other solutions proposed here (to cope with attacks)