Protecting GNSS-based Services using Time Offset
Validation
Kewei Zhang
Networked Systems Security Group
KTH Royal Institute of Technology
Stockholm, Sweden
kewei@kth.se
Marco Spanghero
Networked Systems Security Group
KTH Royal Institute of Technology
Stockholm, Sweden
marcosp@kth.se
Panagiotis Papadimitratos
Networked Systems Security Group
KTH Royal Institute of Technology
Stockholm, Sweden
papadim@kth.se
Abstract—Global navigation satellite systems (GNSS) provide
pervasive accurate positioning and timing services for a large
gamut of applications, from Time based One-Time Passwords
(TOPT), to power grid and cellular systems. However, there can
be security concerns for the applications due to the vulnerability
of GNSS. It is important to observe that GNSS receivers are
components of platforms, in principle having rich connectivity
to different network infrastructures. Of particular interest is
the access to a variety of timing sources, as those can be
used to validate GNSS-provided location and time. Therefore,
we consider off-the-shelf platforms and how to detect if the
GNSS receiver is attacked or not, by cross-checking the GNSS
time and time from other available sources. First, we survey
different technologies to analyze their availability, accuracy and
trustworthiness for time synchronization. Then, we propose a
validation approach for absolute and relative time. Moreover, we
design a framework and experimental setup for the evaluation of
the results. Attacks can be detected based on WiFi supplied time
when the adversary shifts the GNSS provided time, more than
23.942 µs; with Network Time Protocol (NTP) supplied time when
the adversary-induced shift is more than 2.046 ms. Consequently,
the proposal significantly limits the capability of an adversary to
manipulate the victim GNSS receiver.
Index Terms—Time Cross-checking, WiFi, NTP, Replay, Spoof-
ing
I. INTRODUCTION
The recent increased use of global satellite navigation
systems (GNSS), for emerging applications, such as au-
tonomous/unmanned vehicles or intelligent transportation sys-
tems has heightened security concerns. More so, as researchers
recently demonstrated an effective GPS spoofer built with a
Raspberrry Pi and a Software-Defined Radio (SDR), with a
cost of only $250 [1]; or a dual-frequency spoofer built with an
SDR with a cost of only $400 [2]. Therefore, any applications
relying on GNSS, from mainstream mobile devices to smart
vehicles, ships and large, complex systems, such as smart grids
and cellular networks, face a dire risk.
A significant effort to improve security against different
types of attackers, such as GNSS repeaters and spoofers, has
been a central focus for both industry and the research com-
munity. GNSS vulnerabilities have been investigated in several
works, e.g., [1] and [3]–[6], and different countermeasures
have been analyzed and evaluated [7]–[16]. Contributions to-
wards protecting GNSS receivers can be divided into two main
categories: countermeasures on the receiver side and on the
system side. On the receiver side, one approach to detect the
presence of an attacker is to check the received signal strength,
e.g., through received power monitoring (RPM) ( [8], [17]) and
automatic gain control (AGC) monitoring [18]; with special
purpose hardware a receiver can determine the arriving angles
of the signals from different satellites [19]–[21]; some work
compares GNSS measurements with additional positioning
information, e.g., Inertial Navigation System (INS), to detect
the spoofing or replaying attacks [22]–[24]; distortions of
signal correlation function [25]–[27] and clock drift ( [10],
[17]) can also be an indication of an attacker.
On the system side, modification of the GNSS infrastructure
is needed, to add or augment features of Signal in Space
(SIS), to increase the difficulty of mounting attacks. Mili-
tary signals can be encrypted with secret keys that can be
accessed only by authorized entities ( [7], [28]). For civilian-
grade signals, Galileo currently develops navigation message
authentication (NMA) for Open Service (OS) Signals [29]–
[31]; other systems use similar approaches to protect civilian
signal authenticity [7]. However, even with NMA protection,
signals can be still manipulated by sophisticated replay attacks,
such as distance-decreasing attacks ( [4], [32], [33]) and secure
code estimate-replay attacks [30], which can modify each
pseudorange measurement separately.
It is feasible to detect the attack by checking the consistency
of the GNSS position, velocity, and time (PVT) solution.
The aforementioned INS-based countermeasures [22]–[24],
necessitate INSs. Without such hardware, it is not feasible for
many applications to detect abnormalities in the PVT solution
obtained from the GNSS receiver. Methods to detect GNSS
spoofing attacks by checking the clock bias, within a short
period were proposed ( [10], [17], [34]). The detection method
is based on a known linear clock state model with stable clock
drift. However, it was found that the receiver’s clock drift
becomes stable only after about 120 minutes after switching on
the receiver in room temperature, because it takes about 100
minutes for the receiver temperature to become stable [17].
This approach is not easily applicable, less so for a receiver
in cold start.
Currently, many commercial devices/platforms with an em-
bedded GNSS receiver have rich connectivity, by means of
different technologies, notably WLAN and cellular networks.
This leads to another path for time/clock information to be
used as means to detect attacks. The approach is to cross-check
timing information with external time sources. Therefore, we
can leverage these technologies to obtain several different
external time sources, to detect if the GNSS-provided time
is consistent with them. Based on this, if the external timing
information source is not attacked. i.e., if it can be trusted, it is
possible to determine whether the received GNSS signals are
legitimate or not. The effectiveness of this approach depends
on the time accuracy provided by different technologies, as
discussed in Section II. Although the idea to use time as a
mean of verification is not new, we propose, to the best of
our knowledges, a first investigation towards generalizing the
comparison of different time sources to detect discrepancies,
between time provided by the GNSS and external (non-GNSS)
technologies. Our experimental setup, based on commercially
available off-the-shelf (COTS) devices, is a general test setup
to evaluate the performance with real data.
The rest of the paper is organized as follows: Sec. II
analyzes the time accuracy of different technologies; then, the
adversary model is presented in Sec. III, following by our
proposed algorithm in Sec. IV; furthermore, a test setup and
evaluation results are in Sec. V; finally, Sec. VI concludes the
work.
II. RELATED TECHNOLOGIES
A GNSS receiver can be just one component in a sys-
tem/platform that offers many network connectivity options.
These different connections can be leveraged to obtain differ-
ent external time sources independent from each other.
The Network Time Protocol (NTP) and the Precision Time
Protocol (PTP) provide accurate clock synchronization over
LAN/WAN networks and they are the industry standards for
synchronization in computer systems ( [35], [36]). Recently,
several security concerns, especially man-in-the-middle attacks
and denial of service attacks, were investigated [37]–[40].
NTPsec is a security-hardened implementation of NTP, which
aims to make the protocol deployment compliant with more
stringent security, availability, and assurance requirements
[41]. The accuracy of NTP is usually within tens of millisec-
onds over the Internet, and it can be less than 1 millisecond
in LANs with ideal network conditions. However, asymmetric
network conditions and routes degrade NTP accruacy to 100
milliseconds or more ( [42], [43]). PTP suffers from similar
problems, but it provides better accuracy, from hundreds of
nanoseconds to microseconds [44]. In contrast to their good
performance over wired links, using these protocols over
mobile communication links raises a series of challenges. One
of the known problems in implementing NTP over cellular
networks is the change of state of the cellular radio. If the
amount of traffic on the communication link is not enough
to keep the radio in active state, the radio goes in idle
mode. As specified in the 3GPP documentation [45], when
the cellular radio is forced into a idle mode, no physical
uplink or downlink are allocated. The power state transition
introduces significant communication latency and it degrades
the performance, limiting its accuracy. Keep-Alive messages
are needed to generate enough traffic for the connection to
avoid idle states [46]. The achievable accuracy is within tens
of ms ( [46], [47]) with strong constraints on the power
consumption and operational modes of the cellular radio. In
scenarios where power consumption is a critical limitation,
this solution is hardly applicable.
Cellular networks are widely deployed, including 2G, 3G,
4G and now 5G, providing comprehensive network access
coverage in cities, highways and countryside. From the devel-
opment of 3G and 4G to 5G, highly accurate time synchro-
nization has become available. Timing Advance (TA) values,
used to schedule transmissions between User End (UE) and
Radio Base Station (RBS), are used to synchronize UE and
RBS since 2G ( [48], [49]). The TA value is normally between
0 and 63, with iincrements of 3.69 microseconds, i.e., one
bit period. This value also defines the best accuracy the UE
can obtain through the TA values. For LTE, Release 11 of
the LTE standard defines a new System Information Block
(SIB), i.e., SIB16, which contains GPS time and Coordinated
Universal Time (UTC), so that the UE uses them to obtain
GPS and UTC time or local time [50]. In 5G, two proposals
for UE time synchronization methods in RAN#81 leverage
a SIB-based message, i.e., SIB16, to deliver reference time
information to UEs for Time Sensitive Networking (TSN) (
[51], [52]). The worst case synchronization inaccuracy with a
Next Generation Node B (gNB) is expected to be ±250 ns for
small Industrial Internet of Things (IIoT) cells (e.g., up to 10
m radius) [52].
Cellular links are not the only option to access high pre-
cision timing signals. WiFi and other Wireless LAN-based
technologies offer several solutions. In [53], experiments show
that average propagation delay using NTP over WLAN is 2.7
ms with a standard deviation of 2.39 ms. Some customized
WLAN protocols ( [54], [55]) propose storing timestamps
inside Beacons, so that there is no protocol overhead in estab-
lishing synchronization between Access Point (AP) and mobile
stations. It is also proposed to store many older timestamps
in beacons, to ensure reliability in case of beacon loss. The
accuracy these synchronization algorithms achieve is around
100 µs, with a customized driver on a Windows platform.
For wireless distributed systems, synchronization of internal
clocks is a fundamental problem to allow communication.
Protocols such as Reference Broadcast Time Synchronization
(RBS), perform well in distributed scenarios [56]. In urban
environments, the high density of Access Points (APs) can
provide seamless WiFi beacon coverage. This large number
of beacons, generated by APs to advertise their networks, can
be exploited to provide a stable flow of high-precision timing
information. However, as the probability of receiving several
streams of beacons is significant (given the dense deployment
of APs, e.g., in urban environments), the computational power
needed to process all such events can become a significant
bottleneck for a low end platform. To avoid this, a subset of
the available beacons, based on the proximity to the AP and
the target beacon emission rate can be selected.
Local clock references in state-of-the-art CPUs [57] can be
used to provide a very stable time, based on the timestamp
instruction cycle register of the CPU. Specifically, the Time
Stamp Counter (TSC) (and equivalent), a 64-bit processor
register, counts the number of CPU clock cycles since reset.
Therefore, the TSC value maintains very high time resolution,
e.g., one nanosecond for a stable 1 GHz processor. When
the TSC is used for accurate timing, the speed/frequency of
the CPU needs to be controlled and kept stable. Intel allows
developers to extract TSC information since the Pentium CPU
[58]; similarly for AMD processors [59] and ARM processors
[60]. Performance Measurement Units (PMUs) or clock reg-
isters can be read from the Linux kernel and the user space
from ARM, AMD and Intel processors. Even though platform
specific, these registers are common to several architectures of
the same family.
III. SYSTEM MODEL
A. Adversary Model
The mathematical model to obtain the PVT solution at a
GNSS receiver influenced by an adversary can be written as:
y = Hx + f + v (1)
where y, n × 1 vector, contains pseudorange measurements
of the receiver to n satellites; H is a n × 4 observation
matrix; x = [x, y, z, δt], is the receiver state, including three-
dimension coordinates and clock offset; f is a n × 1 offset
vector that an adversary introduces to the pseudorange mea-
surements; v, n× 1 vector, is noise. Generally speaking, there
is no limitation on how the adversary mounts the attacks, e.g.,
by replaying previously recorded signals or by transmitting
fine-grained simulated signals, and the adversary objectives.
Considering a simple adversary, all the elements in x,
including x, y, z and δt, are manipulated when the adversary
induces a specific victim receiver location, or the adversary
could seek to mislead the receiver to follow the adversary-
intended time, by inducing a specific δt. Then, our and any
time cross-checking proposal will detect the attack when the
change in δt exceeds a certain threshold. The objective is to
design time-based validation (or attack detection) that operates
in a way that severely limits the adversary. Intuitively, the
approach detects the lowest discrepancy caused by an attack.
A sophisticated adversary, seeking to change the victim’s
location without modifying the victim’s time [61] cannot be
detected by any clock-related countermeasure, and thus by our
proposal either.
The GNSS receiver may be at cold start or in a state of con-
tinuously tracking satellites. In the cold start, the system needs
to acquire absolute time from satellites or other external time
providers. When the GNSS receiver already tracks satellites,
the adversary can either first jam the signals reception at the
receiver, then transmit recorded/forged signals to the receiver,
or use a signal lift-off technique to take over the receiver.
B. System Assumptions
Maintaining synchronization of the GNSS receiver as accu-
rate as possible is not the goal of our proposal. Instead, we aim
at evaluating to which extent the existing external time transfer
technologies can be used towards the GNSS-provided time
and location verification. When the external time technologies
are used to detect the manipulation of the GNSS-provided
information, clear assumptions on the trustworthiness and
accuracy metrics are needed:
• It is not likely that the adversary can attack the victim
GNSS receiver and at the same time compromise the
external time sources or manipulate the access to the
external, non-GNSS, time sources, e.g., NTP servers.
Therefore, for this work, we assume that external time
sources are trusted. For example, the network access
per se can be encrypted and authenticated, or the time-
providing network server or component (e.g., access point
or base station) can be authenticated.
Remark: In the event of no trusted external non-GNSS
time sources, the approach would amount to a discrep-
ancy detection between GNSS-provided time and one
or more external time sources. Intuitively, such a dis-
crepancy detection between two essentially non-trusted
sources of time can still be useful: it can reveal that either
the GNSS or the external time source(s) is attacked. This
more complex attack surface warrants its own investiga-
tion; we discuss this briefly in Sec. VI.
• The GNSS receiver is always the primary synchronization
source, unless it is deemed not trusted by the valida-
tion/detection scheme.
• The system always chooses the most accurate time
source. The only exception: another available source more
trusted than the default one, even if the latter is less
accurate.
• The system will always synchronize with the most trusted
available source, informing the user about any changes in
time reference.
IV. SOLUTION APPROACH
Without loss of generality, we consider two situations: 1)
there is only one external time technology, e.g., due to limited
connectivity or functionality; 2) multiple available external
time technologies are available. Moreover, the approach can
be developed in two different directions: 1) validating rela-
tive time that is, the difference of the GNSS and external
technologies elapsed time during the same time interval; 2)
validating absolute time, that is, the difference of absolute time
from each technology (GNSS or not). For the sake of simple
presentation, we discuss first the case of a single available
external technology. Then, we extend it to the case of multiple
available external technologies.
A. Single Available External Technology
In general, the device/system can access different external
time sources/technologies, e.g., WLAN or cellular networks,
each providing a different level of accuracy. However, due
Fig. 1: Illustration of the approach with a single external time
source
to environment limitations and other constraints, there might
be only one available external source. As Fig. 1 shows, the
system applies a function, f(.), to the GNSS time and the
one provided by the external technology. The output indicates
whether the GNSS time is consistent with the external time
sources.
This function, f(.), can be implemented based on two
approaches:
• Validating absolute time, T
• Validating relative time, ∆t = T
n
− T
n−1
, where n is the
index of GNSS time update
1) Absolute time checking:
f(t) = f(|T
ext
(t) − T
GN SS
(t)|) (2)
is a function of the time difference between GNSS and the
external technology. Specifically, T
ext
is the time value from
the external source, T
GN SS
is the GNSS-provided time, and
t is a time instance at the system when both T
ext
and T
GN SS
are available.
The receiver starts acquiring time information from the
GNSS, in cold or warm start, and simultaneously acquires time
from the external technology; it updates its GNSS-provided
time every τ seconds, with the value, τ , depending on the
design of the receiver, e.g., 500 ms or 1 s. For each GNSS
update, there is a time fetch from the external time technology.
We do not consider the accuracy of GNSS-provided time, i.e.,
around 100 ns, which means that the GNSS-provided time is
deemed accurate in the absence of an adversary. Therefore,
we have:
f(t) <
ext
(3)
where
ext
is the external time technology accuracy, subject
to the network delays, the wireless propagation environment
or the external time source attached master clock.
For each available technology, there can be multiple time
information sources. For instance, our enhanced receiver can
acquire NTP time from several different NTP servers; or
it can receive WiFi beacons from multiple access points
simultaneously. Therefore, assuming there are k time sources
for a single technology, we have series of f(t) values for each
time source:
f
1
(t
1
) f
1
(t
2
) . . . f
1
(t
n
)
.
.
.
f
k
(t
1
) f
k
(t
2
) . . . f
k
(t
n
)
(4)
By assuming the k sources of one technology (having same
attributes and thus expected time accuracy), we set a counter
m incremented at each time instance t
n
, if Eq. 3 is true:
For i = 1, ..., k; m = m + 1 if f
i
(t
n
) <
ext
(5)
Then, the approach makes a decision at time t
n
based on:
m
k
>
1
2
(or a desired higher value) (6)
which indicates that the majority of sources of the available
time technology satisfy Eq. 3, i.e., the technology-specific
accuracy threshold. If Eq. 6 is not true, this indicates a
discrepancy between time acquired by GNSS and the external
technology.
2) Relative time checking:
f(t) = f(|∆t
ext
(t) − ∆t
GN SS
(t)|) (7)
where ∆t
ext
(t) = T
ext
(t + 1) − T
ext
(t) and ∆t
GN SS
(t) =
T
GN SS
(t+1)−T
GN SS
(t). The idea of relative-time checking
is that, given one interval measured by GNSS-provided time,
the elapsed time measured by the external technology should
be within a certain threshold. In absence of an adversary, f(t)
satisfies the following:
f(t) <
ext
(8)
The validation process is similar as described in Eqs. 4 and 6.
For both absolute-time and relative-time checking, in order
to reduce the false alarm probability, we can extend this
scheme to an aggregated scheme: the approach makes one de-
cision every Q time instances. When any Q successive events
give negative results based on Eq. 6, an attack or discrepancy
of GNSS-provided time and the external technology provided
time is signaled.
B. Multiple External Available Technologies
Multiple external technologies can be available in many
off-the-shelf platforms. As Fig. 2 shows, during the system
bootstrapping phase, the system searches and locks to available
satellites, thus obtains PVT solutions. Meanwhile, it acquires
time information from other external sources. The system has
a predefined setting about the accuracy (and trustworthiness, in
the next version of this work, as currently external time sources
are deemed trusted) of different external time technologies,
according to historical statistics.
Therefore, for absolute-time and relative-time checking at
time instance t, g(t) is defined as follows:
g(t) = g{|T
ext1
(t) − T
GN SS
(t)|, . . . , |T
extk
(t) − T
GN SS
(t)|}
g(t) = g{|∆t
ext1
(t) − ∆t
GN SS
(t)|, . . . ,
|∆t
extk
(t) − ∆t
GN SS
(t)|}
(9)
When we trust all the external non-GNSS time sources
(of different types/technologies), if the majority of those time
technologies fulfills Eq. 6, the approach deems that GNSS
provided time is not faulty.
Fig. 2: Illustration of the approach with multiple external time
sources
If we do not fully trust the external time technologies, the
approach applies a weight to each time technology, by consid-
ering their level of trustworthiness and accuracy. For instance,
in an industrial environment, the trusted WLAN access points
have higher weight than cellular networks. Hence, the decision
at each time instance is made based on:
g(t) = w
ext1
f
ext1
(t)
ext1
+ w
ext2
f
ext2
(t)
ext2
+ · · · + w
extk
f
extk
(t)
extk
< 1
(10)
where w
extk
is the weight of k
th
time technology and
P
k
i=1
w
exti
= 1 for k external time technologies, and f (t)
can be a function based on absolute time, Eq. 2, or relative
time, Eq. 7. The weights, w
extk
, can be defined based on
the trustworthiness and accuracy of external time sources and
the conservativeness of threshold
extk
. In order to reduce the
false alarm probability, aggregation of results of successive Q
decisions, to obtain one final decision on the attack, can be
used.
V. ARCHITECTURE AND EVALUATION
A. Framework/Architecture
To evaluate the concept and demonstrate the results, we
designed an architecture compatible with multiple external
time technologies, as presented in Fig. 3a. We have a cen-
tralized controller that interacts with the system clock and all
other time technologies, including GPS, WiFi beacons, NTP
servers, etc. The system detection is triggered by the GPS
time update within a specified interval; the system makes a
detection decision at each specified interval with the available
collected data.
One of the challenges is the combination of synchronous
and asynchronous data collection processes from different
time sources. The reason is that when the system triggers a
detection event, both for absolute time verification and relative
time verification, all the collected data must be aligned, in
order to compare them with each other. More specifically,
data collection of WiFi beacons is asynchronous due to their
spontaneous transmission characteristics; NTP data collection
is synchronous because the NTP request is on-demand when
the system attempts a request.
The solution is to apply a time alignment for different time
technologies, especially for the asynchronous data collection.
We use the platform/system clock as a reference to align the
data; the system timestamps each data collection with its local
clock and compensates for delays of data provided by different
time technologies.
B. Experimental Setup
We leverage two external time services, NTP and WiFi
beacons, to verify the GPS time, as presented in Fig. 3b.
The ublox EVK-6T evaluation kit [62] offers two interfaces
for data transmission: a USB2 port provides a real-time PVT
solution that the manipulated GPS time is synthesized based
on; a RS232 serial port provides a GPS time pulse for the
host synchronization. The serial port provides a high accuracy
Pulse Per Second (PPS) via the Data Carrier Detect (DCD)
pin, which is used as a reference to check the performance of
the evaluation results.
Beyond the GPS receiver, the rest of the configuration
includes:
• Host machine: Intel I7 CPU running a Linux system
whose kernel supports high precision timing.
• Host WiFi card: Intel Corporation Wireless-AC 9260.
• WiFi beacons: from surrounding access points of the
office building.
• NTP servers: three servers in Sweden.
• GPS PVT rate: 1 Hz.
• Observation window candidates for APs: T
window
=
{1024, 3072 , 5120} ms.
C. Evaluation
1) Accuracy Analysis: To validate the GPS time, we need
to obtain the accuracy,
ext
, of each technology, as shown in
Eqs. 3 and 8. The accuracy is obtained by comparing the time
information from each technology with a GNSS disciplined
oscillator.
For the case of NTP, the accuracy is calculated based on the
offset between the GNSS-provided time and the NTP server
provided time. The left plot of Fig. 4 shows the offset of three
different NTP servers located in the same country, for a period
of 22 hours. We use the 99% quantile of each server offset as
its accuracy, as shown in the right plot of Fig. 4, to represent
our parameter
ext
. The highest value among the three
ext
is
chosen to set the threshold for the NTP time. Therefore, we
have:
N T P
= 2.046 ms (11)
A similar approach is used to profile WiFi beacons. By
default, APs transmit beacons at a 100 Time Unit (TU)
interval which corresponds to 1024 microseconds [63]. In
the IEEE 802.11 standard, a timestamp field contained in
each beacon indicates the time, notably T
B
AP
, the beacon
leaves the AP. Specifically, T
B
AP
is the elapsed time since
