At LANL in the weapons group, we had a unit of time called a shake that
equals 10ns.  I suppose that means two shakes of a lamb's tail is 20ns.

-Bob

http://en.wikipedia.org/wiki/Shake_(time)

On Mon, Aug 24, 2009 at 7:55 AM, Brooke Clarke brooke@pacific.net wrote:

IIRC, a lamb doesn't shake its tail once - always twice, quickly.
Hard to imagine the survival benefit there. But it's been a long
time since I saw a live lamb.

Bill Hawkins

-----Original Message-----
From: Robert Darlington
Sent: Monday, August 24, 2009 10:03 AM

At LANL in the weapons group, we had a unit of time called a shake that
equals 10ns.  I suppose that means two shakes of a lamb's tail is 20ns.

-Bob

http://en.wikipedia.org/wiki/Shake_(time)

On Mon, Aug 24, 2009 at 7:55 AM, Brooke Clarke brooke@pacific.net wrote:

one

Bill Hawkins wrote:

Bill:

Spoofing a GPS receiver should not be too hard.  I would record the GPS
spectrum off the
air, then play it back, delayed by some sufficient time to confuse
whatever you are trying
to confuse.  By playing back actual signals, the GPS receiver would hear
a self consistent
set of signals, just shifted in time.  You would have to be close enough
to the target GPS,
so that your spoofing signal was much stronger than the off the air
signals.  Playing back
signals recorded at another location may or may not help the confusion.
It all depends on
how smart the target GPS receiver is, and what it has been programmed to
alarm, versus just
accept and reset itself.  As another email commented, most consumer GPS
receivers
have almost no protection against this kind of attack.

--- Graham

==

Dear Bill,

Bill Hawkins wrote:

Well, don't assume propper hold-over functionality. You need to really
verify propper operation due to any of a number of failure modes.

Jamming is just one of them. Jamming usually works by a RF signal just
overloads the input, often will an inadequat A/D AGC be the cause in
combination with lack of filters.

Another RF level fault which I've witnessed myself was that the antenna
element came under water. Similarly a christmas-tree put on the roof of
a building killed a telecom operators sync one year...

Another failure mode is various firmware issues. We have seen a fair
amount of those, and they can be hidden in the OEM receiver, killing the
functionality of the product they are included into. There are countless
examples of that, so it is a real issue.

Failure can come fairly quick from signals which is propper signals but
unexpeced by old or buggy firmware.

An important issue from a system perspective is that a GPS receiver (or
any other time-giver) clearly indicates when it can no longer supply the
quality of time and frequency expected of it. One way is to squelch its
outputs. Depending on the system, just loosing signal or when the
expected holdover breaks some estimated frequency or time deviation
limit should qualify as the reason. The reasons for those decissions
should be logged so that post-mortum analysis can be done.

No, it's not difficult. A GPS simulator does it and you can buy them or
rent them commercially. More advanced spoofing attacks was recently
presented in which a hacked GPS receiver was used to produce raw-signals
for a spoofed signal which could "lift" the attacked receiver from
tracking the propper constellations to track the attacker signals which
could then derail it more and more.

As if there isn't enought of that to go around as it is?

You should remember that intentional threat is just one of many
possibilities. Another may be intentional... but not to your installation.

If you use NTP, then that may be both a means to attack, but if done
properly both air and net attacks needs to be coordinated. Non-public
networks helps around that. Etc.

Work is underway to even further investigate these issues.

Sure. But real security does not exist. It's more an issue of how easy
you make it to do attacks and how easy leakage occur anyway. Most
problems relates to lack of insight or sloppyness. Also, what is most
valuable? Continous operation or undisclosure/unchanged of sensitive
information?

You may be perfectly secured, but still not have the security you need.
It goes from both extremes, but we also see those that have neither.

Cheers,
Magnus

Hi, from a timing perspective we treat CERN as a factory of particle beams,
so probably our ideas on timing systems apply to industrial control systems
as well. We have a single GPSDO with Rubidium for holdover and our Central
Timing Generator only looks at it at power up to get its first PPS and UTC
time. From then on it runs counting 10 MHz (or multiples of it) off the same
GPSDO. UTC compliance is important in case of accidents but not absolutely
needed for routine operation. We've seen our GPSDO drift and the
accelerators kept working flawlessly. Our timing generator drives an
internal timing network, and because all critical equipment listens to time
on this network GPS jamming/spoofing would be of no concern in principle.
There are some exceptions to this, with PLCs and other pieces of hardware
getting sync from NTP. We've had problems in our Post Mortem system in the
past, with a PLC not receiving NTP traffic because of router
misconfiguration and this resulting in incoherent time tags. Our proposed
solution for that is to feed a PPS from one of our timing receivers to the
critical PLCs and ask them to time-tag it with their internal NTP-derived
time base.
I agree with Hal that protection through diversity is very effective. We do
checks of our timing system vs. GPS, NTP and a free-running Cesium. If
something goes wrong, we get a warning, diagnose the problem and schedule an
intervention at the earliest convenient time. There was some debate about
installing a distributed system of GPS receivers in the past, but for our
particular application a single source (even if "wrong") is best.

Cheers,

Javier

On Mon, Aug 24, 2009 at 8:30 PM, Bill Hawkins bill@iaxs.net wrote:

Not too hard -> trivially easy.  A L band antenna, an amplifier, and another antenna with enough isolation so you don't make an oscillator will work.  The coax in the system provides the needed delay.  This is the origin of the "GPS jammer from radio shack" stories.

Note that the vulnerable time is during code acquisition.  Once the receiver is tracking a signal, another signal at more than 1 chip delay won't show up in the correlator output, unless it's MUCH (10s of dB) stronger.  However, during acquisition, the search logic tends to pick the strongest signal to lock on to. Since satellites are always appearing and disappearing, the code acquisition process occurs fairly often, although more sophisticated receivers are better at rejecting inconsistent data (e.g. they could reduce the search space when a signal fades, on the assumption that when that signal comes back, it will be in pretty much the same place)