1 / 22

SPINS: Security Protocols for Sensor Networks

SPINS: Security Protocols for Sensor Networks. Adrian Perrig Robert Szewczyk Victor Wen David Culler Doug Tygar UC Berkeley. Sensor Networks are Emerging. Many applications Real-time traffic monitoring Seismic safety Energy efficiency Need secure communication protocols.

kgraziano
Download Presentation

SPINS: Security Protocols for Sensor Networks

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. SPINS:Security Protocols forSensor Networks Adrian Perrig Robert Szewczyk Victor Wen David Culler Doug Tygar UC Berkeley

  2. Sensor Networks are Emerging • Many applications • Real-time traffic monitoring • Seismic safety • Energy efficiency • Need secure communication protocols

  3. Sensors in Cory Hall

  4. Hacker Attack! Sample Sensor Data Light intensity Temperature

  5. Security for Sensor Networks • Authentication • Ensures data integrity & origin • Prevents injecting bogus messages • Confidentiality • Ensures secrecy of data • Prevents eavesdropping

  6. Challenge: Resource Constraints • Limited energy • Limited computation (4 MHz 8-bit) • Limited memory (512 bytes) • Limited code size (8 Kbytes) • ~3.5 K base code (“TinyOS” + radio encoder) • Only 4.5 K for application & security • Limited communication (30 byte packets) • Energy-consuming communication • 1 byte transmission = 11000 instructions

  7. SPINS: Our Solution • SNEP • Sensor-Network Encryption Protocol • Secures point-to-point communication • TESLA • Micro Timed Efficient Stream Loss-tolerant Authentication • Provides broadcast authentication

  8. System Assumptions • Communication patterns • Frequent node-base station exchanges • Frequent network flooding from base • Node-node interactions infrequent • Base station • Sufficient memory, power • Shares secret key with each node • Node • Limited resources, limited trust

  9. SNEP Security Goals • Secure point-to-point communication • Confidentiality, secrecy • Authenticity and integrity • Message freshness to prevent replay • Why not use existing protocols? • E.g. SSL/TLS, IPSEC

  10. Asymmetric Cryptography is Unsuitable • Overhead of digital signatures • High generation cost O(minutes) • High verification cost O(seconds) • High memory requirement • High communication cost ~128 bytes • SNEP only uses symmetric crypto

  11. Basic Crypto Primitives • Code size constraints  code reuse • Only use block cipher encrypt function • Counter mode encryption • Cipher-block-chaining message authentication code (MAC) • Pseudo-Random Generator

  12. SNEP Protocol Details • A and B share • Encryption keys: KAB KBA • MAC keys: K'AB K'BA • Counters: CA CB • To send data D, A sends to B:A B: {D}<KAB, CA> MAC( K'AB , [CA || {D}<KAB, CA>] )

  13. SNEP Properties • Secrecy & confidentiality • Semantic security against chosen ciphertext attack (strongest security notion for encryption) • Authentication • Replay protection • Code size: 1.5 Kbytes • Strong freshness protocol in paper

  14. Broadcast Authentication • Broadcast is basic communication mechanism • Sender broadcasts data • Each receiver verifies data origin Alice M Sender M Dave M M Bob Carol

  15. K Sender M, MAC(K,M) M, MAC(K,M) Bob Alice K K M', MAC(K,M') Simple MAC Insecure for Broadcast

  16. TESLA: Authenticated Broadcast • Uses purely symmetric primitives • Asymmetry from delayed key disclosure • Self-authenticating keys • Requires loose time synchronization • Use SNEP with strong freshness

  17. F Authenticate K5 K5 F K6 F F P2 Verify MAC K5 TESLA Quick Overview I • Keys disclosed 2 time intervals after use • Receiver knows authentic K3 • Authentication of P1: MAC(K5, P1 ) K3 K4 K5 K6 K7 t Time 4 Time 5 Time 6 Time 7 P1 K3

  18. Authenticate K5 F F P1 P2 P3 P4 P5 K2 K2 K3 K4 K5 Verify MACs TESLA Quick Overview II • Perfect robustness to packet loss K3 K4 K5 K6 K7 t Time 4 Time 5 Time 6 Time 7

  19. TESLA Properties • Low overhead (1 MAC) • Communication (same as SNEP) • Computation (~ 2 MAC computations) • Perfect robustness to packet loss • Independent of number of receivers

  20. Energy Cost for Sending a Message • Typical packet size: 28 bytes Security Computation 2% MAC transmission 21% Data transmission 77%

  21. Related Work in Broadcast Authentication • Symmetric schemes • Link-state routing updates [Cheung ’97] • Multi-MAC [Canetti et al. ’99] • Asymmetric schemes • Merkle hash tree [Wong & Lam ’98] • Chained hashes • EMSS [Perrig, Canetti, Tygar, Song ’00] • [Golle & Modadugu ’01] • [Miner & Staddon ’01] • Hybrid schemes • Stream signature [Gennaro & Rohatgi ’97] • K-times signature [Rohatgi ’99]

  22. Conclusion • Strong security protocols affordable • First broadcast authentication • Low security overhead • Computation, memory, communication • Apply to future sensor networks • Energy limitations persist • Tendency to use minimal hardware • Base protocol for more sophisticated security services

More Related