Your SlideShare is downloading. ×
  • Like
015 spins
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

015 spins

  • 329 views
Published

 

Published in Technology , Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
329
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
21
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. SPINS: Security Protocols for Sensor Networks Authors: Adrian Perrig, Robert Szewczyk, Victor Wen,David Culler and J.D.Tygar Presented By :c.manohar babu (Some slides have been taken from authors’ sites)
  • 2. Outline
    • Security for sensor networks
    • - Research Problem
    • Proposed Techniques
    • - SPINS building blocks
    • Applications
    • Related Work
    • Discussion
    • Conclusion
  • 3. Sensor Networks are emerging
    • Many applications
    • - Real-time traffic monitoring
    • - Military applications
    • - Emergency and critical systems etc.
    • Need secure communication protocols
  • 4. Security for Sensor Networks
    • Data Authentication
    • Data Confidentiality
    • Data Integrity
    • Data Freshness
    • - Weak Freshness
    • - Partial message ordering, no delay information
    • - Useful for sensor measurements
    • - Strong Freshness
    • - Total ordering on req-res pair, delay estimation
    • - Useful for time synchronization
  • 5. Challenge: Resource Constraints
    • Limited energy
    • Limited computation(4MHz 8-bit)
    • Limited memory(512 bytes)
    • Limited code size(8 Kbytes)
    • Limited communication(30 byte packets)
    • Energy consuming communication
  • 6. Contributions
    • SNEP
    • -Sensor Network Encryption Protocol
    • - Secures point-to-point communication
    • µTESLA
    • -Micro Timed Efficient Stream Loss-tolerant Authentication
    • -Provides broadcast authentication
  • 7. System Assumptions
    • Communication patterns
    • -Node to base station (e.g. sensor readings)
    • - Base station to node (e.g. specific requests)
    • - Base station to all nodes
    • Base Station
    • - Sufficient memory, power
    • - Shares secret key with each node
    • Node
    • -Limited resources, limited trust
    A B D E F G C Base Station
  • 8. Notation A, B Principals( nodes) N A Nonce generated by A C A Counter generated by A χ AB Master secret key between A and B ( no direction information) K AB Secret encryption key between A and B (depends on direction) K’ AB Secret MAC key between A and B (depends on direction) {M} KAB Encryption of message M with K AB {M} <KAB,IV> Encryption of message M using key KAB and initialization vector IV MAC(K’ AB ,M) Message authentication code (MAC) of M
  • 9. SNEP
    • Data Confidentiality (Semantic Security )
    • Data Authentication
    • Replay Protection
    • Weak Freshness
    • Low Communication Overhead
  • 10. Key Generation /Setup
    • Nodes and base station share a master key pre-deployment
    • Other keys are bootstrapped from the master key:
      • Encryption key
      • Message Authentication code key
      • Random number generator key
    Counter RC5 Block Cipher Key Master Key MAC Key Encryption Key random
  • 11. Authentication, Confidentiality
    • Without encryption can have only authentication
    • For encrypted messages, the counter is included in the MAC
    • Base station keeps current counter for every node
    Node A M, MAC(K’ AB , M) {M} <KAB, CA> , MAC(K’ AB , C A || {M} <KAB, CA> ) Node B
  • 12. Strong Freshness
    • Nonce generated randomly
    • Sender includes Nonce with request
    • Responder include nonce in MAC, but not in reply
    Node A Request, N A {Response} <KBA, CB) , MAC(K’ BA , N A || C B || {Response} <KBA, CB> ) Node B
  • 13. Counter Exchange Protocol
    • Bootstrapping counter values
    Node A C A C B , MAC(K’ BA , C A ||C B ) Node B MAC(K’ AB , C A ||C B )
    • To synchronize:
      • A -> B : N A
      • B -> A : C B , MAC (K’ BA ,N A || C B ).
  • 14. µTESLA : Authenticated Broadcast
    • TESLA : efficient source authentication in multicast for wired networks.
    • Problems with TESLA
    • - Digital Signature for initial packet authentication
    • µTESLA uses only symmetric mechanism
    • -Overhead of 24 bytes per packet
    • µTESLA discloses key once per epoch
    • -One way key chain is too big
    • µTESLA restricts number of authenticated senders
  • 15. Key Setup
    • Main idea: One-way key chains
    • K 0 is initial commitment to chain
    • Base station gives K 0 to all nodes
    K n K n-1 K 1 K 0 X …… . F(Kn) F(K1) F(K2)
  • 16.  TESLA Quick Overview I
    • Keys disclosed 2 time intervals after use
    • Receiver knows authentic K3
    • Authentication of P1:MAC( K5 ,P1)
    K4 K5 K6 K7 t Time 4 Time 5 Time 6 Time 7 K3 P1 K3 P2 K5 F F Authenticate K5 Verify MAC F K6 F K5
  • 17.  TESLA Quick Overview II
    • Perfect robustness to packet loss
    K4 K5 K6 K7 t Time 4 Time 5 Time 6 Time 7 K3 P5 K5 P3 K3 P2 K2 P1 K2 Verify MACs P4 K4 F F Authenticate K5
  • 18.  TESLA Properties
    • Asymmetry from delayed key disclosure
    • Self-authenticating keys
    • Requires loose time synchronization
    • Low overhead (1 MAC)
      • - Communication (same as SNEP)
      • - Computation (~ 2 MAC computations)
    • Independent of number of receivers
  • 19. Applications
    • Authenticated Routing
    • Node to Node Agreement
    • A B: N A , A
    • B S: N A ,N B , A, B, MAC(K’ BS , N A || N B || A || B)
    • S A: {SK AB } KSA , MAC(K’ SA ,N A || A || {SK AB }K SA )
    • S B: {SK AB } KSB , MAC(K’ SB ,N B || B || {SK AB }K SB )
  • 20. Related Work in Broadcast Authentication
    • Symmetric schemes
    • - Link-state routing updates
    • - Multi-MAC
    • Asymmetric schemes
    • - Merkle hash tree
    • Chained hashes
    • - EMSS
    • Hybrid schemes
    • -Stream signature
    • -K-times signature
  • 21. Discussion: Drawbacks
    • The  TESLA protocol lacks scalability
    • - require initial key commitment with each nodes, which is very communication intensive
    • SPINS uses source routing, so vulnerable to traffic analysis
  • 22. Discussion: Risks Un-addressed
    • Information leakage through covert channels
    • No mechanism to determine and deal with compromised nodes.
    • Denial of service attacks
    • No Non-repudiation
  • 23. 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