[time-nuts] Time security musing - attacking the clock itself
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