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

Erich Heine sophacles at gmail.com
Mon Dec 3 20:52:54 UTC 2012


On Mon, Dec 3, 2012 at 11:18 AM, Bob Camp <lists at rtty.us> wrote:

> Hi
>
> One very basic question might be - is a public list read by millions of
> people the right place to dig into this?
>
>
Thanks for bringing this up. I probably should have asked the list about
general comfort levels regarding such a discussion first. My apologies for
such an oversight.

I personally hold the view that such discussions are necessary, if tempered
with a spirit of responsible disclosure. By this I mean public discourse
over general attack and defense techniques is a good thing, in that it
allows the "good guys" the chance to work in solutions and defenses, and
that it keeps engineers informed as to what not to do in their designs.
 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.

The flip side of this is that the bad guys also get access to it. General
IT experience however is that there are usually already bad guys thinking
about that class of attacks, or already exploiting them by the time
defenders start looking into them.

All of that being said, I should mention, that if people are uncomfortable
with this style of discussion on this list, I would be glad to take it off
list. Similarly if anyone wants to discuss such things in a more private
manner, feel free to contact me individually at either the adress I use for
the list, or my university email: eheine at illinois.edu



> 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..).
>

Oh sure, in a desktop this is true, but the sensors I am talking about do
have requirements that are more strict - they generally run and RTOS and
have decent clocks in them to begin with. In a 60Hz power system, a few
microseconds is enough to cause synchronized point-on-wave measurements to
report differences of the type that require corrective action. Similarly
frequency oscillations (frequency of the AC power wave that is measured)
reported by steering a clock to slightly faster then slightly slower on a
regular basis could cause inefficient (that is expensive) precautionary
measures to be taken. So clock steering is a good thing for me to know more
about I think. Thanks for the pointer!


>
> 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.
>
> Bob
>
> -----Original Message-----
> 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.
>
> Some scenarios:
>
> 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 :).
>
> Regards,
> Erich
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>
>
>
> _______________________________________________
> time-nuts mailing list -- time-nuts at febo.com
> To unsubscribe, go to
> https://www.febo.com/cgi-bin/mailman/listinfo/time-nuts
> and follow the instructions there.
>


More information about the time-nuts mailing list