1 / 18

SPINS: Security Protocols for Sensor Networks

SPINS: Security Protocols for Sensor Networks. Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler, J.D. Tygar Research Topics in Security in the context of Crisis Management and Societal Security Dennis K. Nilsson 080415. Sensor Networks. Measurement Control Sensor node limitations

onaona
Télécharger la présentation

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 for Sensor Networks Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler, J.D. Tygar Research Topics in Security in the context of Crisis Management and Societal Security Dennis K. Nilsson 080415

  2. Sensor Networks • Measurement • Control • Sensor node limitations • Processing power • Storage • Bandwidth • Energy

  3. Security Possible? • Current security algorithms • Computational and memory expensive • Authenticated broadcasting • Communication overhead • TESLA – suitable for desktop workstations

  4. Agenda • System Description • Security Requirements • SNEP – Sensor Network Encryption Protocol • µTESLA – Authenticated broadcast • Implementation and Evaluation • Conclusion

  5. System Description • Nodes and powerful base stations • Communication • Node to base station • Base station to node • Base station to all nodes • Trust base stations but not • Individual nodes • Wireless communication • Design • Symmetric cryptography – single block cipher for all cryptographic primitives

  6. Security Requirements • Data confidentiality • Sensitive data should be kept secret • Data authentication • Receiver verifies data was sent from claimed sender • Data integrity • Ensures the receiver that data is unaltered in transit • Data freshness • Implies that data is recent and not replayed

  7. SNEP • Data confidentiality • Two-party data authentication • Data integrity • Data freshness • Prerequisites: • Shared secret key (master key) between each node and the base station

  8. SNEP • Low communication overhead • 8 bytes per message • Does not transmit counter • Keep state at both end points • Achieves semantic security • Randomization using shared counter

  9. SNEP • Encryption • E = {D}<Kencr,C> • MAC • M = MAC(Kmac,C|E) • Message from A to B A → B: {D}<Kencr,C>,MAC(Kmac,C|{D}<Kencr,C>)

  10. µTESLA • Redesign of TESLA protocol • TESLA not suitable for sensor networks • Authenticates initial packet with a digital signature • Overhead of 24 bytes per packet (sensor node packet size ~30 bytes) • Disclose key for previous intervals with every packet • One-way key chain does not fit in memory

  11. µTESLA • Base station broadcasts authenticated messages to the nodes • Base station and nodes loosely time synchronized • Base station computes MAC on a packet with a key that is secret at that time • Receiving node can verify that corresponding MAC key has not been disclosed • MAC key chain – Ki = F(Ki+1)

  12. F F F F K1 K2 K3 K4 µTESLA - Example K0 0 1 2 3 4 time P1 P2 P3 P4 P5 P6 P7 K1 K2 K3 K4

  13. F F K1 µTESLA – Example, dropped msg K0 K2 0 1 2 3 4 time P1 P2 P3 P4 P5 K1 K2

  14. µTESLA • Sender setup • Generate one-way key chain of length n from randomly chosen Kn • Time is divided time intervals • Each key is associated with one interval • Bootstrap receiver • A commitment of the key chain is stored in receiver, subsequent keys are self-authenticated

  15. µTESLA • Authenticating broadcast packets • Receiver must ensure attacker does not know the disclosed key used for MAC (i.e., sender has not disclosed key yet) • Sender-receiver must be loosely time synchronized and receivers must know the key disclosure schedule • Authenticate received key Kj: Ki = Fj-i(Kj)

  16. Implementation and evaluation • RC5 block cipher • small code size and high efficiency • but 32-bit data rotates (8-bit CPU) • Encryption • Counter mode (same function for encryption and decryption) • Random-number generation • MAC(Krand,C) • MAC • CBC-MAC: {M}Kencr, MAC(Kmac,{M}Kencr) • Key setup • Kencr, Kmac, Krand derived from master key

  17. Implementation and evaluation • Code size • Crypto library and protocol implementation – 2kB of program memory • Performance • Key setup 8000 cycles, 8-byte encryption 120 cycles, twenty 30-byte messages per second • Energy costs • Encrypting and signing: 6 bytes overhead per message (~20%) • MAC computation 2%

  18. Conclusion • Designed and implemented security protocols for sensor networks • Authenticated and confidential communication • Authenticated broadcast • Use symmetric cryptography • Code reuse • Communication costs are small • Many elements of the design are universal and can be applied to other sensor networks

More Related