Security in Sensor Networks: Industry Trends, Present and Future Research Directions. Sensor Networks are Here!

Transcription

1 Security in Sensor Networks: Industry Trends, Present and Future Research Directions Adrian Perrig Sensor Networks are Here! Prototype sensor network deployments Burglar alarm in museum Semiconductor fabrication plant Chemical manufacturing plant, oil refinery Biology measurements Structural health monitoring 1

2 Example: Hotel Sensor Network Every room is equipped with a sensor node measuring light intensity, temperature, and humidity Applications Determine occupancy to direct fire fighters Detect energy drainage caused by open windows Detect water leaks Detect break-ins Detect fire Need for Security? Hotel sensor network simply sends all sensed information over wireless network to base station, without using encryption Security not necessary, right? Wrong! 2

3 Private Information Disclosure Much private information is leaked by temperature, humidity, and light measurements Light intensity readings may reveal: Shadows cast onto sensor can reveal information about motion of people Fine-grained light intensity values can reveal TV channel Humidity readings may reveal: Presence of people People talking Alcohol consumption Security is Important! Even for seemingly benign hotel application, security is crucial Privacy risks Burglars can figure out room occupancy Pranksters can fake fire alarm Some may argue that same issues exist without sensor network Can easily listen on door, try to spy through window However, sensors make large-scale attacks trivial! Easily obtain instant information about entire hotel 3

4 Importance of Security in Sensor Applications Manufacturing applications: prevent competitor from detecting production volumes or potential manufacturing problems Pollution monitoring: prevent data tampering Healthcare applications: privacy! Power grid surveillance: prevent malicious data injection Roadmap Attacker model Security requirements Industry standard for secure sensor network Sample research approaches Secure node-to-node communication User-friendly and secure key setup Secure localization Future research directions 4

5 Attacker Model [Gligor] Dolev-Yao adversary controls network Man-in-the-middle: read, replay, forge, block, modify Send/receive any message to/from any principal New sensor network adversary May selectively compromise fraction of nodes Insert replicas of nodes Controls network only at specific locations Sensor Security Requirements Application layer Services layer Network layer Data link/phy layer Neighbor-to-neighbor communication Threats Jamming Eavesdropping Injection Alteration Approach for security Establish shared keys Encrypt and authenticate 5

6 Sensor Security Requirements Application layer Services layer Network layer Data link/phy layer Enable wide-area communication Threats Compromised nodes on path suppress or alter packets Routing attacks Network flooding attacks Wormhole attack Sensor Security Requirements Application layer Services layer Network layer Data link/phy layer Basic services Clustering Time synchronization Node localization Threats Prevent convergence Attack service accuracy or availability 6

7 Sensor Security Requirements Application layer Services layer Network layer Data link/phy layer Sample applications Data aggregation Network query Target tracking Threats Attack data integrity Service disruption Prevent convergence Generic Attacks Need to defend against generic attacks Denial-of-service attacks Battery-drainage attacks Sybil attacks Node replication attacks 7

8 Standard Security Protocols Why not simply leverage standard security protocols? SSL/TLS, SSH, IPsec work just fine. Challenge: severe resource constraints! Limited battery lifetime Limited processing Limited memory capacity Asymmetric cryptographic operations may require on the order of seconds Sensor deployed in unprotected areas without tamperproof hardware Sensor Nets vs. Ad Hoc Nets Limited computation (slow 8- or 16-bit µc) Limited bandwidth Large size (thousands of nodes) Usually immobile One administrative domain Unattended, can be physically compromised High computation (notebook/pda nodes) High bandwidth Medium-sized (hundreds of nodes) Usually mobile Various administrative domains Each node comes with a human user (tampering not a big problem) 8

9 Sensor Network Advantages Seems like sensor network security is quite impossible? Fortunately, sensor networks have features that support security Large-scale: time-consuming to physically compromise large fraction of nodes High redundancy: tolerate small fraction of compromised nodes Approximate results ok Single deploying entity, single trust domain Ideal Secure Sensor Network Assume commodity low-cost sensors Provide simple configuration and maintenance Tolerate installation errors by non-expert installer Provide availability of application, integrity and secrecy of information, even if attacker compromises and controls fraction of sensor nodes 9

10 Secure Node-to-Node Communication Most basic security primitive is secret and authentic node-to-node communication Message encryption achieves secrecy Message authentication code achieves authenticity Assumptions Trusted base station Communicating nodes share secret key Approaches SPINS SNEP TinySec ZigBee SPINS - SNEP SPINS: Secure Protocols for Inter-Networked Sensors [Mobicom 2001] Goal: basic secure communication feasible on resource-constrained sensor network SNEP: Sensor Network Encryption Protocol Base-station-centric security model Each node shares secret key with base station Node-to-node keys are set up through base station Provides: secrecy, authenticity, replay protection Based on RC5 block cipher Relies on synchronized counters (IVs) 10

11 SNEP Protocol Details A and B share Encryption keys: K AB K BA MAC keys: K' AB K' BA Counters: C A C B To send data D, A sends to B: A B: {D} <KAB, C A >, MAC( K' AB, [C A {D} <KAB, C A > ] ) TinySec By Karlof, Sastry, Wagner [Sensys 2004] Provides secrecy and authenticity, but no replay protection Design decision: send 2-byte initialization vector (IV) in each packet In contrast, SNEP assumes synchronized IV Per-packet IV has advantage in environments with very high packet loss Uses Skipjack block cipher 11

12 ZigBee ZigBee security based on trust center, similar to trusted base station Network key is secret shared by all nodes in the network, used for broadcast messages or when no link key is set up Link key is pairwise shared secret key, used for node-to-node secure communication ZigBee Uses AES as the underlying block cipher Set up node-to-node shared secret keys through trust center Provides: secrecy, authenticity, replay protection Does not define: Secure initial key setup mechanism Secure routing protocol Not secure against compromised nodes 12

13 MiniSec Collaboration with Mark Luk, Ghita Mezzour, Abhishek Jain, and Virgil Gligor Goal: highly energy-efficient basic security layer for secure unicast and broadcast communication Provide secrecy, authenticity and replay protection MiniSec-U: Secure Unicast communication MiniSec-B: Secure Broadcast communication Approch: re-design of all cryptographic mechanisms and algorithms, use of new cryptographic primitives Comparison High MiniSec SPINS ZigBee Security TinySec Low Low High Energy Consumption 13

14 MiniSec-U Background: OCB OCB Offset Codebook Mode [Rogaway et al. 03] Block cipher mode of operation Authenticated encryption in a single pass Key IV/Nonce Plaintext OCB Key IV/Nonce Ciphertext MAC/Tag OCB Ciphertext MAC/Tag Plaintext Error Initialization vector (IV) ensures that same plaintext does not encrypt to same ciphertext Needs to be non-repeating In MiniSec, we ll be using an incrementing counter Key IV Method 1: Send IV with Packet Plaintext E Ciphertext MAC/Tag TinySec IV Ciphertext Tag Ciphertext MAC/Tag Key IV D Plaintext 2 bytes bytes Disadvantage: ~ 10% packet overhead IV Sent with Each Packet Entire IV (TinySec, ZigBee) 14

15 Method 2: Synchronized IV SPINS IV kept as incrementing counter on both parties Advantage: Eliminate IV in each packet sent Disadvantage: Counter resynchronization Ciphertext Tag Ciphertext Tag IV = 0 Ciphertext Tag IV = 0 IV = 1 IV = 1 IV = 2 IV = 2 IV = 3 Resynchronize Counter, IV=3 Tag None (SPINS) Entire IV (TinySec, ZigBee) IV Sent with Each Packet MiniSec-U: IV Management IV management is core issue Strike a compromise to attain minimum energy consumption Send last x bits of the IV Low communication overhead Keep x low No counter resynchronization Resynchronizes implicitly None (SPINS) Send partial IV (MiniSec) IV Sent with Each Packet Entire IV (TinySec, ZigBee) 15

16 Energy based on Packet Drop Rate Expected Energy Consumption (mas) Packet Drop Rate MiniSec-U: Summary Employs OCB for authenticated encryption Incrementing counter as IV/Nonce prevents replay attack IV management compromise between TinySec and SPINS Send last x bits of counter Attempt decryption up to maxattempt 16

17 Broadcast Authentication Broadcasts data over wireless network Packet injection usually easy Each receiver can verify data origin Alice M Sender M Dave M M Bob Carol Authentication Needs Asymmetry K = shared key Sender K Msg, MAC(K,Msg) Alice K Msg, MAC(K,Msg) Bob K Forged Msg, MAC(K, Forged Msg) 17

18 Digital Signatures Impractical Signatures (e.g., RSA 1024 bit) are expensive on low-end processors: High generation cost (~10 seconds) High verification cost (~1 second) High communication cost (128 bytes/packet) TESLA Timed Efficient Stream Loss-tolerant Authentication Uses only symmetric cryptography Asymmetry via time Delayed key disclosure Requires loose time synchronization Joint work with Ran Canetti, Dawn Song, Doug Tygar 18

19 Basic Authentication Mechanism F: public one-way function 1: Verify K F(K) Authentic Commitment P MAC(K,P) 2: Verify MAC K disclosed 3: P Authentic! t Security Condition Receiver knows key disclosure schedule Security condition (for packet P): On arrival of P, receiver is certain that sender did not yet disclose K If security condition not satisfied, drop packet 19

20 Bootstrapping Receivers Loose time synchronization Receiver knows maximum time synchronization error, upper bound on sender s time Session setup, authenticated parameters Beginning time of one specific interval Interval duration Key chain commitment Disclosure delay Digital signature for initial authentication TESLA Keys disclosed 2 time intervals after use Receiver setup: Authentic K0, key disclosure schedule Authentication of P1: MAC(K2, P1 ) Authenticate K2 K0 F K1 F K2 F K3 F K4 Time 0 Time 1 Time 2 Time 3 Time 4 P1 P2 Verify MAC K0 K2 t 20

21 TESLA: Robust to Packet Loss K0 Authenticate K2 F F K1 K2 K3 K4 Time 1 Time 2 Time 3 Time 4 P1 P2 P3 P4 P5 t K-1 K-1 K0 K1 K2 Verify MACs Asymmetric Properties Disclosed value of key chain is a public key, it allows authentication of subsequent messages (assuming time synchronization) Receivers can only verify, not generate With trusted time stamping entity, TESLA can provide signature property 21

22 TESLA Summary Low overhead Communication (~ 20 bytes) Computation (~ 1 MAC computation per packet) Perfect robustness to packet loss Independent of number of receivers Delayed authentication Applications Authentic media broadcast Sensor networks Secure routing protocols MiniSec-B: Motivation Many-to-many communication All nodes share symmetric key Core issue: Replay protection 22

23 Key IV TinySec: No Replay Protection Plaintext E Ciphertext MAC/Tag Ciphertext MAC/Tag Key IV D Plaintext IV Ciphertext MAC IV Ciphertext MAC Disadvantage: No replay protection SPINS and ZigBee: Per-Sender State A B C Ciphertext 1 Ciphertext 2 IV AB 1000 IV AB 1000 IV AB = 1001 IV AB = 1001 Ciphertext 1 IV BC = 0000 IV BC = 0000 IV BC = 0001 IV BC = 0001 Disadvantage: Stored state grows at O(n) n is number of senders 23

24 MiniSec-B: Motivation How can we detect replay attacks without persender state? Replay protection approach: Timing based detect replays outside of timing window Requires loose time synchronization Bloom filter detect replays within timing window Probabilistic replay protection Required state: Sender: Incrementing counter Receiver: Two alternating Bloom filters Stored state grows at O(B) B is bandwidth, independent of number of nodes MiniSec-B: Timing-based Approach Time E 1 k E 1 plaintext 1 OCB ciphertext 1, tag 1 Ciphertext 1 Tag 1 ciphertext 1 tag 1 k E OCB 1 E 1 E 2 E 2 ciphertext 1 tag 1 E 3 Ciphertext 1 Tag 1 k E 3 OCB E 3 24

25 MiniSec-B Background: Bloom Filter Space efficient data structure for fast probabilistic membership test Membership addition Membership query Probabilistic membership query Low false positives: when query returns true, small probability that element is not in the set No false negatives: when query returns false, element is not in the set MiniSec-B: Bloom-Filter Based Approach Time Counter plaintext 1 c a = 0 k OCB E 1 c a c a Ciphertext 1 Tag 1 Bloom filter 1 ciphertext 1, tag 1 E plaintext 2 1 E 1 25

26 MiniSec-B: Bloom-Filter Based Approach Time Counter plaintext 1 c a = 0 k OCB E 1 c a c a Ciphertext 1 Tag 1 Bloom filter 1 ciphertext 1, tag 1 E plaintext 2 1 c k a Ciphertext 2 Tag 2 E 1 E 1 c a OCB ciphertext 2, tag 2 MiniSec-B: Bloom-Filter Based Approach Time Counter plaintext 1 c a = 0 k OCB E 1 c a c a Ciphertext 1 Tag 1 Bloom filter 1 ciphertext 1, tag 1 E plaintext 2 1 c k a Ciphertext 2 Tag 2 E 1 E 1 c a OCB ciphertext 2, tag 2 c a Ciphertext 2 Tag 2 26

27 MiniSec-B: Summary Replay protection in many-to-many broadcasts Timing based approach Bloom filter based approach Counter sent with each packet Counter can be very small since it resets at each epoch Probabilistic replay protection False negatives: Replayed packet marked as an innocent packet MinSec-B: 0% False positives: Innocent packet marked as a replayed packet MinSec-B: Low False negatives more important than false positives Comparison TinySec ZigBee SPINS Pros No counter resynchronization No stored state No counter resynchronization Replay protection No packet overhead Replay protection Cons Packet overhead No replay protection High packet overhead O(n) state Counter resynchronization O(n) state MiniSec No packet overhead Implicit counter resynchronization Constant state Probab. replay protection Loose time synchronization 27

28 Roadmap Early sensor network security protocols and ZigBee standard provide secret and authentic node-to-node communication, assuming shared secret keys already set up Open challenge: how to securely set up initial keys? Remaining challenge: secure higher-layer protocols E.g., secure localization, time synchronization User-Friendly and Secure Key Setup Goal: set up shared secret keys between sensor nodes and base station Challenges Human operator is not a security expert, may make mistakes during install Achieve high level of security No special HW for key setup Scale to large networks 28

29 Potential Approaches (1/2) USB cable connects sensor to base station Commodity sensors may not have USB connector Factory installs keys Manufacturer prefers not to be responsible and liable for secrecy of cryptographic keys Complicates inventory management Keys could be compromised during shipping Installer types key into sensor node Commodity sensor nodes have no human-input facilities Potential Approaches (2/2) Diffie-Hellman key establishment Man-in-the-Middle attack possible unless blinded DH values can be authenticated Random-key pre-distribution Rely on secret key pool that is already set up Key infection Not secure if attacker present 29

30 Proposed Approach With Mark Luk, Cynthia Kuo, Evan Gaustad Use a Faraday cage to obtain secret and authenticated communication Confine installation node and to-be-installed node inside Faraday cage to set up keys However, many things can go wrong How do nodes know that cage is closed? What if installer opens cage prematurely and communications leak? What if external attacker jams network? Faraday-Cage Based Key Setup Use two installation sensors, one inside the Faraday cage and the other outside Outside sensor detects if cage incorrectly closed or pre-maturely opened Simple approach robust to installer error 30

31 Secure Localization Challenge: assign accurate coordinates to each sensor node, even in the presence of an active adversary Several promising approaches at IPSN 2005 Lazos, Poovendran, and Capkun: "ROPE: Robust Position Estimation in Wireless Sensor Networks" Li, Trappe, Zhang, and Nath: "Robust Statistical Methods for Securing Wireless Localization in Sensor Networks" Liu, Ning, and Du: "Attack-Resistant Location Estimation in Sensor Networks" Interesting Security Approach Assume honest majority Basic idea: remove beacons that result in largest error, i.e., only consider set of beacons that result in small location error Elegant and simple approach that results in surprisingly high level of resilience to attacks Promising direction for security in sensor nets 31

32 Promising Research Directions Establish realistic attacker model Is it realistic to assume only small fraction of nodes compromised? If attacker can compromise 5%, why not 20%? Maybe hard to compromise first node, but easy to compromise rest Promising Research Directions Leverage scale and redundancy for security Utilize majority-based approaches for security Remove outliers that introduce large error, assumption: outliers are attackers Probabilistic approaches to security May suffice to detect attacker with 90% probability Emergent algorithms for security Algorithms that perform purely local operations that converge to a global property These approaches may limit attacker influence only local neighborhood 32

33 Conclusion Sensor networks provide opportunity to get security right before wide-spread deployment No need for disastrous security flaw Most applications need security Even seemingly benign sensors can reveal surprising amount of information Sensor networks pose new challenges Powerful attacker model Limited hardware resources Opportunity for exciting research directions 33