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

Scott McGrath scmcgrath at gmail.com
Mon Dec 3 19:27:48 UTC 2012


All of these attacks the clock would notice and probably go into holdover   So far these attacks do not allow the time product to be altered in a deterministic manner

Sent from my iPhone

On Dec 3, 2012, at 1:46 PM, "Don Latham" <djl at montana.com> wrote:

> Well, if it's the current set of ruffians we're worried about, my guess
> is a reasonably well-placed RPG would get the job done <1/2 :-)>.
> Don L
> 
> Bob Camp
>> Hi
>> 
>> If your GPS is sitting somewhere on the main power grid, it's often
>> already
>> in a pretty massive electromagnet field. Early on they tried lower
>> frequency
>> time sources and simply could not hear them above the noise of the power
>> plant or switching station. There are multiple papers from the 1970's
>> and
>> 80's going into this.
>> 
>> Bob
>> 
>> -----Original Message-----
>> From: time-nuts-bounces at febo.com [mailto:time-nuts-bounces at febo.com] On
>> Behalf Of Edgardo Molina
>> Sent: Monday, December 03, 2012 1:11 PM
>> To: Discussion of precise time and frequency measurement
>> Subject: Re: [time-nuts] Time security musing - attacking the clock
>> itself
>> 
>> Dear Erich,
>> 
>> I will allow myself to comment briefly on the RF part of your concerns.
>> 
>>>> * 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?
>> 
>> 
>> GPS signals are very low level as we all know and are subject to jamming
>> either intentional or accidental as you are wondering with your
>> microwave
>> signal towards the transmission line. I bet that the majority of the
>> interfering signal will be picked up by the GPS antenna and not by the
>> transmission line. But if the transmission line has nicks, loose
>> couplings
>> or poor shield quality, it will definitely allow the interfering signal
>> to
>> come into the receiver. As a matter of fact, let me ask you this. How
>> concentrated a microwave signal can practically be to cause the damage
>> pointing it to a specific element of the RF chain from a distance? 1º,3º
>> or
>> 10º  in the H-V radiation patterns? What kind of antenna design would be
>> practical for this radiation pattern generation? A deep parabolic dish?
>> Corner reflector? A twenty-something elemet Yagi? At a distance, the
>> signal
>> dispersion will certainly not only hit the transmission line but the GPS
>> antenna and possibly the receiver as well. Remember the microwave signal
>> reflects from nearby objects as well and can cause a change in the wave
>> propagation path.
>> 
>> There are numerous papers and articles on GPS jamming and interference.
>> Again, take a look at NIST archive. You will be delighted when reading
>> about
>> unintentional interference to GPS because of loose connectors in the RF
>> chain.
>> 
>> Thank you.
>> 
>> 
>> Regards,
>> 
>> 
>> 
>> Edgardo Molina
>> Dirección IPTEL
>> 
>> www.iptel.net.mx
>> 
>> T : 55 55 55202444
>> M : 04455 10045822
>> 
>> Piensa en Bits SA de CV
>> 
>> 
>> 
>> Información anexa:
>> 
>> 
>> 
>> 
>> CONFIDENCIALIDAD DE INFORMACION
>> 
>> Este mensaje tiene carácter confidencial. Si usted no es el destinarario
>> de
>> este mensaje, le suplicamos se lo notifique al remitente mediante un
>> correo
>> electrónico y que borre el presente mensaje y sus anexos de su
>> computadora
>> sin retener una copia de los mismos. Queda estrictamente prohibido
>> copiar
>> este mensaje o hacer usode el para cualquier propósito o divulgar su en
>> forma parcial o total su contenido. Gracias.
>> 
>> 
>> NON-DISCLOSURE OF INFORMATION
>> 
>> This email is strictly confidential and may also be privileged. If you
>> are
>> not the intended recipient please immediately advise the sender by
>> replying
>> to this e-mail and then deleting the message and its attachments from
>> your
>> computer without keeping a copy. It is strictly forbidden to copy it or
>> use
>> it for any purpose or disclose its contents to any third party. Thank
>> you.
>> 
>> 
>> 
>> 
>> 
>> 
>> On Dec 3, 2012, at 11:32 AM, "dlewis6767" <dlewis6767 at austin.rr.com>
>> wrote:
>> 
>>> I agree, Bob.
>>> 
>>> Like the billboard on the side of the highway says: - Does Advertising
>> Work? JUST DID -
>>> 
>>> 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.
>>> 
>>> 
>>> _______________________________________________
>>> 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.
>> 
>> 
>> 
>> _______________________________________________
>> 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.
> 
> 
> -- 
> "Neither the voice of authority nor the weight of reason and argument
> are as significant as experiment, for thence comes quiet to the mind."
> De Erroribus Medicorum, R. Bacon, 13th century.
> "If you don't know what it is, don't poke it."
> Ghost in the Shell
> 
> 
> Dr. Don Latham AJ7LL
> Six Mile Systems LLP
> 17850 Six Mile Road
> POB 134
> Huson, MT, 59846
> VOX 406-626-4304
> www.lightningforensics.com
> www.sixmilesystems.com
> 
> 
> 
> _______________________________________________
> 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