MiniSec: A Secure Sensor Network Communication Architecture Carnegie Mellon UniversityUniversity of Maryland at College Park Mark Luk, Ghita Mezzour, Adrian PerrigVirgil Gligor

Agenda 2 Introduction MiniSec-U: Unicast Communication MiniSec-B: Broadcast Communication Implementation Conclusion

Problem 3 Designing a secure sensor network communication protocol is hard

Problem 4 Designing a secure sensor network communication protocol is hard Data secrecy, authentication, replay protection

Problem 5 Designing a secure sensor network communication protocol is hard Data secrecy, authentication, replay protection Low energy consumption

Comparison 6 Energy Consumption Low High Low High Security ZigBee TinySec MiniSec SPINS

Assumptions and Attacker Model 7 Assumptions Communicating parties share symmetric keys Route packets to intended destination with non-zero probability MiniSec-B Loose time synchronization Attacker Model Dolev-Yao attacker model Overhear, intercept, alter, inject arbitrary messages

Agenda 8 Introduction MiniSec-U: Unicast Communication MiniSec-B: Broadcast Communication Implementation Conclusion

MiniSec-U Background: OCB 9 OCB – Offset Codebook Mode [Rogaway et al. 03] Block cipher mode of operation Authenticated encryption in a single pass OCB Plaintext Key IV/Nonce Ciphertext MAC/Tag OCB Key IV/Nonce CiphertextMAC/Tag Plaintext Error  Initialization vector (IV) ensures that same plaintext does not encrypt to same ciphertext Needs to be non-repeating In MiniSec, we’ll be using an incrementing counter

Method 1: Send IV with Packet 10 E Plaintext Key IV CiphertextMAC/Tag D Key IV CiphertextMAC/Tag CiphertextTagIV TinySec 20 – 30 bytes2 bytes Disadvantage: ~ 10% packet overhead Plaintext Entire IV (TinySec, ZigBee ) IV Sent with Each Packet

Method 2: Synchronized IV 11 SPINS IV kept as incrementing counter on both parties Advantage: Eliminate IV in each packet sent Disadvantage: Counter resynchronization IV = 2 CiphertextTagCiphertextTagCiphertextTag IV = 3 Entire IV (TinySec, ZigBee ) None (SPINS) IV Sent with Each Packet IV = 1 IV = 0 Resynchronize Counter, IV=3Tag

MiniSec-U: IV Management 12 IV management is core issue Strike a compromise to attain minimum energy consumption Send last x bits of the IV Low communication overhead Keep x low No counter resynchronization Resynchronizes implicitly Send partial IV (MiniSec) Entire IV (TinySec, ZigBee ) None (SPINS) IV Sent with Each Packet

Example 1: MiniSec-U (x = 1) 13 CiphertextTag0 IV = 1000 IV = 1001IV = 1000 CiphertextTag1  Implicit counter resynchronization  Increment counter until final x bits match bits appended to the packet IV = 1001 IV = 1000IV = 1001  Works if less than 2 x packets dropped  What if more packets are dropped?

Example 2: MiniSec-U (x = 1) 14 CiphertextTag0 IV = 1000 IV = 1001IV = 1000 CiphertextTag1CiphertextTag1 IV = 1010IV = 1000 IV = 1101IV = 1000 IV = 1001IV = 1011IV = 1101  Implicit counter resynchronization  Increment counter by 2 x and reattempt decryption  Until maxAttempt decryptions  More computation  Less communication

MiniSec-U: Summary 15 Employs OCB for authenticated encryption Incrementing counter as IV/Nonce prevents replay attack IV management compromise between TinySec and SPINS Send last x bits of counter Attempt decryption up to maxAttempt

Comparison ProsCons TinySec  No counter resynchronization  Low packet overhead ZigBee  No counter resynchronization  High packet overhead SPINS  No packet overhead  Counter resynchronization MiniSec  No packet overhead  Implicit counter resynchronization 16

Agenda 17 Introduction MiniSec-U: Unicast Communication MiniSec-B: Broadcast Communication Implementation Conclusion

MiniSec-B: Motivation Many-to-many communication All nodes share symmetric key Core issue: Replay protection

TinySec: No Replay Protection 19 E Plaintext Key IV CiphertextMAC/Tag D Key IV CiphertextMAC/Tag CiphertextMACIV Disadvantage: No replay protection Plaintext CiphertextMACIV

SPINS and ZigBee: Per Sender State 20 IV AB = 1000 Ciphertext 1 IV AB = 1001 BAC IV BC = 0000 IV BC = 0001 Ciphertext 2 Disadvantage: Stored state grows at O(n) n is number of senders Ciphertext 1

MiniSec-B: Motivation 21 How can we detect replay attacks without per- sender state? Replay protection approach: Timing based – detect replays outside of timing window Requires loose time synchronization Bloom filter – detect replays within timing window Probabilistic replay protection Required state: Sender: Incrementing counter Receiver: Two alternating Bloom filters Stored state grows at O(B) B is bandwidth, which is constant

MiniSec-B: Timing Based Approach 22 Time E1E1 E3E3 E2E2 plaintext 1 k OCB E1E1 ciphertext 1, tag 1 Ciphertext 1 Tag 1 E1E1 E3E3 E2E2 Ciphertext 1 Tag 1 OCB k E1E1 ciphertext 1 tag 1 OCB k E3E3 ciphertext 1 tag 1

MiniSec-B Background: Bloom Filter 23 Space efficient data structure for fast probabilistic membership test Membership addition Membership query Probabilistic membership query Low false positives: query returns true where element is not in the set No false negatives: query returns false where element is in the set

MiniSec-B: Bloom Filter Based Approach 24 Bloom filter 1 Counter c a = 0 plaintext 2 plaintext 1 k OCB E 1 || c a ciphertext 1, tag 1 Time E1E1 E1E1 Ciphertext 1 Tag 1 caca

MiniSec-B: Bloom Filter Based Approach 25 Bloom filter 1 Counter c a = 0 plaintext 2 OCB k E 1 || c a ciphertext 2, tag 2 plaintext 1 k OCB E 1 || c a ciphertext 1, tag 1 Time E1E1 E1E1 Ciphertext 1 Tag 1 caca Ciphertext 2 Tag 2 caca

MiniSec-B: Bloom Filter Based Approach 26 Bloom filter 1 Counter c a = 0 plaintext 2 OCB k E 1 || c a ciphertext 2, tag 2 plaintext 1 k OCB E 1 || c a ciphertext 1, tag 1 Time E1E1 E1E1 Ciphertext 1 Tag 1 caca Ciphertext 2 Tag 2 caca Ciphertext 2 Tag 2 caca

27 Replay protection in many-to-many broadcasts Timing based approach Bloom filter based approach Counter sent with each packet Counter can be very small since it resets at each epoch Probabilistic replay protection False negatives: Replayed packet marked as an innocent packet MinSec-B: 0% False positives: Innocent packet marked as a replayed packet MinSec-B: Low False negatives more important than false positives MiniSec-B: Summary

Comparison ProsCons TinySec  No counter resynchronization  No stored state  Packet overhead  No replay protection ZigBee  No counter resynchronization  Replay protection  High packet overhead  O(n) state SPINS  No packet overhead  Replay protection  Counter resynchronization  O(n) state MiniSec  No packet overhead  Implicit counter resynchronization  Constant state  Probabilistic replay protection  Loose time synchronization 28

Implementation 29 Telos motes OCB encryption Block cipher: Skipjack 300 bytes of RAM, 3KB of code memory Rewrote TinyOS network stack GenereicComm – generic network stack AMStandard – Active Message transmission

Results PayloadPacket overhead (B) Total Size (B) Energy (mAs) Increase TinyOS/ TinySec % SPINS % MiniSec % 30

Optimal Value of maxAttempts 31 maxAttempts: Max Decryption Attempts Expected Energy Consumption (mAs)

Packet Drop Rate 32 Expected Energy Consumption (mAs) Packet Drop Rate

Conclusion 33 Existing protocols either optimize for high security or low energy utilization MiniSec Low energy consumption High security

Thank You 34