1 / 25

Security on Sensor Networks

Security on Sensor Networks. SPINS: Security Protocol for Sensor Networks TinySec: Security for TinyOS. Presented by Min-gyu Cho. General Security Requirements. Confidentiality:

mort
Download Presentation

Security on 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. Security on Sensor Networks SPINS: Security Protocol for Sensor Networks TinySec: Security for TinyOS Presented by Min-gyu Cho

  2. General Security Requirements • Confidentiality: • The property that information is not made available or disclosed to unauthorized individuals, entities or processes • Authentication • The verification of a claimed identity • Integrity • The assurance that information can only be accessed or modified by those authorized to do so

  3. 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 Asymmetric Cryptography Very Expensive!!!

  4. SPINS • Adrian Perrig, Robert Szewczyk, Victor Wen, David Culler, J. D. Tygar, “SPINS: Security Protocols for Sensor Networks,” MOBICOM 2001 • Security Protocols proposed for Sensor Networks which provides • Authentication • Ensures data integrity & origin • Prevents injecting bogus messages • Confidentiality • Ensures secrecy of data • Prevents eavesdropping

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

  6. 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

  7. 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

  8. 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

  9. SNEP Protocol Details • A and B share • Keys • The master secret key χ • derived keys from the master secret key • Encryption keys: KAB KBA • MAC keys: K'AB K'BA • Counters: CA CB • Counter exchange protocol A  B: CA B  A: CB, MAC(K’BA, CA || CB) A  B: MAC(K’AB, CA || CB)

  10. SNEP Protocol Details (Cont.) • To send data D, A sends to B: A B: {D}<KAB, CA> MAC( K'AB , [CA || {D}<KAB, CA>] ) • To add the freshness for B’s response A B: NA, RA B A: {RB}<KBA, CB> MAC( K‘BA , [NA || CB || {RB}<KBA, CB>] )

  11. 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

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

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

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

  15. 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

  16. 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

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

  18. TinySec: Security for TinyOS • Included in TinyOS 1.x • Link layer security mechanism, providing • Access Control • Integrity • Confidentiality • Transparency to applications and programmers

  19. Block Ciphers • Pseudorandom permutation (invertible) • DES, RC5, Skipjack, AES • Maps n bits of plaintext to n bits of ciphertext • Block size n is typically 64 or 128 bits • Key size k is typically 64 or 128 bits

  20. m1 m2 iv Ek Ek Ek c1 c2 CBC-Mode Symmetric key encryption • Confidentiality achieved by encryption • Encryption schemes (modes) can be built using block ciphers • CBC-mode: break a m bit message into 64 bit chunks (m1,m2,..) • Transmit (c1, c2, …) and iv • iv is needed to achieve semantic security • A message looks different every time it is encrypted • iv reuse may leak information

  21. MAC: Message Authentication Code • Encryption is not enough to ensure message integrity • Receiver cannot detect changes in the ciphertext • Resulting plaintext will still be valid • Integrity achieved by a message authentication code • A t bit cryptographic checksum with a k bit key from an m bit message • Can detect both malicious changes and random errors • Replaces CRC • Can be built using a block cipher • MAC key should be different than encryption key m1 m2 length Ek Ek Ek MAC CBC-MAC Mode

  22. TinyOS System Changes MicaHighSpeedRadio TinySec CBC-MAC CBC-Mode RC5

  23. Grp_ID dest AM length data CRC dest AM IV length data MAC 2 2 1 1 1 2 1 4 1 4 Encrypted MAC’ed Packet Format • Key Differences No CRC -2 bytes No group ID -1 bytes MAC +4 bytes IV +4 bytes • Total: +5 bytes

  24. Usage • Need to be aware of keys & keyfile • Currently, keys part of program, not intrinsic to mote (similar to moteID) • Makerules generates a keyfile if none exists and then uses it for programming all motes; • Keyfiles tied to a particular TinyOS installation. Manual transfer needed to install motes from different computers. • Only application level code change: • Just use SecureGenericComm instead of GenericComm • Works on Simulator

  25. Analysis • Access control and integrity • Probability of blind MAC forgery 1/232 • Industrial strength is usually 1/264 or less • Replay protection not provided, but can be done better at higher layers • Confidentiality • Lots of ways to structure and manage IV’s, but IV reuse will occur after ~65000 messages from each node • For CBC mode, IV reuse is not as severe has other modes • Does not necessarily leak plaintext • Common solution is to increase IV length  adds packet overhead

More Related