Schneier on Security

Clive Robinson • October 16, 2012 4:19 PM

@ Uhu,

… which on a number of operating systems is based on clock-cycles, not on the RTC

As far as I’m aware all major OS’s use the CPU XTAL not the RTC XTAL (32Khz Beta cut watch crystal). Which has a direct relationship to CPU cycles. Also I actualy said,

due to the fact the motherboard XTAL driving the cpu(s) was common to them and had a unique change in frequency against time

I’m sorry if you thought I ment the RTC I did not.

@ John Hardin,

Would the analysis of XTAL-driven clock drift be feasible in an environment where a clock sync utility like NTP was in use.

Yes and no it depends very much on the external refrence and how it’s applied at both ends (ie your measuring system and the remote multi host interface system) and if it’s hardware or software corrected. Do it wrong at your measurment end and the results are meaningless, if done badly at the remote end it makes your job easier due to the more visable artifacts on the Delta F traces.

I have the advantage of having a system at my disposal that has an external hardware refrence (ie an atomic lamp which phase locks a VXCO) that replaced the motherboard XTAL entirely (in normal use the system is actually the controler in a specialised radio receiver / test set).

If you think about what you are looking to measure is the Delta F between your local clock measurment of the timestamp roll over on all the host interfaces, then cross correlate them to decide if they have the same master clock. On a single system they all roll over with the same time interval +- a very small fraction of the drift rate between your timer and the remote system timer (on some VM’s they all roll over together which makes life easier). Normal drift is a slow linear process and the divergance can be seen as a straight line on a graph and the inclination of this line is what produces the fingerprint.

Now if someone uses a software corrector of the internal time it can exhibit a course sawtooth which can be seen as a result of the accumulated error of the drift rate, which when averaged looks like a sinewave at the difference frequency. Better software clock correctors actually implement the equivalent of a PLL, which if correctly setup produces what looks like a low frequency sine wave error function. In both cases this “difference frequency” sine wave can cause some strange side effects in certain applications. But as indicated it produces not a straight line but a straight line modulated by the correction effects (which usually makes the fingerprinting job easier)

Which is partly the reason the ones I’ve developed actually use a long sequence random generator to jitter the timing edge and then put the result through a twenty tap or more lowpass filter. The reason for this is to remove certain side effects that cause issues in RF and Audio measurement (think sub harmonic sampaling). You could (at a squint) view it as a Delta-Sigma loop system.

Oh and enumerating honeynets actually was in my view a minor uses of the time stamp technique by attackers. A more obvious one would be to work out which VM’s shared the same hardware in a co-host situation. That is if two otherwise entirely seperate web sites ran on the same hardware it might be possible to use errors in one site to get at another site in some way (basicaly exploit weaknesses in the VM issolation).