An Improved Clock-skew Measurement Technique for Revealing Hidden Services De−noised Median: 0.08ms ●● ● ●● ● ● ●● Temperature 26.2 ●● ● ●●●●●●●● 26.1 ●●●●●●● ●●●● −1.5 − −2.0 ●● ● ● ●● ● ● ●●●● 26.0 ● ● ● ●● ● ●●●●● 6 ● ● Quantisation error ●●● ●●●●●● 2 ● ●●●● ● 0 ● ●● ● ●● ●● ● ●● ●● ● ● ●●●●● ●●● ● ●● ●● ● ●●●● ● ●● ●● ● ●●●●● ● ● ● ● ● −1 ● ●● ● ● ● ● ●●● ● ●●●● ●● ●●● ●●●●● ● ● ●●●● ●● ●●●●● ● ● ●● ● ● ● ●● ●● Reference Sync ● Random 0 25.8 Sat 17:00 0.0 Time ●● ●●●● ●●●● ●● ● ● −2 ● ● Sat 07:00 ● ●● ● ● ●● ●●●●● ●●●●●● 25.9 ●●●●●●●●●●●●●●●● Fri 21:00 ● ● ● 1 ● ● Variable skew Fri 11:00 4 ● ● ●●● Clock skew change (ppm) ● ● ● ●●● Density ● ● Window size: 7200 s ● 2 ● 26.3 Non−linear offset ● −1.0 Random sample Synchronised sample ● Target timestamp −0.5 ● 26.4 ● ●● ● ● Temperature (°C) Non−linear offset component (ms) 0.0 0.5 Time 1.0 1.5 2.0 Noise (ms) 15:00 19:00 23:00 03:00 07:00 Time (mm:ss) Sebastian Zander1 , Steven J. Murdoch2 1 caia.swin.edu.au/cv/szander 2 www.cl.cam.ac.uk/users/sjm217 Computer Laboratory USENIX Security Symposium, 28 July – 1 August 2008, San Jose, CA, US 1 / 23 Overview • What are hidden services • Revealing hidden services: Clock skew, temperature and network load • Current clock skew estimation approach and noise sources • Improved clock skew estimation: Synchronised sampling • Evaluation of synchronised sampling • New techniques for revealing hidden services • Conclusions and future work 2 / 23 Tor is a low-latency, distributed anonymity system • Real-time TCP anonymisation system (e.g. web browsing) • Supports anonymous operation of servers (hidden services) • These protect the user operating the server and the service itself • Constructs paths through randomly chosen nodes (around 2 500 now) • Multiple layers of encryption hide correlations between input and output data • No intentional delay introduced 3 / 23 Hidden services are built on top of the anonymity primitive the Tor network provides Service Publication Data Transfer Connection Setup Hidden Service 1 * 6 RP IP 7 Introduction Point (IP) Rendevous Point (RP) 2 5 RP Directory Server 8 data 4 IP Client 3 4 / 23 Computers have multiple clocks, some can be queried over the Internet • A clock consists of an: • Oscillator, controlled by a crystal, ticks at a nominal frequency • Counter, counts the number of ticks produced by the oscillator • Some clocks can be queried remotely: Clock Frequency ICMP timestamp 1 kHz NTP Firewall Other Affected Usually Often disabled in blocked operating systems Cannot be Linux specific, very blocked difficult to use Hard to Cannot be measured over block Tor (no end-to-end TCP) Hard to Low frequency, can be block measured over Tor request TCP sequence 1 MHz Affected numbers TCP timestamp 2 Hz – extension 1 kHz HTTP timestamp 1 Hz Unaffected Affected header 5 / 23 Temperature has a small, but remotely measurable, effect on clock skew • In typical PC temperatures, only around ±1 ppm • By requesting timestamps and 10 0 −10 change by ±20 ppm over 150 ◦ C operational range −20 • Skew of typical clock crystal will Clock skew (ppm) of a clock to the ‘true’ clock 20 • Clock skew: difference in frequency −50 0 50 100 Temperature (°C) measuring skews, an estimate of temperature changes can be derived • Even in a well-insulated building, changes in temperature over the day become apparent 6 / 23 Temperature has a small, but remotely measurable, effect on clock skew −0.5 −1.0 change by ±20 ppm over 150 ◦ C operational range Observed skew range −1.5 • Skew of typical clock crystal will Clock skew (ppm) of a clock to the ‘true’ clock 0.0 • Clock skew: difference in frequency Observed temperature range • In typical PC temperatures, only around ±1 ppm 26.5 27.0 27.5 28.0 28.5 29.0 29.5 Temperature (°C) • By requesting timestamps and measuring skews, an estimate of temperature changes can be derived • Even in a well-insulated building, changes in temperature over the day become apparent 6 / 23 Clock skew variations can be extracted with numerical analysis 10 −10 0 Remove noise Differentiate and negate −20 Offset (ms) Remove constant skew from offset 20 Measure clock offset of candidate machine(s) Compare to temperature + + + ++ + ++ + ++ ++++++++++++++ +++++++++++++++++++++++++++++++++++++++++++++ ++++ ++ ++++++ + ++++++++ 37:00 37:30 38:00 38:30 39:00 39:30 40:00 Time (mm:ss) 7 / 23 Clock skew variations can be extracted with numerical analysis Remove constant skew from offset Remove noise Differentiate and negate 0.0 Non−linear offset component (ms) Measure clock offset of candidate machine(s) −0.5 Non−linear offset −1.0 −1.5 − −2.0 Fri 11:00 Fri 21:00 Sat 07:00 Sat 17:00 Time Compare to temperature 7 / 23 Clock skew variations can be extracted with numerical analysis Remove constant skew from offset Remove noise Differentiate and negate Compare to temperature De−noised 0.0 Non−linear offset component (ms) Measure clock offset of candidate machine(s) −0.5 Non−linear offset −1.0 −1.5 − −2.0 Fri 11:00 Fri 21:00 Sat 07:00 Sat 17:00 Time 7 / 23 Clock skew variations can be extracted with numerical analysis Remove constant skew from offset Remove noise Differentiate and negate De−noised 0.0 Non−linear offset component (ms) Measure clock offset of candidate machine(s) −0.5 Non−linear offset −1.0 −1.5 − −2.0 Variable skew Fri 11:00 Fri 21:00 Sat 07:00 Sat 17:00 Time Compare to temperature 7 / 23 Clock skew variations can be extracted with numerical analysis Remove noise Differentiate and negate Compare to temperature − ●● 26.4 ● ●● ● ● −0.5 −1.0 26.3 Non−linear offset ● ● ● ● ● ● ● ●● ● ● ●● Temperature 26.2 ●● ● ●●●●●●●● 26.1 ●●●●●●● ●●●● −1.5 ●● ● ● ●● ● ● ●●●● ● ● ● ●● ● ●●●●● 26.0 Temperature (°C) Remove constant skew from offset De−noised 0.0 Non−linear offset component (ms) Measure clock offset of candidate machine(s) ● ●●● −2.0 ●●● ●●●●●● 25.9 ●●●●●●●●●●●●●●●● Variable skew ● Fri 11:00 Fri 21:00 Sat 07:00 25.8 Sat 17:00 Time 7 / 23 Network load of hidden service can be estimated by measuring temperature induced clock skew • Attacker induces load pattern by making requests to hidden server via Tor • At the same time the attacker directly measures clock-skew patterns of candidates (set of IP addresses) • If the patterns match, the hidden service is revealed Pattern measured Measurer Resulting pattern Pattern injected Attacker Tor Network Hidden Server 8 / 23 Network load of hidden service can be estimated by measuring temperature induced clock skew • Here, a periodic 2 hour on, 2 hour off pattern was used s^c = 95, min s^(t ) = −0.11, max s^(t ) = 0.22 ppm −1 −2 −3 − ● ● ● ●● ● ● ● ●● ● ● ● ● ● ● ● ●● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●● ● ●● ● ● ● ●● ● ●● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●● ● ●● ●● ● ● ● ● ● ● ● ● ● ● ● ● ● ●● ● ● ● ● ●● ● ● ●● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ●● ● ● ● ● ● ● ● ● ● ● ●● ● ● ● ● ● ● ● ● ● ● ● ●● ● ●● ● ● ● ● ● ● ● ● ● ●● ● ● ● ● 39.0 38.5 ● ● ● 38.0 ● ● ● ● ● Temperature (°C) Non−linear offset component (ms) 0 ● 37.5 ● −4 01:00 05:00 09:00 Time (hh:mm) 8 / 23 Measurement errors have two sources: quantization noise and network jitter s^c = 279, min s^(t ) = −0.63, max s^(t ) = 0.88 ppm 0.88 Quantisation noise −1 −2 Network jitter −3 0 −4 −5 −6 Clock skew change (ppm) Non−linear offset component (ms) 0 −0.63 − 06:00 10:00 14:00 18:00 Time (hh:mm) Many samples, over a long time, are needed to eliminate this noise 9 / 23 Quantization noise of a sample depends on how close it was to a clock-edge ● Random sample Target timestamp ● ● ● Quantisation error ● ● ● Time Only the samples made near clock edges contribute to the accuracy of the skew measurement 10 / 23 Current attack is limited by quantisation noise • For 1 kHz clock shown here, Median: 0.53ms max. quantization error is 1 ms 1.0 • Clock-skew cannot be 0.8 Density accurately measured via Tor because available 1 Hz HTTP timestamps have a 1 s period • Temperature change must be induced sending larger amounts of traffic across Tor 0.6 0.4 0.2 0.0 0.0 • May not be possible (Tor has 0.5 1.0 1.5 2.0 2.5 Noise (ms) low capacity and server may limit requests) • Even if possible it would likely raise suspicion 11 / 23 Quantization noise can be effectively eliminated by sampling just before or after clock ticks Target timestamp ● Random sample Synchronised sample ● ● ● Quantisation error ● ● ● Time Now the noise level is independent of clock frequency 12 / 23 Synchronised sampling algorithm • Algorithm first locks onto target’s Median: 0.08ms clock tick, and predicts position (before or after tick) 6 before and after clock ticks (determined by bounds) • If actual position equals expected position, bounds are tightened, otherwise they are opened • It also adjusts the sampling Density • Then it alternately samples 4 2 0 0.0 0.5 1.0 1.5 2.0 Noise (ms) interval based on relative skew between attacker and target • Resulting noise is far lower than random sampling 13 / 23 Evaluation compares synchronised sampling with random sampling in different scenarios • True clock skew cannot be measured, so what baseline to compare against? • Use 1 MHz reference clock realised by exchanging µs resolution timestamps over UDP • Reference clock does not provide true skew, but has minimal quantisation error • Compare clock skew estimates based on TCP or HTTP timestamps reference using root mean square error q with P RMSE = N1 i (x̂i − xi )2 • Use same average sample rates for random and synchronised sampling • One clock-skew estimate is computed for w samples (window) • Use over-sampling to get more frequent clock-skew estimates 14 / 23 With synchronised sampling the accuracy is independent of quantisation noise • Compare synchronised and random sampling in LAN • Obtained clock frequencies by rounding target’s timestamps Avg. samples per window (sync & random) 40 200 400 600 10.000 5.000 800 Sync 100 Hz Sync 250 Hz Sync 1000 Hz Random 100 Hz Random 250 Hz Random 1000 Hz ● RMSE (ppm) ● 1.000 0.500 ● ● ● ● ● ● 0.100 0.050 1200 ● ● ● ● ● ● 0.010 0.005 ● ● ● ● 0 500 1000 1500 Window size (s) 15 / 23 Low-resolution HTTP timestamps become usable for clock-skew estimation • Compare synchronised and random sampling in LAN • Target was running Apache 2.2.4 (no extra load) Avg. samples per window (sync & random) 30 150 300 450 600 900 1000.00 ● RMSE (ppm) 100.00 Reference Sync Random 10.00 1.00 ● ● ● ● ● 0.10 ● ● ● 0.01 0 500 1000 1500 Window size (s) 16 / 23 Even on long-distance path the noise reduction is significant as network jitter is often small • 22 hops (average RTT of 325 ms, but RTT/2 jitter was ≤0.5 ms) • Used 1 kHz TCP timestamps Avg. samples per window (sync & random) 40 2.00 200 400 600 800 ● 1200 ● RMSE (ppm) 1.00 Reference Sync Random 0.50 ● 0.20 ● 0.10 ● 0.05 ● ● ● ● 0.02 0.01 0 500 1000 1500 Window size (s) 17 / 23 Clock skew can be estimated across Tor • Currently performance/reliability of Tor hidden services is poor • Used private 19-node Tor testbed running on Planetlab nodes • Average RTT was 885 ms and RTT/2 jitter up to 50 ms Avg. samples per window (sync & random) 30 600 1800 3600 1000.0 5400 ● RMSE (ppm) ● 100.0 Reference Sync Random ● ● ● 10.0 ● ● ● 1.0 ● ● ● 0.1 0 2000 4000 6000 ● 8000 10000 Window size (s) 18 / 23 Daily temperature-change patterns are visible • Synchronised sampling shows temperature decreasing during night and increasing during day • Random sampling does not show pattern (same window size) Window size: 7200 s ● 2 ● Clock skew change (ppm) ●●● ● ● ● ● ●● ● ● ●● 1 ●●●●● ●●●● ● ●●●●●● ● ●● ●●●●● ●●● ● ●● ●● ●● 0 ● ●● ●● ● ● ● ●● ● ●●●● ● ●● ●● ●●●● ●● ● ●●●● ●●●●● ●● ● ● ● ● ● ● ● −1 ● ● ● ● ●●● ● ●●●● ●● ● ●● ●● ●●● ●●●●● ● ● ●●●● ● ● ● ●●●●● ● ● ● ● ●● ●● ●● −2 Reference 15:00 Sync 19:00 23:00 Random ● 03:00 07:00 Time (mm:ss) 19 / 23 Initial synchronisation is quick even across Tor • Takes about 2.5 minutes for algorithm to synchronise • But high network jitter forces regular opening of bounds and sample interval adjustments 1000 Before Behind Interval 5 500 0 0 −5 −500 −10 −1000 0 200 400 600 800 Adjust interval (µ µs) Adjust before/behind (ms) 10 1000 Clock sample 20 / 23 More efficient variants of the original attack (1) • Attacker measures clock skew of the hidden server via Tor and of candidates directly • Compare fixed skew or variable • Generates only fraction of traffic needed of original attack (here one probe every 2 seconds) • Requires only fraction of time of original attack, especially if fixed skew can be used (here 139 minutes) Others Correct 0.8 RMSE (ppm) skew over time (shown here) to identify hidden server 1.0 0.6 0.4 0.2 0.0 0 100 200 300 400 500 Time (min) 21 / 23 More efficient variants of the original attack (2) • Attacker measures clock skew of hidden service and estimates geographic location • Generates only a fraction of traffic and does not require direct access to the target • Does not provide an unambiguous identification if candidate locations are geographically close 22 / 23 Conclusions and future work • Synchronised sampling significantly improves accuracy of clock-skew estimation • Synchronised sampling enables accurate clock-skew estimation from low-frequency clocks • Improves previous attack and enables new more efficient attacks • Improves other clock-skew-based techniques, such as remote fingerprinting • Extend evaluation (analyse duration and traffic volume of new attacks, use real Tor network) • Improve timing accuracy (use real-time kernel or kernel implementation) • Algorithm parameter tuning 23 / 23
© Copyright 2025 Paperzz