[time-nuts] Time security musing - attacking the clock itself
lists at rtty.us
Mon Dec 3 17:18:10 UTC 2012
One very basic question might be - is a public list read by millions of
people the right place to dig into this?
The most basic thing you can detect is "time went backwards". Obviously, it
should never to this. Because it's easy to detect, I'd assume that the
attacker isn't going to do anything gross. Instead they would try to steer
the clock so it slowly goes out of step with the real world.
If that's correct, then the answer to most of the rest of the questions is
no. A small frequency offset is adequate to do the steer. That sort of
offset isn't going to mess up things like ADC's and com ports. A microsecond
per second slip is a 1 ppm frequency offset. There's nothing in a off the
shelf PC that needs to be accurate to 100 ppm, let alone 1 ppm (other than
the real time clock..).
One hundred microseconds per second is plenty of slip to get things into an
odd state. By the end of 24 hours, you would be off by 8.64 seconds.
From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
Behalf Of Erich Heine
Sent: Monday, December 03, 2012 11:30 AM
To: Discussion of precise time and frequency measurement
Subject: [time-nuts] Time security musing - attacking the clock itself
One of my favorite things about being in security, (and a researcher in
general), is that we regularly get to say "that sounds too hard, what if we
look $HERE instead". So while I catch up on security in the time
synchronization space, I've also been musing on this notion of attacking
the clock. By this I mean I am going to assume the protocols for
synchronization are secure and instead look at other things which can
affect measurement timestamping.
I also am going to assume that an attacker doesn't just want to bring down
any system dependent on compromised devices, but rather wants to cause
instabilities, inefficiencies and other long-term damage (for whatever
reasons - economic, political, revenge, whatever - a good attack is
frequently one that doesn't bring down a system, but instead makes it
untrustworthy and is hard to eradicate).
In my space (power grid) there is a lot of work being done to get good
synchronized measurement of the whole wide-area system. This of course
depends on trusting the clock. Many calculations of state, and problem
detection (e.g. various forms of oscillation) implicitly trust the
measurement is accurate within defined error bands, including time.
What I've learned from reading this list is that clocks are pretty
sensitive - a lot of factors can affect the reliability (and hence
trustworthiness) of the reported time.
So what I am trying to understand today is ways we can affect the
reliability of the clock, having affects on everything mentioned above.
1) I am an attacker. I can get remote root access to a device that depends
on an internal clock synchronized to a trusted source. I don't want to
leave changes in the main firmware/os that are detectable. Once the device
is rebooted I want no obvious signs I was ever there. A common technique
for this is to put exploits into secondary controller chips in the device.
(System boards these days look more like networks of computers than a
single computer - all sorts of chips providing functionality are just
microcontrollers themselves with writable firmware, but limited
introspection capability, making them a prime target for attack). Like I
said, I want to attack the clock and make it unreliable.
* Is there a specific chip/subsystem that can be be modified via firmware
to mess up the clock? I presume there is because the synchronization comes
in off the network. What sort of modifications to the code of that firmware
would break it?
* 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)
* Is the system clock used to drive things like ADCs, if so can messing
with the clock affect calibration of the readings?
2) I don't have access to devices or network. Is there a way to mess with
the time signal that is very difficult to detect. Say GPS spoofing is no
longer a "safe" option. It seems there are a lot of sensitivities in the
timing chain. What sort of factors affect a clock signal?
* Random thought - Can I point a highly directed microwave beam at the coax
from the GPS antenna to the clock to cause noise inside that channel?
* What else can be used to cause external interference to timing, even in
well designed clocks?
3) I have a long planning horizon, and access to the devices at some point
in the supply chain. What sort of small tweaks can I make to the circuit
that are easy and indistinguishable from poor quality control that would
add a lot of noise to a timing signal? Are these things all on a single
chip? Are there traces/components that can be altered/damaged/affected with
strange inductive effects?
So Time-Nuts - what are your thoughts on this musing? I am hoping you all
can provide some insight as to wether these are productive questions to
pursue, or feedback and experience on these type of problems. Mostly
though, I'm working towards a general refinement of my understanding, and I
do that best through feedback :).
time-nuts mailing list -- time-nuts at febo.com
To unsubscribe, go to
and follow the instructions there.
More information about the time-nuts