# Trusted GNSS-Based Time Synchronization for Industry 4.0 Applications
## 4 Trusted Computing
### Integrity Measurement Architecture (IMA)
It calculates the digest of the AK certificate and the value of a \"soft PCR\" and verifies that it corresponds to the PCR9 value; 4. It verifies the integrity of the IMA log by recalculating the value of a \"soft PCR\" from the IMA log itself and comparing it with the value of PCR10; 5. It verifies the files included in the IMA log with the exception of the files to be excluded, (e.g., the log files) against whitelists/blacklists of digests previously built and exchanged in a trusted manner. The result of the integrity status can be: trusted if all files in the IMA log are found in whitelists; unknown if at least one file in the IMA log is not found in whitelists, but no file is found in blacklists; and untrusted if at least one file in the IMA log is found in blacklists or if any of the checks from (a) to (d) fails. 5. Finally, the Attestor closes the TLS channel and takes the appropriate action(s). Which are the appropriate action(s) depends on the specific Industry 4.0 application, and they are subject to further research. ## 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:

* Raspberry Pi(r) 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;
* mosaicHAT [54], an open source hat compatible with RPi4. It is based on the Septentrio's mosaic-X5(r) receiver [55], a multi-band, multi-constellation GNSS module representative of the state of the art and supporting the Galileo signals (i.e., OSNMA-ready);
* Infineon OPTIGAT(tm) TPM SLI 9670 Iridium board [48], an evaluation board with the widely used TPM2.0 chip. In detail, Figure 5a 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 5b 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 con

Figure 5: Picture of the Master clock node (**a**) and Slave clock node (**b**). trolled 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., [PERSON](r) VSP6037L VeroStar(tm) 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(tm) 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.