Secure and Self-Stabilizing Clock Synchronization in Clock Synchronization in Sensor Netw orks Jaap-Henk Hoepman Andreas Larsson Jaap-Henk Hoepman, Andreas Larsson Elad M. Schiller, Philippas Tsigas 13 November 2007
Wireless Sensor Netw orks
12 9 6 11 8 5 5 10 7 4 9 6 3 6 Attacks against clocks 8 5 2 7 7 4 1 6 3 0 6 6 6 5 5 5 5 4 4 4 3 3 3 3 2 2 2 1 1 1 1 0 0 0
Outline � Motivation � Implementation p � Attacks � Correctness � Correctness � Earlier work � Conclusion C l i
The need for clock The need for clock synchronization � Pinpointing events geographically � Time division message scheduling g g � Radio shutoff periods � Certain mathematical functions � Certain mathematical functions � …
Result of traditional protocols l t l diti f t lt R Need for precision Required result
Adversary � Much more powerful than the nodes • Intercepting • Replaying • Delaying � Capturing nodes and impersonating
Self-stabilization, Security & Self stabilization, Security & Fault tolerance � Dealing with transient faults � Security needs self-stabilization • Security under certain assumptions • Attacks eventually violate assumptions Arbitrary starting configuration � Fault tolerance � Fault tolerance – message loss message loss • Noise • Collisions Collisions
Outline � Motivation � Implementation p � Attacks � Correctness � Correctness � Earlier work � Conclusion C l i
The clock model � Offset is arbitrary � Rate, ρ , is varying • Manufacturing variations • Environmental variations � Clock rate stays within a certain interval Clock rate stays within a certain interval ρ < ρ < ρ min max
Roundtrip synchronization D C C B B A Offset Delay Delay
Offset with higher precision Reference Broadcast R2 R1 R1 R2 R2
The protocol layers Policy for accuracy and energy budget Clock adjustments [Römer et al. 05] j [ ] Filtering out delays [Song et al. 06] Beacon scheduling Beacon scheduling Beacon scheduling Beacon scheduling No self-stabilizing implementation exists Secure communication primitives [Sun et al. 06]
Combining the tw o approaches R n R2 R1 R1 … R1 R2 R i+1 Beacon sent by node i: A i R i-1 … B A R 0 B A
R n R n R n R n Dealing w ith message loss … … … … R i+1 R i+1 R i+1 R i+1 … … A i A i A i A i R i-1 R i-1 R i-1 R i-1 … … … … R 0 R 0 R 0 R 0 Q-1 … … Q 0 1
Delivering to upper layer � Data held by a node • Its beacon send times • Its receive times of beacons • The corresponding data received from others � Delivery to upper layer is delayed • Collect as much as possible before reporting
Randomized beacon scheduling Partition time Divide partitions into slots ( n log 2 n ) p ( g ) Randomly send one beacon per partition
Time complexity n nodes send a message of size O ( n ) each n nodes send a message of size O ( n ) each Optimal Optimal Our randomized strategy Our randomized strategy 2 log 2 2 n log n n n n n n = bound on degree of nodes b d d f d
Outline � Motivation � Implementation p � Attacks � Correctness � Correctness � Earlier work � Conclusion C l i
The attacker model � Interception of messages • Stop receival • Replay later � Capturing nodes p g • Get data including keys • Stop nodes p • Impersonate nodes
Delay attacks R1 R1 R1 R2 R2 � Cryptography does not help � Nonce does not help
Dealing w ith delay attacks A A D D B C � Locally calculate delay � Filter out over delayed beacons � Filter out over-delayed beacons • Byzantine agreement [Ganeriwal et al. 05] • Outlier filtering [Song et al 06] • Outlier filtering [Song et al. 06]
Dealing w ith captured nodes � Impersonated nodes send misleading data • Send at one time, claim another � Filter out misleading beacons • Byzantine agreement [Ganeriwal et al. 05] y g [ ] • Outlier filtering [Song et al. 06]
Outline � Motivation � Implementation p � Attacks � Correctness � Correctness � Earlier work � Conclusion C l i
Correctness proof � Beacon scheduler • Partially synchronous system • Message collision and omission � Probabilistic delivery guarantees • Every node sends a beacon that every node receives • Every node receives a response to its beacon Every node receives a response to its beacon from every node � Beacon aggregation (appears in TR) gg g ( pp )
Outline � Motivation � Implementation p � Attacks � Correctness � Correctness � Earlier work � Conclusion C l i
Self-stabilizing but not Secure � [Herman and Zhang 06] • a model for clock synchronization in sensor network • show that the converge-to-max approach is stabilizing • h th t th t h i t bili i � A single captured node attack • At any time introduce the maximal clock value At any time introduce the maximal clock value � Adversary sends the clock “far into the future” • Preventing a continuous time approximation function e e t g a co t uous t e app o at o u ct o
Secure but not Self-stabilizing � No existing secure and self-stabilizing implementations • Many implementations require initial clock M i l i i i i i l l k synchronization prior to the first pulse-delay attack � The adversary can risk detection and � The adversary can risk detection and intercept all beacons for a long period • As a result: arbitrary clock offsets • The system has to use global restart • No global restart after deployment!
Secure but not Self-stabilizing � [Sun et al. 05] cluster-wise synchronization • Based on synchronous rounds • Byzantine agreement • Synchronized clock at the starting configuration � We make n o assumptions on synchronous rounds or start
Secure but not Self-stabilizing � [Manzo et al. 05] • Consider attacks on unsecured clock synchronization • S • Suggest counter measures t t • Use a randomly selected “core” of nodes to minimize the effect of captured nodes • Do not consider the cases in which the adversary captures nodes after the core selection � We make no assumption regarding the W k ti di th distribution of the captured nodes
Secure but not Self-stabilizing � [Farrugia and Simon 06] • A cross-network spanning tree in which the clock values propagate for global clock synchronization values propagate for global clock synchronization • No pulse-delay attacks are considered � [Sun et al. 06] [Sun et al. 06] • Use external source nodes to increase the resilience against an attack that compromises source nodes � We use no source nodes
Outline � Motivation � Implementation p � Attacks � Correctness � Correctness � Earlier work � Conclusion C l i
Conclusion � System settings of traditional networks • cannot be assumed � Designer assumptions • cannot hold forever � Self-stabilization can provide self- defense capabilities p
Thank you for your attention Thank you for your attention y y Andreas Larsson l larandr@cs.chalmers.se d @ h l Chalmers University of Technology
Recommend
More recommend
