Presentation is loading. Please wait.

Presentation is loading. Please wait.

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

Similar presentations


Presentation on theme: "MiniSec: A Secure Sensor Network Communication Architecture Carnegie Mellon UniversityUniversity of Maryland at College Park Mark Luk, Ghita Mezzour, Adrian."— Presentation transcript:

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

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

3 Problem 3 Designing a secure sensor network communication protocol is hard

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

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

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

7 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

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

9 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

10 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

11 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

12 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

13 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?

14 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

15 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

16 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

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

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

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

20 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

21 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

22 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

23 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

24 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

25 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

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

28 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

29 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

30 Results PayloadPacket overhead (B) Total Size (B) Energy (mAs) Increase TinyOS/ 802.15.4 2412360.034- TinySec2417410.038713.9% SPINS2420440.041522.2% MiniSec2415390.03688.3% 30

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

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

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

34 Thank You 34 mluk@cmu.edu www.ece.cmu.edu/~mluk


Download ppt "MiniSec: A Secure Sensor Network Communication Architecture Carnegie Mellon UniversityUniversity of Maryland at College Park Mark Luk, Ghita Mezzour, Adrian."

Similar presentations


Ads by Google