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

dlewis6767 dlewis6767 at austin.rr.com
Mon Dec 3 17:32:13 UTC 2012

I agree, Bob.

Like the billboard on the side of the highway says: - Does Advertising Work? 

The bad guys can read this list same as the good guys.

From: "Bob Camp" <lists at rtty.us>
Sent: Monday, December 03, 2012 11:18 AM
To: "'Discussion of precise time and frequency measurement'" 
<time-nuts at febo.com>
Subject: Re: [time-nuts] Time security musing - attacking the clock itself

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