The cornerstone of Industry 4.0 [1
] are cyber-physical systems (CPS), which are closely connected with computer systems and which can interact and collaborate with other CPS systems [2
]. These concepts represent the basis of decentralization and cooperation between connected systems: they are closely linked to the Industry 4.0 paradigm and fully enabled by information and communication technologies [3
Networked environments and Industrial Internet of Things (IIoT) [4
] need accurate, reliable and trusted time synchronization and time distribution [6
], with different requirements in terms of synchronization accuracy and precision. For instance, the scheduling and synchronization of multiple factories represents an interesting high level application of the Industry 4.0 paradigm [5
]. Due to rapidly changing market requirements, factories have shifted from a centralized to a more decentralized structure in many areas of decision making, including scheduling. Since limited resources make scheduling an important decision in the production, accurate time synchronization and efficient scheduling solutions are vital for improving the productivity in a multi-factory production network [7
Another relevant example is the case of Digital Twins (DTs) in Industry 4.0 [8
]: the underlying idea is that a real product and its virtual counterpart are twins that travel a parallel journey from design and development to production and service life. A DT must be always in sync with the corresponding physical asset. Such synchronization is needed to correctly update and to keep the operational data (i.e., failure and erroneous data) consistent within the production system.
Nowadays, several Industry 4.0 applications already imply stringent synchronization requirements (e.g., sub-microsecond accuracy). Among the others, we consider the following ones especially relevant:
Automation and control systems
], that need an accurate common notion of time as well as a reliable shared communication medium for timely data exchange, for instance to synchronize multi axis drive systems and subsystems with cyclic operation;
Measurement and automatic test systems
], which usually take advantage of accurate time stamping of logged data, for example to correlate acquired values in decentralized locations;
Power generation, transmission and distribution systems
], requiring a precise time synchronization of all the critical points within the power grid to accurately measure the delivered/consumed power and to predict critical load situations.
In this context, satellite-derived timing information plays a key role in the provisioning of an absolute time reference to a significant number of current and future connected systems. Global Navigation Satellite System (GNSS) receivers combined with specific transport protocols or with distributed synchronization approaches can indeed satisfy the stringent requirements foreseen in several industrial applications [13
provides a common scheme of a synchronization network, representative of a typical time distribution network and highlighting the role of GNSS technologies. In this scheme, accurate time information is generated by each GNSS satellite and then transmitted by means of properly formatted radio-frequency (RF) signals [14
]. A Master Clock node of the network accurately synchronizes its local clock using a GNSS receiver, taking advantage of the signals received from the GNSS satellites visible at its location [16
]. As illustrated in Figure 1
, a distribution network allows us to distribute the timing information to all the nodes, achieving an accurate synchronization between the Master Clock and multiple Slave Clocks. The distribution network can take advantage of different protocols and technologies, depending on the application requirements and constraints. Among the others, the Precision Time Protocol (PTP) represents a well-known and widely adopted solution for accurate time distribution in a network of clocks organized in a master–slave hierarchy [16
]. Such a synchronization protocol, also known as IEEE-1588 standard [18
], allows for absolute time synchronization in the range of hundreds of nanoseconds through hardware assistance (SyncE) and, potentially, sub-nanosecond accuracy with the White Rabbit extension of PTP (WR-PTP) [20
Nevertheless, a conscious adoption of the Industry 4.0 paradigm also requires the introduction of appropriate cybersecurity solutions. In fact, cyberattacks and hacking of factory industrial control systems are dramatically increasing in recent years. Proper mitigation measures against these attacks are needed to avoid the emergence of an internet of insecure industrial things [22
]. The same statement is also applicable to all the grids and telecommunications networks recognized as critical infrastructures [23
], especially the upcoming 5G [16
] that is considered as a key enabler for several Industry 4.0 applications. In all these cases, possible synchronization inaccuracies can directly result in a degradation of the quality of service provided by the communication network (e.g., reduced throughput, increased latency and jitter) and, in extreme cases, in a complete disruption of the considered system or application.
Two areas in Figure 1
represent likely targets for potential attacks (i.e., viable attack vectors) and, thus, need appropriate protection:
GNSS RF spectrum, potentially targeted by attacks against the GNSS signals;
Time Distribution Network, potentially targeted by attacks to the synchronization information. We can further divide this category into:
attacks targeting the Precision Time Protocol over the network, and
attacks against the integrity of PTP software (SW) running at each node and the related configuration files.
It is worth noting that recent scientific literature has extensively investigated attacks to the GNSS RF spectrum (i.e., attack vector 1) and to the PTP protocol and packets over the network (i.e., 2.a). Proper countermeasures against them are already available (e.g., refer to [26
] and references therein). For this reason, the following sections will summarize these specific attack vectors, while their experimental assessment is out of the scope of this paper.
On the other hand, to the best of the authors’ knowledge, previous works have not widely covered the attacks to the PTP SW integrity within nodes (i.e., 2.b). This category of attacks is gaining special attention in both scientific and industrial communities, where the investigation of possible cybersecurity solutions is an active research topic, stressing the need for software integrity control at network nodes. For these reasons, we recognize this category of attacks and related solutions as especially relevant and challenging for Industry 4.0 applications and, thus, worth of further investigation.
Motivated by this background, the paper has the following objectives:
An analysis of attack vectors for GNSS-based synchronization distribution networks, with a special attention to attacks not widely covered in prior work (i.e., 2.b);
The proposition of a novel solution for PTP nodes augmented with Trusted Computing technologies to counteract attacks to their integrity, complementing existing security solutions that focus on GNSS RF Spectrum and PTP protocol only;
A reference implementation on a testbed, capable to demonstrate the proposed solution by means of quantitative results.
Our proposed approach differs from other authentication and authorization-based solutions already available in prior work and suitable to ensure the integrity of the network protocols and all type of exchanged packets. In fact, our solution leverages the Trusted Computing principles to achieve a level of trust in the behavior of the synchronization distribution network. It is capable to ensure the integrity of the software and configuration of all the nodes and, thus, to avoid the exchange of incorrect synchronization information over secure protocols. For a more complete view on prior works about SW vulnerabilities in other domains, interested readers can also refer to [29
] and the references therein.
In this sense, the contribution of the paper is twofold:
We present our proposed implementation based on Trusted Computing and capable of protecting the integrity of the nodes of a synchronization distribution network.
Next, we propose and describe a new testbed, suitable to emulate the identified attacks and to demonstrate the effectiveness of the proposed solution.
After this introduction, the paper is organized as follows. Section 2
provides an overview of the vulnerabilities and solutions related to the GNSS RF spectrum, while Section 3
covers the network attack vector. After that, Section 4
discusses the Trusted Computing paradigm, as a suitable solution to protect the SW integrity of the nodes. Then, Section 5
describes in detail our implementation and Section 6
presents and discusses the obtained results. Finally, Section 7
concludes the paper with the main remarks.
2. GNSS RF Spectrum Attack Vector
GNSS technologies [14
] have shown a remarkable growth in the last years, being nowadays adopted in the most different fields of applications such as: consumer devices (e.g., smartphones, cameras, wearable devices, etc.), vehicular applications (e.g., road user charging, bike sharing, connected and automated driving, etc.), manned and unmanned aviation (e.g., drones), industrial applications and even in critical infrastructures. Every system that makes use of GNSS-derived data must trust them before taking decisions, especially in case of safety-critical or liability-critical applications.
The widespread adoption of GNSS technologies creates incentives for the attackers that want to impair or fool any system that rely on GNSS to estimate the position, the velocity and, especially, the time information [26
]. GNSS receivers and connected devices integrating these receivers are all vulnerable to intentional attacks, aiming to affect the availability and the reliability of the GNSS signals and data. In general, GNSS RF attacks are classified in three main categories [24
Jamming, that is the blocking of the reception of GNSS signals by intentionally emitting RF interferences to disrupt the functionalities of the receivers, in order to reduce the signal-to-noise power level;
Meaconing, that corresponds to the rebroadcasting of delayed GNSS signals, without any distinction between signals received from different satellites;
Spoofing, that refers to the transmission of counterfeit GNSS-like signals, with the intent to produce false position and/or time data at the victim receiver.
Each of these three categories can be put in place in different ways, implying a different complexity and cost at the attacker side. Among the possible attacks, only few can be considered likely to be deployed in real applications [12
Different countermeasures against these attacks are already available and widely discussed by the GNSS research community [26
]. Please note that a comprehensive review of the state of the art related to GNSS RF attacks and proposed solutions is out of the scope for this paper. Nonetheless, interested readers can refer to [17
] and the references therein.
Among the most recent solutions, it is worth to point out the on-going effort of the European Galileo program to gradually add authentication services to its first and second generation of satellites signals, in order to enable authentication functionalities for future civil receivers [27
]. The Galileo Open Service Navigation Message Authentication (OSNMA) consists in a mechanism that allows the receivers to verify the authenticity of GNSS information, making sure that the data they receive are indeed from Galileo satellites and have not been modified in any way [32
]. GNSS receivers can take advantage of such capability for implementing simple but effective detection methods against several spoofing attacks [16
]. The first-ever signal-in-space transmission of Galileo OSNMA started on November 2020, and tests are currently underway in order to consolidate the service [34
5. Reference Implementation
The following paragraphs provide a description of our proposed testbed, intended to be representative of a typical synchronization distribution network. We have implemented the nodes of the testbed by means of the following components:
4 (RPi4) Model B [53
], a flexible and high-performance Single Board Computer with a well-supported set of SW libraries and tools for the Linux environment;
], an open source hat compatible with RPi4. It is based on the Septentrio’s mosaic-X5®
], a multi-band, multi-constellation GNSS module representative of the state of the art and supporting the Galileo signals (i.e., OSNMA-ready);
Infineon OPTIGA™ TPM SLI 9670 Iridium board [48
], an evaluation board with the widely used TPM2.0 chip.
In detail, Figure 5
a shows a picture of a Master node in our testbed, consisting in a RPi4 with both the mosaicHAT and the TPM stacked on top of it, while Figure 5
b presents a Slave node (i.e., a RPi4 with the TPM only).
These components are instrumental to build a highly flexible and reconfigurable testbed, thus suitable to analyze relevant attack vectors and countermeasures in a controlled and legal framework. Our testbed is also scalable, thus we can easily extend it to emulate different network topologies, potentially including a large number of nodes, but avoiding the complexities related to the operation of real PTP hardware in a synchronization distribution network.
For this purpose, Figure 6
shows a network topology based on five nodes that we will adopt in all the tests reported in next section.
The picture presents the following components, clockwise starting from the upper right corner:
A professional GNSS antenna (i.e., Tallysman®
VSP6037L VeroStar™ Full GNSS Precision Antenna plus L-band [56
]), placed on the desk for illustration purposes only, but properly mounted on the rooftop of the building during the tests;
Three RPi4 configured as Master nodes (i.e., Master 1, 2, and 3), including both a GNSS module and a TPM stacked on top of it;
Two RPi4 configured as Slave nodes (i.e., Slave 4 and 5), without a GNSS module.
All five RPi4 nodes in Figure 6
are connected to the power supply and to the same Local Area Network (LAN) by means of a switch and Ethernet cables. As far as the three Master nodes are concerned, we connected them to the same GNSS antenna through a signal splitter. Only the Master 1 is equipped with the mosaicHAT [54
], while the other two Master nodes have low cost GNSS modules (i.e., Uputronics™ Raspberry Pi GPS/RTC Expansion Board [57
] for Master 2, Adafruit Ultimate GPS HAT [58
] for Master 3). Moreover, the Master 1 is configured as the Grand Master clock for the PTP protocol, while the Master 2 acts as backup master clock and the Master 3 (i.e., the white node in the middle of Figure 6
) is used as a monitoring node. In detail, the Master 3 is capable to estimate the relative synchronization errors of the other nodes on the LAN in real time, taking advantage of the ntpq
], and to collect detailed log files, by means of a properly configured ntpd
It must be remarked that this setup is potentially suitable to a comparative performance assessment of the different GNSS modules and/or for emulating different attacks against the GNSS RF Spectrum (see Section 2
). Nonetheless, as previously highlighted in Section 1
, GNSS RF vulnerabilities are out of the scope for this paper, thus the role of the GNSS modules in our testbed is just to provide a reliable time synchronization to all the RPi4 nodes. For these reasons, the experiments presented in following section will focus only on attacks against the SW integrity and configuration of the nodes.
6. Results and Discussion
The testbed introduced in the previous section is suitable to test different SW stacks and configurations and to comparatively assess them in terms of performance and robustness. For instance, we can test both the configurations #1 and #2 as in previous Figure 2
on the Master node. In the first case, the gpsmon
utility program [60
] allows to check the behavior of gpsd
in real-time [41
]. On the other hand, the ntpq
] is usable in both configurations to monitor the status of ntpd
] and then to estimate the synchronization performance of the Master 1 in our testbed.
It is worth recalling that our testbed adopts the ntpd daemon to accurately synchronize the local clock of the Master node to the GNSS time scale, while ptpd distributes the timing information from the Master to multiple Slave nodes. Typical time distribution networks can require a remarkable amount of time (e.g., ranging from few minutes up to several days) to achieve an initial synchronization between multiple nodes. In fact, small frequency and phase corrections allow to gradually and continuously adjust (i.e., discipline) all the clocks. The required amount of time for these operations mainly depends on the quality of the local oscillators of the nodes, on the specific configuration of ntpd and ptpd, and on the application requirements in terms of synchronization accuracy and precision.
As an example, Table 1
summarizes the obtained results running both the previous configurations #1 and #2 for different time intervals (i.e., from 5 min up to 3 days). In detail, Table 1
reports offset and jitter values (in milliseconds) estimated by ntpq
for both 1PPS and NMEA outputs in configuration #1, while in configuration #2 such values are available just for 1PPS.
The 1PPS columns demonstrate that the configurations #1 and #2 result in equivalent performance after 1 h (i.e., a synchronization accuracy of the order of 1 s). Thus, we select the configuration #2 in order to simplify the SW stack and to reduce possible vulnerabilities in the Master nodes, and we will use it in the following tests.
The testbed also provides a playground to test different attacks. For instance, the network topology shown in Figure 6
is suitable to emulate specific attacks against the PTP SW integrity of the nodes, according to the previous discussion in Section 3.2
. In detail, Figure 7
reports the obtained results considering the following attacks:
An attack against the SW integrity of the ptpd daemon;
An attack against the ptpd configuration file.
The Attack 1 emulates an attacker that has gained access with superuser privileges to the two Slave nodes. The attack consists in the installation of a maliciously modified executable file on both the nodes, obtained by modifying the original source code of ptpd
]. In our test, the modified SW introduces an instantaneous time bias on all the time stamps received by each Slave node. We insert such bias in the lowest possible level of the ptpd
source code, as close as possible to the NIC hardware (i.e., by adding 12 lines of code to the net.c
source file). The instantaneous bias has an initial small magnitude, intended to be undetectable with conventional measures (e.g., on ptpd
statistics and event logs), and it gradually increases with a consistent sign over the duration of the attack, thus resulting in a frequency drift. In this way, a sufficiently long attack duration can produce arbitrarily large time offsets on the target nodes, potentially with different relative time offsets (i.e., different error magnitude and/or sign). As shown in Figure 7
a, the first test lasts for approximately one hour and begins with an initial phase in nominal conditions, where all the five nodes are correctly synchronized. Then, the attack actually starts to introduce a time bias at 14:36. In this test, we intentionally introduce a different frequency drift in the two victim nodes (i.e., 1
s/s on Slave 4 and 0.5
s/s on Slave 5) during the second part of the test. For this reason, the Slave 4 reaches a time synchronization error larger than 2 ms at the end of the test, while the Slave 5 shows an error larger than 1 ms with respect to all the other Master nodes.
On the other hand, the Attack 2 emulates a simpler scenario where we assume that the attacker is only capable to edit the ptpd
configuration file (and not its executable file). In practice, the modified configuration file on each target Slave node introduces a constant time bias with an arbitrarily large magnitude on all the time stamps received from the Master node. Such large bias can result in a time step on the victim clocks during the attack execution, potentially detectable with conventional measures (e.g., on ptpd
statistics and event logs). We emulate this attack on our testbed by setting a wrong value for one of the parameters in the ptpd
configuration file (i.e., ptpengine:offset_shift
). In this way, we introduce an error of 2 ms and 1 ms for Slave 4 and Slave 5, respectively, thus resulting in different relative time offsets, as demonstrated in Figure 7
Trusted Computing principles enables the mitigation of both these attacks. In fact, the Remote Attestation is capable to detect the unauthorized replacement of an executable file (or a shared library), when the Attestor compares the IMA Log with whitelists/blacklists. The same consideration applies for an unauthorized modification to a configuration file.
In the following example we first measure as good the executable of the ptpd daemon and its configuration file, as the measurements in the IMA log coincide with the ones in whitelist. An excerpt of the output of the command showing the IMA log is as follows:
|[email protected]:~/$ sudo cat /sys/kernel/security/ima/ascii_runtime_measurements|
|10|| ||03eb317e687cbd21e360e257b4810f8ac711fb4c|| ||ima|| ||9797edf8d0eed36b1cf92547816051c8af4e45ee|| ||boot_aggregate|
|10|| ||1110984f14fc70c87f90053612c3feaa068f66d6|| ||ima|| ||339c9d9d10d1fc25731d6f3d00b80e173e35456c|| ||/lib/systemd/systemd|
|10|| ||bc447ab6e2f476455644dbcf9187c922418f02ba|| ||ima|| ||369c4027e9b09131c6971ee963bfd37d41dc251c|| ||/lib/arm-linux-gnueabihf/ld-2.28.so|
|10|| ||e359bd4b3a5b64f125dda645958237a123fe9fe7|| ||ima|| ||9e7916b2b9232f7db4cff863a6588e10253c0285|| ||/etc/ld.so.preload|
|…|| || || || || || || || |
|10|| ||26bf9166f38fd64c452484ddc48d91c32913b53b|| ||ima|| ||77a352d6c2817ef4c6df25512f104e46fcf1d6e0|| ||/usr/local/sbin/ptpd2|
|10|| ||d52997919ea0fe1cdec53bf2546d3db3076e9f58|| ||ima|| ||b526bd78d18255929e2c2d2ccd821c47abc10912|| ||/home/pi/PTPd/ptpd2.slave.conf|
|…|| || || || || || || || |
The last two rows are related to the ptpd executable file and to its configuration file installed in the Slave 4 and Slave 5 nodes, including their full path names.
An excerpt of the whitelist file is the following:
Looking at the first two rows of the whitelist, we can appreciate that the digest values for both the configuration file and the ptpd executable are consistent with the corresponding values of the previous IMA log.
At this point, we simulate the previous Attack 1 (i.e., an unauthorized SW modification) by stopping the PTP daemon, replacing the ptpd executable with a maliciously modified version, and then running it with the nominal configuration, as follows:
These commands trigger new IMA measurements, which result in the following records appended to the IMA log:
By comparing the IMA log and the whitelist, the attack is immediately detected, as the digest for ptpd in the former is different from the new digest in the latter.
At the end of that test, we restore the original ptpd and reboot both the Slave nodes in order to return to the nominal synchronization of all the nodes. Then, we can emulate the Attack 2 (i.e., an unauthorized modification on the configuration file). First, we retrieve the Process ID (PID) of the running ptpd daemon by watching the content of its status log file, then we overwrite the original configuration file with a maliciously modified version and, finally, we send the appropriate signal (i.e., SIGHUP) to ptpd in order to force it to reload its configuration file:
As in previous attack, these commands trigger new IMA measurements, as follows:
In this case, the attack is detectable by comparing the digest of the configuration file in the IMA log with the previous value stored in the whitelist.
It is worth clarifying that, for both attacks, the detection by the Attestor can have a potential delay with respect to the actual attack initiation. Such a delay depends on the given periodicity at which the Attestor contacts the nodes to attest/verify the integrity of their software and configuration: a frequent execution of such Remote Attestation protocol allows a rapid detection of an ongoing attack, but it comes at the price of an increased computational load and network overhead. In this sense, the periodicity of the attestation procedure represents an important design parameter to be tailored to each use case in Industry 4.0 applications, trading-off security versus complexity.