015 spins

555 views
420 views

Published on

Published in: Technology, Education
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
555
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
29
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

015 spins

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

×