WSN: Security<br />Peter Chapin<br />Abe Barth-Werb<br />Rob Rohr<br />Diana Tatar<br />CS295/361<br />Wireless Sensor Net...
Agenda<br /><ul><li>Security OverviewPeter Chapin
Simulation Environment – TOS1.xAbe Barth-Werb
TinySec – TOS1.xRob Rohr
MiniSec – TOS2.xDiana Tatar</li></li></ul><li>WSN Security(Background)‏<br />Peter C. Chapin<br />
Security Services, Part 1<br />Confidentiality<br />Keep data from unauthorized eyes (encryption)‏<br />Authentication<br ...
Security Services, Part 2<br />Anti-Replay<br />Reject authenticated packets that are “replayed” by an adversary to confus...
Other Kinds of Attacks<br />Traffic Analysis<br />A concern when the fact communication has taken place is itself revealin...
Special Challenges, Part 1<br />Small Computational Resources<br />Public key methods too computational intensive (even EC...
Special Challenges, Part 2<br />Extremely Powerful Adversaries<br />Adversary not limited to mote technology!<br />Can use...
Special Challenges, Part 3<br />No Physical Security!<br />Adversary who steals a mote can:<br />Manipulate sensors to gen...
Special Challenges, Part 4<br />Low Power Operation<br />Must minimize radio overhead. Can't bulk up packets with security...
Key Distribution<br />How do the nodes get the keys?<br />Use a single, network-wide key<br />Simple to deploy<br />Allows...
Probabilistic Key Sharing<br />Each node has k<br />keys drawn randomly<br />from a pool of size P<br />Shared keys<br />R...
SNEP / TinySec / MiniSec<br />SNEP<br />Oldest of the three<br />Relatively high packet overhead (8 bytes)‏<br />TinySec<b...
TinyOS Simulation EnvironmentTOSSIM, TinyViz<br />Abe Barth-Werb<br />
BEWARE!<br />Tiny OS 1 ONLY!!!<br />
Cool stuff from 40,000 feet<br />Radio Loss Simulation<br />Lossy builder<br />Packet Injection<br />SerialForwarder<br />...
DEMO-O-CLOCK!!!!<br />
TinySecAn overview<br />Rob Rohr<br />It’s tiny.  Really.<br />And somewhat secure.<br />
Security Risks in Wireless Sensory Networks<br />K<br />K<br />Eavesdropping<br />Confidentiality<br />Packet Injection<br...
TinySec Architectural Features<br />Single shared global cryptographic key<br />Link layer encryption and integrity protec...
TinySec Summary<br />Security properties<br />Access control<br />Integrity<br />Confidentiality<br />Performance<br />5 b...
Block Ciphers<br />Pseudorandom permutation (invertible)<br />DES, RC5, Skipjack, AES<br />Maps n bits of plaintext to nbi...
Packet Format<br />dest<br />IV<br />data<br />MAC<br />AM<br />length<br />2<br />1<br />4<br />1<br />4<br />Encrypted<b...
MHSRTinySecM<br />TinySecM<br />CBC-ModeM<br />CBC-MACM<br />RC5M<br />TinySec Interfaces<br />TinySec<br />TinySecM: brid...
Security Analysis<br />Access control and integrity<br />Probability of blind MAC forgery 1/232<br />Replay protection not...
Cipher Performance<br />2 block cipher operations per block, which take 1.0 ms/block<br />For comparison, takes an ~4.8 ms...
Discussion<br />Short packets have more overhead<br />Min data size is 8 bytes (size of block cipher)<br />Packet length n...
Usage: How does this change my life?<br />Need to be aware of keys & keyfile<br />Currently, keys part of program, not int...
Conclusions<br />TinySec can provide transparent security for applications<br />Access control<br />Integrity<br />Confide...
MiniSec:A Secure Sensor Network Communication Architecture<br />Diana Tatar<br />Developed by Carnegie Mellon University<b...
Goal:<br />Design a secure sensor network communication protocol that provides<br />Data secrecy<br />Authentication 	<br ...
Comparison<br />High<br />ZigBee<br />MiniSec<br />SPINS<br />Security<br />TinySec<br />Low<br />High<br />Low<br />Energ...
Plaintext<br />Ciphertext<br />MAC/Tag<br />Key<br />Key<br />IV/Nonce<br />IV/Nonce<br />Ciphertext<br /> MAC/Tag<br />Er...
Block cipher mode of operation
Authenticated encryption in a single pass</li></ul>OCB<br />OCB<br /><ul><li>Initialization vector (IV) ensures that same ...
Needs to be non-repeating
An incrementing counter is used</li></li></ul><li>Plaintext<br />Ciphertext<br />MAC/Tag<br />Key<br />IV<br />Ciphertext<...
Ciphertext<br />Tag<br />Ciphertext<br />Tag<br />Ciphertext<br />Tag<br />IV = 0<br />IV = 0<br />IV = 1<br />IV = 1<br /...
IV kept as incrementing counter on both parties
Advantage: Eliminate IV in each packet sent
Disadvantage: Counter resynchronization</li></ul>IV = 2<br />IV = 2<br />IV = 3<br />
MiniSec-U: IV Management<br /><ul><li>IVmanagement is core issue
Strike a compromise to attain minimum energy consumption
Send last xbits of the IV
Upcoming SlideShare
Loading in …5
×

WSN Security (Background)‏

8,478 views
8,376 views

Published on

1 Comment
2 Likes
Statistics
Notes
No Downloads
Views
Total views
8,478
On SlideShare
0
From Embeds
0
Number of Embeds
14
Actions
Shares
0
Downloads
145
Comments
1
Likes
2
Embeds 0
No embeds

No notes for slide

WSN Security (Background)‏

  1. 1. WSN: Security<br />Peter Chapin<br />Abe Barth-Werb<br />Rob Rohr<br />Diana Tatar<br />CS295/361<br />Wireless Sensor Networks<br />Feb. 12, 2008<br />
  2. 2. Agenda<br /><ul><li>Security OverviewPeter Chapin
  3. 3. Simulation Environment – TOS1.xAbe Barth-Werb
  4. 4. TinySec – TOS1.xRob Rohr
  5. 5. MiniSec – TOS2.xDiana Tatar</li></li></ul><li>WSN Security(Background)‏<br />Peter C. Chapin<br />
  6. 6. Security Services, Part 1<br />Confidentiality<br />Keep data from unauthorized eyes (encryption)‏<br />Authentication<br />Only accept packets from authorized senders (MAC, not expensive digital signatures)‏<br />Data Integrity<br />Ensure packets not maliciously modified in flight (MAC replaces normal CRC).<br />BUT... don't interfere with in-network data aggregation (so no end-to-end protection).<br />
  7. 7. Security Services, Part 2<br />Anti-Replay<br />Reject authenticated packets that are “replayed” by an adversary to confuse the network.<br />Can't keep arbitrary amounts of information about past packets.<br />One approach: label each outgoing packet with a counter. Receiver ignores old labels.<br />TinySec does nothing to protect against replays.<br />Authors argue this is outside the scope of the link layer.<br />
  8. 8. Other Kinds of Attacks<br />Traffic Analysis<br />A concern when the fact communication has taken place is itself revealing.<br />Normally thwarted by generating spurious traffic.<br />Obvious this is undesirable in a WSN<br />Denial of service<br />Keep nodes busy with many queries. Prevents nodes from engaging in normal activity.<br />Sleep Deprivation<br />A form of denial of service specifically intended to wear down batteries.<br />
  9. 9. Special Challenges, Part 1<br />Small Computational Resources<br />Public key methods too computational intensive (even ECC is too hard).<br />Symmetric algorithms must be selected carefully<br />Must be easy to compute<br />Must have small memory footprint (instruction and data)‏<br />No space for large arrays of pre-computed data.<br />Skipjack seems favored by some researchers.<br />MiniSec authors used OCB mode<br />Computes MAC and cipher text in a single pass.<br />
  10. 10. Special Challenges, Part 2<br />Extremely Powerful Adversaries<br />Adversary not limited to mote technology!<br />Can use a cluster of workstations to crack security in recorded packets.<br />Can use powerful antennae and transceivers to interact with WSN from a “safe” distance.<br />BUT...<br />WSN can't send/receive packets too quickly.<br />Hard for adversary to collect data or execute trial-and-error style attacks.<br />
  11. 11. Special Challenges, Part 3<br />No Physical Security!<br />Adversary who steals a mote can:<br />Manipulate sensors to generate bogus data.<br />Attempt to extract key material from it.<br />Countermeasures:<br />Tamperproof packaging<br />Does it really exist?<br />Key revocation protocols<br />Not all applications suffer from a lack of physical security.<br />
  12. 12. Special Challenges, Part 4<br />Low Power Operation<br />Must minimize radio overhead. Can't bulk up packets with security headers.<br />Large IVs, large nonces, long time stamps...<br />All bad.<br />Must use clever techniques to minimize packet size<br />Pack bits into other header fields<br />Maintain synchronized state on two communicating motes; use headers only to keep synchronized.<br />
  13. 13. Key Distribution<br />How do the nodes get the keys?<br />Use a single, network-wide key<br />Simple to deploy<br />Allows easy network auto-configuration and self-healing.<br />BUT... a single node compromise breaks the network.<br />Use a different key for each communicating pair<br />Introduces a key distribution problem.<br />Lots of research on this.<br />
  14. 14. Probabilistic Key Sharing<br />Each node has k<br />keys drawn randomly<br />from a pool of size P<br />Shared keys<br />Radio<br />connectivity<br />“A Key Management Scheme for Distributed Sensor Networks”<br />Eschenauer and Gligor, CCS '02<br />
  15. 15. SNEP / TinySec / MiniSec<br />SNEP<br />Oldest of the three<br />Relatively high packet overhead (8 bytes)‏<br />TinySec<br />Leaves out key distribution and anti-replay<br />MiniSec<br />Provides anti-replay support using synchronized counters.<br />But uses clever methods to keep counters in synch<br />OCB mode for faster MAC+ ciphertextcomputation.<br />
  16. 16. TinyOS Simulation EnvironmentTOSSIM, TinyViz<br />Abe Barth-Werb<br />
  17. 17. BEWARE!<br />Tiny OS 1 ONLY!!!<br />
  18. 18. Cool stuff from 40,000 feet<br />Radio Loss Simulation<br />Lossy builder<br />Packet Injection<br />SerialForwarder<br />TOSSIM Power<br />TinyViz<br />TinyViz plug-ins<br />
  19. 19. DEMO-O-CLOCK!!!!<br />
  20. 20. TinySecAn overview<br />Rob Rohr<br />It’s tiny. Really.<br />And somewhat secure.<br />
  21. 21. Security Risks in Wireless Sensory Networks<br />K<br />K<br />Eavesdropping<br />Confidentiality<br />Packet Injection<br />Access control<br />Integrity<br />Jamming<br />Replay<br />Denial of Service<br />TinySec<br />K<br />K<br />Adversary<br />
  22. 22. TinySec Architectural Features<br />Single shared global cryptographic key<br />Link layer encryption and integrity protection  transparent to applications<br />New radio stack based on original<br />Cryptography based on a block cipher<br />K<br />K<br />K<br />
  23. 23. TinySec Summary<br />Security properties<br />Access control<br />Integrity<br />Confidentiality<br />Performance<br />5 bytes / packet overhead<br />Peak bandwidth (8 bytes data):25 packets/sec vs.40 packets/sec<br />(TinySec) (MHSR)<br />
  24. 24. Block Ciphers<br />Pseudorandom permutation (invertible)<br />DES, RC5, Skipjack, AES<br />Maps n bits of plaintext to nbits of ciphertext<br />Used to build encryption schemes and message authentication codes (MAC)<br />
  25. 25. Packet Format<br />dest<br />IV<br />data<br />MAC<br />AM<br />length<br />2<br />1<br />4<br />1<br />4<br />Encrypted<br />MAC’ed<br />Key Differences<br />No CRC -2 bytes<br />No group ID -1 bytes<br />MAC +4 bytes<br />IV +4 bytes<br />Total: +5 bytes<br />
  26. 26. MHSRTinySecM<br />TinySecM<br />CBC-ModeM<br />CBC-MACM<br />RC5M<br />TinySec Interfaces<br />TinySec<br />TinySecM: bridges radio stack and crypto libraries<br />BlockCipher<br />3 Implementations: RC5M, SkipJackM, IdentityCipher<br /> (SRI has implemented AES)<br />BlockCipherMode<br />CBCModeM: handles cipher text stealing<br />No length expansion when encrypting data<br />MAC<br />CBCMACM: computes message authentication code using CBC<br />
  27. 27. Security Analysis<br />Access control and integrity<br />Probability of blind MAC forgery 1/232<br />Replay protection not provided, but can be done better at higher layers<br />Confidentiality – Reused IVs can leak information<br />IV reuse will occur after 216 messages from each node [1 msg / min for 45 days]<br />Solutions<br />increase IV length  adds packet overhead<br />key update protocol  adds complexity<br />Applications have different confidentiality requirements<br />Need a mechanism to easily quantify and configure confidentiality guarantees<br />Applications may provide IVs implicitly (e.g. timestamps)<br />Apps may guarantee sufficient variability in their messages<br />
  28. 28. Cipher Performance<br />2 block cipher operations per block, which take 1.0 ms/block<br />For comparison, takes an ~4.8 ms to send one block over radio<br />Encryption and MAC can be overlapped with transmission/reception<br />
  29. 29. Discussion<br />Short packets have more overhead<br />Min data size is 8 bytes (size of block cipher)<br />Packet length not affected for more than 8 bytes of data <br />Acknowledgments can be authenticated with no extra work or overhead<br />1/256 chance of forgery<br />Group ID no longer supported<br />
  30. 30. Usage: How does this change my life?<br />Need to be aware of keys & keyfile<br />Currently, keys part of program, not intrinsic to mote (similar to moteID)<br />Makerulesgenerates a keyfile if none exists, used for programming all motes;<br />Keyfileresides in user’s home directory. Manual transfer needed to install motes from different computers.<br />Only application level code change:<br />Just use SecureGenericComm instead of GenericComm<br />Works in simulator<br />
  31. 31. Conclusions<br />TinySec can provide transparent security for applications<br />Access control<br />Integrity<br />Confidentiality<br />Problems not addressed:<br />Jamming <br />Node or key compromise<br />Replay<br />Denial of service<br />
  32. 32. MiniSec:A Secure Sensor Network Communication Architecture<br />Diana Tatar<br />Developed by Carnegie Mellon University<br />
  33. 33. Goal:<br />Design a secure sensor network communication protocol that provides<br />Data secrecy<br />Authentication <br />Replay protection<br />Freshness<br />Low energy consumption<br />Resilient to Lost Messages<br />
  34. 34. Comparison<br />High<br />ZigBee<br />MiniSec<br />SPINS<br />Security<br />TinySec<br />Low<br />High<br />Low<br />Energy Consumption<br />
  35. 35. Plaintext<br />Ciphertext<br />MAC/Tag<br />Key<br />Key<br />IV/Nonce<br />IV/Nonce<br />Ciphertext<br /> MAC/Tag<br />Error<br />Plaintext<br />MiniSec-U: Unicast Communication<br /><ul><li>Offset Codebook Mode (OCB) - Encryption
  36. 36. Block cipher mode of operation
  37. 37. Authenticated encryption in a single pass</li></ul>OCB<br />OCB<br /><ul><li>Initialization vector (IV) ensures that same plaintext does not encrypt to same ciphertext
  38. 38. Needs to be non-repeating
  39. 39. An incrementing counter is used</li></li></ul><li>Plaintext<br />Ciphertext<br />MAC/Tag<br />Key<br />IV<br />Ciphertext<br />MAC/Tag<br />Method 1: Send IV with Packet<br />Key<br /> E <br /> D <br />IV<br />Plaintext<br />TinySec<br />Ciphertext<br />Tag<br />IV<br />20 – 30 bytes<br />2 bytes<br />Disadvantage: ~ 10% packet overhead<br />Method used by TinySec<br />
  40. 40. Ciphertext<br />Tag<br />Ciphertext<br />Tag<br />Ciphertext<br />Tag<br />IV = 0<br />IV = 0<br />IV = 1<br />IV = 1<br />Resynchronize Counter, IV=3<br />Tag<br />Method 2: Synchronized IV <br /><ul><li>SPINS
  41. 41. IV kept as incrementing counter on both parties
  42. 42. Advantage: Eliminate IV in each packet sent
  43. 43. Disadvantage: Counter resynchronization</li></ul>IV = 2<br />IV = 2<br />IV = 3<br />
  44. 44. MiniSec-U: IV Management<br /><ul><li>IVmanagement is core issue
  45. 45. Strike a compromise to attain minimum energy consumption
  46. 46. Send last xbits of the IV
  47. 47. Low communication overhead
  48. 48. Keep x low
  49. 49. No counter resynchronization
  50. 50. Resynchronizes implicitly </li></ul>Send partial IV<br />(MiniSec)<br />Entire IV<br />(TinySec, ZigBee)<br />None<br />(SPINS)<br />IV Sent with Each Packet<br />
  51. 51. Pros<br />Cons<br />TinySec<br /><ul><li> No counter resynchronization
  52. 52. Low packet overhead </li></ul>ZigBee<br /><ul><li> No counter resynchronization
  53. 53. High packet overhead</li></ul>SPINS<br /><ul><li> No packet overhead
  54. 54. Counter resynchronization</li></ul>MiniSec<br /><ul><li> No packet overhead
  55. 55. Implicit counter resynchronization</li></ul>Comparison<br />
  56. 56. MiniSec-B:Broadcast Communication<br />Many-to-many communication<br />All nodes share symmetric key<br />OCB-Authentication & Encryption<br />Replay protection<br />Timing based – detect replays outside of timing window<br />Bloom filter – detect replays within timing window<br />
  57. 57. TinySec: No protection<br />Ciphertext<br />MAC<br />IV<br />Ciphertext<br />MAC<br />IV<br />Disadvantage: No replay protection<br />
  58. 58. B<br />A<br />C<br />Ciphertext1<br />Ciphertext2<br />IVAB = 1000<br />IVAB = 1000<br />IVAB = 1001<br />IVAB = 1001<br />IVBC = 0000<br />IVBC = 0000<br />IVBC = 0001<br />IVBC = 0001<br />Ciphertext1<br />SPINS and ZigBee: Per Sender State<br />Disadvantage: Stored state grows at O(n)<br />n is number of senders<br />
  59. 59. Ciphertext1<br />Tag1<br />ciphertext1<br />tag1<br />k<br />OCB<br />E1<br />ciphertext1, tag1<br />ciphertext1<br />tag1<br />Ciphertext1<br />Tag1<br />k<br />OCB<br />E3<br />MiniSec-B: Timing Based Approach<br />Time<br />plaintext1<br />E1<br />E1<br />k<br />OCB<br />E1<br />E2<br />E2<br />E3<br />E3<br />
  60. 60. Ciphertext1<br />Tag1<br />ca<br />k<br />OCB<br />E1 || ca<br />ciphertext1, tag1<br />MiniSec-B: Bloom Filter Based Approach<br />Time<br />Counter<br />ca= 0<br />Bloom <br />filter1<br />plaintext1<br />E1<br />E1<br />plaintext2<br />
  61. 61. Ciphertext1<br />Tag1<br />ca<br />k<br />OCB<br />E1 || ca<br />ciphertext1, tag1<br />Ciphertext2<br />Tag2<br />ca<br />k<br />OCB<br />E1 || ca<br />ciphertext2, tag2<br />MiniSec-B: Bloom Filter Based Approach<br />Time<br />Counter<br />ca= 0<br />Bloom <br />filter1<br />plaintext1<br />E1<br />E1<br />plaintext2<br />
  62. 62. Ciphertext1<br />Tag1<br />ca<br />k<br />OCB<br />E1 || ca<br />ciphertext1, tag1<br />Ciphertext2<br />Tag2<br />ca<br />k<br />OCB<br />E1 || ca<br />ciphertext2, tag2<br />Ciphertext2<br />Tag2<br />ca<br />MiniSec-B: Bloom Filter Based Approach<br />Time<br />Counter<br />ca= 0<br />Bloom <br />filter1<br />plaintext1<br />E1<br />E1<br />plaintext2<br />
  63. 63. Pros<br />Cons<br />TinySec<br /><ul><li>No counter resynchronization
  64. 64. No stored state
  65. 65. Packet overhead
  66. 66. No replay protection</li></ul>ZigBee<br /><ul><li>No counter resynchronization
  67. 67. Replay protection
  68. 68. High packet overhead
  69. 69. O(n) state </li></ul>SPINS<br /><ul><li> No packet overhead
  70. 70. Replay protection
  71. 71. Counter resynchronization
  72. 72. O(n) state</li></ul>MiniSec<br /><ul><li> No packet overhead
  73. 73. Implicit counter resynch
  74. 74. Constant state
  75. 75. Probabilistic replay protection
  76. 76. Loose time synchronization</li></ul>Comparison<br />
  77. 77. Conclusion<br />Existing protocols either optimize for high security or low energy utilization<br />MiniSec<br />Low energy consumption<br />High security<br />
  78. 78. Bibliography<br />Team project web site<br />http://sharepoint.uvm.edu/sites/tinysec<br />WSN Security<br />TBA<br />TinySec<br />TinySec: A Link Layer Security Architecture for Wireless Sensor Networkshttp://naveen.ksastry.com/papers/tinysec-sensys04.pdf<br />TinySec: User Manualhttp://www.tinyos.net/tinyos-1.x/doc/tinysec.pdf<br /><ul><li>MiniSec
  79. 79. MiniSec: A Secure Network Communication Architecturehttp://sparrow.ece.cmu.edu/group/minisec.html
  80. 80. Simulation
  81. 81. TOSSIM: A Simulator for TinyOS Networks http://www.cs.berkeley.edu/~pal/pubs/nido.pdf
  82. 82. TinyViz: TOSSIM and TinyVizhttp://webs.cs.berkeley.edu/retreat-1-03/slides/1-03-tossim-tinyviz.pdfAlso, TOS1.x Tutorial, Lesson 5
  83. 83. PowerTOSSIM: Efficient Power Simulation for TinyOS Applications (SenSys ’04)http://www.eecs.harvard.edu/~shnayder/ptossim/</li>

×