[time-nuts] Time security query

[Magnus Danielson]

Dear Bill,

Bill Hawkins wrote:
> Group,
> 
> The questions of network and radio security are being applied to industrial
> control systems, which is my field of endeavor.
> 
> Control systems also require an accurate sense of time of day, to stamp the
> time of events occurring in the controlled process. GPS is the preferred way
> to get accurate time, even though process sensors seldom sample faster than
> 120 times per second. These time stamps are required by government
> regulations
> in some industries.
> 
> So, what are the threats to a GPS time receiver? Jamming is possible, or
> just
> overloading the receiver, but the receiver goes into holdover mode and keeps
> on ticking with the disciplined oscillator. This does little damage compared
> with jamming the transmissions of wireless sensors.

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.

> Spoofing the time from a remote location seems impossible. Or is it just
> difficult? Security by obscurity is not secure.

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.

> Continual time changes could
> confuse a control system that had scheduled activities, as well as mess up
> the trends and logs that record the history of the process.

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.

> Thanks for any comments I can pass on in a talk on this subject.

Work is underway to even further investigate these issues.

> Bill Hawkins
> 
> Observation: Passwords are merely obscure.

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