An Improved Clock-skew MeasurementTechnique for Revealing Hidden Services
Time
Fri 11:00 Fri 21:00 Sat 07:00 Sat 17:00
Non
−lin
ear
offs
et c
ompo
nent
(m
s)
−−2.0
−1.5
−1.0
−0.5
0.0
●
●
●●
●●●
●●
●●
●
●●
●●●
●●
●
●●
●●
●●●
●●●●
●
●
●
●
●
●
●
●
●
●
●●
●
●
●●
●
●●●
●
●
●
●
●
●●
●
●
●
●●
●●
●
●●
●●
●●●
●●
●
●
●●
●●●
●
●
●●
●
●
●●
●●●
●
●
●
●
25.8
25.9
26.0
26.1
26.2
26.3
26.4
Tem
pera
ture
(°C
)
●
Non−linear offset
De−noised
Variable skew
Temperature
Time
Tar
get t
imes
tam
p
●
●
●
●
●
●
Quantisation error
● Random sampleSynchronised sample
Median: 0.08ms
Noise (ms)
Den
sity
0
2
4
6
0.0 0.5 1.0 1.5 2.0
●●●
●●●●●●●
●
●
●●●●●
●●
●●●
●●
●
●●●
●●
●●
●●
●●●●●
●
●●
●●●●●
●●●●
●●
●●●
●●●●
●●●●
●●●●●
●●●
●●
●●●
●●
●●
●●
●●●●●●
●●
●●
●●●●●●
●●
●●●●
●
●●●
●●●
●●
●●●●●
●
●●●●●●●
●●
●●●
●●●●●
●●
●●
●●●●●
●●
●
●●
●●●●
−2
−1
0
1
2
Window size: 7200 s
Time (mm:ss)
Clo
ck s
kew
cha
nge
(ppm
)
15:00 19:00 23:00 03:00 07:00
●●●
●●●●●●●
●
●
●●●●●
●●
●●●
●●
●
●●●
●●
●●
●●
●●●●●
●
●●
●●●●●
●●●●
●●
●●●
●●●●
●●●●
●●●●●
●●●
●●
●●●
●●
●●
●●
●●●●●●
●●
●●
●●●●●●
●●
●●●●
●
●●●
●●●
●●
●●●●●
●
●●●●●●●
●●
●●●
●●●●●
●●
●●
●●●●●
●●
●
●●
●●●●
●Reference Sync Random
Sebastian Zander1, Steven J. Murdoch2
1caia.swin.edu.au/cv/szander2www.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 anonymitysystem
• Real-time TCP anonymisationsystem (e.g. web browsing)
• Supports anonymous operation ofservers (hidden services)
• These protect the user operating theserver and the service itself
• Constructs paths through randomlychosen nodes (around 2 500 now)
• Multiple layers of encryption hidecorrelations between input andoutput data
• No intentional delay introduced
3 / 23
Hidden services are built on top of theanonymity primitive the Tor network provides
Hidden Service
Introduction
Point (IP)
Rendevous
Point (RP)
Directory
Server
Client
Service Publication Connection Setup Data Transfer
1
2
3
4
5
6
7
8
IP
IP
RP
RP
data
*
4 / 23
Computers have multiple clocks, some can bequeried 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 NTP Firewall Other
ICMP timestamp
request
1 kHz Affected Usually
blocked
Often disabled in
operating systems
TCP sequence
numbers
1 MHz Affected Cannot be
blocked
Linux specific, very
difficult to use
TCP timestamp
extension
2 Hz –
1 kHz
Unaffected Hard to
block
Cannot be measured over
Tor (no end-to-end TCP)
HTTP timestamp
header
1 Hz Affected Hard to
block
Low frequency, can be
measured over Tor
5 / 23
Temperature has a small, but remotelymeasurable, effect on clock skew
• Clock skew: difference in frequencyof a clock to the ‘true’ clock
• Skew of typical clock crystal willchange by ±20 ppm over 150 ◦ Coperational range
• In typical PC temperatures, onlyaround ±1 ppm
• By requesting timestamps andmeasuring skews, an estimate oftemperature changes can be derived
• Even in a well-insulated building,changes in temperature over the daybecome apparent
Temperature (°C)
Clo
ck s
kew
(pp
m)
−50 0 50 100
−20
−10
010
20
6 / 23
Temperature has a small, but remotelymeasurable, effect on clock skew
• Clock skew: difference in frequencyof a clock to the ‘true’ clock
• Skew of typical clock crystal willchange by ±20 ppm over 150 ◦ Coperational range
• In typical PC temperatures, onlyaround ±1 ppm
• By requesting timestamps andmeasuring skews, an estimate oftemperature changes can be derived
• Even in a well-insulated building,changes in temperature over the daybecome apparent
Temperature (°C)
Clo
ck s
kew
(pp
m)
Observedskew range
Observed temperature range
26.5 27.0 27.5 28.0 28.5 29.0 29.5
−1.
5−
1.0
−0.
50.
0
6 / 23
Clock skew variations can be extracted withnumerical analysis
Measure clockoffset of candidatemachine(s)
Remove constantskew from offset
Remove noise
Differentiate andnegate
Compare totemperature
Time (mm:ss)
Offs
et (
ms)
37:00 37:30 38:00 38:30 39:00 39:30 40:00
−20
−10
010
20++++
++++++++++++ ++++++++++++++++++++++++++++++++++++
++++++++++++ ++
++++++++++++++++++++++
+++
7 / 23
Clock skew variations can be extracted withnumerical analysis
Measure clockoffset of candidatemachine(s)
Remove constantskew from offset
Remove noise
Differentiate andnegate
Compare totemperature
Time
Fri 11:00 Fri 21:00 Sat 07:00 Sat 17:00
Non
−lin
ear
offs
et c
ompo
nent
(m
s)
−−2.0
−1.5
−1.0
−0.5
0.0
Non−linear offset
7 / 23
Clock skew variations can be extracted withnumerical analysis
Measure clockoffset of candidatemachine(s)
Remove constantskew from offset
Remove noise
Differentiate andnegate
Compare totemperature
Time
Fri 11:00 Fri 21:00 Sat 07:00 Sat 17:00
Non
−lin
ear
offs
et c
ompo
nent
(m
s)
−−2.0
−1.5
−1.0
−0.5
0.0
Non−linear offset
De−noised
7 / 23
Clock skew variations can be extracted withnumerical analysis
Measure clockoffset of candidatemachine(s)
Remove constantskew from offset
Remove noise
Differentiate andnegate
Compare totemperature
Time
Fri 11:00 Fri 21:00 Sat 07:00 Sat 17:00
Non
−lin
ear
offs
et c
ompo
nent
(m
s)
−−2.0
−1.5
−1.0
−0.5
0.0
Non−linear offset
De−noised
Variable skew
7 / 23
Clock skew variations can be extracted withnumerical analysis
Measure clockoffset of candidatemachine(s)
Remove constantskew from offset
Remove noise
Differentiate andnegate
Compare totemperature
Time
Fri 11:00 Fri 21:00 Sat 07:00 Sat 17:00
Non
−lin
ear
offs
et c
ompo
nent
(m
s)
−−2.0
−1.5
−1.0
−0.5
0.0
●
●
●●
●●●
●●
●●
●
●●
●●●
●●
●
●●
●●
●●●
●●●●
●
●
●
●
●
●
●
●
●
●
●●
●
●
●●
●
●●●
●
●
●
●
●
●●
●
●
●
●●
●●
●
●●
●●
●●●
●●
●
●
●●
●●●
●
●
●●
●
●
●●
●●●
●
●
●
●
25.8
25.9
26.0
26.1
26.2
26.3
26.4
Tem
pera
ture
(°C
)
●
Non−linear offset
De−noised
Variable skew
Temperature
7 / 23
Network load of hidden service can be estimatedby measuring temperature induced clock skew
• Attacker induces load pattern by making requests to hiddenserver via Tor
• At the same time the attacker directly measures clock-skewpatterns of candidates (set of IP addresses)
• If the patterns match, the hidden service is revealed
Attacker Tor Network Hidden Server
Measurer
Pattern measured
Pattern injected
Resulting pattern
8 / 23
Network load of hidden service can be estimatedby measuring temperature induced clock skew
• Here, a periodic 2 hour on, 2 hour off pattern was used
Time (hh:mm)
01:00 05:00 09:00
Non
−lin
ear
offs
et c
ompo
nent
(m
s)
−
−4
−3
−2
−1
0
sc = 95, min s(t) = −0.11, max s(t) = 0.22 ppm
●
●
●
●
●
●
●
●
●●
●
●
●●
●
● ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●●
● ●
●
●
●
●●
●
●
●
●
●●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●●
●
●●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●●
●
●
●
●
●
●
●
●
●
●
●●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
● ●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●●
● ●
●
●●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
●
● ●
●
●
●
●
●
●
●
●
●
●
37.5
38.0
38.5
39.0
Tem
pera
ture
(°C
)
●
8 / 23
Measurement errors have two sources:quantization noise and network jitter
06:00 10:00 14:00 18:00
Time (hh:mm)
Non
−lin
ear
offs
et c
ompo
nent
(m
s)
−−6
−5
−4
−3
−2
−1
0
−0.63
0
0.88
Clo
ck s
kew
cha
nge
(ppm
)
Quantisation noise
Network jitter
sc == 279, min s((t)) == −0.63, max s((t)) == 0.88 ppm
Many samples, over a long time, are needed to eliminate this noise
9 / 23
Quantization noise of a sample depends on howclose it was to a clock-edge
Time
Tar
get t
imes
tam
p
●
●
●
●
●
●
Quantisation error
● Random sample
Only the samples made near clock edges contribute to the accuracyof the skew measurement
10 / 23
Current attack is limited by quantisation noise
• For 1 kHz clock shown here,max. quantization error is 1 ms
• Clock-skew cannot beaccurately measured via Torbecause available 1 Hz HTTPtimestamps have a 1 s period
• Temperature change must beinduced sending largeramounts of traffic across Tor
• May not be possible (Tor haslow capacity and server maylimit requests)
• Even if possible it wouldlikely raise suspicion
Median: 0.53ms
Noise (ms)
Den
sity
0.0
0.2
0.4
0.6
0.8
1.0
0.0 0.5 1.0 1.5 2.0 2.5
11 / 23
Quantization noise can be effectively eliminatedby sampling just before or after clock ticks
Time
Tar
get t
imes
tam
p
●
●
●
●
●
●
Quantisation error
● Random sampleSynchronised sample
Now the noise level is independent of clock frequency12 / 23
Synchronised sampling algorithm
• Algorithm first locks onto target’sclock tick, and predicts position(before or after tick)
• Then it alternately samplesbefore and after clock ticks(determined by bounds)
• If actual position equals expectedposition, bounds are tightened,otherwise they are opened
• It also adjusts the samplinginterval based on relative skewbetween attacker and target
• Resulting noise is far lower thanrandom sampling
Median: 0.08ms
Noise (ms)
Den
sity
0
2
4
6
0.0 0.5 1.0 1.5 2.0
13 / 23
Evaluation compares synchronised samplingwith random sampling in different scenarios
• True clock skew cannot be measured, so what baseline tocompare against?
• Use 1 MHz reference clock realised by exchanging µs resolutiontimestamps over UDP
• Reference clock does not provide true skew, but has minimalquantisation error
• Compare clock skew estimates based on TCP or HTTPtimestamps with reference using root mean square error
RMSE =√
1N
∑i(xi − xi)2
• Use same average sample rates for random and synchronisedsampling
• 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 isindependent of quantisation noise
• Compare synchronised and random sampling in LAN• Obtained clock frequencies by rounding target’s timestamps
●
●
●
●
●
●●
●
0 500 1000 1500
Window size (s)
40 200 400 600 800 1200
RM
SE
(pp
m)
0.0050.010
0.0500.100
0.5001.000
5.00010.000
Avg. samples per window (sync & random)
●
●
●
●
●
●●
●
●
●
●
●
●
●
●
●
●
●
Sync 100 HzSync 250 HzSync 1000 HzRandom 100 HzRandom 250 HzRandom 1000 Hz
15 / 23
Low-resolution HTTP timestamps becomeusable for clock-skew estimation
• Compare synchronised and random sampling in LAN• Target was running Apache 2.2.4 (no extra load)
●
●●
●
●●
●●
0 500 1000 1500
Window size (s)
0.01
0.10
1.00
10.00
100.00
1000.00
30 150 300 450 600 900
RM
SE
(pp
m)
Avg. samples per window (sync & random)
●
●●
●
●●
●●
●
ReferenceSyncRandom
16 / 23
Even on long-distance path the noise reductionis 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
●
●
●
●
●●
●●
0 500 1000 1500
0.01
0.02
0.05
0.10
0.20
0.50
1.00
2.00
Window size (s)
40 200 400 600 800 1200
RM
SE
(pp
m)
Avg. samples per window (sync & random)
●
●
●
●
●●
●●
●
ReferenceSyncRandom
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
●
●●
●
●
●
●
●
●
●●
0 2000 4000 6000 8000 10000
Window size (s)
0.1
1.0
10.0
100.0
1000.0
30 600 1800 3600 5400
RM
SE
(pp
m)
Avg. samples per window (sync & random)
●
●●
●
●
●
●
●
●
●●
●
ReferenceSyncRandom
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)
●●●
●●●●●●●
●
●
●●●●●
●●
●●●
●●
●
●●●
●●
●●
●●
●●●●●
●
●●
●●●●●
●●●●
●●
●●●
●●●●
●●●●
●●●●●
●●●
●●
●●●
●●
●●
●●
●●●●●●
●●
●●
●●●●●●
●●
●●●●
●
●●●
●●●
●●
●●●●●
●
●●●●●●●
●●
●●●
●●●●●
●●
●●
●●●●●
●●
●
●●
●●●●
−2
−1
0
1
2
Window size: 7200 s
Time (mm:ss)
Clo
ck s
kew
cha
nge
(ppm
)
15:00 19:00 23:00 03:00 07:00
●●●
●●●●●●●
●
●
●●●●●
●●
●●●
●●
●
●●●
●●
●●
●●
●●●●●
●
●●
●●●●●
●●●●
●●
●●●
●●●●
●●●●
●●●●●
●●●
●●
●●●
●●
●●
●●
●●●●●●
●●
●●
●●●●●●
●●
●●●●
●
●●●
●●●
●●
●●●●●
●
●●●●●●●
●●
●●●
●●●●●
●●
●●
●●●●●
●●
●
●●
●●●●
●Reference Sync Random
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
0 200 400 600 800 1000
−10
−5
0
5
10
Clock sample
Adj
ust b
efor
e/be
hind
(m
s)
−1000
−500
0
500
1000
Adj
ust i
nter
val (
µµs)
BeforeBehindInterval
20 / 23
More efficient variants of the original attack (1)
• Attacker measures clock skew ofthe hidden server via Tor and ofcandidates directly
• Compare fixed skew or variableskew over time (shown here) toidentify hidden server
• Generates only fraction of trafficneeded of original attack (hereone probe every 2 seconds)
• Requires only fraction of time oforiginal attack, especially if fixedskew can be used (here 139minutes)
0 100 200 300 400 500
0.0
0.2
0.4
0.6
0.8
1.0
Time (min)
RM
SE
(pp
m)
OthersCorrect
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 ofclock-skew estimation
• Synchronised sampling enables accurate clock-skew estimationfrom 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 newattacks, use real Tor network)
• Improve timing accuracy (use real-time kernel or kernelimplementation)
• Algorithm parameter tuning
23 / 23