As part of a broader organisational restructure, data networking research at Swinburne University of Technology has moved from the Centre for Advanced Internet Architecture (CAIA) to the Internet For Things (I4T) Research Lab.

Although CAIA no longer exists, this website reflects CAIA's activities and outputs between March 2002 and February 2017, and is being maintained as a service to the broader data networking research community.

Remote Synchronised Clock Skew Probing

Introduction

All networked devices, such as end hosts, routers, proxies, have clocks constructed from hardware and software components. A clock consists of a crystal oscillator that ticks at a nominal frequency and a counter that counts the number of ticks. The actual frequency of a device's clock depends on the environment, such as the temperature and humidity, as well as the type of crystal. The clock skew is the difference in frequency of a clock and a reference clock (which in the optimal case is the `true' clock).

If clock information is remotely accessible, one can measure the clock skew between the local clock and the remote clock. Previous research proposed using remote clock skew measurements for fingerprinting hosts and for uncovering the identity of anonymous servers [1][2]. The latter application can be extended towards a general temperature-based covert channel.

Remote clock skew is measured by obtaining timestamps from the target's clock and comparing these timestamps against the local clock. In the case of fingerprinting, the measurement can be passive if the attacker is able to observe network traffic with timestamps between the target and a third party. However, often an attacker does not have this capability and needs to solicit timestamps from the target. Even if an attacker can passively observe the target's traffic, in some cases the measurement needs to be semi-passive [2].

In previous research, the clock skew was remotely measured by random sampling of timestamps from the clock. This measurement suffers from two main sources of noise: network jitter and timestamp quantisation error [1]. Network jitter is often small and skewed towards zero, even on long-distance paths, because of over-provisioning in current IP networks. Quantisation noise depends on the frequency of the target's clock. Depending on the type of available timestamps, the quantisation noise is significantly larger than the noise introduced by typical network jitter in the Internet.

Figure 1 shows an example of a clock skew measurement across the Internet in the style of [1]. The constant clock skew has already been removed. The gray dots are the offsets between the two clocks, the green line on top is the piece-wise estimation of the variable skew and the blue triangles are the negated values of the derivative of the variable clock skew (thenegated clock skew change).

quantisation noise and network jitter

Figure 1: Quantisation noise and network jitter example

To minimise the quantisation error, Steven Murdoch proposed to use synchronised sampling instead of random sampling [1]. The attacker synchronises its timestamp requests with the target's clock ticks, attempting to get timestamps right after the clock tick, where the quantisation error is smallest. This approach has the potential to reduce the quantisation noise to a small margin, independent of the clock frequency.

Figure 2 illustrates the benefit of synchronised sampling over random sampling. The solid step line is the target’s clock value over time and the dashed line shows the true time. Random samples are distributed randomly between clock ticks whereas synchronised samples are taken close before or close after the clock tick. Note that the synchronised samples are taken alternatingly before and after the clock tick for the purpose of synchronisation. The quantisation errors are the differences between samples y-values and the true time. The absolute quantisation errors are shown as barsat the bottom. Synchronised sampling leads to smaller errors in comparison with random sampling.

synchronised vs. random sampling
Figure 2: Synchronised vs. random sampling

Synchronised sampling allows accurate clock-skew estimation even for low-resolution timestamps, such as the 1 Hz timestamp of the HTTP protocol. This is important because ICMP or TCP timestamps are not always available. For example, the Tor anonymisation network [3] supports only TCP, and TCP connections are only between a pair of nodes but not end-to-end. To identify a web server hidden by Tor, an attacker could only use HTTP timestamps [1].

I have developed and evaluated a technique for synchronised sampling. I have evaluated the new technique and compared it against random sampling in a LAN testbed and over a 22 hop Internet path. The results show that the quantisation noise is reduced to a few hundred microseconds independent of the clock frequency and the accuracy of the skew measurement is significantly higher compared to random sampling. Especially for low-frequency clocks the improvement is huge: for low frequency HTTP timestamps the quantisation error is reduced by more than two orders of magnitude.

Documentation

The synchronised sampling algorithm developed as well as the evaluation and comparison against random sampling are described in a paper published at USENIX Security Symposium 2008 [4]. Earlier, Steven gave a presentation at EuroBSDCon including some slides on how synchronised sampling works and how it reduces the quantisation noise [5].

Running Code

The following package contains the tool for random and synchronised timestamp probing of ICMP, TCP and HTTP timestamps. The tool is implemented in C/C++. The package also contains R [6] code for the actual estimation of the variable clock skew based on the timestamps collected. The R code is a modified and extended version of Steven's original code [7].

Download cprobe-0.3.tar.gz

If you find any bugs or have suggestions for improving the code please drop me an email!

Acknowledgements

This work was done while I was visiting the Cambridge Computer Lab. Thanks to Steven Murdoch and Markus Kuhn for their valuable comments and support. Special thanks to Andrew Moore for giving me access to his network measurement testbed, which I used in the evaluation.

References

  1. S. J. Murdoch. Hot or Not: Revealing Hidden Services by Their Clock Skew. In Proceedings of 13th ACM Conference on Computer and Communications Security (CCS), pages 27–36, November 2006. http://www.cl.cam.ac.uk/~sjm217/papers/ccs06hotornot.pdf
  2. T. Kohno, A. Broido, kc claffy. Remote Physical Device Fingerprinting. In Proceedings of IEEE Symposium
    on Security and Privacy, pages 211–225, May 2005.
  3. R. Dingledine, N. Mathewson, P. Syverson. Tor: The Second-generation Onion Router. In Proceedings of
    the 13th USENIX Security Symposium, August 2004.
  4. S. Zander, S. Murdoch, "An Improved Clock-skew Measurement Technique for Revealing Hidden Services", 17th Usenix Security Symposium, San Jose, USA, July/August 2008. http://www.usenix.org/events/sec08/tech/zander.html (official version) http://caia.swin.edu.au/cv/szander/publications/usenix08clockskew.pdf (personal copy)
  5. S. J. Murdoch, S. Zander, Talk: Hot or Not: Fingerprinting hosts through clock skew, EuroBSDCon 2007. http://www.cl.cam.ac.uk/~sjm217/talks/eurobsdcon07hotornot.pdf
  6. The R Project for Statistical Computing. http://www.r-project.org/
  7. S. J. Murdoch. TempCov - set of programs to collect, analyse and plot clock skew, 2006. http://www.cl.cam.ac.uk/~sjm217/projects/anon/tempcov-latest.tar.gz
Last Updated: Wednesday 23-Jul-2008 13:03:51 AEST | Maintained by: Sebastian Zander (szander@swin.edu.au) | Authorised by: Grenville Armitage ( garmitage@swin.edu.au)