An Improved Clock-skew Measurement Technique for

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