Download presentation
Presentation is loading. Please wait.
Published byDonna Jocelyn Richardson Modified over 9 years ago
1
1 Security in Ad-Hoc Wireless Networks of Embedded Devices Ehud Meiri Embedded Computing Seminar 2005/6
2
2 Talk Outline Introduction Security Basics Security in Ad-hoc Wireless Networks Miscellaneous
3
3 Introduction The Embedded Environment Historical Perspective - Why Do We Need Security?
4
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
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
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
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
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
9 Security Basics Security Criteria EncryptionAuthentication
10
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
11 Security Criteria ► Three main security concerns: Confidentiality ► Data privacy Availability ► Resistance to DOS attacks Authenticity ► Keeping “foreign objects” out, data integrity
12
12 Encryption ► A basic building block of security ► Public vs. Symmetric key cryptography ► Embedded devices have power constraints Asymmetric keys are 10 3 -10 4 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
13 Advanced Encryption Standard (AES) ► The Rijndael block cipher was selected by NIST in 2000 to be the AES Replacement for DES Key length of 128, 192, or 256 bits, block is 128 bits http://www.iaik.tu-graz.ac.at/research/krypto/AES/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
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
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
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
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_Pointhttp://en.wikipedia.org/wiki/Thermal_Design_Point, http://en.wikipedia.org/wiki/Montgomery_reductionhttp://en.wikipedia.org/wiki/Montgomery_reduction http://citeseer.ist.psu.edu/ravi02system.html
18
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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.htmlhttp://citeseer.csail.mit.edu/537210.html - Only a starting point…
34
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
35 Miscellaneous Sleep Deprivation Torture Security Bugs
36
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
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)
Similar presentations
© 2024 SlidePlayer.com Inc.
All rights reserved.