Secure and Fault-Tolerant Clock Synchronization in Sensor Networks

1. Secure and Fault-Tolerant Clock Synchronization in Sensor Networks Andreas Larsson Elad M. Schiller Philippas Tsigas

2. Outline Introduction challenges, opportunities and assumptions Our Contribution self-* and secure clock synchronization key establishment with mobile device optimizing communication Discussion

3. 12:02 12:04 12:03 12:01 12:00 12:05 12:00 12:03 12:04 12:02 12:01 12:05 12:01 12:00 12:02 12:03 12:05 12:04 Challenges • Gradient synch. • consistent state update • duplicate detection • from multiple sensors • object tracking • find the path using timestamps • can reverse the path 12:03 12:01 12:02

4. Challenges 12:02 12:01 12:01 12:00 12:02 12:03 12:00 12:05 12:03 12:04 12:01 12:02 12:07 12:06 12:03 12:05 12:04 12:00 • Gradient synch. • consistent state update • duplicate detection • from multiple sensors • object tracking • find the path using timestamps • canreversethe path 12:01 12:03 12:02

5. Challenges • Gradient synch. • Security • attack broadcasts • DoS attacks • pseudo collisions (jamming) • snoop messages • replay attacks • wormholes attack

6. Challenges 12:06 12:00 12:05 12:01 12:02 12:07 12:03 12:04 12:03 12:00 12:01 12:02 12:05 12:03 12:04 12:02 • Gradient synch. • Security • attack broadcasts • pulse delay attacks • The attacker • snoop a message on the fly • jam the signal of the message • replay the message later

7. Challenges • Gradient synch. • Security • attack broadcasts • pulse delay attacks • attack motes • destroy motes • capture motes • reveal private state • impersonation attacks • sybil attacks • exhaust battery and bandwidth

8. Challenges • Gradient synch. • Security • Sensor networks • unreliable motes • locality of communication • limited computation power • limited energy • configuration

9. Opportunities if attacker knows then is exposed • Cryptography • symmetric keys • encrypt/decrypt with same key • pro • affordable computation and size • cons • secure bootstrap environment

10. Opportunities • Cryptography • symmetric keys • public-key (authentication) • public key known to all, and • private key known to sender only • cons • unaffordable computation and size • pro • unattended bootstrap environment few verifications are affordable (Watro et al SASN'04)

11. Opportunities • Cryptography • Synch. techniques • round trip synchronization • the offset is • δ(S,R1) =½[(T2-T1)-(T4-T3)] • estimated delay • d(S,R1) =½[(T2-T1)+(T4-T3)] • Ganeriwal, Capkun & Srivastava WiSe'05 R1 T3 T2 time {T2, T3} S T1 T4

12. Opportunities • Cryptography • Synch. techniques • round trip synchronization • Pro • if communication delays are known • can detectdelay attacks! • cons • ifSis captured then • don’t deliver detection • ifR1is captured then • false positive (send falseT2and T3) R1 T3 T2 time {T2, T3} S T1 T4

13. Opportunities • Cryptography • Synch. techniques • round trip synchronization • reference broadcast • the offset is δ(R1,R2) =T2-T1 • Elson et al Operation System Rev. 2002 R1 T1 time S {T1} R2 T2

14. Opportunities • Cryptography • Synch. techniques • round trip synchronization • reference broadcast • Pro • improved synchronization in wireless • receivemore deterministic thansend • resilient to capturedSorR • no false positive • cons • messages fromScan be delayed R1 T1 time S {T1} R2 T2

15. Opportunities • round trip synchronization • reference broadcast • multi-round clock sampling • Cryptography • Synch. techniques • precision depends on • frequency of one-shot synchronization • sample different clocks • pro • remove outliers (faulty motes) • cons • accuracy limited • by synchronization duration • larger overheads

16. Opportunities • Cryptography • Synch. techniques • round trip synchronization • reference broadcast • multi-round clock sampling • how to find outliers • Song, Zhu and Cao MASS'05 • generalized extreme studentized deviate • pro • stateless computation • cons • upper boundf : number of outliers • resilient to a number of outliers • good for3f<n

17. Assumptions Security attack is detected when continuous contention drop in participation ratio common security scheme are used e.g., authentication and encryption we establish key distribution

18. Assumptions • elementary attacker • single attacker • distinct location at any time • incorruptible code for motes • that can emulate motes • uniform broadcasting • Security • Elementary attacker

19. Clock Synchronization • Taking turns as synchronizers • requirements • similar to token circulation • lightweight probabilistic version • in a legal execution • every non-captured mote • participate infinitely often time • pair wise participation ratio 1 ± ε • εboundedvalue random value

20. Clock Synchronization E 4 1,3 E * * E 2 • Taking turns as synchronizers • requirements • slot allocation (synchronous) • eventually stabilizes • resilience • time division • slot stores ID of last n synchronizers • s-next ← null • if ∃s: i ∈ slot[s] and • i = choose(slot[s]) then • s-next ← s • if ∄s: i ∈ slot[s] then • s-next←choose({s|slot[s]=E}) • use s-next(*skip round if null*)

21. Clock Synchronization 3 4 1 6 7 5 8 2 • Taking turns as synchronizers • requirements • slot allocation (synchronous) • eventually stabilizes • resilience • time division • within a round • all “unsloted” motes skip a round • “read” slots` allocation & try again • scheduler-luck game • correct allocation in the next round

22. Clock Synchronization 4 3 6 1 7 5 2 8 • Taking turns as synchronizers • requirements • slot allocation (synchronous) • stabilizes • resilience • time division • within constant number of rounds • all “unsloted” motes skip a round • “read” slots` allocation & try again • scheduler-luck game • correct allocation in the next round • when using k n log n – 1 slots • probability 1-2-k

23. Clock Synchronization safe unsafe empty • Taking turns as synchronizers • requirements • slot allocation (synchronous) • stabilizes • timedivision • uniform time units (observed locally) • in a legal execution • m: distance between synchronizers • e: empty slot is observed when • e = 2m+1 and m ≥2 • number of required time units • TimeUnits(x)=(x-1)e+1and • TimeUnits(n log n) ∈O(k m n log n)

24. Clock Synchronization • Motes take turns as synchronizers • Synchronization event • delay attacks and captured motes • combines • round trip synchronization • reference broadcast • the synchronizer sends apulse • theaudiencerespondwith • theirreferences • testforpulsedelay attacks • problem: • capturedR : false positive • capturedS : no detection T6 T2 T3 {T1} {T1,2,3} {T4',5} T1 T4 T4' T5

25. Clock Synchronization • Motes take turns as synchronizers • Synchronization event • delay attacks and captured motes • combines • round trip synchronization • reference broadcast • multi-round sampling + piggybacking • broadcasts T1 & vector of responds • [T2] jresponse to synchronizer j • remove outliers using GESD • capturedR :T2 (fixed a synchronizer) • capturedS: offsets (fixed responder) • δ(Si, R) =T2-T1where T2 are time samples sent by mote R to synchronizers {Si}1n in times {T1}1n

26. Key Distribution • Existing solutions • assume secure bootstrap • symmetric master key • capture one –capture all • key rings • capture some –capture all • Chan, Perrig and Song SP'03 • example for symmetric master key • key pool in several spaces • Du, Deng, Han at el • ACM Trans. Inf. System Security 2005 • example for key rings • we propose • secure automated distribution

27. Key Distribution • Existing solutions • Mobile Device • attended environment • secure channels • unattended environment • insecure channels • attended environment • mobile device:I-AM-ALIVE • mote: myID • mobile device: the moteinitial key

28. Key Distribution • Network degradation • Existing solutions • Maintenance tool • attended environment • secure channels • unattended environment • insecure channels • unattended environment • mobile device:I-AM-ALIVE • authenticatewith the public keys recall Watro et al (SASN'04) • mote: myID • mobile device: pairwise keys • random for each pair • initial key encryption

29. Optimization Broadcast Primitive authentication using pair wise keys one key for every receiver requires O(n) computation requires O(n) message size we use one key for all receivers! • Sun, Ning and Wang • J. Selected Areas in Communication 2006 • prepare a sequencex1, x2, ..., xk • randomx1andXi= hash(xi-1) • sendxkas a commitment • encrypt with pair wise keys hash

30. Optimization Broadcast Primitive authentication using pair wise keys one key for every receiver requires O(n) computation requires O(n) message size we use one key for all receivers! • send k-1 messages • <m1i, xk-1>, …, <mk-1, x1> • pro • on arrival verification • cons • few verifications are affordable • overhead: sender storesO(k)keys hash = <

31. Optimization Broadcast Primitive authentication using pair wise keys one key for every receiver requires O(n) computation requires O(n) message size we use one key for all receivers! • post arrival verification • choose a randomseedandkey • commitment to aseed • don’t sendkeyof commitment!

32. Optimization Broadcast Primitive authentication using pair wise keys one key for every receiver requires O(n) computation requires O(n) message size we use one key for all receivers! • post arrival authentication • choose a randomseedandkey • commitment to aseed • don’t sendkeyof commitment! • send any number of messages • <m1i, x1>, <m2, x2>, … • x0= seedandxi= poly-rand(xi-1) • store arriving messages poly

33. Optimization Broadcast Primitive authentication using pair wise keys one key for every receiver requires O(n) computation requires O(n) message size we use one key for all receivers! • when authentication is required • either by receiver or sender • revile the commitment: sendkey • receiver verifies sequence of keys • poly-rand sequence starts atseed

34. Optimization Broadcast Primitive authentication using pair wise keys one key for every receiver requires O(n) computation requires O(n) message size we use one key for all receivers! • when authentication is required • either by receiver or sender • revile the commitment: sendkey • receiver verifies sequence of keys • poly-rand sequence starts atseed = < poly

35. Optimization Broadcast Primitive authentication using pair wise keys one key for every receiver requires O(n) computation requires O(n) message size we use one key for all receivers! • when authentication is required • either by receiver or sender • revile the commitment: sendkey • receiver verifies sequence of keys • poly-rand sequence starts atseed = =

36. Optimization Broadcast Primitive authentication using pair wise keys one key for every receiver requires O(n) computation requires O(n) message size we use one key for all receivers! • use sequence numbers • more than1message (seq. num.) • request authentication • attacker sends pseudo-messages • end-up withO(n)authentication • use Sun at el method for the firstk • then use post-verification = =

37. Discussion • Our contribution • 1st self-* secure clock synch. • captured motes and pulse-delay • accuracy and overheads • similar toreference broadcasting • improved security primitives

38. Discussion • Our contribution • Related work • secure bootstrap • none consider both • pulse delay attacks • captured motes • some of them aren't fault tolerant • possible deadlocks

39. Your attention is appreciated More details: Technical report number 2006:16 Computer Science and Engineering Chalmers University of technology, 2006 Web: http://www.cs.chalmers.se/~dcs/