# Trusted GNSS-Based Time Synchronization for Industry 4.0 Applications
## 4 Trusted Computing
### Integrity Measurement Architecture (IMA)
\begin{table}
\begin{tabular}{l r r r r r} \hline \hline \multicolumn{2}{c}{**Obtained Outputs**} & \multicolumn{2}{c}{**1 PPS**} & \multicolumn{2}{c}{**NMEA**} \\
**Duration** & **Configuration** & **Offset** & **Jitter** & **Offset** & **Jitter** \\ \hline
5 min & \#1 & \(-\)4.224 & 1.106 & \(-\)4.477 & 1.147 \\  & \#2 & \(-\)3.636 & 0.896 & - & - \\
10 min & \#1 & 0.038 & 0.022 & \(-\)0.306 & 0.135 \\  & \#2 & 0.032 & 0.018 & - & - \\
1 h & \#1 & 0.001 & 0.001 & 0.190 & 0.130 \\  & \#2 & \(-\)0.001 & 0.001 & - & - \\
3 days & \#1 & 0.001 & 0.001 & 1.287 & 0.182 \\  & \#2 & \(-\)0.001 & 0.001 & - & - \\ \hline \hline \end{tabular}
\end{table} 
Table 1: Obtained time offset and jitter values (in ms) in different configurations. 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[46]. 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 7a, 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 us/s on Slave 4 and 0.5 us/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

Figure 7: Obtained results on the testbed during the first attack against the software integrity (**a**) and the second attack against the configuration of the Precision Time Protocol (**p**TP) daemon (**b**). 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 pptpd statistics and event logs). We emulate this attack on our testbed by setting a wrong value for one of the parameters in the pptpd configuration file (i.e., pptengine: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 7b. 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 pptpd daemon and its configuration file, as the measurements in the IMA log coincide with the ones in whitelist.