[time-nuts] Time security musing - attacking the clock itself

Hal Murray hmurray at megapathdsl.net
Mon Dec 3 22:35:00 UTC 2012

sophacles at gmail.com said:
> So what I am trying to understand today is ways we can affect the
> reliability of the clock, having affects on everything mentioned above. 

There is a big overlap between maliciously attacking the clock and the clock 
doing something crazy due to bugs in hardware, firmware, software, or wetware 

If I was working in that area, I think the first step would be to collect a 
data base of interesting events to make a checklist of things to think about 
and/or feed to regression testing.

I don't know much about power grid control.  Is there a good overview web 

What level of time accuracy do you need?  ms? us?  Do you need absolute 
accuracy or just stability?

What sort of network environment are you using?  Are you on a well run 
lightly loaded private net or running on the big bad internet?  What sort of 
OSes are you using?  Does each control room have it's own good source of time 
(local GPS) or do some of them get time over the net?


> * Is the method for reading the clock a directly wired GPIO pin, or is it on
> a shared bus like I2C or SPI? (If so, other things on the bus could be
> compromised instead to not play nice with bus and affect readings) 

I think you are missing a key idea.

Most OSes maintain the system clock in software.  Once the system is up and 
running, there is no off-chip hardware involved to read-the-clock.  Most 
systems read the RTC/TOY clock once at boot time and use that to initialize 
the internal clock.  Details vary with OS and hardware.

Most modern CPUs have a counter that runs at the CPU clock frequency.  Intel 
calls it the TSC.  If you can adjust the CPU frequency (to save power), there 
is probably some counter that runs at a fixed frequency.  Timekeeping is just 
read that counter and do some math.

Very old systems used to bump the time on every scheduler interrupt.  That 
interrupt often came from the RTC chip.  Not quite so old systems did that, 
but also interpreted between scheduler ticks using the TSC.

The crystal that drives the CPU and/or the calibration software is often off 
by 10s or 100s of ppm.  Most OSes have a system call to adjust the 
calibration factor.  ntpd calls it drift.  This makes a huge difference.

If you have a local PPS source, you can use it and ntpd as a thermometer.

Changes in self heating when the workload changes makes this area very 


> Specific attacks (e.g. Device X has software bug Y allowing $Algorithm to
> cause $Result) should be reported to the vendor quietly to allow them to fix
> it, and once a fix is available, it should be publicly disclosed to allow
> people informed decision on upgrades and mitigation, as well as to provide
> understanding and examples for future defenders. 

Some vendors have a history of ignoring reports of serious security problems. 
 I think the "allow them to fix it" needs a timeout.

That whole approach assumes that everybody can just blindly install all the 
vendors software updates as soon as they are released.  That's not likely to 
be the procedure in any high reliability environment.

These are my opinions.  I hate spam.

More information about the time-nuts mailing list