Time service jamming means that there are distortions such that normal time services can't be provided anymore. For example, in case of long wave receivers or GPS devices an easy approach for jamming could be to install a cheap RF transmitter for the target frequency which generates a much stronger signal than the original one, so the original signal disappears in the noise and can't be evaluated anymore.
Jamming can even affect time services unintentionally. For example, there are trucks drivers which have GPS jammers installed in their vehicles to avoid being located by their employer. While driving around these GPS jammers can accidentally affect other important services. For example see:
There are also reports of intentional use of GPS jammers. For example, see:
The U.S. Air Force who operates the GPS system has been aware of potential jamming problems for a long time:
On the other hand, the U.S. Air Force itself does GPS jamming, too, e.g.:
Jamming is evil but it can easily be detected by receivers, when decoding of the original time signal suddenly fails. Good receivers can then switch to holdover mode and continue to provide a high quality time for some holdover interval.
When a time receiver has evaluated an incoming time signal properly for some time, and has adjusted its internal time accordingly, then the receiver's internal time doesn't become inaccurate immediately when the incoming signal suddenly becomes unavailable due to jamming, or technical faults (antenna cable interrupted). However, the receiver's internal time starts drifting slowly in this case, based on its internal oscillator. This is called holdover mode.
How long the time in holdover mode may still be accepted by client applications depends on
For example, if the oscillator drifts 1 ms per day in holdover mode then the time can be accepted for 10 days if the application requires only 10 ms accuracy, but for applications expecting 0.5 ms accuracy the limit is already reached after half a day.
So the required quality of an oscillator depends on the maximum length of a holdover interval to be accepted, and the accuracy requirements of the client applications.
While jamming just makes a time service unavailable, time service spoofing tries to provide a time receiver with a wrong time. It is very hard, if not even impossible, to detect or avoid this.
Goals of this approach could be to spoof crypto systems, for example to change the time back to the past so that a crypto key which has already expired is accepted as valid.
Back in 1999 the film Entrapment with Sean Connery and Catherine Zeta-Jones already picked up the idea to use time spoofing for some criminal activities. The thieves manipulate the time of a bank by subtracting 1/10th of a second for an hour or so during the millenium countdown before midnight, thus creating a 10 seconds “time gap” which they use to transfer money away from the bank.
In 2013 there was an experiment by the University of Austin, Texas, where they successfully tried to spoof a yacht with wrong position (which includes wrong time) so that the yacht finally found itself in a different location than expected:
In April 2016 there was a report that Iranian forces captured two U.S. Navy patrol boats and 10 sailors after they allegedly strayed into Iranian waters:
In May 2016 there was a presentation by Pierluigi Paganini at a conference which just showed that NTP servers can easily be spoofed if they have been configured to rely only on a single reference time source, which is not particularly surprising:
In July 2016 there was a report about an exercise using a relatively low cost multipurpose TX and RX capable software defined radio to spoof GPS receivers:
In August 2017 there was an article on gpsworld.com that an apparent mass GPS spoofing attack in June involved more than 20 vessels in the Black Sea and suggests that Russia may be aggressively experimenting with signal disruption and spurious substitution:
These examples just makes clear that special precautions are required to detect or even avoid spoofing.
A different spoofing approach is to modify specific client systems or application and provide them with a spoofed position and/or time instead of the true position and time determined by a GPS/GNSS receiver.
A popular example is a hack for Android or IOS devices where a fake position is supplied to other apps like Pokémon GO, so users could detect and catch Pokémons not only at their real current position, but all over the world, without actually moving there:
Unlike the Pokémon spoofing exercise mentioned in the previous chapter, this kind of spoofing doesn't affect the real satellite signals, and thus only hacked devices are susceptible to this kind of spoofing.
A first idea how time service spoofing could be prevented is to avoid letting a time services accept a time step anymore after it has already be synchronized. However, a spoofer doesn't necessarily need to start providing a time which is is remarkably off the real time. He can start with the correct time and then pull the time slowly away, as shown in the film from 1999.
Time receivers still need to accept small time corrections to be able to discipline their internal system time and oscillator, so if the time manipulation only occurs slowly enough then spoofing will succeed.
Spoofing GPS or other GNSS signals requires quite some effort, and thus GPS simulators aren't cheap. However, if there's enough return-of-investment for some criminal action it isn't particulary hard to use such a simulator for spoofing.
A possible approach to detect and avoid this at the receiver side is to use a combination of different antennae for reception, and let the receiver check the signal from which satellite is received by which antenna. If a GPS satellite is expected high above the horizon at direction North, and another satellite in direction East, but all signals are received from the antenna which points to South with a low elevation then this should be suspective and could be a spoofing attack.
However, this approach requires some effort in the receiver, and thus is pretty expensive. Also, things are not as simple as they look at the first glance. GPS signals can be reflected at buildings, etc., and the reflected waves can indeed be received from a different direction than the original waves.
A good way to detect and avoid spoofing is to use different, independent time sources as backup sources. The receiver can then check the time offsets between these sources to determine if they all agree on the same current time.
Of course it must be made sure that the backup time sources aren't also affected by spoofing. The facts mentioned above are basically also valid for other GNSS systems like GLONASS, Beidou, and Galileo. So long wave signals e.g. from DCF77, MSF, or WWVB come first into mind as a backup sources. However, these aren't really suitable, either.
Some GPS receivers can even generate an output signal which can be used to drive a long wave antenna and thus make up a long wave transmitter. Such GPS receiver driven by a GPS simulator can also easily generated a spoofed long wave signal which corresponds to the GPS signal, so that the attacked receiver doesn't notice a time difference.
A common problem with LF transmitters is that there's only a single transmitter. LORAN-C, on the other hand, has been a predecessor of GPS which was going to be deprecated. Recently governments have decided to modernize the LORAN-C system with improved technology called E-LORAN, e.g.:
The NTP daemon (ntpd) gets its reference time from one or more time sources, which can be for example a GPS receiver (a refclock),
or one or more upstream NTP servers on the network.
ntpd computes the difference between the reference time(s) and its own system time, and tries to make this time difference as small as possible.
If the computed time difference suddenly steps from a small value to a larger value then either the administrator has changed the system time, or the time provided by the upstream time source has jumped.
If the new time difference is below a certain limit (128 ms by default) then ntpd corrects the offset by slewing the system time. If the time offset is above that limit then ntpd waits until the stepout limit (900 s by default) is reached, then steps the system time and starts over from scratch. This large step is only executed it the time offset is below the so-called panic threshold (1000 s by default). If the sudden time offset exceeds this limit then ntpd stops itself with a log message saying that the administrator has to check and set the system time first.
As mentioned above, also ntpd has to accept small time steps, which can occur for example if a refclock has been in holdover mode for some time,
its time has drifted, and then the clock synchronized again, and ntpd has to follow. Similarly this happens at clients if the time of an upstream NTP server has drifted, and the upstream server synchronized again to the correct current time.
Thus it is of course possible to spoof ntpd by applying small time steps which seem to origin from a refclock, or from an upstream server.
The best method to avoid this is by using a diversity of time sources, for example different refclocks getting time from different sources, and different upstream servers installed in different geographic locations.
If a local refclock is spoofed then ntpd sees that the refclock time drifts away from the time provided by the upstream servers, and thus the upstream servers can overvote the refclocks, and ntpd discards the refclocks instead of letting its system time follow the spoofer. However, this still doesn't yield absolute protection: If a man-in-the-middle has access to your network then it can grap the request packets sent to the remote NTP server, and can send replies with spoofed time back to the ntpd instance which has sent the request.
NTP servers and clients can be configured to use authentication mechanisms to let clients be sure the time they receive from a server has indeed been sent by the server, and not by a man-in-the-middle. More details can be found in the article on NTP Authentication.
Alternatively, the network connection can be routed via an encrypted channel, e.g. a VPN connection.
Please note that encryption and decryption of the network packets requires additional processing time on both the client and server, so the resulting time accuracy may be degraded.
Meinberg LANTIME time servers provide different ways to monitor the time on different remote NTP or PTP sites, and generate an alert if the time offset exceeds a specified limit. Which kind of monitoring is supported depends on the LANTIME model and firmware version, so please see the LANTIME's manual, or contact Meinberg support at support@meinberg.de for detailed information.
Anyway, the monitoring features can be used to at least detect spoofing attacks. Since eventually the monitoring device itself is being spoofed, it may make sense to let also the LANTIMEs at different geographic locations monitor each other.
There's always a possibility for jamming, and also for spoofing. If an attacker provides sufficient effort he can still spoof your time service, but this can get really expensive for the attacker.
— Martin Burnicki martin.burnicki@meinberg.de 2019-02-27