# Trusted GNSS-Based Time Synchronization for Industry 4.0 Applications
## 4 Trusted Computing
### Integrity Measurement Architecture (IMA)
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 utility [59], and to collect detailed log files, by means of a properly configured ntpd daemon [42]. 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. Figure 6: Picture of the full testbed, configured with three Master nodes and two Slave 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 utility [59] is usable in both configurations to monitor the status of ntpd[42] 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 1 PPS and NMEA outputs in configuration #1, while in configuration #2 such values are available just for 1 PPS. The 1 PPS 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 \(\upmu\)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:

1. An attack against the SW integrity of the ptpd daemon;
2. An attack against the ptpd configuration file.